linux-kernel - Re: [PATCH v2 00/14] Clean H264 stateless uAPI

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3072394.25LIjdDuC7@kista>
Date:   Tue, 11 Aug 2020 21:16:09 +0200
From:   Jernej Škrabec <jernej.skrabec@...l.net>
To:     linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        Ezequiel Garcia <ezequiel@...labora.com>
Cc:     Tomasz Figa <tfiga@...omium.org>, kernel@...labora.com,
        Jonas Karlman <jonas@...boo.se>,
        Hans Verkuil <hverkuil@...all.nl>,
        Alexandre Courbot <acourbot@...omium.org>,
        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>,
        Ezequiel Garcia <ezequiel@...labora.com>
Subject: Re: [PATCH v2 00/14] Clean H264 stateless uAPI

Hi!

Dne četrtek, 06. avgust 2020 ob 17:12:56 CEST je Ezequiel Garcia napisal(a):
> Here's a new round for the H.264 uAPI cleanup, which as discussed
> aims at being stabilized and promoted as a first-class public uAPI soon.
> 
> It should be noted that there is already GStreamer native
> support for this interface, which will be part of 1.18,
> once it's released.
> 
> I have pushed a branch porting GStreamer to
> support these interface changes:
> 
> https://gitlab.freedesktop.org/ezequielgarcia/gst-plugins-bad/-/commits/for_
> h264_uapi_v3
> 
> As was discussed the SLICE_PARAMS control is now clarified
> to work for one-slice-per-request operation, using CAPTURE
> buffer holding features. This is how Cedrus driver is implemented.
> 
> The other drivers currently supported Hantro and Rockchip VDEC,
> as well as the MTK stateless decoder posted by Alex Courbot
> operate in frame-based mode.
> 
> These "frame-based" devices parse the slice headers in hardware,
> and therefore shall not support SLICE_PARAMS. To that extent,
> the redundant bitstream fields are now part of the DECODE_PARAMS
> control.
> 
> Hopefully now the specification documentation is clear enough.
> GStreamer, Chromium and FFmpeg (which I'm sure will be implemented
> as soon as we stabilize the API) should serve as reference examples
> on how the API is consumed.
> 

I tested this series using https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.3.1 on Cedrus (Allwinner H6) using additional patch 
contained in discussion around patch 3 and I couldn't find any issue.

You can add to whole series:
Tested-by: Jernej Skrabec <jernej.skrabec@...l.net>

Best regards,
Jernej