Re: Way to request a time discontinuity in a V4L2 encoder device

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Sylwester,

On Monday 05 November 2012 21:47:00 Sylwester Nawrocki wrote:
> On 11/05/2012 11:45 AM, Alain VOLMAT wrote:
> > Hi Laurent,
> > 
> > Yes indeed, meta plane seems a good candidate. It was the other option.
> > 
> > The pity with that is that the FMT can thus no longer be standard FMT but
> > a specific format that include both plane 0 with real frame data and plane
> > 1 with meta data.
> >
> > So, standard V4L2 application (that doesn't know about this time
> > discontinuity stuff) wouldn't be able to push things into the encoder
> > since they are not aware of this 2 plane format.
> >
> > Or maybe we should export 2 format, 1 standard one that doesn't have time
> > discontinuity support, thus not best performance but still can do things
> > and a second format that has 2 planes
> 
> Not sure what media guys think about it, I was considering making it
> possible for applications (or libv4l or any other library) to request
> additional meta data plane at a video capture driver, e.g. with VIDIOC_S_FMT
> ioctl. With same fourcc for e.g. 1-planar buffers with image data and 2-
> planar buffer with meta data in plane 1. However this would be somehow
> device-specific, rather than a completely generic interface. Since frame-
> meta data is often device specific. For camera it would depend on the image
> sensor whether the additional plane request on a /dev/video? would be
> fulfilled by a driver or not.
> 
> I don't think duplicating 4CCs for the sake of additional meta-data plane is
> a good idea.

I agree with you. A generic way to enable meta-data in a separate plane 
without requiring a separate 4CC is a good idea.

> Your case is a bit different, since you're passing data from application to
> a device. Maybe we could somewhat standardize the meta data buffer content,
> e.g. by using some standard header specifying what kind of meta data
> follows.
> Perhaps struct v4l2_plane::data_offset can be helpful here. This is how
> it's documented
> 
>   * @data_offset:	offset in the plane to the start of data; usually 0,
>   *			unless there is a header in front of the data
> 

There's also 11 reserved fields.

> I mean, the header would specify what actual meta-data is in that additional
> plane. Standardising that "standard" meta-data would be another issue.
>
> I think this per buffer device control issue emerged in the past during the
> Exynos Multi Format Codec development. There were proposals of per-buffer
> v4l2 controls. IIRC it is currently resolved in that driver by doing
> VIDIOC_S_CTRL before QBUF. However the meta data plane approach looks more
> interesting to me.

Maybe it's time to discuss the topic again then :-)

-- 
Regards,

Laurent Pinchart