From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31C99C282CE for ; Tue, 4 Jun 2019 09:09:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 07D0624CB3 for ; Tue, 4 Jun 2019 09:09:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727068AbfFDJJM (ORCPT ); Tue, 4 Jun 2019 05:09:12 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:47987 "EHLO relay7-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726873AbfFDJJM (ORCPT ); Tue, 4 Jun 2019 05:09:12 -0400 X-Originating-IP: 90.88.144.139 Received: from aptenodytes (aaubervilliers-681-1-24-139.w90-88.abo.wanadoo.fr [90.88.144.139]) (Authenticated sender: paul.kocialkowski@bootlin.com) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id C005020009; Tue, 4 Jun 2019 09:09:07 +0000 (UTC) Message-ID: Subject: Re: Proposed updates and guidelines for MPEG-2, H.264 and H.265 stateless support From: Paul Kocialkowski To: Boris Brezillon , Thierry Reding Cc: Nicolas Dufresne , Linux Media Mailing List , Hans Verkuil , Tomasz Figa , Alexandre Courbot , Maxime Ripard , Jernej Skrabec , Ezequiel Garcia , Jonas Karlman Date: Tue, 04 Jun 2019 11:09:07 +0200 In-Reply-To: <20190604110527.48d16907@collabora.com> References: <0be542fabc57c38596bdb1db44aead7054a89158.camel@bootlin.com> <20190603112449.GA30132@ulmo> <20190604085503.GE9048@ulmo> <20190604110527.48d16907@collabora.com> Organization: Bootlin Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi, On Tue, 2019-06-04 at 11:05 +0200, Boris Brezillon wrote: > On Tue, 4 Jun 2019 10:55:03 +0200 > Thierry Reding 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