[mythtv] XvMC VLD Decoding stuttering problems on some videos

Terry Barnaby terry1 at beam.ltd.uk
Tue Sep 26 21:39:28 UTC 2006

Isaac Richards wrote:
> On Monday 25 September 2006 4:12 pm, Terry Barnaby wrote:
>> Hi, a bit stuck now.
>> Basically the X11L lock for XvMCPutSlice2 in VideoOutputXv::DrawSlice
>> occasionally take a long time to lock (> 300ms). This causes the video
>> output stage to run out of decoded video frames and hence a Prebuffering
>> pause.
>> It looks like the thread holding the lock is doing the XSync in
>> VideoOutputXv::Show. However the XSync call never takes longer than a
>> few ms and hence should not be holding up the XvMCPutSlice2 for 300ms.
>> So, could it be that the display output thread (which is running
>> real-time ??) is running hard and not letting the decoder thread get a
>> look in occasionally ??
> Could be.  Any idea which lock it's waiting on when it's stuck for that long?
> Another thing I've been pondering is moving the actual video decode to the 
> output thread - keeping the demux separate as it is currently.  Should make 
> it possible to get rid of a _lot_ of that locking..
> Isaac
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Hi Isaac,

The XvMCPutSlice2 lock was actually waiting on the VideoOutputXv::Show 
XSync lock, as stated. However the XSync call never takes longer than a
few ms so something else is holding the system up.

I've tried turning off the real-time mode of the display thread to no 
I've disabled the use of X11L/X11U around the XvMCPutSlice2 (These are 
not actually needed as XvMCPutSlice2 goes through DRM and not through 
the standard X11 interface). The effective XvMCPutSlice2 call still can 
take a long time occassionly.

It appears that some thread is running hard in MythTv at the time the 
XvMCPutSlice2 call needs to run on occassion. MythTv is using 60% CPU 
which is rather high (I would expect about 20% with this system). I've 
tried using OProfile to find out the culprit and I do see a high usage 
of memcpy (15%) however the --callgraph option of OProfile does not seem 
to work with the Via CPU and so I cannot see which MythTv function is 
using the memcpy so heavily ...

I am trying to track down the code that is running heavily, any ideas ?



More information about the mythtv-dev mailing list