linux-kernel - Re: [linux-sunxi] Cedrus driver

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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 17 Nov 2017 09:01:27 +0100
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     Nicolas Dufresne <nicolas@...fresne.ca>
Cc:     Giulio Benetti <giulio.benetti@...ronovasrl.com>,
        Andreas Baierl <list@...reisrum.de>,
        linux-sunxi@...glegroups.com, robh+dt@...nel.org,
        mark.rutland@....com, linux@...linux.org.uk, wens@...e.org,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, thomas@...sch.nl,
        linux-media@...r.kernel.org
Subject: Re: [linux-sunxi] Cedrus driver

Hi Nicolas,

On Thu, Nov 16, 2017 at 02:59:55PM -0500, Nicolas Dufresne wrote:
> Le jeudi 16 novembre 2017 à 12:02 +0100, Maxime Ripard a écrit :
> > Assuming that the request API is in, we'd need to:
> >   - Finish the MPEG4 support
> >   - Work on more useful codecs (H264 comes to my mind)
> 
> For which we will have to review the tables and make sure they match
> the spec (the easy part). But as an example, that branch uses a table
> that merge Mpeg4 VOP and VOP Short Header. We need to make sure it does
> not pause problems or split it up. On top of that, ST and Rockchip
> teams should give some help and sync with these tables on their side.
> We also need to consider decoder like Tegra 2. In H264, they don't need
> frame parsing, but just the PPS/SPS data (might just be parsed in the
> driver, like CODA ?). There is other mode of operation, specially in
> H264/HEVC low latency, where the decoder will be similar, but will
> accept and process slices right away, without waiting for the full
> frame.

Sorry if it's a dumb question, but what branches and tables are you
talking about here?

> We also need some doc, to be able to tell the GStreamer and FFMPEG team
> how to detect and handle these decoder. I doubt the libv4l2 proposed
> approach will be used for these two projects since they already have
> their own parser and would like to not parse twice. As an example, we
> need to document that V4L2_PIX_FMT_MPEG2_FRAME implies using the
> Request API and specific CID. We should probably also ping the Chrome
> Devs, which probably have couple of pending branches around this.

We've had a prototype that wasn't based on libv4l but was based on the
VA-API, and it's been working great for us so far.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Download attachment "signature.asc" of type "application/pgp-signature" (802 bytes)