[BDPNA]

With the latest SVNs, over the past couple of weeks, I've been noticing a lot of stuttering in video on my Mac Mini. Or whatever you call it - Some people call it judder, jitter, hiccups, choppy. I've got one of the older models, but still a C2D and 4 GB of RAM in there.

As per usual, it is most common under higher bitrates in 1080p, around 20+ FPS, resulting in a choppy skipping forward motion of the video, and normally reserved to more fluid moments with a lot of motion on the screen. Audio seems fine.

I realize some of this might have to do with the encode of the mkv file itself, but also want to do my best to get the most out of the system. It seems that some users have tried Plex and had better results (I plan to do that as well) and also am going to copy a file locally to the machine and compare, to see if the network is a bottleneck (I don't expect but you never know).

Aside from turning Vertical Sync on ALWAYS, what other video-related settings might I be missing that I could use to benefit the video? I am streaming over a wired network, yet I see no cache option anywhere (I recall this option being visibile on older XBMC builds). Is this something you need to set in a config file manually, and if so, what values might stop the dropped frames?

If anyone else is experiencing choppy video on their mini with the latest SVN builds, maybe we can talk about it here and find some solutions. I know there was a thread like this for the Apple TV, but I figured maybe us Mini owners under OSX could talk as well.

BTW my mini was one of the last models with the Intel 950 for video, so it's looking like GPU acceleration won't be possible, so no Linux for me.

[jmarshall]

Other than dropping the quality of the decoding via the advancedsettings.xml option <skiploopfilter>, there is not a lot that you can on your system. Perhaps telling us what settings you have in Settings->Video-Player might be useful, however. Some of the A/V sync options may take more CPU than others.

Some 1080p h264 streams are simply so difficult to decode, that your C2D is just too slow for them. I have a 1.83GHz Mini similar to yours, and it definitely struggles with full-frame 1080p content. Non-full frame (eg 1920x800) tends to work OK though.

Cheers,
Jonathan

[BDPNA]

I'll have to research skiploopfilter I guess and see where I can go. I'll check my settings as well. I am definitely running full screen 60hz 1920x1080 just as you are on the same type machine...Hopefully there's a way around the bottleneck.

Do you have any of the sync options turned on? I think I just turned them off in the hopes it might save some resources.

Thanks a lot for the reply.

[jmarshall]

I have them turned off - I doubt they'll use much resources anyway, other than the one that resamples audio (which obviously you don't want with passthrough).

Unfortunately there's nothing else that can be done, other than awaiting some small miracles from the ffmpeg guys.

Cheers,
Jonathan

[mmmfishies]

I often hear about people having good luck with 720p/1080i H.264 video on a Mac Mini and I'm not having the same experience. I'm using an Hauppauge HDPVR 1212 to record 1080i and 720p video in H.264 with AC3 audio at some pretty modest bitrates - 2.5-8Mbits/s. I have a ~2007 vintage 1.83GHz C2D Mac Mini with 1GB of RAM, connected to my TV using the DVI connector.

I've tried adjusting a bunch of settings, including much of what's recommended on this forum, and I can't seem to play back H.264 video without dropping enough frames to cause skipping in the video. I've noticed that the container can make a difference - Transport Steam gives the worst performance, MP4 is the best, and MKV seems to be somewhere in the middle. I built XBMC using the latest SVN as of last night, and I see CPU usage in the neighborhood of ~130% when playing back typical clips (cores fairly evenly loaded). My 2.8GHz C2D MBP is able to play the clip flawlessly (~100% CPU), so I don't think there's anything wrong with it.

Thinking that there may be something weird with my build, I tried the stock build with no better results.

Would adding additional RAM help? I believe that some of that would be allocated for video memory, but I don't know if that would do anything for performance. For what it's worth, I see some suspicious lines in the log (see below) that say the codec "didn't consume the full packet". I see the same behavior both from the local hard drive and over a gigabit network (logs below were local). "skiploopfilter" definitely seems to improve things, but I'd prefer to make sure that everything else is in order before affecting the playback quality.

Here's some more info:

OSX Version: 10.5
SVN Revision: 21930
FULL Debug Log: http://pastebin.com/m2a589a21
Skin name: PM3.HD

Thanks,
Rob

[davilla]

I often hear about people having good luck with 720p/1080i H.264 video on a Mac Mini and I'm not having the same experience. I'm using an Hauppauge HDPVR 1212 to record 1080i and 720p video in H.264 with AC3 audio at some pretty modest bitrates - 2.5-8Mbits/s. I have a ~2007 vintage 1.83GHz C2D Mac Mini with 1GB of RAM, connected to my TV using the DVI connector.

