Re: [RFC 0/7] media: Clean and make H264 stateless uAPI public

Nicolas Dufresne
2020-06-25T14:42:57Z

[-- Attachment #1: Type: text/plain, Size: 3511 bytes --]

Le mardi 23 juin 2020 à 15:28 -0300, Ezequiel Garcia a écrit :
> The recent patch posted by Jernej (which I'm including for context),
> encouraged me to address all the known issues in the uAPI.
>
> I hope we can finally make this uAPI interface
> public; it would be nice to address the other codec
> interfaces so we can move the codec drivers out of staging.
>
> It should be noted that there is already GStreamer native
> support for this interface, which will be part of 1.18,
> once it's released [1], as well as support in Chromium [2].

Keep in mind, no one did a MultiView and/or SVC implementation in
userspace yet. Multiview seems to share a lot of interlacing, which
ffmpeg implementation covers, but some validation would be nice.

As for SVC, I only started looking at that this means for decoding. It
looks like buffer "holding" mechanism is mostly what we need, I'd would
simply like to verify, as I was told that scaling down might be
required when SVC stream is missing (but perhaps this is optional ?)

>
> The basic idea here is to sanitize the interface,
> making sure the structs are aligned to 64-bit,
> adding reserved fields for padding where suitable.
>
> These reserved fields can then be used to support future extensions,
> in case such need appears.
>
> In addition to this, moving the slice invariant fields
> to the per-frame control, makes the frame-mode driver
> implementation much nicer and the interface; see patch 6/7 for details.
>
> I'm not adding a MAINTAINERS entry, but I'd like to do so,
> so we make sure any uAPI changes are sent to those involved.
>
> Another potential change is the addition of a "Since:" tag to the
> control specification, so we can document which kernel version
> added the interface. This might prove useful if reserved
> fields are then used to extend the interface.
>
> Finally, I'm sneaking here a change from Philipp Zabel
> which apparently fell thru the cracks.

Thanks a lot of working on this.

>
> [1] https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/tree/master/sys/v4l2codecs
> [2] https://chromium.googlesource.com/chromium/src.git/+/refs/heads/master/media/gpu/v4l2/
>
> Ezequiel Garcia (5):
> fixup! media: uapi: h264: update reference lists
> media: uapi: h264: increase size of fields
> media: uapi: h264: pad v4l2_ctrl_h264_pps to 64-bit
> media: uapi: h264: Clean slice invariants syntax elements
> media: uapi: make H264 stateless codec interface public
>
> Jernej Skrabec (1):
> media: uapi: h264: update reference lists
>
> Philipp Zabel (1):
> media: uapi: h264: clarify pic_order_cnt_bit_size field
>
> .../media/v4l/ext-ctrls-codec.rst | 135 ++++++++++++------
> drivers/media/v4l2-core/v4l2-ctrls.c | 31 ++++
> drivers/media/v4l2-core/v4l2-h264.c | 8 +-
> .../staging/media/hantro/hantro_g1_h264_dec.c | 21 ++-
> drivers/staging/media/hantro/hantro_h264.c | 3 +-
> drivers/staging/media/hantro/hantro_hw.h | 5 +-
> drivers/staging/media/rkvdec/rkvdec-h264.c | 6 +-
> .../staging/media/sunxi/cedrus/cedrus_h264.c | 15 +-
> include/media/v4l2-ctrls.h | 3 +-
> include/media/v4l2-h264.h | 5 +-
> .../linux/v4l2-h264-ctrls.h} | 73 ++++++----
> 11 files changed, 194 insertions(+), 111 deletions(-)
> rename include/{media/h264-ctrls.h => uapi/linux/v4l2-h264-ctrls.h} (88%)
>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 195 bytes --]