cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
1,508 Views
Registered: ‎03-14-2018

YUV420 only supports 24-bits colordepth ? Kintex7 HDMI 2.0 RX core

Jump to solution

We seem to be receiving 4:2:0 AXI-S compliant signals out of our HDMI 2.0 Rx core.  We recover video test patterns through the core basically ok.  However, 4:2:0 (specifically) video out the HDMI RX core appears to always be mapped to 8-bits per component instead of 12-bits as requested in the GUI by me when I generated the core.  All 4:2:2 and 4:4:4 modes operate fine with 12-bits per components, thus obeying my request for 12 bits per component.  8 bit sources and 10 bit sources align themselves to my requested 12-bit interface just fine.

 

Is 4:2:0 supported at other bit depths than 8-bits per component?  A commented out section of the driver code states 'YUV420 only supports 24-bits colordepth'.  If the driver needs to be told how to configure the core for 12-bits per component when in 4:2:0, I'd like to know how.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
1,770 Views
Registered: ‎08-02-2007

@emmeyarwood

 

Firstly please ensure Video over AXIS compliant YUV420 Support is selected in HDMI RX GUI.

 

Which version are you using? We recently have tested HDMI example design with Roku Ultra, which play with 4k60 YUV 420 10 bits

 

What's your HDMI source?

 

For the data mapping, please take a look at page 36 of PG236 : https://www.xilinx.com/support/documentation/ip_documentation/v_hdmi_rx_ss/v3_0/pg236-v-hdmi-rx-ss.pdf

 

" for YUV 4:2:0 deep color (10, 12, or 16 bits), the data representation is the same as shown in Figure 3-6 and Figure 3-7. The only difference is that each component carries more bits (10, 12, and 16). To make the YUV 4:2:0 compatible with AXI4-Stream Video IP and System Design Guide [Ref 14], enable it from the HDMI Receiver Subsystem GUI. "

 

 

 

View solution in original post

4 Replies
Highlighted
Visitor
Visitor
1,483 Views
Registered: ‎03-14-2018

Based on experiments today, it would appear that the bus is NOT mapping to 8-bits and may very well be mapping to 12-bits per component like I requested from the core settings.

 

My problem may be that the CHROMA_PARITY bit is opposite what I want.  Because it is backwards, I believe I'm coping zero-value,  non-existent chroma from the even lines to the following odd lines and ending up with zero value chroma across the entire frame.  It explains why my grey test patterns look dimensionally correct but are all made of shades of green.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
1,771 Views
Registered: ‎08-02-2007

@emmeyarwood

 

Firstly please ensure Video over AXIS compliant YUV420 Support is selected in HDMI RX GUI.

 

Which version are you using? We recently have tested HDMI example design with Roku Ultra, which play with 4k60 YUV 420 10 bits

 

What's your HDMI source?

 

For the data mapping, please take a look at page 36 of PG236 : https://www.xilinx.com/support/documentation/ip_documentation/v_hdmi_rx_ss/v3_0/pg236-v-hdmi-rx-ss.pdf

 

" for YUV 4:2:0 deep color (10, 12, or 16 bits), the data representation is the same as shown in Figure 3-6 and Figure 3-7. The only difference is that each component carries more bits (10, 12, and 16). To make the YUV 4:2:0 compatible with AXI4-Stream Video IP and System Design Guide [Ref 14], enable it from the HDMI Receiver Subsystem GUI. "

 

 

 

View solution in original post

Highlighted
Visitor
Visitor
1,394 Views
Registered: ‎03-14-2018

Hi,

 

I have 4:2:0 working now.

I properly detect the chroma on the first line of each pair of lines (i.e. the even lines) without having to modify CHROMA_PARITY in the timing register set.

 

Through some experimentation of interpreting the bus as 8, 10, and 12 bpc, we confirmed visually that the core is correctly outputting 4:2:0 with the same 12 bpc that I requested for more traditional 4:4:4 and 4:2:2 modes.

 

Thanks for the help!

Emme

 

 

0 Kudos
Highlighted
Moderator
Moderator
1,386 Views
Registered: ‎11-09-2015

Hi @emmeyarwood,

 

As the issue is solved, please kindly close the topic by marking a reply as accepted solution.

 

Thanks and Regards,


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos