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. 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. 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, -- Sakari Ailus e-mail: sakari.ailus@xxxxxx jabber/XMPP/Gmail: sailus@xxxxxxxxxxxxxx -- 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
