lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <93c98569-0282-80d9-78ad-c8ab8fd9db92@xs4all.nl>
Date:   Tue, 5 Dec 2017 14:03:37 +0100
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Dmitry Osipenko <digetx@...il.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Stephen Warren <swarren@...dotorg.org>,
        Vladimir Zapolskiy <vz@...ia.com>
Cc:     Dan Carpenter <dan.carpenter@...cle.com>,
        linux-media@...r.kernel.org, linux-tegra@...r.kernel.org,
        devel@...verdev.osuosl.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Maxime Ripard <maxime.ripard@...e-electrons.com>,
        Giulio Benetti <giulio.benetti@...ronovasrl.com>
Subject: Re: [PATCH v4 3/5] staging: Introduce NVIDIA Tegra video decoder
 driver

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!)

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.

> 
>> 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!

	Hans

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