Re: [PATCH v2 3/3] uvcvideo: add a metadata device node

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

 



Hi Laurent,

On Tue, 6 Dec 2016, Laurent Pinchart wrote:

> Hi Guennadi,
> 
> On Monday 05 Dec 2016 23:13:53 Guennadi Liakhovetski wrote:
> > Just one question:
> > 
> > On Tue, 6 Dec 2016, Laurent Pinchart wrote:
> > >>>> +	/*
> > >>>> +	 * Register a metadata node. TODO: shall this only be enabled
> > >>>> for some
> > >>>> +	 * cameras?
> > >>>> +	 */
> > >>>> +	if (!(dev->quirks & UVC_QUIRK_BUILTIN_ISIGHT))
> > >>>> +		uvc_meta_register(stream);
> > >>>> +
> > >>> 
> > >>> I think so, only for the cameras that can produce metadata.
> > >> 
> > >> Every UVC camera produces metadata, but most cameras only have standard
> > >> fields there. Whether we should stream standard header fields from the
> > >> metadata node will be discussed later. If we do decide to stream
> > >> standard header fields, then every USB camera gets metadata nodes. If we
> > >> decide not to include standard fields, how do we know whether the camera
> > >> has any private fields in headers without streaming from it? Do you want
> > >> a quirk for such cameras?
> > > 
> > > Unless they can be detected in a standard way that's probably the best
> > > solution. Please remember that the UVC specification doesn't allow vendors
> > > to extend headers in a vendor-specific way.
> > 
> > Does it not? Where is that specified? I didn't find that anywhere.
> 
> It's the other way around, it document a standard way to extend the payload 
> header. Any option you pick risks being incompatible with future revisions of 
> the specification. For instance the payload header's bmHeaderInfo field can be 
> extended through the use of the EOF bit, but a future version of the 
> specification could also extend it, in a way that would make a vendor-specific 
> extension be mistaken for the standard extension.
> 
> Now, you could add data after the standard payload without touching the 
> bmHeaderInfo field, but I'm still worried it could be broken by future 
> versions of the specification.

Exactly - using "free" space in payload headers is not a part of the spec, 
but is also not prohibited by it. As for future versions - cameras specify 
which version of the spec they implement, and existing versions cannot 
change. If a camera decides to upgrade and in future UVC versions there 
won't be enough space left for the private data, only then the camera 
manufacturer will have a problem, that they will have to solve. The 
user-space software will have to know, that UVC 5.1 metadata has a 
different format, than UVC 1.5, that's true.

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