From: Hans Verkuil <hverkuil@xs4all.nl>
To: Philipp Zabel <p.zabel@pengutronix.de>, linux-media@vger.kernel.org
Cc: Tomasz Figa <tfiga@chromium.org>,
Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
Ezequiel Garcia <ezequiel@collabora.com>,
Boris Brezillon <boris.brezillon@collabora.com>,
kernel@pengutronix.de
Subject: Re: [PATCH 2/2] media: uapi: h264: clarify pic_order_cnt_bit_size field
Date: Thu, 26 Sep 2019 16:16:39 +0200 [thread overview]
Message-ID: <5df2e20e-b9e3-4a79-956e-e4d5c9f4a996@xs4all.nl> (raw)
In-Reply-To: <1569506956.3011.7.camel@pengutronix.de>
On 9/26/19 4:09 PM, Philipp Zabel wrote:
> Hi Hans,
>
> On Thu, 2019-09-26 at 15:23 +0200, Hans Verkuil wrote:
>> On 9/5/19 3:12 PM, Philipp Zabel wrote:
>>> Since pic_order_cnt_bit_size is not a syntax element itself, explicitly
>>> state that it is the total size in bits of the pic_order_cnt_lsb,
>>> delta_pic_order_cnt_bottom, delta_pic_order_cnt[0], and
>>> delta_pic_order_cnt[1] syntax elements contained in the slice.
>>>
>>> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
>>> ---
>>> Documentation/media/uapi/v4l/ext-ctrls-codec.rst | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
>>> index c281bc7ed1b3..08b49b2bbfa8 100644
>>> --- a/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
>>> +++ b/Documentation/media/uapi/v4l/ext-ctrls-codec.rst
>>> @@ -1799,7 +1799,8 @@ enum v4l2_mpeg_video_h264_hierarchical_coding_type -
>>> - Size in bits of the dec_ref_pic_marking() syntax element.
>>> * - __u32
>>> - ``pic_order_cnt_bit_size``
>>> - -
>>> + - Size in bits of the pic_order_cnt_lsb, delta_pic_order_cnt_bottom,
>>> + delta_pic_order_cnt[0], and delta_pic_order_cnt[1] syntax elements.
>>
>> It's a little bit ambiguous: this field contains the size in bits of all these
>> fields combined, right? Not the size in bits of each field separately.
>
> Yes.
>
>> I.e. if these fields are all 8 bits, then pic_order_cnt_bit_size is 4*8 and
>> not just 8.
>
> The size of pic_order_cnt_lsb is determined by another field's value
> (log2_max_pic_order_cnt_lsb_minus4), and the other three are
> exponential-Golomb coded, so each can be of different length (including
> zero).
>
>> I think this should be rephrased.
>
> Ok, how about:
>
> "Combined size in bits of the picture order count related syntax
> elements: pic_order_cnt_lsb, delta_pic_order_cnt_bottom,
> delta_pic_order_cnt[0], and delta_pic_order_cnt[1]."
That's better.
>
> Actually, there's either pic_order_cnt_lsb + (optionally)
> delta_pic_order_cnt_bottom present, or delta_pic_order_cnt[0] +
> (optionally) delta_pic_order_cnt[1], never all four. Describing that in
> the uapi docs seemed overly verbose, though.
I agree.
Regards,
Hans
The relevant part in the
> slice_header() syntax spec looks like this:
>
> if (pic_order_cnt_type == 0) {
> pic_order_cnt_lsb
> if (bottom_field_pic_order_in_frame_present_flag && !field_pic_flag)
> delta_pic_order_cnt_bottom
> }
> if (pic_order_cnt_type == 1 && !delta_pic_order_always_zero_flag) {
> delta_pic_order_cnt[0]
> if (bottom_field_pic_order_in_frame_present_flag && !field_pic_flag)
> delta_pic_order_cnt[1]
> }
>
> pic_order_cnt_bit_size is supposed to be the size in bits of this whole
> block. pic_order_cnt_type and log2_max_pic_order_cnt_lsb_minus4 are from
> the SPS header, bottom_field_pic_order_in_frame_present_flag is from the
> PPS header, and field_pic_flag is contained earlier in the slice header.
>
> regards
> Philipp
>
prev parent reply other threads:[~2019-09-26 14:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 13:12 [PATCH 1/2] media: uapi: h264: clarify dec_ref_pic_marking_bit_size fields Philipp Zabel
2019-09-05 13:12 ` [PATCH 2/2] media: uapi: h264: clarify pic_order_cnt_bit_size field Philipp Zabel
2019-09-26 13:23 ` Hans Verkuil
2019-09-26 14:09 ` Philipp Zabel
2019-09-26 14:16 ` Hans Verkuil [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=5df2e20e-b9e3-4a79-956e-e4d5c9f4a996@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=boris.brezillon@collabora.com \
--cc=ezequiel@collabora.com \
--cc=kernel@pengutronix.de \
--cc=linux-media@vger.kernel.org \
--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).