Hi, On Tue, 2019-06-04 at 11:05 +0200, Boris Brezillon wrote: > On Tue, 4 Jun 2019 10:55:03 +0200 > Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > > On Mon, Jun 03, 2019 at 02:52:44PM -0400, Nicolas Dufresne wrote: > > [...] > > > There is one thing that come up though, if we enable per-frame decoding > > > on top of per-slice decoder (like Cedrus), won't we force userspace to > > > always compute l0/l1 even though the HW might be handling that ? Shall > > > we instead pass the modification list and implement the non-parsing > > > bits of applying the modifications in the kernel ? > > > > Applying the modifications is a standard procedure, right? If it's > > completely driver-agnostic, it sounds to me like the right place to > > perform the operation is in userspace. > > Well, the counter argument to that is "drivers know better what's > needed by the HW", and if we want to avoid doing useless work without > having complex caps checking done in userspace, doing this task > kenel-side makes sense. I believe we should also try and alleviate the pain on the user-space side by having these decoder-specific details handled by the kernel. It also brings us closer to bitstream format (where the modifications are coded) and leaves DPB management to the decoder/driver, which IMO makes a lot of sense. Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com
