Re: [RFC] Resolution change support in video codecs in v4l2

['Sakari Ailus' <sakari.ailus@iki.fi>]

On Wed, Dec 07, 2011 at 12:12:08PM +0100, Kamil Debski wrote:
> 
> > From: Sakari Ailus [mailto:sakari.ailus@iki.fi]
> > 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@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk