On Wed, 2012-05-23 at 09:43 +0200, Hans Verkuil wrote: > Hi Andrzej! > > Thanks for the patch, but I do have two questions: > > On Tue 22 May 2012 17:33:53 Andrzej Hajda wrote: > > Those patches add end of stream handling for s5p-mfc encoder. > > > > The first patch was sent already to the list as RFC, but the discussion ended > > without any decision. > > This patch adds new v4l2_buffer flag V4L2_BUF_FLAG_EOS. Below short > > description of this change. > > > > s5p_mfc is a mem-to-mem MPEG/H263/H264 encoder and it requires that the last > > incoming frame must be processed differently, it means the information about > > the end of the stream driver should receive NOT LATER than the last > > V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer. Common practice > > of sending empty buffer to indicate end-of-stream do not work in such case. > > Setting V4L2_BUF_FLAG_EOS flag for the last V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE > > buffer seems to be the most straightforward solution here. > > > > V4L2_BUF_FLAG_EOS flag should be used by application if driver requires it > > How will the application know that? Application can always set this flag, it will be ignored by drivers not requiring it. I see some drawback of this solution - application should know if the frame enqueued to the driver is the last one. If the application receives frames to encode form an external source (for example via pipe) it often does not know if the frame it received is the last one. So to be able to properly queue frame to the driver it should wait with frame queuing until it knows there is next frame or end-of-stream is reached, in such situation it will properly set flag before queuing. Alternative to "V4L2_BUF_FLAG_EOS" solution is to implement "wait for next frame" logic directly into the driver. In such case application can use empty buffer to signal the end of the stream. Driver waits with frame processing if there are at least two buffers in output queue. Then it checks if the second buffer is empty if not it process the first buffer as a normal frame and repeats procedure, if yes it process the first buffer as the last frame and releases second buffer. The drawback of this solution is that it wastes resources/space (additional buffer) and time (delayed encoding). I am still hesitating which solution is better, any advices? > > and it should be set only on V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffers. > > Why only for this type? I wanted to say only for output buffers not just output multi-plane. And why not capture? Explanation below. Capture buffers are filled by driver, so only drivers could set this flag. Some devices provides information about the end of the stream together with the last frame, but some devices provides this info later (for example s5p-mfc :) ). In the latter case to properly flag the capture buffer driver should wait for next available frame. Simpler solution is to use current solution with sending empty buffer to signal the end of the stream. Regards Andrzej Hajda -- 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
