From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Nicolas Dufresne <nicolas@ndufresne.ca>
Cc: Giulio Benetti <giulio.benetti@micronovasrl.com>,
Andreas Baierl <list@imkreisrum.de>,
linux-sunxi@googlegroups.com, robh+dt@kernel.org,
mark.rutland@arm.com, linux@armlinux.org.uk, wens@csie.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, thomas@vitsch.nl,
linux-media@vger.kernel.org
Subject: Re: [linux-sunxi] Cedrus driver
Date: Fri, 17 Nov 2017 09:01:27 +0100 [thread overview]
Message-ID: <20171117080127.mtfkehxbofk56alv@flea> (raw)
In-Reply-To: <1510862395.8053.39.camel@ndufresne.ca>
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
prev parent reply other threads:[~2017-11-17 8:01 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1510059543-7064-1-git-send-email-giulio.benetti@micronovasrl.com>
[not found] ` <1b12fa21-bfe6-9ba7-ae1d-8131ac6f4668@micronovasrl.com>
[not found] ` <6fcdc0d9-d0f8-785a-bb00-b1b41c684e59@imkreisrum.de>
[not found] ` <693e8786-af83-9d77-0fd4-50fa1f6a135f@micronovasrl.com>
2017-11-16 11:02 ` [linux-sunxi] Cedrus driver Maxime Ripard
2017-11-16 12:30 ` Giulio Benetti
2017-11-16 12:53 ` Maxime Ripard
2017-11-16 12:57 ` Giulio Benetti
2017-11-16 13:12 ` Hans Verkuil
2017-11-16 13:17 ` Giulio Benetti
2017-11-16 13:39 ` Maxime Ripard
2017-11-16 13:42 ` Giulio Benetti
2017-11-28 0:03 ` Giulio Benetti
2017-11-28 8:35 ` Maxime Ripard
2017-11-28 9:50 ` Giulio Benetti
2017-11-28 11:20 ` Thomas van Kleef
2017-11-28 11:26 ` Giulio Benetti
2017-11-28 11:29 ` Thomas van Kleef
2017-11-28 11:54 ` Giulio Benetti
2017-11-28 12:31 ` Thomas van Kleef
2017-11-28 12:52 ` Maxime Ripard
2017-11-28 13:03 ` Giulio Benetti
2017-11-28 13:07 ` Maxime Ripard
2017-11-28 13:12 ` Giulio Benetti
2017-11-28 15:17 ` Maxime Ripard
2017-11-28 15:19 ` Giulio Benetti
2017-11-28 12:26 ` Maxime Ripard
2017-11-28 14:51 ` Thomas van Kleef
2017-11-28 15:35 ` Maxime Ripard
2017-11-29 15:36 ` Thomas van Kleef
2017-11-30 15:24 ` Maxime Ripard
2017-11-16 13:39 ` Hans Verkuil
2017-11-16 19:59 ` Nicolas Dufresne
2017-11-17 8:01 ` Maxime Ripard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171117080127.mtfkehxbofk56alv@flea \
--to=maxime.ripard@free-electrons.com \
--cc=devicetree@vger.kernel.org \
--cc=giulio.benetti@micronovasrl.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=linux@armlinux.org.uk \
--cc=list@imkreisrum.de \
--cc=mark.rutland@arm.com \
--cc=nicolas@ndufresne.ca \
--cc=robh+dt@kernel.org \
--cc=thomas@vitsch.nl \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox