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