YCbCr 4:2:2 in HDMI- Zybo Z7-20

[dgottesm]

Hi all

Here is a quote from Wikipedia's page on HDMI

"HDMI permits sRGB 4:4:4 chroma subsampling (8–16 bits per component), xvYCC 4:4:4 chroma subsampling (8–16 bits per component), YCbCr 4:4:4 chroma subsampling (8–16 bits per component), or YCbCr 4:2:2 chroma subsampling (8–12 bits per component). The color spaces that can be used by HDMI are ITU-R BT.601, ITU-R BT.709-5 and IEC 61966-2-4."

I have a  video in 8 bit 480p YCbCr 4:2:2 format sitting in BRAM, and I want to output it with HDMI. I have a Zybo Z7-20 board. Is there a way to output the data directly without converting to other color spaces. If I do have to convert, than can someone explain the process that needs to be done, both in theory and in practice?

This person seems to think that HDMI is simple enough: http://www.fpga4fun.com/HDMI.html, but he has 4:4:4 RGB.

EDIT: I thought about it a little more...It could be that switching to another color space is not 'my problem'. It could be the receiver's responsibility. Meaning that the HDMI screen has to be told to be prepared to receive YCbCr 4:2:2... If this is the case, in what format do I send my data to the HDMI port...what does it expect... HDMI has three differential data lines, a clock, VCC and ground, (the rest I can ignore) so I assume it gets serial data...

Anyone with any ideas, anything to add/fix...  

EDIT 2: Here is a quote from the HDMI protocol

"Video data is carried as a series of 24-bit pixels on the three TMDS data channels. TMDS encoding converts the 8 bits per channel into the 10 bit DC-balanced, transition minimized sequence which is then transmitted serially across the pair at a rate of 10 bits per pixel clock period." I did not understand all of this, but I think it means that the data is sent at 8 times the rate as the clock... so maybe its not as simple as I thought... still welcoming words of advice...

[hamster]

Hi,

The "HDMI" on Fpga4fun is actually DVI-D, which is electrically compatible to HDMI but doesn't support any of the useful features like sound, colour spaces or 422 pixel formats.

If you have the option, it will be quicker to use an IP block, however, if you want to implement it at a low level:.

1. A guard band added to the start of the video data - this consists of a special sequence of bytes. This is easy.

2. The HDMI "AVI infoframe" data packet.- this describes the video format as it goes over the wire, and it is in this packet that the HDMI source tells the HDMI sink if the stream is RGB444 or YCC4444 or YCC422.

Building the inforpacket is quite hard - it uses a separate coding scheme layered over the low level TMDS signalling, and has ECC and if this is wrong then the HDMI sink won't be able to decode the video stream correctly.

