From: "Jernej Škrabec" <jernej.skrabec@siol.net>
To: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
Ezequiel Garcia <ezequiel@collabora.com>
Cc: Tomasz Figa <tfiga@chromium.org>,
kernel@collabora.com, Jonas Karlman <jonas@kwiboo.se>,
Hans Verkuil <hverkuil@xs4all.nl>,
Alexandre Courbot <acourbot@chromium.org>,
Jeffrey Kardatzke <jkardatzke@chromium.org>,
Nicolas Dufresne <nicolas.dufresne@collabora.com>,
Philipp Zabel <p.zabel@pengutronix.de>,
Maxime Ripard <mripard@kernel.org>,
Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
Ezequiel Garcia <ezequiel@collabora.com>
Subject: Re: [PATCH v2 00/14] Clean H264 stateless uAPI
Date: Tue, 11 Aug 2020 21:16:09 +0200 [thread overview]
Message-ID: <3072394.25LIjdDuC7@kista> (raw)
In-Reply-To: <20200806151310.98624-1-ezequiel@collabora.com>
Hi!
Dne četrtek, 06. avgust 2020 ob 17:12:56 CEST je Ezequiel Garcia napisal(a):
> Here's a new round for the H.264 uAPI cleanup, which as discussed
> aims at being stabilized and promoted as a first-class public uAPI soon.
>
> 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.
>
> I have pushed a branch porting GStreamer to
> support these interface changes:
>
> https://gitlab.freedesktop.org/ezequielgarcia/gst-plugins-bad/-/commits/for_
> h264_uapi_v3
>
> As was discussed the SLICE_PARAMS control is now clarified
> to work for one-slice-per-request operation, using CAPTURE
> buffer holding features. This is how Cedrus driver is implemented.
>
> The other drivers currently supported Hantro and Rockchip VDEC,
> as well as the MTK stateless decoder posted by Alex Courbot
> operate in frame-based mode.
>
> These "frame-based" devices parse the slice headers in hardware,
> and therefore shall not support SLICE_PARAMS. To that extent,
> the redundant bitstream fields are now part of the DECODE_PARAMS
> control.
>
> Hopefully now the specification documentation is clear enough.
> GStreamer, Chromium and FFmpeg (which I'm sure will be implemented
> as soon as we stabilize the API) should serve as reference examples
> on how the API is consumed.
>
I tested this series using https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.3.1 on Cedrus (Allwinner H6) using additional patch
contained in discussion around patch 3 and I couldn't find any issue.
You can add to whole series:
Tested-by: Jernej Skrabec <jernej.skrabec@siol.net>
Best regards,
Jernej
prev parent reply other threads:[~2020-09-01 21:39 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-06 15:12 [PATCH v2 00/14] Clean H264 stateless uAPI Ezequiel Garcia
2020-08-06 15:12 ` [PATCH v2 01/14] media: uapi: h264: Update reference lists Ezequiel Garcia
2020-08-06 15:47 ` Paul Kocialkowski
2020-08-06 15:54 ` Jernej Škrabec
2020-08-07 14:33 ` Ezequiel Garcia
2020-08-08 19:12 ` Ezequiel Garcia
2020-08-06 15:12 ` [PATCH v2 02/14] media: uapi: h264: Further clarify scaling lists order Ezequiel Garcia
2020-08-06 15:12 ` [PATCH v2 03/14] media: uapi: h264: Split prediction weight parameters Ezequiel Garcia
2020-08-08 21:01 ` Jonas Karlman
2020-08-09 13:55 ` Ezequiel Garcia
2020-08-09 21:11 ` Jernej Škrabec
2020-08-10 12:57 ` Ezequiel Garcia
2020-08-10 14:55 ` Jonas Karlman
2020-08-10 15:28 ` Ezequiel Garcia
2020-08-10 16:57 ` Jonas Karlman
2020-08-10 20:04 ` Ezequiel Garcia
2020-08-10 17:05 ` Jernej Škrabec
2020-08-10 19:30 ` Ezequiel Garcia
2020-08-10 19:34 ` Jernej Škrabec
2020-08-10 20:08 ` Ezequiel Garcia
2020-08-11 22:06 ` Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 04/14] media: uapi: h264: Clarify pic_order_cnt_bit_size field Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 05/14] media: uapi: h264: Increase size of 'first_mb_in_slice' field Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 06/14] media: uapi: h264: Clean DPB entry interface Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 07/14] media: uapi: h264: Increase size of DPB entry pic_num Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 08/14] media: uapi: h264: Drop SLICE_PARAMS 'size' field Ezequiel Garcia
2020-08-06 15:50 ` Paul Kocialkowski
2020-08-07 14:44 ` Ezequiel Garcia
2020-08-19 13:54 ` Paul Kocialkowski
2020-08-20 7:32 ` Ezequiel Garcia
2020-08-28 14:21 ` Nicolas Dufresne
2020-08-06 15:13 ` [PATCH v2 09/14] media: uapi: h264: Clarify SLICE_BASED mode Ezequiel Garcia
2020-08-06 15:52 ` Paul Kocialkowski
2020-08-06 15:13 ` [PATCH v2 10/14] media: uapi: h264: Clean slice invariants syntax elements Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 11/14] media: hantro: Don't require unneeded H264_SLICE_PARAMS Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 12/14] media: rkvdec: " Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 13/14] media: cedrus: h264: Properly configure reference field Ezequiel Garcia
2020-08-06 15:13 ` [PATCH v2 14/14] media: cedrus: h264: Fix frame list construction Ezequiel Garcia
2020-08-11 19:16 ` Jernej Škrabec [this message]
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=3072394.25LIjdDuC7@kista \
--to=jernej.skrabec@siol.net \
--cc=acourbot@chromium.org \
--cc=ezequiel@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=jkardatzke@chromium.org \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mripard@kernel.org \
--cc=nicolas.dufresne@collabora.com \
--cc=p.zabel@pengutronix.de \
--cc=paul.kocialkowski@bootlin.com \
--cc=tfiga@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.