[mythtv] XvMC VLD Decoding stuttering problems on some videos

[Terry Barnaby]

Terry Barnaby wrote:
> 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
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Sorry I meant in 1. above videoOutput->ProcessFrame() function instead 
of "if(yuv_need_copy)" section. In fact removing this call reduces the 
Display thread CPU usage to around 6% and thus overall CPU usage to 
about 20% which I would expect for MythTv running on a Via M10K box 
using XvMC VLD.

Cheers


Terry