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@xxxxxxxx> Best regards, Jernej
