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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06-12-2011 12:28, 'Sakari Ailus' wrote:
Hi all,

On Tue, Dec 06, 2011 at 01:00:59PM +0100, Laurent Pinchart wrote:
...
2) new requirement is for a bigger buffer. DMA transfers need to be
stopped before actually writing inside the buffer (otherwise, memory
will be corrupted).

In this case, all queued buffers should be marked with an error flag.
So, both V4L2_BUF_FLAG_FORMATCHANGED and V4L2_BUF_FLAG_ERROR should
raise. The new format should be available via G_FMT.

I'd like to reword this as follows:

1. In all cases, the application needs to be informed that the format has
changed.

V4L2_BUF_FLAG_FORMATCHANGED (or a similar flag) is all we need. G_FMT will
report the new format.

2. In all cases, the application must have the option of reallocating buffers
if it wishes.

In order to support this, the driver needs to wait until the application
acknowledged the format change before it starts decoding the stream.
Otherwise, if the codec started decoding the new stream to the existing
buffers by itself, applications wouldn't have the option of freeing the
existing buffers and allocating smaller ones.

STREAMOFF/STREAMON is one way of acknowledging the format change. I'm not
opposed to other ways of doing that, but I think we need an acknowledgment API
to tell the driver to proceed.

Forcing STRAEMOFF/STRAEMON has two major advantages:

1) The application will have an ability to free and reallocate buffers if it
wishes so, and

2) It will get explicit information on the changed format. Alternative would
require an additional API to query the format of buffers in cases the
information isn't implicitly available.

As already said, a simple flag may give this meaning. Alternatively (or complementary,
an event may be generated, containing the new format).

If we do not require STRAEMOFF/STREAMON, the stream would have to be paused
until the application chooses to continue it after dealing with its buffers
and formats.

No. STREAMOFF is always used to stop the stream. We can't make it mean otherwise.

So, after calling it, application should assume that frames will be lost, while
the DMA engine doesn't start again.

For things like MPEG decoders, Hans proposed an ioctl, that could use to pause
and continue the decoding.

I'd still return a specific error when the size changes since it's more
explicit that something is not right, rather than just a flag. But if I'm
alone in thinking so I won't insist.

Regards,


--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux