From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Hans Verkuil <hverkuil@xs4all.nl>, linux-media@vger.kernel.org
Subject: Re: [PATCH 2/6 v5] V4L: Add a UVC Metadata format
Date: Thu, 9 Nov 2017 08:37:38 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.20.1711090834220.23569@axis700.grange> (raw)
In-Reply-To: <1861262.E5lR5RDANx@avalon>
Hi Laurent,
On Thu, 9 Nov 2017, Laurent Pinchart wrote:
> Hi Guennadi,
>
> On Wednesday, 8 November 2017 12:43:46 EET Guennadi Liakhovetski wrote:
[snip]
> > To recall the metadata buffer layout should be
> >
> > struct uvc_meta_buf {
> > uint64_t ns;
> > uint16_t sof;
> > uint8_t length;
> > uint8_t flags;
> > uint8_t buf[];
> > } __attribute__((packed));
> >
> > where all the fields, beginning with "length" are a direct copy from the
> > UVC payload header. If multiple such payload headers have arrived for a
> > single frame, they will be appended and .bytesused will as usually have
> > the total byte count, used up in this frame. An application would then
> > calculate lengths of those individual metadata blocks as
> >
> > sizeof(.ns) + sizeof(.sof) + .length
> >
> > But this won't work with the "standard" UVC metadata format where any
> > private data, following standard fields, are dropped. In that case
> > applications would have to look at .flags and calculate the block length
> > based on them. Another possibility would be to rewrite the .length field
> > in the driver to only include standard fields, but I really don't think
> > that would be a good idea.
>
> For the standard header the length can indeed be easily computed from the
> flags. I wonder, however, why you think rewriting length would be a bad idea ?
Because I like the guarantee of the least intrusion. We (so far)
guarantee, that the buffer contents beyond the system and the USB
timestamps are a direct unmodified copy from the camera. This seems to be
a good principle to stick to.
Thanks
Guennadi
next prev parent reply other threads:[~2017-11-09 7:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-28 12:33 [PATCH 0/6 v5] uvcvideo: metadata nodes and controls Guennadi Liakhovetski
2017-07-28 12:33 ` [PATCH 1/6 v5] UVC: fix .queue_setup() to check the number of planes Guennadi Liakhovetski
2017-07-31 13:57 ` Laurent Pinchart
2017-07-31 13:58 ` Laurent Pinchart
2017-07-28 12:33 ` [PATCH 2/6 v5] V4L: Add a UVC Metadata format Guennadi Liakhovetski
2017-07-28 12:46 ` Hans Verkuil
2017-10-30 12:10 ` Hans Verkuil
2017-11-06 14:53 ` Guennadi Liakhovetski
2017-11-07 11:14 ` Laurent Pinchart
2017-11-08 10:43 ` Guennadi Liakhovetski
2017-11-09 5:42 ` Laurent Pinchart
2017-11-09 7:37 ` Guennadi Liakhovetski [this message]
2017-10-17 12:51 ` Laurent Pinchart
2017-07-28 12:33 ` [PATCH 3/6 v5] uvcvideo: convert from using an atomic variable to a reference count Guennadi Liakhovetski
2017-07-31 14:39 ` Laurent Pinchart
2017-07-28 12:33 ` [PATCH 4/6 v5] uvcvideo: add a metadata device node Guennadi Liakhovetski
2017-07-28 12:50 ` Hans Verkuil
2017-07-28 13:03 ` Guennadi Liakhovetski
2017-10-18 7:32 ` Guennadi Liakhovetski
2017-10-18 14:00 ` Laurent Pinchart
2017-10-18 7:35 ` [PATCH 4/6 v6] " Guennadi Liakhovetski
2017-07-28 12:33 ` [PATCH 5/6 v5] uvcvideo: send a control event when a Control Change interrupt arrives Guennadi Liakhovetski
2017-07-30 6:31 ` kbuild test robot
2017-07-30 6:31 ` [PATCH] uvcvideo: fix ifnullfree.cocci warnings kbuild test robot
2017-08-08 2:18 ` [lkp-robot] [uvcvideo] c698cbbd35: Failed to query (GET_INFO) UVC control 11 on unit 1: -32 (exp. 1) kernel test robot
2017-10-17 18:18 ` Laurent Pinchart
2017-10-17 18:17 ` [PATCH 5/6 v5] uvcvideo: send a control event when a Control Change interrupt arrives Laurent Pinchart
2017-07-28 12:33 ` [PATCH 6/6 v5] uvcvideo: handle control pipe protocol STALLs Guennadi Liakhovetski
2017-10-17 18:34 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.1711090834220.23569@axis700.grange \
--to=g.liakhovetski@gmx.de \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox