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=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED,USER_AGENT_NEOMUTT 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 35E0AC43441 for ; Mon, 19 Nov 2018 14:12:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 04B7120870 for ; Mon, 19 Nov 2018 14:12:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 04B7120870 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729459AbeKTAgY (ORCPT ); Mon, 19 Nov 2018 19:36:24 -0500 Received: from mail.bootlin.com ([62.4.15.54]:47724 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726235AbeKTAgY (ORCPT ); Mon, 19 Nov 2018 19:36:24 -0500 Received: by mail.bootlin.com (Postfix, from userid 110) id 13C0720791; Mon, 19 Nov 2018 15:12:38 +0100 (CET) Received: from localhost (unknown [185.94.189.187]) by mail.bootlin.com (Postfix) with ESMTPSA id C4B9D20745; Mon, 19 Nov 2018 15:12:37 +0100 (CET) Date: Mon, 19 Nov 2018 15:12:37 +0100 From: Maxime Ripard To: Tomasz Figa Cc: Pawel Osciak , Hans Verkuil , Alexandre Courbot , Sakari Ailus , Laurent Pinchart , Paul Kocialkowski , Chen-Yu Tsai , Linux Kernel Mailing List , "list@263.net:IOMMU DRIVERS , Joerg Roedel ," , Linux Media Mailing List , Nicolas Dufresne , jenskuske@gmail.com, linux-sunxi@googlegroups.com, thomas.petazzoni@bootlin.com Subject: Re: [PATCH v2 0/2] media: cedrus: Add H264 decoding support Message-ID: <20181119141237.qwwdn27e6jwjvhmz@flea> References: <20181115145650.9827-1-maxime.ripard@bootlin.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="zmi43yrjnqz7zkau" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --zmi43yrjnqz7zkau Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Tomasz, On Fri, Nov 16, 2018 at 04:04:40PM +0900, Tomasz Figa wrote: > > I've been using the controls currently integrated into ChromeOS that > > have a working version of this particular setup. However, these > > controls have a number of shortcomings and inconsistencies with other > > decoding API. I've worked with libva so far, but I've noticed already > > that: > > - The kernel UAPI expects to have the nal_ref_idc variable, while > > libva only exposes whether that frame is a reference frame or > > not. I've looked at the rockchip driver in the ChromeOS tree, and > > our own driver, and they both need only the information about > > whether the frame is a reference one or not, so maybe we should > > change this? >=20 > Since this is something that is actually present in the stream and the > problem is that libva doesn't convey the information properly, I > believe you can workaround it in the libva backend using this API by > just setting it to 0 and some arbitrary non-zero value in a binary > fashion. That could work yes, thanks for the suggestion! > > - The H264 bitstream exposes the picture default reference list (for > > both list 0 and list 1), the slice reference list and an override > > flag. The libva will only pass the reference list to be used (so > > either the picture default's or the slice's) depending on the > > override flag. The kernel UAPI wants the picture default reference > > list and the slice reference list, but doesn't expose the override > > flag, which prevents us from configuring properly the > > hardware. Our video decoding engine needs the three information, > > but we can easily adapt to having only one. However, having two > > doesn't really work for us. > > >=20 > From what I can see in the H.264 Slice header, there are 3 related data: > - num_ref_idx_active_override_flag - affects the number of reference > indices for the slice, > - ref_list_l{0,1}_modifications - modifications for the reference lists, > - ref_pic_list_modification_flag_l{0,1} - selects whether the > modifications are applied. >=20 > The reference lists inside the v4l2_ctrl_h264_slice_param are expected > to already take all the above into account and be the final reference > lists to be used for the slice. For reference, the H.264 specification > refers to those final reference lists as RefPicList0 and RefPicList1 > and so the names of the fields in the struct. >=20 > There is some interesting background here, though. The Rockchip VPU > parses the slice headers itself and handles the above data on its own. > This means that it needs to be programmed with the unmodified > reference lists, as in v4l2_ctrl_h264_decode_param. >=20 > Given that, it sounds like we need to have both. Your driver would > always use the lists in v4l2_ctrl_h264_slice_param, while the Rockchip > VPU would ignore them, use the ones in v4l2_ctrl_h264_decode_param and > perform the per-slice modifications on its own. I guess that would work, yep Thanks! Maxime --=20 Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com --zmi43yrjnqz7zkau Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCW/LE1QAKCRDj7w1vZxhR xU6lAQCzHT+UfaY4dv6lCYEoscex90eOwXS0/ocDdzhogtlupQEAmk5Cm8O2uK2v n7r5Zwk9nm0dlXFOvMi9Auac66YJzw0= =6I8o -----END PGP SIGNATURE----- --zmi43yrjnqz7zkau--