Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752196AbdLKAND (ORCPT ); Sun, 10 Dec 2017 19:13:03 -0500 Received: from mail-lf0-f50.google.com ([209.85.215.50]:38053 "EHLO mail-lf0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751137AbdLKAM7 (ORCPT ); Sun, 10 Dec 2017 19:12:59 -0500 X-Google-Smtp-Source: AGs4zMZ4Niusn8Le0kpiZrjRAghDzVE65ALep1V50emPVSipZ2hslzWt61CxrKQhg0hNrgJ+r5ElFw== Subject: Re: [PATCH v4 3/5] staging: Introduce NVIDIA Tegra video decoder driver To: Nicolas Dufresne , Hans Verkuil , Thierry Reding , Jonathan Hunter , Greg Kroah-Hartman , Rob Herring , Mauro Carvalho Chehab , Stephen Warren , Vladimir Zapolskiy Cc: Dan Carpenter , linux-media@vger.kernel.org, linux-tegra@vger.kernel.org, devel@driverdev.osuosl.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Maxime Ripard , Giulio Benetti References: <1a3798f337c0097e67d70226ae3ba665fd9156c2.1508448293.git.digetx@gmail.com> <3ac6a087-def2-014f-673d-1be9d5094635@gmail.com> <93c98569-0282-80d9-78ad-c8ab8fd9db92@xs4all.nl> <1512934179.4281.15.camel@ndufresne.ca> From: Dmitry Osipenko Message-ID: Date: Mon, 11 Dec 2017 03:12:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1512934179.4281.15.camel@ndufresne.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 844 Lines: 15 On 10.12.2017 22:29, Nicolas Dufresne wrote: > Le dimanche 10 décembre 2017 à 21:56 +0300, Dmitry Osipenko a écrit : >>> I've CC-ed Maxime and Giulio as well: they are looking into adding support for >>> the stateless allwinner codec based on this code as well. There may well be >>> opportunities for you to work together, esp. on the userspace side. Note that >>> Rockchip has the same issue, they too have a stateless HW codec. >> >> IIUC, we will have to define video decoder parameters in V4L API and then make a >> V4L driver / userspace prototype (ffmpeg for example) that will use the requests >> API for video decoding in order to upstream the requests API. Does it sound good? > > Chromium/Chrome already have support for that type of decoder in their > tree. In theory, it should just work. Everything is possible, in theory ;)