Mailing List Archive

XvMC VLD Decoding stuttering problems on some videos
Hi,

I have been using MythTv 0.16 with little problem for a long time but
now have "upgraded" to 0.20. However I am having problems with the XvMC
VLD decoding. Basically the system works but there is quite a lot of
stuttering in the video and audio on some stored video.

My systems client is a Via M10K system running a relatively virgin
Fedora Core 5 installation. The server is also running Fedora Core 5 and
has a couple of DVB-T tuner cards.

Xine is running fine with about 11% CPU usage so the hardware/OS/drivers
appear to be fine.

I have been doing some testing using the "mythtv" application with a
stored file. With some videos there is no stuttering: see Works
attachment but with some videos there is a lot of stuttering: see
Glitches. With the working video the system uses about 40% CPU and with
the bad video about 60% CPU. These are rather high CPU figures compared
with Xine.

Does anyone have any clues on where to look to solve this problem ?

Cheers


Terry
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
On Fri, Sep 22, 2006 at 08:42:29PM +0100, Terry Barnaby wrote:
>
> Does anyone have any clues on where to look to solve this problem ?
>
>

Right this is interesting

Working:
> 2006-09-20 07:14:15.557 XvMCSurfaceTypes::find(w 544, h 576, chroma 1, vld 1, idct 0, mpeg2, sub-width 0, sub-height 0, disp, p<= 68, 680 <=p, port, surfNum)

Not working:
> 2006-09-20 07:15:52.405 XvMCSurfaceTypes::find(w 720, h 576, chroma 1, vld 1, idct 0, mpeg2, sub-width 0, sub-height 0, disp, p<= 68, 680 <=p, port, surfNum)


So the difference between the streams is 544x576 vs 720x576.


Stuart

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
Stuart Auchterlonie wrote:
> On Fri, Sep 22, 2006 at 08:42:29PM +0100, Terry Barnaby wrote:
>> Does anyone have any clues on where to look to solve this problem ?
>>
>>
>
> Right this is interesting
>
> Working:
>> 2006-09-20 07:14:15.557 XvMCSurfaceTypes::find(w 544, h 576, chroma 1, vld 1, idct 0, mpeg2, sub-width 0, sub-height 0, disp, p<= 68, 680 <=p, port, surfNum)
>
> Not working:
>> 2006-09-20 07:15:52.405 XvMCSurfaceTypes::find(w 720, h 576, chroma 1, vld 1, idct 0, mpeg2, sub-width 0, sub-height 0, disp, p<= 68, 680 <=p, port, surfNum)
>
>
> So the difference between the streams is 544x576 vs 720x576.
>
>
> Stuart
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Yes, it is a different resolution. It is probably also from a different
DVB-T channel and so has probably other MPEG differences.

I have further tracked this down to the system occasionally taking a
long time (> 200ms) in XvMCPutSlice2(). So this points to the XvMCVLD
library/via X driver/hardware although this does not tally with the fact
that xine plays the same video file fine ...

I will investigate a bit further.

Terry
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
Terry Barnaby wrote:
> Stuart Auchterlonie wrote:
>> On Fri, Sep 22, 2006 at 08:42:29PM +0100, Terry Barnaby wrote:
>>> Does anyone have any clues on where to look to solve this problem ?
>>>
>>>
>> Right this is interesting
>>
>> Working:
>>> 2006-09-20 07:14:15.557 XvMCSurfaceTypes::find(w 544, h 576, chroma 1, vld 1, idct 0, mpeg2, sub-width 0, sub-height 0, disp, p<= 68, 680 <=p, port, surfNum)
>> Not working:
>>> 2006-09-20 07:15:52.405 XvMCSurfaceTypes::find(w 720, h 576, chroma 1, vld 1, idct 0, mpeg2, sub-width 0, sub-height 0, disp, p<= 68, 680 <=p, port, surfNum)
>>
>> So the difference between the streams is 544x576 vs 720x576.
>>
>>
>> Stuart
>>
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev@mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
> Yes, it is a different resolution. It is probably also from a different
> DVB-T channel and so has probably other MPEG differences.
>
> I have further tracked this down to the system occasionally taking a
> long time (> 200ms) in XvMCPutSlice2(). So this points to the XvMCVLD
> library/via X driver/hardware although this does not tally with the fact
> that xine plays the same video file fine ...
>
> I will investigate a bit further.
>
> Terry
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Hi, got a bit further, it was'nt XvMCPutSlice2() taking > 200ms it was
the X11L performed as part of X11S. So something has locked the internal
MytTv XServer lock but not released it ....
Any ideas ? Will test a bit further.

