[mythtv-users] Mac OS X choppy playback at high display resolutions, such as 1080p

[Todd Ignasiak]

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+  
displays.
  - When the problem is seen, Scaling + color conversion takes a  
large percentage of CPU, but function is absent in normal playback  
scenarios.
  - 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:

41.7% YUV422_UC_ToRGB32BitColorBGRA
7.7% ml_set_interrupts_enabled
7.0% mmx_i420_2vuy
6.0% mpeg_decode_mb
4.7% linearBlendMMX

Obviously, YUV422_UC_ToRGB32BitColorBGRA is the big consumer here.    
The chain of function calls leading to YUV422 looks like:

VideoOutputQuartzView::Show()
DecompressSequenceFrameWhen
.... (snipped) ...
YUV422CodecComponentDispatch
ScalingCodecComponentDispatch
... (snip) ...
PrepareForBlitThenDoBlit
FinalGlueBeforeTheBlit
YUV422_UC_ToRGB32BitColorBGRA


Turning off "Scale video as necessary" causes  
YUV422_UC_ToRGB32BitColorBGRA to be removed from the CPU user list  
completely.
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  
changed was:

     DeleteQuartzBuffers();

     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;

     CreateQuartzBuffers();


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  
like:
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...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20071007/90da88a6/attachment.htm