> From: Mauro Carvalho Chehab [mailto:mchehab@xxxxxxxxxx] > Sent: 06 December 2011 15:42 > > 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. Do you mean all buffers or just those that are queued in hardware? What has been processed stays processed, it should not matter to the buffers that have been processed. The compressed buffer that is queued in the driver and that caused the resolution change is on the OUTPUT queue. STREMOFF is only done on the CAPTURE queue, so it stays queued and information is retained. >From CAPTURE all processed buffers have already been dequeued, so yes the content of the buffers queued in hw is lost. But this is ok, because after the resolution change the previous frames are not used in prediction. My initial idea was to acknowledge the resolution change by G_FMT. Later in our chat it had evolved into S_FMT. Then it mutated into STREAMOFF/STREAMON on the CAPTURE queue. > > For things like MPEG decoders, Hans proposed an ioctl, that could use to > pause > and continue the decoding. This still could be useful... But processing will also pause when hw runs out of buffers. It will be resumed after the application consumes/produces new buffers and enqueue them. > > > 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, > > Best wishes, -- Kamil Debski Linux Platform Group Samsung Poland R&D Center -- 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
