From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Osipenko Subject: Re: [PATCH v4 3/5] staging: Introduce NVIDIA Tegra video decoder driver Date: Sun, 10 Dec 2017 21:56:35 +0300 Message-ID: References: <1a3798f337c0097e67d70226ae3ba665fd9156c2.1508448293.git.digetx@gmail.com> <3ac6a087-def2-014f-673d-1be9d5094635@gmail.com> <93c98569-0282-80d9-78ad-c8ab8fd9db92@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <93c98569-0282-80d9-78ad-c8ab8fd9db92@xs4all.nl> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" To: Hans Verkuil , Thierry Reding , Jonathan Hunter , Greg Kroah-Hartman , Rob Herring , Mauro Carvalho Chehab , Stephen Warren , Vladimir Zapolskiy Cc: devel@driverdev.osuosl.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, Maxime Ripard , Giulio Benetti , Dan Carpenter , linux-media@vger.kernel.org List-Id: linux-tegra@vger.kernel.org On 05.12.2017 16:03, Hans Verkuil wrote: > On 12/05/17 13:17, Dmitry Osipenko wrote: >> Hi Hans, >> >> On 04.12.2017 17:04, Hans Verkuil wrote: >>> Hi Dmitry, >>> >>> As you already mention in the TODO, this should become a v4l2 codec driver. >>> >>> Good existing examples are the coda, qcom/venus and mtk-vcodec drivers. >>> >>> One thing that is not clear from this code is if the tegra hardware is a >>> stateful or stateless codec, i.e. does it keep track of the decoder state >>> in the hardware, or does the application have to keep track of the state and >>> provide the state information together with the video data? >>> >>> I ask because at the moment only stateful codecs are supported. Work is ongoing >>> to support stateless codecs, but we don't support that for now. >>> >> >> It is stateless. Is there anything ready to try out? If yes, could you please >> give a reference to that work? > > I rebased my two year old 'requests2' branch to the latest mainline version and > gave it the imaginative name 'requests3': > > https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=requests3 > > (Note: only compile tested!) Thank you very much. > This is what ChromeOS has been using (actually they use a slightly older version) > and the new version that is currently being developed will be similar, so any work > you do on top of this will carry over to the final version without too much effort. > > At least, that's the intention :-) > > 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? >> >>> Anyway, I'm OK with merging this in staging. Although I think it should go >>> to staging/media since we want to keep track of it. >>> >> >> Awesome, I'll move driver to staging/media in V5. Thanks! > > Nice, thanks! From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752270AbdLJS4n (ORCPT ); Sun, 10 Dec 2017 13:56:43 -0500 Received: from mail-lf0-f47.google.com ([209.85.215.47]:42248 "EHLO mail-lf0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751860AbdLJS4k (ORCPT ); Sun, 10 Dec 2017 13:56:40 -0500 X-Google-Smtp-Source: AGs4zMbv+IwrEt6ylUkanr1jhE8aWEbCPn8jQnnZbdnKD2joofAgVCcv5heDwfc/Xf4LVhCwT86zxA== Subject: Re: [PATCH v4 3/5] staging: Introduce NVIDIA Tegra video decoder driver To: 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> From: Dmitry Osipenko Message-ID: Date: Sun, 10 Dec 2017 21:56:35 +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: <93c98569-0282-80d9-78ad-c8ab8fd9db92@xs4all.nl> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05.12.2017 16:03, Hans Verkuil wrote: > On 12/05/17 13:17, Dmitry Osipenko wrote: >> Hi Hans, >> >> On 04.12.2017 17:04, Hans Verkuil wrote: >>> Hi Dmitry, >>> >>> As you already mention in the TODO, this should become a v4l2 codec driver. >>> >>> Good existing examples are the coda, qcom/venus and mtk-vcodec drivers. >>> >>> One thing that is not clear from this code is if the tegra hardware is a >>> stateful or stateless codec, i.e. does it keep track of the decoder state >>> in the hardware, or does the application have to keep track of the state and >>> provide the state information together with the video data? >>> >>> I ask because at the moment only stateful codecs are supported. Work is ongoing >>> to support stateless codecs, but we don't support that for now. >>> >> >> It is stateless. Is there anything ready to try out? If yes, could you please >> give a reference to that work? > > I rebased my two year old 'requests2' branch to the latest mainline version and > gave it the imaginative name 'requests3': > > https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=requests3 > > (Note: only compile tested!) Thank you very much. > This is what ChromeOS has been using (actually they use a slightly older version) > and the new version that is currently being developed will be similar, so any work > you do on top of this will carry over to the final version without too much effort. > > At least, that's the intention :-) > > 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? >> >>> Anyway, I'm OK with merging this in staging. Although I think it should go >>> to staging/media since we want to keep track of it. >>> >> >> Awesome, I'll move driver to staging/media in V5. Thanks! > > Nice, thanks!