> 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. > Anyone with more knowledge of codecs than myself might be able to give a > concrete example. Sebastian? > -- Kamil Debski Linux Platform Group Samsung Poland R&D Center -- 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
