linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC]  V4L HDR Architecture Proposal
@ 2020-01-22 20:13 Dylan Yip
  2020-01-23 13:06 ` Hans Verkuil
  0 siblings, 1 reply; 11+ messages in thread
From: Dylan Yip @ 2020-01-22 20:13 UTC (permalink / raw)
  To: Laurent Pinchart, hverkuil, linux-media
  Cc: Varunkumar Allagadapa, Madhurkiran Harikrishnan, Jianqiang Chen,
	Hyun Kwon, Cyril Chemparathy, Vishal Sagar, Sandip Kothari,
	Subhransu Sekhar Prusty

Hi All,

We are planning to add HDR10 and HDR10+ metadata support into the V4L framework and were hoping for some feedback before we started implementation.

For context, Xilinx HDMI RX IP currently uses a AXI LITE interface where HDR metadata is obtained from a hardware FIFO. To access these packets a CPU copy is required. 
We are in the process of migrating towards a AXI MM interface where the hardware will directly write HDR metadata into memory. 
Currently the HDMI RX driver (https://github.com/Xilinx/hdmi-modules/blob/master/hdmi/xilinx-hdmirx.c) is modeled as a v4l subdev. This is linked to a DMA IP which utilizes the DMA engine APIs and registers itself as a video node for video data. 

HDR10 will only consist of static metadata which will come once per stream. However, HDR10+ will have dynamic metadata which can potentially come once per frame and be up to ~4000 bytes. We would like V4L architecture to be flexible to support both. 

We have 2 different proposals that we believe will work:

A. 2 video node approach (1 for video, 1 for metadata) - This will align with current v4l metadata structure (i.e. uvc) but will require our HDMI RX driver to register a subdev and device node
	a. Our HDMI RX driver will register a v4l subdev (for video data) and a metadata node
		i. Is this acceptable?
	b. Applications will qbuf/dqbuf to both video and metadata nodes for each frame

B. 1 video node approach - This will avoid mixing v4l subdev and v4l device node functionality inside HDMI RX driver but it strays from current v4l metadata architecture and also changes v4l subdev functionality
	a. We would add a "read" function to v4l subdev's
		i. This will also require us to add some "capabilities" field to subdev or be able to query for the "read" function
	b. HDMI Rx driver will register a v4l subdev with "read" function/capability
	c. Application can directly pass a buffer in the "read" function to HDMI RX subdev to obtain HDR metadata
		i. We will need to pass subdev name from application or be able to query all subdevs for this "read" capability, is this acceptable?

Please let me know your opinions on which approach is best or propose another approach if these 2 are unfit. Thanks

Best,
Dylan Yip

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-05-18 22:17 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-22 20:13 [RFC] V4L HDR Architecture Proposal Dylan Yip
2020-01-23 13:06 ` Hans Verkuil
2020-01-24  9:04   ` Vishal Sagar
2020-01-24 10:10     ` Hans Verkuil
2020-01-24 12:08       ` Laurent Pinchart
2020-01-29  6:14         ` Dylan Yip
2020-01-29  7:30           ` Hans Verkuil
2020-01-30  7:00             ` Dylan Yip
2020-02-12 16:48               ` Laurent Pinchart
2020-02-19 10:41                 ` Hans Verkuil
2020-05-18 22:16                   ` VDRU VDRU

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).