lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 25 Jul 2020 23:34:00 +0900
From:   Alexandre Courbot <acourbot@...omium.org>
To:     Ezequiel Garcia <ezequiel@...labora.com>
Cc:     Linux Media Mailing List <linux-media@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Tomasz Figa <tfiga@...omium.org>, kernel@...labora.com,
        Jonas Karlman <jonas@...boo.se>,
        Hans Verkuil <hverkuil@...all.nl>,
        Jeffrey Kardatzke <jkardatzke@...omium.org>,
        Nicolas Dufresne <nicolas.dufresne@...labora.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Maxime Ripard <mripard@...nel.org>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Subject: Re: [PATCH 08/10] media: uapi: h264: Clean slice invariants syntax elements

On Thu, Jul 16, 2020 at 5:23 AM Ezequiel Garcia <ezequiel@...labora.com> wrote:
>
> The H.264 specification requires in its "Slice header semantics"
> section that the following values shall be the same in all slice headers:
>
>   pic_parameter_set_id
>   frame_num
>   field_pic_flag
>   bottom_field_flag
>   idr_pic_id
>   pic_order_cnt_lsb
>   delta_pic_order_cnt_bottom
>   delta_pic_order_cnt[ 0 ]
>   delta_pic_order_cnt[ 1 ]
>   sp_for_switch_flag
>   slice_group_change_cycle
>
> and can therefore be moved to the per-frame decode parameters control.

I am really not a H.264 expert, so this question may not be relevant,
but are these values specified for every slice header in the
bitstream, or are they specified only once per frame?

I am asking this because it would certainly make user-space code
simpler if we could remain as close to the bitstream as possible. If
these values are specified once per slice, then factorizing them would
leave user-space with the burden of deciding what to do if they change
across slices.

Note that this is a double-edged sword, because it is not necessarily
better to leave the firmware in charge of deciding what to do in such
a case. :) So hopefully these are only specified once per frame in the
bitstream, in which case your proposal makes complete sense.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