On Wed, Dec 07, 2011 at 12:12:08PM +0100, Kamil Debski wrote: > > > From: Sakari Ailus [mailto:sakari.ailus@xxxxxx] > > Sent: 06 December 2011 23:42 > > > > [...] > > > > > > >>>That's a good point. It's more related to changes in stream properties > > --- > > > >>>the frame rate of the stream could change, too. That might be when you > > could > > > >>>like to have more buffers in the queue. I don't think this is critical > > > >>>either. > > > >>> > > > >>>This could also depend on the properties of the codec. Again, I'd wish > > a > > > >>>comment from someone who knows codecs well. Some codecs need to be able > > to > > > >>>access buffers which have already been decoded to decode more buffers. > > Key > > > >>>frames, simply. > > > >> > > > >>Ok, but let's not add unneeded things at the API if you're not sure. If > > we have > > > >>such need for a given hardware, then add it. Otherwise, keep it simple. > > > > > > > >This is not so much dependent on hardware but on the standards which the > > > >cdoecs implement. > > > > > > Could you please elaborate it? On what scenario this is needed? > > > > This is a property of the stream, not a property of the decoder. To > > reconstruct each frame, a part of the stream is required and already decoded > > frames may be used to accelerate the decoding. What those parts are. depends > > on the codec, not a particular implementation. > > They are not used to accelerate decoding. They are used to predict what > should be displayed. If that frame is missing or modified it will cause > corruption in consecutive frames. > > I want to make it clear - they are necessary, not optional to accelerate > decoding speed. I think we're talking about the same thing. They are being used to accelerate it --- instead of reconstructing the previous frame from the compressed stream, the codecjust reuses it. In practice this is always done and the implementations probably require it. -- Sakari Ailus e-mail: sakari.ailus@xxxxxx jabber/XMPP/Gmail: sailus@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
