[MPlayer-dev-eng] Do decoders have a stream ?
damm at opensource.se
Wed Aug 27 11:30:13 CEST 2003
> > > > > > 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.
> > 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
Allright, then I know.
Thanks for your input!
More information about the MPlayer-dev-eng