[mythtv] [PATCH] Re: XvMC VLD Decoding stuttering problems on some videos

Terry Barnaby terry1 at beam.ltd.uk
Fri Sep 29 08:56:48 UTC 2006

>>Enclosed is the current patch. It is just one at the moment, but it is
>>quite small so easy to split. I will split it down and put them in the
>>Trac system when I have tested it a bit more ...
> I've attached an alternate patch to Trac ticket #1842.  It accomplishes
> basically the same thing by making the decoding thread real-time with a
> thread priority below the display thread, and changing the real-time
> thread scheduler to round-robin.  (It's enabled when the "Realtime
> Decoding" setup option is selected.)  My next plan was to split it out
> to a separate configuration option.  Is this method perferred over renicing?
> The downside, of course, is that another real-time thread is another set
> of opportunities for the system to hang (especially with a corrupted
> stream.)
> The patch on the above ticket also changes the number of XvMC surfaces
> for VLD playback to 12 (from 16), which (in combination with the RT
> change) fixes VLD playback on my CN400-based system.  I will split the
> two out into separate patches shortly...
> Brian
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

I think it would be better to stick to the nice(-10).
There is a lot of code running in the Decoder thread, including all of 
the libavformat/libavcodec stuff all of which could cause issues when 
running as a privileged real-time process.
Also the Decoder thread does not need to be as "real-time" as the 
display thread as it has a few output buffers giving about 240ms of leeway.


More information about the mythtv-dev mailing list