[mythtv] XvMC VLD Decoding stuttering problems on some videos

[Terry Barnaby]

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

The CPU usage in the Display thread appears to be due to the OSD code in 
VideoOutputXv::ProcessFrameXvMC(). Does any one know how this works and 
perhaps pass an eye over the code to see why it is running during normal 
video display ?

Cheers

Terry