Re: [RFC PATCH 2/2] [media] videobuf2: return -EPIPE from DQBUF after the last buffer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 02 February 2015 15:00:51 Hans Verkuil wrote:
> On 01/22/2015 12:28 PM, Philipp Zabel wrote:
> > If the last buffer was dequeued from a capture queue, let poll return
> > immediately and let DQBUF return -EPIPE to signal there will no more
> > buffers to dequeue until STREAMOFF.
> 
> This looks OK to me, although I would like to see comments from others as
> well. Of course, this needs to be documented in the spec as well.

I haven't followed the V4L2 codec API discussion during ELC-E. Could someone 
briefly expose the rationale for this and the codec draining flow ? The 
explanation should probably included in the documentation.

Existing applications will receive -EPIPE from DQBUF now. Have potential 
breakages been taken into account ?

> > Signed-off-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>
> > ---
> > TODO: (How) should the last_buffer_dequeud flag be cleared in reaction to
> > V4L2_DEC_CMD_START?
> 
> I would suggest an inline function in videobuf2-core.h that clears the flag
> and that drivers can call. I don't think the vb2 core can detect when it is
> OK to clear the flag, it needs to be told by the driver (correct me if I am
> wrong).

-- 
Regards,

Laurent Pinchart

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




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux