[mythtv] XvMC VLD Decoding stuttering problems on some videos

[Terry Barnaby]

Terry Barnaby wrote:
> 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
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Some current status of where I am in tracking down this problem.
I think the problem is basically the fact that the decoder thread is not 
getting enough processor time. If I set the decoder thread to a nice of 
-10 in NuppelVideoPlayer::StartPlaying() the prebuffering problem goes away.

What I think is happening is:
1. There is some issue in the Display thread. This is taking about 40% 
of the CPU with some jumps to 60%. The time taken appears to be in the 
"if(yuv_need_copy)" section and the videoOutput->DoneDisplayingFrame()
function call.

2. Fedora Core 5 has a Linux timer tick (HZ) of 100Hz by default thus a 
normal minimum task run time can be 10ms.

3. When the Display thread is not running (40% of the time) then all 
other system tasks including the other MythTv threads need to run. The 
decode thread is just one of these but it needs about 10% of the CPU.
As it is running quite hard it is probably backed off by the system 
scheduler in favor of the other processes at the same priority level.
With a XvMC system the decoder thread has a limited number of buffers 
(about 240ms worth on a XvMCVLD and less on an XvMC Nvidia system) and 
so it cannot afford to wait to long before running.

So, if my reasoning is right, then it would be worth setting the decoder 
thread to a nice value just below the display thread (or at least a good 
-ve value). This should work even if the display thread is a real-time 
process. It may also be worth raising the priority of the 
RingBuffer::ReadAheadThread().

However, we also need to see what is causing the large CPU usage in the 
Display thread. This, I believe, is why we have started seeing this 
problem in the later MythTv releases ...

Cheers


Terry