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

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

Hi Kamil,

On Wed, Jan 04, 2012 at 11:19:08AM +0100, Kamil Debski wrote:
...
> > > This takes care of the delay related problems by requiring more buffers.
> > > You have an initial delay then the frames are returned with a constant
> > rate.
> > >
> > > Dequeuing of any frame will be delayed until it is no longer used - it
> > doesn't
> > > matter whether it is a key (I) frame, P frame o r a B frame. Actually B
> > frames
> > > shouldn't be used as reference. Usually a frame is referencing only 2-3
> > previous
> > > and maybe 1 ahead (for B-frames) frames and they don't need to be I-frames.
> > Still
> > > the interval between I-frames may be 16 or even many, many, more.
> > 
> > Considering it can be 16 or even more, I see even more reason in returning
> > frames when hardware only reads them.
> 
> It can be 31337 P-frames after an I-frame but it doesn't matter, as the codec
> will never ever need more than X frames for reference. Usually the X is small, 
> like 2-3. I have never seen a number as high as 16. After this X frames are
> processed
> and kept it will allow to dequeue frames with no additional delay.
> This is a CONSTANT delay. 

It's constant, and you need up to that number more frames available for
decoding. There's no way around it.

> P-frames are equally good as reference as I-frames. No need to keep the I-frame
> for an indefinite time.
> 
> In other words: interval between I-frames is NOT the number of buffers that
> have to be kept as reference.

Referring to what Wikipedia has to say about H.264:

	Using previously-encoded pictures as references in a much more
	flexible way than in past standards, allowing up to 16 reference
	frames (or 32 reference fields, in the case of interlaced encoding)
	to be used in some cases. This is in contrast to prior standards,
	where the limit was typically one; or, in the case of conventional
	"B pictures", two. This particular feature usually allows modest
	improvements in bit rate and quality in most scenes. But in certain
	types of scenes, such as those with repetitive motion or
	back-and-forth scene cuts or uncovered background areas, it allows a
	significant reduction in bit rate while maintaining clarity.

<URL:http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC>

We need to be prepared to the worst case, which, according to this, is 16.

Regards,

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk