Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752273AbdLJT3q (ORCPT ); Sun, 10 Dec 2017 14:29:46 -0500 Received: from mail-qt0-f180.google.com ([209.85.216.180]:44033 "EHLO mail-qt0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751994AbdLJT3n (ORCPT ); Sun, 10 Dec 2017 14:29:43 -0500 X-Google-Smtp-Source: AGs4zMZ8cmPhAOYYKWsJ+2+pJvWo9xjkjxqdpgShuPs1BDDJsPRj6fl31YxiLc14+wxSfL3L4XLBzA== Message-ID: <1512934179.4281.15.camel@ndufresne.ca> Subject: Re: [PATCH v4 3/5] staging: Introduce NVIDIA Tegra video decoder driver From: Nicolas Dufresne To: Dmitry Osipenko , 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 Date: Sun, 10 Dec 2017 14:29:39 -0500 In-Reply-To: References: <1a3798f337c0097e67d70226ae3ba665fd9156c2.1508448293.git.digetx@gmail.com> <3ac6a087-def2-014f-673d-1be9d5094635@gmail.com> <93c98569-0282-80d9-78ad-c8ab8fd9db92@xs4all.nl> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.2 (3.26.2-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 759 Lines: 14 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. Nicolas