linux-kernel - Re: Stateless Encoding uAPI Discussion and Proposal

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]

Message-ID: <c6a222be5eee962581cf5dcb9a1473cf45ff303c.camel@collabora.com>
Date:   Mon, 24 Jul 2023 10:03:12 -0400
From:   Nicolas Dufresne <nicolas.dufresne@...labora.com>
To:     Michael Grzeschik <mgr@...gutronix.de>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Cc:     linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        Hans Verkuil <hverkuil@...all.nl>,
        Sakari Ailus <sakari.ailus@....fi>,
        Andrzej Pietrasiewicz <andrzej.p@...labora.com>,
        Michael Tretter <m.tretter@...gutronix.de>,
        Jernej Škrabec <jernej.skrabec@...il.com>,
        Chen-Yu Tsai <wens@...e.org>,
        Samuel Holland <samuel@...lland.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: Stateless Encoding uAPI Discussion and Proposal

Le vendredi 21 juillet 2023 à 20:19 +0200, Michael Grzeschik a écrit :
> > As a result, we cannot expect that any given encoder is able to produce frames
> > for any set of headers. Reporting related constraints and limitations (beyond
> > profile/level) seems quite difficult and error-prone.
> > 
> > So it seems that keeping header generation in-kernel only (close to where the
> > hardware is actually configured) is the safest approach.
> 
> For the case with the rkvenc, the headers are also not created by the
> kernel driver. Instead we use the gst_h264_bit_writer_sps/pps functions
> that are part of the codecparsers module.

One level of granularity we can add is split headers (like SPS/PPS) and
slice/frame headers. It remains that in some cases, like HEVC, when the slice
header is byte aligned, it can be nice to be able to handle it at application
side in order to avoid limiting SVC support (and other creative features) by our
API/abstraction limitations. I think a certain level of "per CODEC" reasoning is
also needed. Just like, I would not want to have to ask the kernel to generate
user data SEI and other in-band data.

regards,
Nicolas