Re: [PATCH 0/2] s5p-mfc: added encoder support for end of stream handling

[Andrzej Hajda <a.hajda@samsung.com>]

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