lkml.org 
[lkml]   [2020]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 00/14] Clean H264 stateless uAPI
Date
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@siol.net>

Best regards,
Jernej


\
 
 \ /
  Last update: 2020-09-01 23:43    [W:0.201 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site