On Wed 23 May 2012 13:20:03 Andrzej Hajda wrote:
> 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.
That's going to make it very hard to write generic applications: people will
always forget to set that flag, unless they happen to using your hardware.
> 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.
In the current V4L2 API the last output frame is reached when:
1) the filehandle is closed
2) VIDIOC_STREAMOFF is called
3) VIDIOC_ENCODER_CMD is called with V4L2_ENC_CMD_STOP.
The latter is currently only used by MPEG encoders, but it might be an idea
to consider it for your hardware as well. Perhaps a flag like
'stop_after_next_frame'
is needed.
How are cases 1 and 2 handled today?
And what happens if the app sets the EOS flag, and then later queues another
buffer without that flag. Is that frame accepted/rejected/ignored?
I'm trying to understand how the current implementation behaves in corner cases
like those.
> 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.
I don't believe this is documented anywhere. Wouldn't it be better to send
a V4L2_EVENT_EOS event? That's documented and is the way I would expect this
to work.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
