public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: nicolas@ndufresne.ca (Nicolas Dufresne)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-sunxi] Cedrus driver
Date: Thu, 16 Nov 2017 14:59:55 -0500	[thread overview]
Message-ID: <1510862395.8053.39.camel@ndufresne.ca> (raw)
In-Reply-To: <20171116110204.poakahqjz4sj7pmu@flea>

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.

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.

regards,
Nicolas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171116/b9fdd8c2/attachment.sig>

  reply	other threads:[~2017-11-16 19:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-07 12:59 [PATCH 1/1] add mali r6p2 dt node Giulio Benetti
2017-11-07 13:02 ` Maxime Ripard
     [not found] ` <1b12fa21-bfe6-9ba7-ae1d-8131ac6f4668@micronovasrl.com>
     [not found]   ` <6fcdc0d9-d0f8-785a-bb00-b1b41c684e59@imkreisrum.de>
2017-11-16 10:37     ` [linux-sunxi] Cedrus driver Giulio Benetti
2017-11-16 11:02       ` Maxime Ripard
2017-11-16 19:59         ` Nicolas Dufresne [this message]
2017-11-17  8:01           ` Maxime Ripard

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=1510862395.8053.39.camel@ndufresne.ca \
    --to=nicolas@ndufresne.ca \
    --cc=linux-arm-kernel@lists.infradead.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