From: Hans Verkuil <hverkuil@xs4all.nl>
To: Ezequiel Garcia <ezequiel@collabora.com>, linux-media@vger.kernel.org
Cc: kernel@collabora.com,
Nicolas Dufresne <nicolas.dufresne@collabora.com>,
Tomasz Figa <tfiga@chromium.org>,
linux-rockchip@lists.infradead.org,
Heiko Stuebner <heiko@sntech.de>, Jonas Karlman <jonas@kwiboo.se>,
Philipp Zabel <p.zabel@pengutronix.de>,
Boris Brezillon <boris.brezillon@collabora.com>,
Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
Alexandre Courbot <acourbot@chromium.org>,
fbuergisser@chromium.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 04/11] media: uapi: h264: Add the concept of start code
Date: Mon, 12 Aug 2019 13:57:50 +0200 [thread overview]
Message-ID: <c4adc667-590b-438d-f8ef-ebcc7eee6004@xs4all.nl> (raw)
In-Reply-To: <95b8f8f8d5d4f6394cfd5858a29d507b7e77be2f.camel@collabora.com>
On 8/12/19 1:56 PM, Ezequiel Garcia wrote:
> On Mon, 2019-08-12 at 12:11 +0200, Hans Verkuil wrote:
>> On 8/8/19 12:34 PM, Ezequiel Garcia wrote:
>>> Stateless decoders have different expectations about the
>>> start code that is prepended on H264 slices. Add a
>>> menu control to express the supported start code types
>>> (including no start code).
>>>
>>> Drivers are allowed to support only one start code type,
>>> but they can support both too.
>>>
>>> Note that this is independent of the H264 decoding mode,
>>> which specifies the granularity of the decoding operations.
>>> Either in frame-based or slice-based mode, this new control
>>> will allow to define the start code expected on H264 slices.
>>>
>>> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
>>> ---
>>> Changes in v4:
>>> * New patch.
>>> ---
>>> .../media/uapi/v4l/ext-ctrls-codec.rst | 31 +++++++++++++++++++
>>> drivers/media/v4l2-core/v4l2-ctrls.c | 9 ++++++
>>> include/media/h264-ctrls.h | 6 ++++
>>> 3 files changed, 46 insertions(+)
>>>
>>> diff --git a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
>>> index ea0455957149..94fd3a9b8b9e 100644
>>> --- a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
>>> +++ b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
>>> @@ -2062,6 +2062,37 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>>> The OUTPUT buffer should contain all slices needed to decode the
>>> frame/field.
>>>
>>> +``V4L2_CID_MPEG_VIDEO_H264_STARTCODE (enum)``
>>> + Specifies the H264 slice start code expected for each slice.
>>> + This control shall e used to complement V4L2_PIX_FMT_H264_SLICE
>>
>> e -> be
>>
>>> + pixel format. Drivers may expose a single or multiple
>>> + start codes, depending on what they can support.
>>> +
>>> + .. note::
>>> +
>>> + This menu control is not yet part of the public kernel API and
>>> + it is expected to change.
>>> +
>>> +.. c:type:: v4l2_mpeg_video_h264_startcode
>>> +
>>> +.. cssclass:: longtable
>>> +
>>> +.. flat-table::
>>> + :header-rows: 0
>>> + :stub-columns: 0
>>> + :widths: 1 1 2
>>> +
>>> + * - ``V4L2_MPEG_VIDEO_H264_NO_STARTCODE``
>>> + - 0
>>> + - Selecting this value specifies that H264 slices are passed
>>> + to the driver without any start code.
>>> + Bla.
>>
>> Bla?
>>
>
> Well, despite how many times I reviewed this doc, it seems
> this slipped through :-(
>
>>> + * - ``V4L2_MPEG_VIDEO_H264_ANNEX_B_STARTCODE``
>>> + - 1
>>> + - Selecting this value specifies that H264 slices are expected
>>> + to be prefixed by Annex B start codes. According to :ref:`h264`
>>> + valid start codes can be 3-bytes 0x000001, or 4-bytes 0x00000001.
>>> +
>>
>> I had the impression that it is more common to require startcodes. If that's
>> indeed the case, shouldn't this have value 0 instead of 1?
>> 1?
>>
>
> I'm not sure this is indeed the case.
>
> For instance, VA-API accelerators work on H264 slices that are not
> prepended by the NALU start code.
>
> I'm fine flipping the values, but at this point, with only cedrus and hantro,
> there's doesn't seem to be a "natural" choice.
OK, let's keep this as-is then.
Regards,
Hans
>
> Thanks,
> Ezequiel
>
next prev parent reply other threads:[~2019-08-12 11:57 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-08 10:34 [PATCH v4 00/11] media: hantro: Add support for H264 decoding Ezequiel Garcia
2019-08-08 10:34 ` [PATCH v4 01/11] lib/sort.c: implement sort() variant taking context argument Ezequiel Garcia
2019-08-08 10:34 ` [PATCH v4 02/11] media: uapi: h264: Rename pixel format Ezequiel Garcia
2019-08-08 10:34 ` [PATCH v4 03/11] media: uapi: h264: Add the concept of decoding mode Ezequiel Garcia
2019-08-12 10:19 ` Hans Verkuil
2019-08-12 11:59 ` Ezequiel Garcia
2019-08-08 10:34 ` [PATCH v4 04/11] media: uapi: h264: Add the concept of start code Ezequiel Garcia
2019-08-12 10:11 ` Hans Verkuil
2019-08-12 11:56 ` Ezequiel Garcia
2019-08-12 11:57 ` Hans Verkuil [this message]
2019-08-08 10:34 ` [PATCH v4 05/11] media: uapi: h264: Get rid of the p0/b0/b1 ref-lists Ezequiel Garcia
2019-08-12 10:20 ` Hans Verkuil
2019-08-12 10:53 ` Ezequiel Garcia
2019-08-08 10:34 ` [PATCH v4 06/11] media: cedrus: Cleanup control initialization Ezequiel Garcia
2019-08-08 10:34 ` [PATCH v4 07/11] media: cedrus: Specify the required H264 start code Ezequiel Garcia
2019-08-08 10:34 ` [PATCH v4 08/11] media: hantro: Move copy_metadata() before doing a decode operation Ezequiel Garcia
2019-08-08 10:34 ` [PATCH v4 09/11] media: hantro: Add core bits to support H264 decoding Ezequiel Garcia
2019-08-08 10:34 ` [PATCH v4 10/11] media: hantro: Add support for H264 decoding on G1 Ezequiel Garcia
2019-08-08 10:34 ` [PATCH v4 11/11] media: hantro: Enable H264 decoding on rk3288 Ezequiel Garcia
2019-08-12 10:41 ` [PATCH v4 00/11] media: hantro: Add support for H264 decoding Philipp Zabel
2019-08-12 18:45 ` Ezequiel Garcia
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=c4adc667-590b-438d-f8ef-ebcc7eee6004@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=acourbot@chromium.org \
--cc=boris.brezillon@collabora.com \
--cc=ezequiel@collabora.com \
--cc=fbuergisser@chromium.org \
--cc=heiko@sntech.de \
--cc=jonas@kwiboo.se \
--cc=kernel@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.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 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).