[mythtv-users] Mac OS X choppy playback at high display resolutions, such as 1080p
todd.ignasiak at gmail.com
Mon Oct 8 00:52:42 UTC 2007
I have seen several reports of people having problems with high
resolution displays, commonly on 1080p displays. But, I could never
reproduce it on my systems. I recently got access to a new iMac with
a 1920x1200 display and was able to see the problem, and I wanted to
see if anyone else has done any debugging on this.
I'll include a lot of details below.. the executive summary is:
- Choppy playback of 1080i video with Mac front-end on 1080P+
- When the problem is seen, Scaling + color conversion takes a
large percentage of CPU, but function is absent in normal playback
- Quicktime may be kicking scaling to a software function rather
than normal hardware scaling/color conversion, when this issue is seen.
Problem details: Mac OS X front-end, "Scale Video as Needed" turned
ON in setup,1080i video. Playback of video generates a very high CPU
load, and the video is very choppy as if it is skipping many frames.
This is seen on several versions, including 0.20.2 and 0.21svn.
I used Apple's Shark profiling tool to see where the CPU was being
used when the problem was happening. The top users were:
Obviously, YUV422_UC_ToRGB32BitColorBGRA is the big consumer here.
The chain of function calls leading to YUV422 looks like:
.... (snipped) ...
... (snip) ...
Turning off "Scale video as necessary" causes
YUV422_UC_ToRGB32BitColorBGRA to be removed from the CPU user list
Also, if I run MythFrontend on my MacBook Pro, where the problem
doesn't happen, I don't see YUV422_UC_ToRGB32BitColorBGRA whether
scaling is on or off.
Some other threads mentioned modifying videoout_quartz.cpp to modify
the video / aspect-ratio detection, so I tried that. The code
data->srcWidth = input_size.width();
data->srcHeight = input_size.height();
data->srcAspect = aspect;
data->srcMode = db_aspectoverride;
+ if ( data->srcWidth == 1920 && data->srcHeight == 1088 )
+ data->srcHeight = 1080;
Once I changed that, the first few programs I tried played back
flawlessly, and YUV422_UC_ToRGB32BitColorBGRA was no longer in the
list in Shark. But, in further testing with an 0.20.2 front-end, the
problem still showed up with some 1080i programs. (In my 0.21svn
version the few programs I tried worked fine. But, that was a test
back-end, so I had few programs to try it with. I modified the
0.20.2 front-end and tried with my more plentiful program list on
that back-end, and found that many 1080i programs still showed the
problem, by several worked fine with the hack in place.)
CPU Usage in good video playback (lower resolution displays, with
scaling turned off, or on some programs with the hack in place) looks
22.2% mach_kernel ml_set_interrupts_enabled
9.7% mythavcodec mpeg_decode_mb
8.7% commpage __longcopy
8.6% mythtv mmx_yuv420_2vuy
5.5% mythavcodec ff_simple_idct_add_mmx
So, my guess is that there is an issue in some 1080i programs, or the
QuickTime library usage, that causes the scaling and color conversion
to be kicked to a software function. But, I know nothing about
QuickTime, so that's just a guess.
Anyone else got any debugging info about this, or QuickTime
experience with similar issues?
Also note: Some previous reports of this problem on a Mac Mini
thought it was because the Mini or the Mini's integrated GPU was not
powerful enough. Most of my testing was on a new iMac (2.4GHz
Core2Duo, 2GB RAM, ATI GPU). So, the issue is not just a power limit.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users