linux-kernel - Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in try_fmt and g

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]

Date:   Thu, 02 Mar 2017 08:42:51 +0100
From:   Andrzej Hajda <a.hajda@...sung.com>
To:     Nicolas Dufresne <nicolas.dufresne@...labora.com>,
        Thibault Saunier <thibault.saunier@....samsung.com>,
        linux-kernel@...r.kernel.org
Cc:     Mauro Carvalho Chehab <mchehab@...nel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Kukjin Kim <kgene@...nel.org>,
        Mauro Carvalho Chehab <mchehab@...pensource.com>,
        Andi Shyti <andi.shyti@...sung.com>,
        linux-media@...r.kernel.org, Shuah Khan <shuahkh@....samsung.com>,
        Javier Martinez Canillas <javier@....samsung.com>,
        linux-samsung-soc@...r.kernel.org,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Inki Dae <inki.dae@...sung.com>,
        Sylwester Nawrocki <s.nawrocki@...sung.com>,
        linux-arm-kernel@...ts.infradead.org,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Jeongtae Park <jtp.park@...sung.com>,
        Kyungmin Park <kyungmin.park@...sung.com>,
        Kamil Debski <kamil@...as.org>
Subject: Re: [PATCH v6 2/2] [media] s5p-mfc: Handle 'v4l2_pix_format:field' in
 try_fmt and g_fmt

On 01.03.2017 16:21, Nicolas Dufresne wrote:
> Le mercredi 01 mars 2017 à 14:12 +0100, Andrzej Hajda a écrit :
>> - on output side you have encoded bytestream - you cannot say about
>> interlacing in such case, so the only valid value is NONE,
>> - on capture side you have decoded frames, and in this case it
>> depends
>> on the device and driver capabilities, if the driver/device does not
>> support (de-)interlacing (I suppose this is MFC case), interlace type
>> field should be filled according to decoded bytestream header (on
>> output
>> side), but no direct copying from output side!!!
> I think we need some nuance here for this to actually be usable. If the
> information is not provided by the driver (yes, hardware is limiting
> sometimes), it would make sense to copy over the information that
> userspace provided. Setting NONE is just the worst approximation in my
> opinion.

The whole point is that s_fmt on output side is to describe format of
the stream passed to the device, and in case of decoder it is just
mpeg/h.26x/... stream. It does not contain frames, fields, width, height
- it is just raw stream of bytes. We cannot say in such case about field
type, there is not such thing as interlaced byte stream.
Using s_fmt on output to describe things on capture side look for me
unnecessary and abuses V4L2 API IMO.

>
> About MFC, it will be worth trying to read the DISPLAY_STATUS after the
> headers has been processed. It's not clearly stated in the spec if this
> will be set or not.
>
Documentation for MFC6.5 states clearly:

> Note: On SEQ_DONE, INTERLACE_PICTURE will return the picture type to
> be decoded based on the
> sequence header information.

In case of MFC5.1 it is unclear, but I hope HW behaves the same way.

Anyway I agree it will be good to fix it at least for MFC6.5+, any
volunteer?


Regards

Andrzej