[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4d08d98d853d78bbb6dba826d30c3386fe0b31e8.camel@collabora.com>
Date: Wed, 30 Aug 2023 11:10:52 -0400
From: Nicolas Dufresne <nicolas.dufresne@...labora.com>
To: Hsia-Jun Li <Randy.Li@...aptics.com>,
Paul Kocialkowski <paul.kocialkowski@...tlin.com>
Cc: linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
Hans Verkuil <hverkuil@...all.nl>,
Sakari Ailus <sakari.ailus@....fi>,
Andrzej Pietrasiewicz <andrzej.p@...labora.com>,
Michael Tretter <m.tretter@...gutronix.de>,
Jernej Škrabec <jernej.skrabec@...il.com>,
Chen-Yu Tsai <wens@...e.org>,
Samuel Holland <samuel@...lland.org>,
Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: Stateless Encoding uAPI Discussion and Proposal
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
Powered by blists - more mailing lists