All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paulk@sys-base.io>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Cc: Daniel Almeida <dwlsalmeida@gmail.com>,
	Adam Ford <aford173@gmail.com>,
	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,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	Gustavo Padovan <gus@collabora.com>
Subject: Re: Hantro H1 Encoding Upstreaming
Date: Sat, 18 Jan 2025 18:00:17 +0100	[thread overview]
Message-ID: <Z4veIWQC8ARKEPzI@collins> (raw)
In-Reply-To: <a6e7a9a0426df1902965262328d1da8e9339b952.camel@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]

Hi,

Le Wed 15 Jan 25, 14:51, Nicolas Dufresne a écrit :
> Le mercredi 15 janvier 2025 à 16:03 +0100, Paul Kocialkowski a écrit :
> > We could have some common per-codec bitstream generation v4l2 code with either
> > a cpu buffer access backend or a driver-specific implementation for writing the
> > bits. I already have a base for this in my cedrus h264 encoder work:
> > https://github.com/bootlin/linux/blob/cedrus/h264-encoding/drivers/staging/media/sunxi/cedrus/cedrus_enc_h264.c#L722
> 
> There is a lot of code in there that you can throw directly into v4l2-h264, this
> is exactly what that library is meant for. It had never meant to be limited to
> generating intermediate reference lists for decoders, or to be decoder specific.
> Note that golomb coding can further be generalized.
> 
> I do agree at least for now that letting the driver write headers have more
> advantages. It allows notably to turn off the knobs that would not otherwise be
> supported.

Yes it seems common that hardware will not support certain features or values
and need some bitstream values set to some hard-coded values. There's also
various controls for the stateful API that define most of the basic things that
can be configured in the SPS/PPS. Then each driver exposing what it supports
is a pretty good fit.

> The modification would of course be reference at s_ctrl time,
> assuming you reuse existing sps/pps and other similar compound controls. As we
> didn't have encoder in mind when we created these compound controls, its
> possible that we'll have to add an extended one to fill the gaps, which has
> always been the plan.

I'm not really sure it's needed to pass the whole pps/sps in controls.
Reusing the individual stafeul controls feels like a good fit from what I can
see. And yes we'd need some extra info to be passed from userspace about things
like frame type, qp, etc that will impact the generated bitstream.

Paul

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2025-01-18 17:00 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
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 [this message]
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=Z4veIWQC8ARKEPzI@collins \
    --to=paulk@sys-base.io \
    --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=nicolas.dufresne@collabora.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.