[RFC] V4L HDR Architecture Proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux