From: Boris Brezillon <boris.brezillon@collabora.com>
To: Mauro Carvalho Chehab <mchehab@kernel.org>,
Hans Verkuil <hans.verkuil@cisco.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Sakari Ailus <sakari.ailus@iki.fi>,
linux-media@vger.kernel.org
Cc: Tomasz Figa <tfiga@chromium.org>,
Nicolas Dufresne <nicolas@ndufresne.ca>,
kernel@collabora.com,
Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Ezequiel Garcia <ezequiel@collabora.com>,
Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@siol.net>,
Alexandre Courbot <acourbot@chromium.org>,
Thierry Reding <thierry.reding@gmail.com>
Subject: Re: [PATCH v2 0/3] media: uapi: h264: First batch of adjusments
Date: Mon, 10 Jun 2019 10:57:06 +0200 [thread overview]
Message-ID: <20190610105706.33aa0b95@collabora.com> (raw)
In-Reply-To: <20190610085250.3255-1-boris.brezillon@collabora.com>
On Mon, 10 Jun 2019 10:52:47 +0200
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> Hello,
>
> This is a first batch of adjustments to the stateless H264 decoder
> uAPI. The first one is about adding support for per-frame decoding,
> which is the only mode supported on some codecs (the hantro G1 block
> supports per-slice decoding but not in an way that would allow
> efficient multiplexing of several decoding contexts).
>
> The second modification drops the P0/B0/B1 ref lists from the
> decode_params control. These lists are no longer needed now that we know
> we can build them kernel side based on the DPB.
>
> There are few more changes in the pipe, but I'd like to sync with Paul,
> Jonas, Jernej and Nicolas before modifying:
> * Enforce order of the scaling list (looks like the rockchip and cedrus
> have different expectations)
> * Pass top/bottom field info as flags in the DPB entry: the field
> attached to the capture buffer is not accurate as capture bufs might
> contain both top/bottom (meaning they are actually interlaced), but a
> coded frame might contain only one of these fields. Note
> that there's also a problem with the output -> capture field flag
> propagation we have in copy_metadata() because a coded slice might
> contain only data for top or bottom, but the capture frame might
> contain both. Doing capture->field = output->field means we're lying
> about what's inside the capture buffer (not sure we have
> implementation checking that)
> * s/dpb/refs/: looks like we're abusing the term DPB which is supposed
> to be implementation specific. What's provided by the bitstream is a
> list of references that will be used to decode a frame
> * ... (add your own)
>
> Feel free to comment on these changes and/or propose alternatives.
>
> Regards,
>
> Boris
>
> Changes in v2:
> * Allow decoding multiple slices in per-slice decoding mode
> * Minor doc improvements/fixes
Forgot:
* Drop sunxi changes until we settle on the uAPI changes (supporting
multi-slice decoding in per-slice mode requires a bit more work and I
can't test it)
>
> Boris Brezillon (3):
> media: uapi: h264: Clarify our expectations regarding NAL header
> format
> media: uapi: h264: Add the concept of decoding mode
> media: uapi: h264: Get rid of the p0/b0/b1 ref-lists
>
> .../media/uapi/v4l/ext-ctrls-codec.rst | 56 +++++++++++++++----
> drivers/media/v4l2-core/v4l2-ctrls.c | 9 +++
> include/media/h264-ctrls.h | 13 +++++
> 3 files changed, 68 insertions(+), 10 deletions(-)
>
prev parent reply other threads:[~2019-06-10 8:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-10 8:52 [PATCH v2 0/3] media: uapi: h264: First batch of adjusments Boris Brezillon
2019-06-10 8:52 ` [PATCH v2 1/3] media: uapi: h264: Clarify our expectations regarding NAL header format Boris Brezillon
2019-06-26 11:23 ` Paul Kocialkowski
2019-06-10 8:52 ` [PATCH v2 2/3] media: uapi: h264: Add the concept of decoding mode Boris Brezillon
2019-06-26 11:30 ` Paul Kocialkowski
2019-06-26 15:26 ` Boris Brezillon
2019-06-28 5:35 ` Tomasz Figa
2019-06-10 8:52 ` [PATCH v2 3/3] media: uapi: h264: Get rid of the p0/b0/b1 ref-lists Boris Brezillon
2019-06-26 11:33 ` Paul Kocialkowski
2019-06-26 11:48 ` Boris Brezillon
2019-06-10 8:57 ` Boris Brezillon [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=20190610105706.33aa0b95@collabora.com \
--to=boris.brezillon@collabora.com \
--cc=acourbot@chromium.org \
--cc=ezequiel@collabora.com \
--cc=hans.verkuil@cisco.com \
--cc=jernej.skrabec@siol.net \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=maxime.ripard@bootlin.com \
--cc=mchehab@kernel.org \
--cc=nicolas@ndufresne.ca \
--cc=paul.kocialkowski@bootlin.com \
--cc=sakari.ailus@iki.fi \
--cc=tfiga@chromium.org \
--cc=thierry.reding@gmail.com \
/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.