All of lore.kernel.org
 help / color / mirror / Atom feed
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>,
	Boris Brezillon <boris.brezillon@collabora.com>
Subject: [PATCH v2 1/3] media: uapi: h264: Clarify our expectations regarding NAL header format
Date: Mon, 10 Jun 2019 10:52:48 +0200	[thread overview]
Message-ID: <20190610085250.3255-2-boris.brezillon@collabora.com> (raw)
In-Reply-To: <20190610085250.3255-1-boris.brezillon@collabora.com>

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>
---
Changes in v2:
* None

Note: we might want to add a nal_header_size field to allow drivers to
quickly find where the actual payload start. That'd be particularly
useful here since ANNEX B start codes can be of arbitrary size
(2+(0x00 bytes) + 1(0x01 byte)). The other option would be to enforce
the number of leading 0x00 bytes (a minimum of 2 is required).
---
 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 d6ea2ffd65c5..82547d5de250 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.20.1


  reply	other threads:[~2019-06-10  8:52 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 ` Boris Brezillon [this message]
2019-06-26 11:23   ` [PATCH v2 1/3] media: uapi: h264: Clarify our expectations regarding NAL header format 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 ` [PATCH v2 0/3] media: uapi: h264: First batch of adjusments Boris Brezillon

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=20190610085250.3255-2-boris.brezillon@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.