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

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

Hi Mauro,

On Tue, Dec 06, 2011 at 02:39:41PM -0200, Mauro Carvalho Chehab wrote:
...
> >I think that still it should contain no useful data, just *_FORMAT_CHANGED | *_ERROR
> >flags set. Then the application could decide whether it keeps the current
> >size/alignment/... or should it allocate new buffers. Then ACK the driver.
> 
> This will cause frame losses on Capture devices. It probably doesn't make sense to
> define resolution change support like this for output devices.
> 
> Eventually, we may have an extra flag: *_PAUSE. If *_PAUSE is detected, a VIDEO_DECODER_CMD
> is needed to continue.
> 
> So, on M2M devices, the 3 flags are raised and the buffer is not filled.  This would cover
> Sakari's case.

This sounds good in my opinion. I've been concentrated to memory-to-memory
devices so far, but I now reckon the data to be processed might not arrive
from the system memory.

I agree we need different behaviour in the two cases: when the data arrives
from the system memory, no loss of decoded data should happen due to
reconfiguration of the device done by the user --- which sometimes is
mandatory.

Would pause, as you propose it, be set by the driver, or by the application
in the intent to indicate the stream should be stopped whenever the format
changes, or both?

> >The thing is that we have two queues in memory-to-memory devices.
> >I think the above does apply to the CAPTURE queue:
> >- no processing is done after STREAMOFF
> >- buffers that have been queue are dequeued and their content is lost
> >Am I wrong?
> 
> This is what is there at the spec. I think we need to properly specify what
> happens for M2M devices.

I fully agree. Different device profiles have a role in this.

Cheers,

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