[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
effect.
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 ?
Cheers
Terry
More information about the mythtv-dev
mailing list