I've tried adjusting a bunch of settings, including much of what's recommended on this forum, and I can't seem to play back H.264 video without dropping enough frames to cause skipping in the video. I've noticed that the container can make a difference - Transport Steam gives the worst performance, MP4 is the best, and MKV seems to be somewhere in the middle. I built XBMC using the latest SVN as of last night, and I see CPU usage in the neighborhood of ~130% when playing back typical clips (cores fairly evenly loaded). My 2.8GHz C2D MBP is able to play the clip flawlessly (~100% CPU), so I don't think there's anything wrong with it.

Thinking that there may be something weird with my build, I tried the stock build with no better results.

Would adding additional RAM help? I believe that some of that would be allocated for video memory, but I don't know if that would do anything for performance. For what it's worth, I see some suspicious lines in the log (see below) that say the codec "didn't consume the full packet". I see the same behavior both from the local hard drive and over a gigabit network (logs below were local). "skiploopfilter" definitely seems to improve things, but I'd prefer to make sure that everything else is in order before affecting the playback quality.

Here's some more info:

OSX Version: 10.5
SVN Revision: 21930
FULL Debug Log: http://pastebin.com/m2a589a21
Skin name: PM3.HD

Thanks,
Rob

Make triple sure that your Hauppauge HDPVR 1212 is running the latest firmware. Previous firmware version had a bug that would effect the display pts (timing). This would cause all sorts of frame drops and skips.

[mmmfishies]

Make triple sure that your Hauppauge HDPVR 1212 is running the latest firmware. Previous firmware version had a bug that would effect the display pts (timing). This would cause all sorts of frame drops and skips.

Thanks for the quick response. I installed version 1.5.6 of the Windows drivers a while ago and it updated the firmware to 1.18 (May 7, 2009). EyeTV confirms that, and I don't see anything newer at Hauppauge.

[davilla]

"didn't consume the full packet" is from the render trying to drop frames and hurry up. The flags to ffmpeg cause it to not consume the full demuxed packet.

It's a symptom, not the cause.

A 1.83GHz C2D Mac Mini should be able to handle 720p from the HDPVR. The AppleTV can almost do it but needs skiploopfilter enabled.

I've always been able to handle HDPVR 720p on a 2GHz C2D MacBook. I can try my 1.6GHz CD MacMini the next time I boot into OSX, it's a test bed right now for a secret project

[mmmfishies]

"didn't consume the full packet" is from the render trying to drop frames and hurry up. The flags to ffmpeg cause it to not consume the full demuxed packet.

It's a symptom, not the cause.

A 1.83GHz C2D Mac Mini should be able to handle 720p from the HDPVR. The AppleTV can almost do it but needs skiploopfilter enabled.

I've always been able to handle HDPVR 720p on a 2GHz C2D MacBook. I can try my 1.6GHz CD MacMini the next time I boot into OSX, it's a test bed right now for a secret project

Now you've got me interested in your secret project

In any case, my current video settings are here. Does anything there look amiss?

[BDPNA]

I'm just bummed that my 1.83 C2D mini with 4GB RAM can't handle 1080p as I expected that it could. It's to the point where it's hit or miss, it will play some 1080p but you never know when dropped frames are going to show up (usually during the best scenes of a film where a lot of action is happening, perfectly bad timing).

So far 720p seems pretty rock solid to me. Though looking at mmmfishies settings, I don't think I have any of the clock sync turned on right now, is that recommended?

If only we could get hardware acceleration. I am tempted to get a new mini just to try the Linux port with the Nvidia graphics acceleration boost though I think even that doesn't help with 1080 mkv at this stage. Im afraid the Intel 950 and this version of the mini has been pushed as far as it can, CPU-wise. 720p mkv seems to be the limit, in general, unless it's a very low-encoded 1080p which doesn't really even matter at that point.

[Z3rO]

If only we could get hardware acceleration. I am tempted to get a new mini just to try the Linux port with the Nvidia graphics acceleration boost though I think even that doesn't help with 1080 mkv at this stage.

The Killa sample runs with no dropped frames in this setup. So it DOES help.

[BDPNA]

Z3rO - No way, that's awesome. What are the specs on your mini that does this?

I am going to be very tempted to sell my current Mini and upgrade to one of the newest Minis with nvidia on board if it can handle 1080p that well.

Details? Please do tell! I'm all ears.

[Z3rO]

Z3rO - No way, that's awesome. What are the specs on your mini that does this?

I am going to be very tempted to sell my current Mini and upgrade to one of the newest Minis with nvidia on board if it can handle 1080p that well.

Details? Please do tell! I'm all ears.

http://forum.xbmc.org/showthread.php?p=3...post363436

That thread is a good read btw.