From: Ezequiel Garcia <ezequiel@collabora.com>
To: Boris Brezillon <boris.brezillon@collabora.com>,
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>,
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: Fri, 05 Jul 2019 13:40:03 -0300 [thread overview]
Message-ID: <2f836ff0ce9ea68329a81e83109e53e24f7783c6.camel@collabora.com> (raw)
In-Reply-To: <20190703122849.6316-2-boris.brezillon@collabora.com>
Hi Boris, Paul,
On Wed, 2019-07-03 at 14:28 +0200, 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.
>
> 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.
>
Currently, the H264 slice V4L2_PIX_FMT_H264_SLICE_RAW,
is specified to _not_ contain the ANNEX B start code.
As you know, this is used in the cedrus driver, which is not
expecting the start code.
What's the plan regarding that?
Thanks,
Ezequiel
next prev parent reply other threads:[~2019-07-05 16:40 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 [this message]
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
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=2f836ff0ce9ea68329a81e83109e53e24f7783c6.camel@collabora.com \
--to=ezequiel@collabora.com \
--cc=acourbot@chromium.org \
--cc=boris.brezillon@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 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).