public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Daniel Almeida <dwlsalmeida@gmail.com>, Adam Ford <aford173@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>,
	andrzejtp2010@gmail.com, Frank Li	 <frank.li@nxp.com>,
	ming.qian@oss.nxp.com, linux-media	 <linux-media@vger.kernel.org>,
	linux-imx@nxmp.com, paulk@sys-base.io,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	Gustavo Padovan <gus@collabora.com>
Subject: Re: Hantro H1 Encoding Upstreaming
Date: Tue, 14 Jan 2025 11:16:47 -0500	[thread overview]
Message-ID: <a393b3324c60c2c13994d34ca90faf4eb604ae43.camel@collabora.com> (raw)
In-Reply-To: <A3476357-8D8D-4B82-8CAB-58370BECF575@gmail.com>

Hi everyone,

despite Andrzej having left the community, we are not giving up on the encoder
work. In 2025, we aim at working more seriously on the V4L2 spec, as just
writing driver won't cut it. Each class of codecs needs a general workflow spec
similar to what we have already for stateful encoder/decoder and stateless
decoder.

- https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-decoder.html
- https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-encoder.html
- https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/dev-stateless-decoder.html

It is on top of this, that for each codec we have to add controls (mostly
compound) specifics and details that suites stateless accelerators.

From a community stand point, the most important focus is to write and agree on
spec and controls. Once we have that, vendors will be able to slowly move away
from their custom solution, and compete on actual hardware rather then
integration.

It is also time to start looking toward the future, since Hantro H1 is very
limited and ancient encoder. On same brand, if someone could work on VC8000E
shipped on IMX8M Plus, or Rockchip codecs, that will certainly help progress. We
can also get inspiration from many other stateless encoding APIs now, notably
VA, DXVA and Vulkan Video.

Of course, folks likes to know when this will happen, stateless decoders took 5
years from start to the first codec being merged, hopefully we don't beat that
record. I personally aim for producing work during the summer, and mostly focus
on the spec. Its obvious for me that testing on H1 with a GStreamer
implementation is the most productive, though I have strong interest in having
an ecosystem of drivers. A second userspace implementation, perhaps ffmpeg ?,
could also be useful.

If you'd like to take a bite, this is a good thread to discuss forward. Until
the summer, I planned to reach to Paul, who made this great presentation [1] at
FOSDEM last year and start moving the RFC into using these ideas. One of the
biggest discussion is rate control, it is clear to me that modern HW integrated
RC offloading, though some HW specific knobs or even firmware offloading, and
this is what Paul has been putting some thought into.

If decoders have progressed so much in quality in the last few years, it is
mostly before we have better ways to test them. It is also needed to start
thinking how do we want to test our encoders. The stateful scene is not all
green, with a very organic groth and difficult to unify set of encoders. And we
have no metric of how good or bad they are either.

regards,
Nicolas

Le lundi 13 janvier 2025 à 18:08 -0300, Daniel Almeida a écrit :
> +cc Nicolas
> 
> 
> Hey Adam,
> 
> 
> > 
> > Daniel,
> > 
> > Do you know if anyone will be picking up the H1 encoder?
> > 
> > adam
> > > 
> > > — Daniel
> > > 
> > 
> 
> I think my colleague Nicolas is the best person to answer this.
> 
> — Daniel


  reply	other threads:[~2025-01-14 16:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-13 20:25 Hantro H1 Encoding Upstreaming Fabio Estevam
2025-01-13 20:28 ` Fabio Estevam
2025-01-13 20:38   ` Daniel Almeida
2025-01-13 20:54     ` Adam Ford
2025-01-13 21:08       ` Daniel Almeida
2025-01-14 16:16         ` Nicolas Dufresne [this message]
2025-01-14 18:01           ` Andrzej Pietrasiewicz
2025-01-14 18:06             ` Nicolas Dufresne
2025-01-15 11:31           ` Adam Ford
2025-01-15 13:53           ` Michael Tretter
2025-01-15 15:03           ` Paul Kocialkowski
2025-01-15 19:43             ` Nicolas Dufresne
2025-01-18 16:49               ` Paul Kocialkowski
2025-01-15 19:51             ` Nicolas Dufresne
2025-01-18 17:00               ` Paul Kocialkowski
2025-01-15 20:14             ` Nicolas Dufresne
2025-01-18 17:15               ` Paul Kocialkowski

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=a393b3324c60c2c13994d34ca90faf4eb604ae43.camel@collabora.com \
    --to=nicolas.dufresne@collabora.com \
    --cc=aford173@gmail.com \
    --cc=andrzejtp2010@gmail.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=dwlsalmeida@gmail.com \
    --cc=festevam@gmail.com \
    --cc=frank.li@nxp.com \
    --cc=gus@collabora.com \
    --cc=linux-imx@nxmp.com \
    --cc=linux-media@vger.kernel.org \
    --cc=ming.qian@oss.nxp.com \
    --cc=paulk@sys-base.io \
    /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