linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Hsia-Jun Li <Randy.Li@synaptics.com>,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Cc: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	"Hans Verkuil" <hverkuil@xs4all.nl>,
	"Sakari Ailus" <sakari.ailus@iki.fi>,
	"Andrzej Pietrasiewicz" <andrzej.p@collabora.com>,
	"Michael Tretter" <m.tretter@pengutronix.de>,
	"Jernej Škrabec" <jernej.skrabec@gmail.com>,
	"Chen-Yu Tsai" <wens@csie.org>,
	"Samuel Holland" <samuel@sholland.org>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: Stateless Encoding uAPI Discussion and Proposal
Date: Wed, 30 Aug 2023 11:10:52 -0400	[thread overview]
Message-ID: <4d08d98d853d78bbb6dba826d30c3386fe0b31e8.camel@collabora.com> (raw)
In-Reply-To: <52e9b710-5011-656b-aebf-8d57e6496ddd@synaptics.com>

Le mercredi 23 août 2023 à 11:04 +0800, Hsia-Jun Li a écrit :
> > Though, if we drop the GOP structure and favour this approach, the latency could
> > be regain later by introducing fence base streaming. The technique would be for
> > a video source (like a capture driver) to pass dmabuf that aren't filled yet,
> > but have a companion fence. This would allow queuing requests ahead of time, and
> > all we need is enough pre-allocation to accommodate the desired look ahead. Only
> > issue is that perhaps this violates the fundamental of "short term" delivery of
> > fences. But fences can also fail I think, in case the capture was stopped.
> > 
> I don't think it would help. Fence is a thing for DRM/GPU without a queue.
> Even with a fence, would the video sink tell us the motion delta here?

It helps with the latency since the encoder can start its search and analyzes as
soon as frames are available, instead of until you have all N frames available
(refer to the MIN_BUFFER_FOR controls used when lookahead is needed).

> > We can certainly move forward with this as a future solution, or just don't
> > implement future aware RC algorithm in term to avoid the huge task this involves
> > (and possibly patents?)
> > 
> I think we should not restrict how the userspace(vendor) operate the 
> hardware.

Omitting is not restricting. Vendors have to learn to be community members and
propose/add the tools and APIs they need to support their features. We cannot
fix vendors in this regard, those who jumps over that fence are wining.

Nicolas

  reply	other threads:[~2023-08-30 18:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-11 17:12 Stateless Encoding uAPI Discussion and Proposal Paul Kocialkowski
2023-07-11 18:18 ` Nicolas Dufresne
2023-07-12 14:07   ` Paul Kocialkowski
2023-07-25  3:33     ` Hsia-Jun Li
2023-07-25 12:15       ` Paul Kocialkowski
2023-07-26  2:49         ` Hsia-Jun Li
2023-07-26 19:53           ` Nicolas Dufresne
2023-07-27  2:45             ` Hsia-Jun Li
2023-07-27 17:10               ` Nicolas Dufresne
2023-07-26  8:18   ` Hans Verkuil
2023-08-09 14:43     ` Paul Kocialkowski
2023-08-09 17:24       ` Andrzej Pietrasiewicz
2023-07-21 18:19 ` Michael Grzeschik
2023-07-24 14:03   ` Nicolas Dufresne
2023-07-25  9:09     ` Paul Kocialkowski
2023-07-26 20:02       ` Nicolas Dufresne
2023-08-10 13:44 ` Paul Kocialkowski
2023-08-10 14:34   ` Nicolas Dufresne
2023-08-11 20:08     ` Paul Kocialkowski
2023-08-21 15:13       ` Nicolas Dufresne
2023-08-22  8:30         ` Hsia-Jun Li
2023-08-22 20:31           ` Nicolas Dufresne
2023-08-23  3:04             ` Hsia-Jun Li
2023-08-30 15:10               ` Nicolas Dufresne [this message]
2023-08-30 16:51                 ` Randy Li
2023-08-30 15:18               ` Nicolas Dufresne
2023-08-31  9:32                 ` Hsia-Jun Li
2023-08-23  8:05         ` Paul Kocialkowski
2023-11-15 13:19           ` 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=4d08d98d853d78bbb6dba826d30c3386fe0b31e8.camel@collabora.com \
    --to=nicolas.dufresne@collabora.com \
    --cc=Randy.Li@synaptics.com \
    --cc=andrzej.p@collabora.com \
    --cc=hverkuil@xs4all.nl \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=m.tretter@pengutronix.de \
    --cc=paul.kocialkowski@bootlin.com \
    --cc=sakari.ailus@iki.fi \
    --cc=samuel@sholland.org \
    --cc=thomas.petazzoni@bootlin.com \
    --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;
as well as URLs for NNTP newsgroup(s).