[MPlayer-dev-eng] Do decoders have a stream ?

[Magnus Damm]

Hi again,

> > > > So what about implementing decoding ahead in one process into G2 ;-)
> > > 
> > > cannot be done unless your hardware supports timed display of frames
> > 
> > Huh, cannot be done? =)
> > I'm not an expert on the subject, but wouldn't it be possible to have
> > a goal of always keeping an adjustable number of frames decoded in 
> > separate fifos for {video|audio|sub|whatever}, and let the "regular" 
> > timer loop decide when to display? (replace with hardware dependent 
> > timing code when available)  Then prioritize to fill up the audio 
> > fifo first. And then you have the framedropping, it's done ahead of 
> > time when the video fifo is filled up.
> 
> this can be done, but what is the use of it?
> the goal of decoding ahead is to use the time now spent in sleep() to
> decode next frame(s). and it's coming from definition that you need 2
> threads (one for display frame from fifo at the right time, can be done by
> some hw, and one for decoding the frames (filling the fifo)).
 
Two threads, agreed.
The use of it would probably be to have a more precise timing, IMHO.
I don't think that decoding of say five frames in a row consumes equal amount
of time on each decoded frame, the time spent decoding will vary from frame
to frame. This means that the decoding process of one frame might consume more
time than what we have left until next frame is supposed to be displayed.
But we don't know when and if that is, it's up to the decoder to consume cpu 
time. And unless every codec is checked to not consume too much cpu, the result 
will (on some low end cpu:s) be jerky, not very jerky, but still jerky video.
By placing it in a separate thread you allow the time spent in decoding of one 
frame to vary, the important thing is the average. 

/ magnus