Hi Kamil, On Tue, Dec 06, 2011 at 04:03:33PM +0100, Kamil Debski wrote: ... > > > >The user space still wants to be able to show these buffers, so a new > > flag > > > >would likely be required --- V4L2_BUF_FLAG_READ_ONLY, for example. > > > > > > Huh? Assuming a capture device, when kernel makes a buffer available to > > userspace, > > > kernel should not touch on it anymore (not even for read - although > > reading from > > > it probably won't cause any issues, as video applications in general don't > > write > > > into those buffers). The opposite is true for output devices: once > > userspace fills it, > > > and queues, it should not touch that buffer again. > > > > > > This is part of the queue/dequeue logic. I can't see any need for an extra > > > flag to explicitly say that. > > > > There is a reason to do so. An example of this is below. The > > memory-to-memory device has two queues, output can capture. A video decoder > > memory-to-memory device's output queue handles compressed video and the > > capture queue provides the application decoded frames. > > > > Certain frames in the stream are key frames, meaning that the decoding of > > the following non-key frames requires access to the key frame. The number of > > non-key frame can be relatively large, say 16, depending on the codec. > > > > If the user should wait for all the frames to be decoded before the key > > frame can be shown, then either the key frame is to be skipped or delayed. > > Both of the options are highly undesirable. > > I don't think that such a delay is worrisome. This is only initial delay. > The hw will process these N buffers and after that it works exactly the same > as it would without the delay in terms of processing time. Well, yes, but consider that the decoder also processes key frames when the decoding is in progress. The dequeueing of the key frames (and any further frames as long as the key frame is needed by the decoder) will be delayed until the key frame is no longer required. You need extra buffers to cope with such a situation, and in the worst case, or when the decoder is just as fast as you want to show the frames on the display, you need double the amount of buffers compared to what you'd really need for decoding. To make matters worse, this tends to happen at largest resolutions. I think we'd like to avoid this. -- 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
