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

Magnus Damm damm at opensource.se
Wed Aug 27 11:30:13 CEST 2003


Hi there,

> > > > > > 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? =)
> 
> of course i meant cannot be done (well) in one process/thread.

Yeah, of course, sorry about that.

> 
> > Two threads, agreed.
> > The use of it would probably be to have a more precise timing, IMHO.
> 
> yes i know its use in 2+ threads, of course.
> i only dont know what is its use in one thread, ie. just delaying video
> stream by a few frames. maybe it could help framedrop a bit, by giving more
> chanse to always skip B frame.

Agreed.
 
> > 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. 
> 
> i know, but it only happens on slow (boundary) cpus, not being able fast
> enough to decode any frame in less than 1/fps time.
> this issue was addressed by mplayerxp fork (by Nick), with less than more
> success.

Allright, then I know. 
Thanks for your input!

/ magnus



More information about the MPlayer-dev-eng mailing list