linux-kernel - Re: [PATCHv4 1/2] media: docs-rst: Document memory-to-memory video decoder interface

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: <f016182a-e7b8-2dc9-edde-e62e8aacc63b@xs4all.nl>
Date:   Wed, 12 Jun 2019 08:49:31 +0200
From:   Hans Verkuil <hverkuil-cisco@...all.nl>
To:     Nicolas Dufresne <nicolas@...fresne.ca>,
        linux-media@...r.kernel.org
Cc:     Tomasz Figa <tfiga@...omium.org>, linux-kernel@...r.kernel.org,
        Alexandre Courbot <acourbot@...omium.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        Andrew-CT Chen <andrew-ct.chen@...iatek.com>,
        Tiffany Lin <tiffany.lin@...iatek.com>,
        Pawel Osciak <posciak@...omium.org>,
        Maxime Jourdan <mjourdan@...libre.com>
Subject: Re: [PATCHv4 1/2] media: docs-rst: Document memory-to-memory video
 decoder interface

On 6/12/19 2:25 AM, Nicolas Dufresne wrote:
> Le mardi 11 juin 2019 à 10:29 +0200, Hans Verkuil a écrit :
>> On 6/10/19 9:54 PM, Nicolas Dufresne wrote:
>>> Hi Hans,
>>>
>>> I went through it, and I think we are close to ready. Unfortunately, I
>>> believe the SOURCE_CHANGE event is still under specified. There was a
>>> post recently to try and add a new flag for changes in color space
>>> which is not included here. We are also missing a workflow for changes
>>> that don't affect the allocation but will affect the rendering on a
>>> display (like colorimetry). Userspace needs to know at which frames
>>> these parameter changes in order to signal that to the following
>>> processing block. I think we must have a plane for this.
>>
>> Yes, we need a new flag for the SOURCE_CHANGE event to indicate colorimetry
>> changes. That's actually useful for e.g. HDMI receivers as well.
>>
>> But I don't see why that should make much of a change to the spec: you still
>> have to drain the capture queue, the only difference is that you don't need
>> to reallocate buffers, you can just restart the decoder.
> 
> I don't think you need to drain the queue if the change is just
> metadata that have no impact on the buffers allocation or layout. I
> think we should have a way to communicate these changed while
> streaming. Basically, something like the event, but serialized.

I guess we can extend the struct v4l2_event_src_change and add a buffer
index field to indicate at which capture buffer index the colorimetry
change takes effect. Then there is no need for draining.

In the future when we create replacement streaming ioctls and have a
new, larger struct v4l2_buffer, then we can add the colorimetry information
there as well.

Regards,

	Hans