linux-kernel - Re: [PATCH v1 0/2] NVIDIA Tegra20 video decoder driver

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: <d2d4c970-d921-c282-b70e-00247c5de50f@gmail.com>
Date:   Tue, 26 Sep 2017 15:32:23 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Rob Herring <robh+dt@...nel.org>, linux-tegra@...r.kernel.org,
        devel@...verdev.osuosl.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH v1 0/2] NVIDIA Tegra20 video decoder driver

On 26.09.2017 09:54, Greg Kroah-Hartman wrote:
> On Tue, Sep 26, 2017 at 01:15:41AM +0300, Dmitry Osipenko wrote:
>> This driver provides accelerated video decoding to NVIDIA Tegra20 SoC's,
>> it is a result of reverse-engineering efforts. Driver has been tested on
>> Toshiba AC100 and Acer A500, it should work on any Tegra20 device.
>>
>> In userspace this driver is utilized by libvdpau-tegra [0] that implements
>> VDPAU interface, so any video player that supports VDPAU can provide
>> accelerated video decoding on Tegra20 on Linux.
> 
> Why not use the v4l2 api instead?  Doesn't that provide the same needed
> user/kernel api here instead of creating yet-another-custom ioctl?
> 

1) The HW doesn't generalize for the common API. Like for example, it isn't
capable of unpacking bitstream encoded with CABAC (Context-adaptive binary
arithmetic coding), so unpacking should be done in software and then VDE HW
isn't capable of decoding such a stream in a fully-automated manner, software
would have to feed engine with a chunks of macroblocks untill the whole frame is
decoded. That lameness is partially hidden in the BLOB's firmware, that firmware
actually is just a driver BTW.

2) We want to have decoding integrated with the presentation of the decoded
video frame. So having v4l interface for decoding would be just an extra
unnecessary shim, increasing CPU / memory resources usage and complexity of the
code.

3) The decoding and presentation are already implemented using VDPAU API and
proven to work decently in that way.

-- 
Dmitry