linux-kernel - Re: [RFC PATCH 0/3] Implement Region of Interest(ROI) support.

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: <6b5746cd16edf589fca79e2e6f8cf7f706309815.camel@ndufresne.ca>
Date: Thu, 15 Jan 2026 08:42:09 -0500
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Deepa Guthyappa Madivalara <deepa.madivalara@....qualcomm.com>, Mauro
 Carvalho Chehab <mchehab@...nel.org>, Vikash Garodia
 <vikash.garodia@....qualcomm.com>, Dikshita Agarwal	
 <dikshita.agarwal@....qualcomm.com>, Abhinav Kumar
 <abhinav.kumar@...ux.dev>,  Bryan O'Donoghue	 <bod@...nel.org>
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-arm-msm@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] Implement Region of Interest(ROI) support.

Hi,

Le mercredi 14 janvier 2026 à 14:14 -0800, Deepa Guthyappa Madivalara a écrit 

[...]

> 
> Thanks for the quick comments.
> Qp map for can be too much data to be sent from user space to firmware 
> via control per frame.
> Ex: Avc has mbsize as 16 and the max mbpf iris driver supports is 8192x4352.
> This would mean 136kb of data (8bit Qp) needs to be transferred for each 
> frame in worst case.
> While are still evaluating Qp map option, due to firmware performance 
> issues we are
> gravitating more towards rectangle ROI.
> I am not sure if we will need to support the Qp map in the future.

Have you read how this is implemented in Vulkan and D3D12 ? Please have a read:

- Vulkan Video, see quantizationMapTexelSize [0]
- D3D, see QPMapRegionPixelsSize [1]

[0] https://docs.vulkan.org/features/latest/features/proposals/VK_KHR_video_encode_quantization_map.html
[1] https://microsoft.github.io/DirectX-Specs/d3d/D3D12_Video_Encoding_Texture_QPMap_DirtyMap_MotionVectors.html

Note that D3D also support dirty regions (what you call ROI in this proposal),
with no limits, since these are translated into map by drivers (its a software
feature on top) and motion search hints, that one seems rare.

I'm not against having ROI in our API, its common in older chips designs, but
its clearly going away in the long run since most fixed hardware impose very low
region count, which is not usable for modern application. ROI it trivial to
implement on top of QP maps.

A typical use case for that is to use lightweight AI or traditional CV to locate
most relevant portion of a video. The result is more like a heat map, not a set
of rectangles. Then we roughly map that in a low granularity QPMap before
encoding. This allow maintaining very low bandwidth, while preserving the
information needed for the heavier processing in the cloud. I'm including one of
the many example of that, this is a talk from Spiideo [2].

[2] https://gstconf.ubicast.tv/videos/region-based-compression-in-gstreamer/

regards,
Nicolas

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)