From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Boris Brezillon <boris.brezillon@collabora.com>
Cc: 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, Tomasz Figa <tfiga@chromium.org>,
Nicolas Dufresne <nicolas@ndufresne.ca>,
kernel@collabora.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 v3 1/3] media: uapi: h264: Clarify our expectations regarding NAL header format
Date: Thu, 25 Jul 2019 21:26:10 +0200 [thread overview]
Message-ID: <20190725192610.GC14499@aptenodytes> (raw)
In-Reply-To: <20190703122849.6316-2-boris.brezillon@collabora.com>
Hi,
On Wed 03 Jul 19, 14:28, Boris Brezillon wrote:
> Looks like some stateless decoders expect slices to be prefixed with
> ANNEX B start codes (they most likely do some kind of bitstream parsing
> and/or need that to delimit slices when doing per frame decoding).
> Since skipping those start codes for dummy stateless decoders (those
> expecting all params to be passed through controls) should be pretty
> easy, let's mandate that all slices be prepended with ANNEX B start
> codes.
>
> If we ever need to support AVC headers, we can add a new menu control
> to select the type of NAL header to use.
After thinking a bit about this, I'd rather be in favor of having offsets
in the control structures rather than forcing the start code type or having a
dedicated control for that, as I've mentionned on the other patch.
What do you think?
Cheers,
Paul
> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
> Reviewed-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
> ---
> Changes in v3:
> * Add Paul's R-b
>
> Changes in v2:
> * None
> ---
> Documentation/media/uapi/v4l/ext-ctrls-codec.rst | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
> index 7a1947f5be96..3ae1367806cf 100644
> --- a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
> +++ b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
> @@ -1726,6 +1726,7 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
> :ref:`h264`, section 7.4.3 "Slice Header Semantics". For further
> documentation, refer to the above specification, unless there is
> an explicit comment stating otherwise.
> + All slices should be prepended with an ANNEX B start code.
>
> .. note::
>
> --
> 2.21.0
>
--
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2019-07-25 19:26 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-03 12:28 [PATCH v3 0/3] media: uapi: h264: First batch of adjusments Boris Brezillon
2019-07-03 12:28 ` [PATCH v3 1/3] media: uapi: h264: Clarify our expectations regarding NAL header format Boris Brezillon
2019-07-05 16:40 ` Ezequiel Garcia
2019-07-05 17:16 ` Boris Brezillon
2019-07-25 6:42 ` Boris Brezillon
2019-07-25 19:36 ` Paul Kocialkowski
2019-07-26 2:39 ` Ezequiel Garcia
2019-07-26 6:28 ` Boris Brezillon
2019-07-26 7:30 ` Boris Brezillon
2019-07-26 8:53 ` Hans Verkuil
2019-07-27 9:27 ` Paul Kocialkowski
2019-07-27 9:46 ` Boris Brezillon
2019-07-29 13:25 ` Paul Kocialkowski
2019-07-29 14:19 ` Boris Brezillon
2019-07-27 12:52 ` Ezequiel Garcia
2019-07-27 13:49 ` Boris Brezillon
2019-07-29 13:33 ` Paul Kocialkowski
2019-07-25 19:26 ` Paul Kocialkowski [this message]
2019-07-03 12:28 ` [PATCH v3 2/3] media: uapi: h264: Add the concept of decoding mode Boris Brezillon
2019-07-22 15:29 ` Hans Verkuil
2019-07-22 17:54 ` Boris Brezillon
2019-07-22 19:00 ` Hans Verkuil
2019-07-25 19:20 ` Paul Kocialkowski
2019-07-03 12:28 ` [PATCH v3 3/3] media: uapi: h264: Get rid of the p0/b0/b1 ref-lists Boris Brezillon
2019-07-03 17:18 ` Nicolas Dufresne
2019-07-05 15:24 ` Ezequiel Garcia
2019-07-24 3:39 ` Tomasz Figa
2019-07-24 5:46 ` Boris Brezillon
2019-07-25 19:38 ` Paul Kocialkowski
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=20190725192610.GC14499@aptenodytes \
--to=paul.kocialkowski@bootlin.com \
--cc=acourbot@chromium.org \
--cc=boris.brezillon@collabora.com \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).