[MPlayer-dev-eng] Adding threaded functionality to mplayer NODAEMON

[Nico Sabbi]

Roberto Ragusa wrote:

>On Sun, 12 Sep 2004 09:32:49 +0900
>Attila Kinali <attila at kinali.ch> wrote:
>
>  
>
>>DO NOT SEND MAILS DIRECTLY TO DEVELOPERS!
>>We all read this list!
>>    
>>
>
>Sorry, I reply personally and CC the list by habit.
>
>Thank you for your detailed reply.
>The discussion on threads has been pratically settled through the
>mail replies from last days.
>
>The summary I can make is that L2 cache thrashing is (according to you
>developers, who have direct experience) really important for performance.
>I pointed out that a frame is almost the entire size of the cache (if not bigger),
>so the filtering stage will not have hot caches after the decoding stage, but
>apparently slice by slice processing in mplayer is more common than I thought.
>
>  
>
>>Is it possible to extract a clock from the DVB stream, w/o relying on
>>the bandwidth ? If so, this should be used to adjust MPlayer's
>>reference. Ie implementing a PLL in software.
>>    
>>
>
>It is possible, the PCR pid (usually equal to the video pid) has the timings.
>Real set top boxes use that reference for buffer management syncronization and
>I suppose they are also able to use it to clock the TV encoder chip, which
>in turns clocks the beam of your TV.
>In this way you watch television at 25.001 fps or 24.999 fps, exactly how
>the broadcaster wants.
>
>The buffer fill management is easy, but I don't know how it can be implemented
>in mplayer (as everything depends on audio, I messed with the quantity of
>audio samples, and it worked).
>
>  
>

when encoding the PCR (or the SCR) on the muxer side, is it necessary that
[PS]CR increase linearly or can it drift at will?
I'm preparing a patch for the mpeg muxer, and calculating SCR is a real 
nightmare