An absolute minimal HDMI output design (with only support for 3-bit colour have a look at http://hamsterworks.co.nz/mediawiki/index.php/Minimal_HDMI - but that design is not a good way to approach the your problem. You will want a proper TMDS encoding layer that supports the full range of data values to generate 24-bit images (or for YCC it will actually be 12-bits for each component).

[dgottesm]

@hamster

Thanks for your response. Yeah after doing a little more research I saw that people use the rgb2dvi IP to drive the HDMI... it’s not extremely difficult to convert YCbCr 4:2:2 to RGB 4:4:4. Actually, my problem with the rgb2dvi IP is that the IP documentation says it supports resolutions from 1920x1080/60 Hz to 800x600/60 Hz. My video is 480p, which is 640x480...

any thoughts? My first thought would be to add a bunch of black pixels as filler, but that would affect my clock and frame rate...

 

[hamster]

12 minutes ago, dgottesm said:

@hamster

Thanks for your response. Yeah after doing a little more research I saw that people use the rgb2dvi IP to drive the HDMI... it’s not extremely difficult to convert YCbCr 4:2:2 to RGB 4:4:4. Actually, my problem with the rgb2dvi IP is that the IP documentation says it supports resolutions from 1920x1080/60 Hz to 800x600/60 Hz. My video is 480p, which is 640x480...

any thoughts? My first thought would be to add a bunch of black pixels as filler, but that would affect my clock and frame rate...

 

If the video is coming from memory, using the faster pixel clocks isn't a problem just add a black border (80 pixels left and right, 60 pixels top and bottom) would be simple.

If they are standards compliant all HDMI devices (both sources and sinks) "should" support 640x480 (24.something MHz pixel clock). Odds are that the PLL/DCM used by RGB2DVI to generate the clocks for the SERDES blocks isn't configured to lock onto really slow pixel clock rates below 50MHz. I've never used RGV2DVI, but if the source is included then checking out the clocking and doubling the Multiply/Divide values to keep the VCO frequency in the correct range should be all that is needed.

If this does work, then just put your Y values to all three channels ( R, G & B ), and you should have a 8-bit greyscale image, without any mucking around with HDMI.

[dgottesm]

@hamster

Thanks for your quick reply!

1 hour ago, hamster said:

If the video is coming from memory, using the faster pixel clocks isn't a problem just add a black border (80 pixels left and right, 60 pixels top and bottom) would be simple.

Will it still be simple if I am not saving a whole frame in memory, but only 3 or 6 lines? Granted, I know exactly how many pixels per line and per frame, but I need to move the data along and I can't have it wait there while I am drawing borders.

 

2 hours ago, hamster said:

If they are standards compliant all HDMI devices (both sources and sinks) "should" support 640x480 (24.something MHz pixel clock).

So are you saying that I don't need to add borders, just edit the source code so that it supports 640x480?

 

2 hours ago, hamster said:

Odds are that the PLL/DCM used by RGB2DVI to generate the clocks for the SERDES blocks isn't configured to lock onto really slow pixel clock rates below 50MHz. I've never used RGV2DVI, but if the source is included then checking out the clocking and doubling the Multiply/Divide values to keep the VCO frequency in the correct range should be all that is needed.

Can you help me with that? that sounds scary...

 

2 hours ago, hamster said:

If this does work, then just put your Y values to all three channels ( R, G & B ), and you should have a 8-bit greyscale image, without any mucking around with HDMI.

In the end, I do hope to get color, but I suppose that this a start. It wouldn't be mucking around with HDMI, it would be chroma resampling (4:2:2 -> 4:4:4) and converting from YCbCr to RGB

Thanks

David

[dgottesm]

Also, another question

The IP requires as an input HSYNC and VSYNC signals. I am not saving any timing information into BRAM, only pixel data. But again, since I know how many pixels per line and how many lines per frame, I can keep track and in theory, generate these signals myself. My question is, how long (how many clocks, how many 'lines') do the signals need to be? What is it based on?

[hamster]

12 hours ago, dgottesm said:

Also, another question

The IP requires as an input HSYNC and VSYNC signals. I am not saving any timing information into BRAM, only pixel data. But again, since I know how many pixels per line and how many lines per frame, I can keep track and in theory, generate these signals myself. My question is, how long (how many clocks, how many 'lines') do the signals need to be? What is it based on?

You will find a good explanation here: https://reference.digilentinc.com/nexys_vga/refmanual

There is a list of timing modes at http://hamsterworks.co.nz/mediawiki/index.php/VGA_timings - hope these help.

If you look around the internet you will find lots of simple VGA projects - including this one:

http://www.hamsterworks.co.nz/mediawiki/index.php/Papilio_Plus/Hello_World

 

[dgottesm]

@hamster

Wow! Thanks very much!

Two questions

1) My video is ITU-R BT.656, (which is coming in de-interlaced, but forget about that) which means that the pixel speed is actually 27 MHz (13.5 MHz per byte, an average of two bytes per pixel because of chroma sub-smapling), as opposed to 25 MHz. Is that OK? Does that change the numbers? What if it was 54 MHz (2*27)?

2) Couldn't help but notice that all of your projects were for VGA. I am working with HDMI. Does that change anything?

Thanks again!