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: <ad61378b-e279-d161-adaa-17349adf183e@xs4all.nl>
Date:   Fri, 29 May 2020 09:31:45 +0200
From:   Hans Verkuil <hverkuil@...all.nl>
To:     dikshita@...eaurora.org
Cc:     Nicolas Dufresne <nicolas@...fresne.ca>,
        linux-media@...r.kernel.org, stanimir.varbanov@...aro.org,
        linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        vgarodia@...eaurora.org, majja@...eaurora.org, jdas@...eaurora.org
Subject: Re: [RFC] METADATA design using V4l2 Request API

On 29/05/2020 04:18, Nicolas Dufresne wrote:
> Le jeudi 28 mai 2020 à 16:18 +0530, dikshita@...eaurora.org a écrit :
>>> not allowed. So I need to know more about this.
>>> Regards,
>>>        Hans
>>
>> we need this for use cases like HDR10+ where metadata info is part of
>> the bitstream.
>>
>> To handle such frame specific data, support for request api on capture 
>> plane would be needed.
> 
> I have a bit of a mixed impression here. Considering how large the ioctl
> interface overhead is, relying on HW parser to extract this medata woud be the
> last thing I would consider.
> 
> Instead, I'm quite convince we can achieve greater and likely zero-copy
> perfromance by locating this header in userspace. So everytime I see this kind
> of API, were the HW is *needed* to parse a trivial bit of bistream, I ended
> thinking that we simply craft this API to expose this because the HW can do it,
> but no further logical thinking or higher level design seems to have been
> applied.
> 
> I'm sorry for this open critic, but are we designing this because the HW
> designer exposed that feature? This is so low complexity to extract in
> userspace, with the bonus that we are not forced into expanding the
> representation to another form immediatly, as maybe the display will be able to
> handle that form directly (where converting to a C structure and then back to
> some binary format to satisfy DRM property seems very sub-optimal).
> 
> Nicolas
> 

Nicolas raises good questions: it would help if you can give more detailed information
about the hardware. We had similar discussions with Xilinx about HDR10+ (see this
thread: https://www.spinics.net/lists/linux-media/msg163297.html).

There is no clear answer at the moment on how to handle dynamic HDR metadata.
It will help if we have some more information how different SoCs handle this
in hardware.

Regards,

	Hans

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