All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Ricardo Ribalda <ribalda@chromium.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Guennadi Liakhovetski <guennadi.liakhovetski@intel.com>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/3] media: uvcvideo: Introduce V4L2_META_FMT_UVC_CUSTOM
Date: Fri, 14 Mar 2025 07:34:56 +0100	[thread overview]
Message-ID: <20250314073456.25817a3d@foz.lan> (raw)
In-Reply-To: <20250313-uvc-metadata-v3-3-c467af869c60@chromium.org>

Em Thu, 13 Mar 2025 12:06:27 +0000
Ricardo Ribalda <ribalda@chromium.org> escreveu:

> The UVC driver provides two metadata types V4L2_META_FMT_UVC, and
> V4L2_META_FMT_D4XX. The only difference between the two of them is that
> V4L2_META_FMT_UVC only copies PTS, SCR, size and flags, and
> V4L2_META_FMT_D4XX copies the whole metadata section.
> 
> Now we only enable V4L2_META_FMT_D4XX for the Intel D4xx family of
> devices, but it is useful to have the whole metadata section for any
> device where vendors include other metadata, such as the one described by
> Microsoft:
> https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/mf-capture-metadata
> 
> This patch introduces a new format V4L2_META_FMT_UVC_CUSTOM, that is
> identical to V4L2_META_FMT_D4XX but it is available to all the UVC
> devices.
> 
> Suggested-by: Hans de Goede <hdegoede@redhat.com>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
>  .../userspace-api/media/v4l/meta-formats.rst       |  1 +
>  .../userspace-api/media/v4l/metafmt-uvc-custom.rst | 31 +++++++++++++++++
>  MAINTAINERS                                        |  1 +
>  drivers/media/usb/uvc/uvc_metadata.c               | 40 ++++++++++++++++++----
>  drivers/media/v4l2-core/v4l2-ioctl.c               |  1 +
>  include/uapi/linux/videodev2.h                     |  1 +
>  6 files changed, 69 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/userspace-api/media/v4l/meta-formats.rst b/Documentation/userspace-api/media/v4l/meta-formats.rst
> index 86ffb3bc8ade2e0c563dd84441572ecea1a571a6..9fd83f4a3cc8509702a2a9f032fdc04bf6c6d1bc 100644
> --- a/Documentation/userspace-api/media/v4l/meta-formats.rst
> +++ b/Documentation/userspace-api/media/v4l/meta-formats.rst
> @@ -19,6 +19,7 @@ These formats are used for the :ref:`metadata` interface only.
>      metafmt-pisp-fe
>      metafmt-rkisp1
>      metafmt-uvc
> +    metafmt-uvc-custom
>      metafmt-vivid
>      metafmt-vsp1-hgo
>      metafmt-vsp1-hgt
> diff --git a/Documentation/userspace-api/media/v4l/metafmt-uvc-custom.rst b/Documentation/userspace-api/media/v4l/metafmt-uvc-custom.rst
> new file mode 100644
> index 0000000000000000000000000000000000000000..9f150fc2b6f379cc4707ff45041dd014956ae11a
> --- /dev/null
> +++ b/Documentation/userspace-api/media/v4l/metafmt-uvc-custom.rst
> @@ -0,0 +1,31 @@
> +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
> +
> +.. _v4l2-meta-fmt-uvc-custom:
> +
> +*********************************
> +V4L2_META_FMT_UVC_CUSTOM ('UVCC')
> +*********************************
> +
> +UVC Custom Payload Metadata.
> +
> +
> +Description
> +===========
> +
> +V4L2_META_FMT_UVC_CUSTOM buffers follow the metadata buffer layout of
> +V4L2_META_FMT_UVC with the only difference that it includes all the UVC
> +metadata, not just the first 2-12 bytes.
> +
> +The most common metadata format is the one proposed by Microsoft(R)'s UVC
> +extension [1_], but other vendors might have different formats.
> +
> +Applications might use information from the Hardware Database (hwdb)[2_] to
> +process the camera's metadata accordingly.

Having something like that at the userspace API shouldn't be handled
lightly. This sounds to me that passing a blank check for vendors to stream
whatever they want without any requirements to provide and sort of
documentation for the usersace to decode it.

Also, it would be hard for userspace to distinguish what metatata
is contained for a random UVC camera. Please let's not do that.

As the specific issue here is to support an already known extension,
which is already documented, Just add an specific format for it, e.g. 
you could add something like that at the documentation:

	V4L2_META_FMT_MSXU_UVC_1_5
	   Microsoft extensions to USB Video Class 1.5 specification.
	
	   For more details, see: https://learn.microsoft.com/en-us/windows-hardware/drivers/stream/uvc-extensions-1-5	

And then add the corresponding format to V4L2 API.

Regards,
Mauro

  reply	other threads:[~2025-03-14  6:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 12:06 [PATCH v3 0/3] media: uvcvideo: Introduce V4L2_META_FMT_UVC_CUSTOM + other meta fixes Ricardo Ribalda
2025-03-13 12:06 ` [PATCH v3 1/3] media: uvcvideo: Do not mark valid metadata as invalid Ricardo Ribalda
2025-03-13 12:06 ` [PATCH v3 2/3] media: Documentation: Add note about UVCH length field Ricardo Ribalda
2025-03-13 12:06 ` [PATCH v3 3/3] media: uvcvideo: Introduce V4L2_META_FMT_UVC_CUSTOM Ricardo Ribalda
2025-03-14  6:34   ` Mauro Carvalho Chehab [this message]
2025-03-14  8:28     ` Ricardo Ribalda
2025-03-14  9:09       ` Laurent Pinchart
2025-03-14 10:17         ` Ricardo Ribalda
2025-04-03 21:40           ` Ricardo Ribalda

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=20250314073456.25817a3d@foz.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=guennadi.liakhovetski@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=ribalda@chromium.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.