Terry

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
Terry Barnaby wrote:
> Terry Barnaby wrote:
>> Stuart Auchterlonie wrote:
>>> On Fri, Sep 22, 2006 at 08:42:29PM +0100, Terry Barnaby wrote:
>>>> Does anyone have any clues on where to look to solve this problem ?
>>>>
>>>>
>>> Right this is interesting
>>>
>>> Working:
>>>> 2006-09-20 07:14:15.557 XvMCSurfaceTypes::find(w 544, h 576, chroma 1, vld 1, idct 0, mpeg2, sub-width 0, sub-height 0, disp, p<= 68, 680 <=p, port, surfNum)
>>> Not working:
>>>> 2006-09-20 07:15:52.405 XvMCSurfaceTypes::find(w 720, h 576, chroma 1, vld 1, idct 0, mpeg2, sub-width 0, sub-height 0, disp, p<= 68, 680 <=p, port, surfNum)
>>> So the difference between the streams is 544x576 vs 720x576.
>>>
>>>
>>> Stuart
>>>
>>> _______________________________________________
>>> mythtv-dev mailing list
>>> mythtv-dev@mythtv.org
>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>> Yes, it is a different resolution. It is probably also from a different
>> DVB-T channel and so has probably other MPEG differences.
>>
>> I have further tracked this down to the system occasionally taking a
>> long time (> 200ms) in XvMCPutSlice2(). So this points to the XvMCVLD
>> library/via X driver/hardware although this does not tally with the fact
>> that xine plays the same video file fine ...
>>
>> I will investigate a bit further.
>>
>> Terry
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev@mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
> Hi, got a bit further, it was'nt XvMCPutSlice2() taking > 200ms it was
> the X11L performed as part of X11S. So something has locked the internal
> MytTv XServer lock but not released it ....
> Any ideas ? Will test a bit further.
>
> Terry
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

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 ??

Any ideas ??

Terry
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
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@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
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@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@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
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@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@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@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
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@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@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@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@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
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@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@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@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@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@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
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@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@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@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@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@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

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
On Wednesday 27 September 2006 6:01 pm, Terry Barnaby wrote:
> 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 ....

It's not supposed to be drawn _all_ the time, just when there's something
visible..

Isaac
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
Isaac Richards wrote:
> On Wednesday 27 September 2006 6:01 pm, Terry Barnaby wrote:
>> 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 ....
>
> It's not supposed to be drawn _all_ the time, just when there's something
> visible..
>
> Isaac
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Well its the "interactive" OSD that is being displayed all of the time.
Not sure why this is, I note my video has a DVB_SUBTITLE stream ....

Terry
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
Terry Barnaby wrote:
> Isaac Richards wrote:
>> On Wednesday 27 September 2006 6:01 pm, Terry Barnaby wrote:
>>> 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 ....
>> It's not supposed to be drawn _all_ the time, just when there's something
>> visible..
>>
>> Isaac
>> _______________________________________________
>> mythtv-dev mailing list
>> mythtv-dev@mythtv.org
>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
> Well its the "interactive" OSD that is being displayed all of the time.
> Not sure why this is, I note my video has a DVB_SUBTITLE stream ....
>
> Terry
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Ok, I think I have now fixed the problem. The interactive TV OSD was
enabled even if "EnableMHEG" was not set to 1.
I assume that the interactive TV OSD needs to be displayed all the time
when "EnableMHEG" is set to 1 ?

I will create a Trac patch that does the following:
1. Disables interactive TV OSD when "EnableMHEG" is 0.
2. Sets the decoder thread's nice value to -10.
3. Adds a configuration option for "ChromaKeyOSD" to it is easy for
people to use this feature on XvMC VLD systems.

Terry
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
On 09/28/06 02:51, Terry Barnaby wrote:

>3. Adds a configuration option for "ChromaKeyOSD" to it is easy for
>people to use this feature on XvMC VLD systems.
>
>

