[mythtv] XvMC VLD Decoding stuttering problems on some videos

[Terry Barnaby]

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

Ah is it that the OSD is now always drawn in MythTv ?
It appears that it is always drawn on my system causing the large CPU
usage. Setting the UseChromaKeyOSD=1 seems to reduce CPU usage
dramatically ....

Terry