Hi,
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.
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
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.
--
Regards,
Sylwester
--
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