The reason this is not currently a setting is because Daniel is not yet
finished with the code (although the mythtv-vid branch's chroma-key code
is nearly complete). I'm sure he'll put in a setting when he feels it's
ready (probably after merging mythtv-vid into trunk).

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
Terry Barnaby schrieb:
> 2. Sets the decoder thread's nice value to -10.
>
Can you post a patch for this one, please. Maybe I will get ride of my
random prebuffering pauses with it applied.

Kristian.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
On Thu, Sep 28, 2006 at 02:28:29PM +0200, Kristian Kalweit wrote:
> Date: Thu, 28 Sep 2006 14:28:29 +0200
> From: Kristian Kalweit <kalweit@exorpro.de>
> Subject: Re: [mythtv] XvMC VLD Decoding stuttering problems on some videos
> To: Development of mythtv <mythtv-dev@mythtv.org>
>
> Terry Barnaby schrieb:
> > 2. Sets the decoder thread's nice value to -10.
> >
> Can you post a patch for this one, please. Maybe I will get ride of my
> random prebuffering pauses with it applied.
>

Can you please post all the patches (separately would be nice, but we'll
take what we can get). I have a severe stuttering problem with nVidia
XvMC at all resolutions, but can do 1080i with Bob de-int almost
flawlessly with the standard decoder.

Pat
--

Patrick Ouellette pat@flying-gecko.net
kb8pym@arrl.net Amateur Radio: KB8PYM
Living life to a Jimmy Buffett soundtrack
"Crank the amp to 11, this needs more cowbell - and a llama wouldn't hurt either"
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
On Thursday 28 September 2006 2:51 am, Terry Barnaby wrote:
> Ok, I think I have now fixed the problem. The interactive TV OSD was
> enabled even if "EnableMHEG" was not set to 1.
> I assume that the interactive TV OSD needs to be displayed all the time
> when "EnableMHEG" is set to 1 ?

It wasn't just the ITV OSD set that was always displayed on my machine - one
of the other CC sets was always on as well. I checked in some better
detection code for that stuff -- could people test, please (without any
additional patches)?

Isaac
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
Isaac Richards wrote:
> On Thursday 28 September 2006 2:51 am, Terry Barnaby wrote:
>> Ok, I think I have now fixed the problem. The interactive TV OSD was
>> enabled even if "EnableMHEG" was not set to 1.
>> I assume that the interactive TV OSD needs to be displayed all the time
>> when "EnableMHEG" is set to 1 ?
>
> It wasn't just the ITV OSD set that was always displayed on my machine - one
> of the other CC sets was always on as well. I checked in some better
> detection code for that stuff -- could people test, please (without any
> additional patches)?
>
> Isaac
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Hi Isaac,

Yes, your patch basically fixes the OSD issue.

I think it would be worth making the decoder thread a higher priority
than base system processes as well however, especially using XvMC as
there are limited output buffers to use and so little leeway in time
available. If some other system processes get started it is not easy for
the decoder thread to keep up with the real-time display thread. (Note
my simple nice(-10) patch will also set the RingBuffer::ReadAheadThread
and AudioOutputBase::OutputAudioLoop's to -10 when watching liveTv.
Maybe these should be left alone, if so this would need improving).

After doing the above, my system runs smoothly watching video's but
still has a few pre-buffering pauses when watching live TV.
So there are still some issues here. The CPU usage of the Video Display
thread leaps up when the pre-buffering pauses occur so I suspect some
other issues in the Display thread.

In general it appears that to much is being done in the Display thread,
especially as it is a real-time process. Maybe it would be worth
simplifying this to just the GetFrame,MergeOSD,WaitforSync,Display
functionality and not do so much OSD work ?

Terry
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: XvMC VLD Decoding stuttering problems on some videos [ In reply to ]
Terry Barnaby schrieb:
>
> I think it would be worth making the decoder thread a higher priority
> than base system processes as well however, especially using XvMC as
> there are limited output buffers to use and so little leeway in time
> available. If some other system processes get started it is not easy for
> the decoder thread to keep up with the real-time display thread. (Note
> my simple nice(-10) patch will also set the RingBuffer::ReadAheadThread
> and AudioOutputBase::OutputAudioLoop's to -10 when watching liveTv.
> Maybe these should be left alone, if so this would need improving).
>
>

Where do make the nice(-10) for the AudioOutput? If I only make the
nice(-10) for the decoder (see your posted patch) I get heavy sound lags
at prebuffering pauses.

Kristian.
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev