[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc423e4144e1c9ea32f6adbaa8319e38f1443896.camel@ndufresne.ca>
Date: Fri, 19 Jul 2024 11:36:07 -0400
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Benjamin Gaignard <benjamin.gaignard@...labora.com>, Hans Verkuil
<hverkuil-cisco@...all.nl>, mchehab@...nel.org,
ezequiel@...guardiasur.com.ar
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-rockchip@...ts.infradead.org, kernel@...labora.com
Subject: Re: [PATCH v4 0/2] Enumerate all pixels formats
Hi,
Le vendredi 19 juillet 2024 à 15:47 +0200, Benjamin Gaignard a écrit :
> > What exactly is the problem you want to solve? A real-life problem, not a theoretical
> > one :-)
>
> On real-life: on a board with 2 different stateless decoders being able to detect the
> one which can decode 10 bits bitstreams without testing all codec-dependent controls.
That leans toward giving an answer for the selected bitstream format though,
since the same driver may do 10bit HEVC without 10bit AV1.
For the use case, both Chromium and GStreamer have a need to categorized
decoders so that we avoid trying to use decoder that can't do that task. More
platforms are getting multiple decoders, and we also need to take into account
the available software decoders.
Just looking at the codec specific profile is insufficient since we need two
conditions to be met.
1. The driver must support 10bit for the specific CODEC (for most codec this is
profile visible)
2. The produced 10bit color format must be supported by userspace
In today's implementation, in order to test this, we'd need to simulate a 10bit
header control, so that when enumerating the formats we get a list of 10bit
(optionally 8bit too, since some decoder can downscale colors) and finally
verify that these pixel formats are know by userspace. This is not impossible,
but very tedious, this proposal we to try and make this easier.
Nicolas
Powered by blists - more mailing lists