Issue with DVI to RGB and non integer (1.001) frame rates

[whoooo]

I'm having some trouble using the Digilent DVI to RGB IP with non integer frame rate videos. My test project is a single VDMA passthrough which takes in a 1080p 30fps/1.001 stream with a pixel clock of 148.5/1.001 MHz. My video output does one of two things. One- it contains old data on alternating lines, which looks like an interlaced video not being correctly deinterlaced and causes fuzzing and ghosting, or two-  the output contains a static image with color channels switched around and the entire image shifted over. If I unplug the HDMI cable and plug it back in, the color channels switch around and the image shifts over again. The project works fine for 1080p 30fps videos. Looking at the output of the IP block, I'm seeing the active video signal staying high for either 1922 counts,1922 counts followed by 68 counts, or 1922 counts followed by 100 counts followed by 36 counts, as seen below:

From what I can tell, the IP block is either locking to the wrong location, or it's getting a lock, but a clocking issue is causing it to miss/double up on data? The reason I say this is that 1920*1.001 = 1921.92, which rounds up to 1922. This makes me think that the 148.5/1.001MHz data is being grabbed at the wrong rate and causing extra data to be included.

Does the DVI to RGB IP support non integer frame rates, or should I look for another solution?

[hamster]

2 hours ago, whoooo said:

I'm having some trouble using the Digilent DVI to RGB IP with non integer frame rate videos. My test project is a single VDMA passthrough which takes in a 1080p 30fps/1.001 stream with a pixel clock of 148.5/1.001 MHz. My video output does one of two things. One- it contains old data on alternating lines, which looks like an interlaced video not being correctly deinterlaced and causes fuzzing and ghosting, or two-  the output contains a static image with color channels switched around and the entire image shifted over. If I unplug the HDMI cable and plug it back in, the color channels switch around and the image shifts over again. The project works fine for 1080p 30fps videos. Looking at the output of the IP block, I'm seeing the active video signal staying high for either 1922 counts,1922 counts followed by 68 counts, or 1922 counts followed by 100 counts followed by 36 counts, as seen below:

From what I can tell, the IP block is either locking to the wrong location, or it's getting a lock, but a clocking issue is causing it to miss/double up on data? The reason I say this is that 1920*1.001 = 1921.92, which rounds up to 1922. This makes me think that the 148.5/1.001MHz data is being grabbed at the wrong rate and causing extra data to be included.

Does the DVI to RGB IP support non integer frame rates, or should I look for another solution?

Those extra blocks looks like HDMI data islands. The shouldn't be there on a true DVI signal.

If this is so, the active lines will also have a two-byte guard band at the start too. (So 1920 pixels will be 1922 bytes with a constant two byte preamble).

I and not sure that DVI2RGB is ddesigned to receive and filter RGB - guessing not from this trace.

[hamster]

It is most likely the souce defaults to HDMI mode if it can not get the EDID data from the FPGA when it detects a cable hot-plug...

[whoooo]

@hamster Looks like you're right- it's two bytes of guard data plus constant length blocks at the end of certain lines. It shouldn't be too hard to strip that out since the total cycles between lines is constant. Thanks!

[hamster]

It seems easy on the surface of it, but

- The different channels have different guard band values

- You need to work out what blanking and sync signals you need to assert during the guard bands and data packet guard bands

- The HDMI pixel data might be in "Studio level" (16-239) rather than full range (0-255)

- The video data might be in YCrCb 444 rather than RGB 444 format. (The RGB 444 means that for each four pixels there are 4 R values, 4 G values and 4 B values)

- The video data might be in YCrCb 422, where you have 12-bit values, and you get four Y (brghtness) but only two Cr or Cb values per for pixels. (which is more like TV video formats)

I made an attempt at decoding this, and it seems to work ok. You might be able to find any hints you need at my project:

https://github.com/hamsternz/Artix-7-HDMI-processing/blob/master/src/hdmi_input.vhd

but the source for all knowledge is the HDMI specification - find it by searching for "hdmi specification 1.2a filetype:pdf" or "hdmi specification 1.4 filetype:pdf" - e.g.

http://read.pudn.com/downloads72/doc/261979/HDMI_Specification_1.2a.pdf