HDMI Specification Question for P2

MSwann

I need a better understanding of what is happening in a bit of code shown below that Chip wrote for his Goertzel example driving HDMI.
Please reference the attached image of one HDMI video frame.

'***************************************
'*  VGA 640 x 480 x 8bpp luma8 - HDMI  *
'***************************************

DAT             org

pgm_hdmi        setcmod #$100                   'enable HDMI mode
                drvl    #7<<6 + hdmi_base       'enable HDMI pins
                wrpin   ##%100100<<8,#7<<6 + hdmi_base  'set 1 mA drive on HDMI pins

                setxfrq ##$0CCCCCCC+1           'set streamer freq to 1/10th clk (25 MHz)

                rdfast  ##640*480/64,##bitmap   'set rdfast to wrap on 300KB bitmap

' Field loop

field           mov     hsync0,sync_000         'vsync off
                mov     hsync1,sync_001

                callpa  #25,#blank              'top blanks

                mov     i,#480                  'set visible lines
line            call    #hsync                  'do horizontal sync
                xcont   m_rf,#hdmi_color        'do visible line
                djnz    i,#line                 'another line?

                callpa  #18,#blank              'bottom blanks

                mov     hsync0,sync_222         'vsync on
                mov     hsync1,sync_223

                callpa  #2,#blank               'vertical sync blanks

                jmp     #field                  'loop

' Subroutines

blank           call    #hsync                  'blank lines
                xcont   m_vi,hsync0
        _ret_   djnz    pa,#blank

hsync           xcont   m_bs,hsync0             'horizontal sync
                xzero   m_sn,hsync1
        _ret_   xcont   m_bv,hsync0

' Data

sync_000        long    %1101010100_1101010100_1101010100_10    '
sync_001        long    %1101010100_1101010100_0010101011_10    '        hsync
sync_222        long    %0101010100_0101010100_0101010100_10    'vsync
sync_223        long    %0101010100_0101010100_1010101011_10    'vsync + hsync

m_bs            long    $70810000 + hdmi_base<<17 + 16          'before sync
m_sn            long    $70810000 + hdmi_base<<17 + 96          'sync
m_bv            long    $70810000 + hdmi_base<<17 + 48          'before visible
m_vi            long    $70810000 + hdmi_base<<17 + 640         'visible
m_rf            long    $B0820000 + hdmi_base<<17 + 640         'visible rfbyte luma8

i               res     1
hsync0          res     1
hsync1          res     1

The attached video frame shows what it calls TMDS Periods of three types:
(1) Control Periods
(2) Data Island Periods, and
(3) Video Data Periods
Chip's code appears to only generate Control Periods and Video Data Periods, of which I am guessing the below sync_nnn lines represent data for Control Periods.
Is my guess correct?

sync_000        long    %1101010100_1101010100_1101010100_10    '
sync_001        long    %1101010100_1101010100_0010101011_10    '        hsync
sync_222        long    %0101010100_0101010100_0101010100_10    'vsync
sync_223        long    %0101010100_0101010100_1010101011_10    'vsync + hsync

Help me understand what the sequence of bits means.

Thanks,
Mark

cgracey

Yes, those ten-bit patterns are control values for HDMI, sent on Red, Green, and Blue channels. There is some question about which are needed in which channels. It looks from the data there that only the blue channel (last 10-bit group before the %10) is carrying the control values.

rogloh

Yes, your guess is correct. Chip is sending standard DVI not HDMI which includes islands and guard bands etc. These long values above are the combinations of three 10 bit symbols used to generate the 2 bit control period values used by each TDMS channel (R/G/B). Bit 1 = 1 in each long indicates raw symbols are being output through the encoder instead of mapping true 24 bit RGB via regular video TMDS symbols. In the control periods only 2 input bits are used to encode symbols so 4 values are used (quaternary). This is what the "000" in the sync_000 indicates, it means send symbol "0" (%00) on the red channel, send symbol "0" (%00) on green channel, send symbol "0" (%00) on the blue channel. sync_223 means it is sending symbol "2" (%10) on red, symbol "2" (%10) and symbol "3" (%11) on blue. There is a mapping from 2 bit control value to 4 different 10 bit patterns sent over the wire on each channel and Chip's table is showing some of the combinations used.

Be sure to get the 10 bit values endianness correct in the long too.

In control periods only the blue channel (channel 0) is used for HSYNC and VSYNC. This is controlled by the quaternary "z" value of "sync_xyz". Eg.

z=0, encode 00 - hsync is low, vsync is low
z=1, encode 01 - hsync is high, vsync is low
z=2, encode 10 - hsync is low, vsync is high
z=3, encode 11 - hsync is high, vsync is high

In theory the red and green channel values "x" and "y" should be sending the 00 pattern too in the control period, but IIRC many DVI decoders seem to ignore that. DVI allows 00 for red, and either 00 or 01 for green. HDMI makes use of these extra 4 bits (2 red, and 2 green) to indicate other values for preambles of data islands and video periods etc. Eg, the preamble for a data island would be "sync_11x", which encodes the input (%01) on red and (%01) on green, while the value of x for the blue channel would depend on the hsync/vsync states at the time.

MSwann

Thanks @cgracey, that makes sense. I just dug further in the HDMI pdf I have and found what each 10-bit group means.
The blue channel contains VSYNC and HSYNC. The GREEN and RED channel together announce the beginning of either a Data Island Period or a Video Data Period. In this case only Video Data Periods are announced.

MSwann

Next question, @cgracey.
The spec says each Video Data Period is prefixed with a leading Guard Band consisting of two special characters encoded into 10-bit patterns.
Does your code emit a Guard Band?

MSwann

@rogloh, thanks for that explanation. It's matching what I see in the HDMI pdf. It indicates that DVI is a subset of HDMI, if I got that correct.
Alright, now that I have some understanding, I want to encode stereoscopic frames.
I have a PDF showing the HDMI version 1.4A spec for extracting the 3D signal, but I have no clue how to properly encode the vendor-specific info-frame packets to tell what video format I'm using. Plus I thing all this requires I go beyond DVI and emit more things like guard bands.
Any ideas?

rogloh

Yes it does require you do go well beyond DVI. You will need a whole bunch of things including a TERC4 encoder, ability to send guard bands, data islands, info frame packets and do parity generation for the different error correcting codes sent over the link. TERC4 encoding is achievable (at SDTV resolution) on the P2 with a whole lot of work if you have all the information available and a good way to debug it. I don't know about 3D stuff, those formats are likely to require pixel clocks much higher than what the P2 can output. You may also have to license different specs to be able to get access to all the information so you can figure out how to do it unless it is fully defined in the documents you already have. I think some more details of the Vendor specific info frames may be defined in CTA-861 specs, for example.

cgracey

MSwann wrote: »

Next question, @cgracey.
The spec says each Video Data Period is prefixed with a leading Guard Band consisting of two special characters encoded into 10-bit patterns.
Does your code emit a Guard Band?

It doesn't look like it. It would be pretty apparent, wouldn't it?

evanh

I think what Roger said first was that HDMI has those guard bands, islands, error correction and what not, as extras - DVI keeps it simple without them. You could call HDMI an optional extension to the protocol.

MSwann

cgracey wrote: »

MSwann wrote: »

Next question, @cgracey.
The spec says each Video Data Period is prefixed with a leading Guard Band consisting of two special characters encoded into 10-bit patterns.
Does your code emit a Guard Band?

It doesn't look like it. It would be pretty apparent, wouldn't it?

Yea, it was a stupid question, but I didn't know enough about how the P2 implements HDMI mode to know what is going on under the hood, or not going on under the hood.

cgracey

> @MSwann said:
> cgracey wrote: »
>
> MSwann wrote: »
>
> Next question, @cgracey.
> The spec says each Video Data Period is prefixed with a leading Guard Band consisting of two special characters encoded into 10-bit patterns.
> Does your code emit a Guard Band?
>
>
>
>
> It doesn't look like it. It would be pretty apparent, wouldn't it?
>
>
>
>
> Yea, it was a stupid question, but I didn't know enough about how the P2 implements HDMI mode to know what is going on under the hood, or not going on under the hood.

I wasn't implying there was anything wrong with your question. I was just wondering if maybe I didn't understand what was involved, myself.

potatohead

I have a 3D capable TV. Once in a while, I will work on complex CAD models in 3D. Think automotive or aero type models, wiring, hydraulics, etc. Many nVidia gfx sub-systems will output 3D HDMI to a display that identifies as one. I use a Quadro 1000 M

In the most basic sense, the frame rate is doubled. 60hz becomes 120.

However, the shutter glasses do need to run at 50ish Hz+ / eye to avoid fatigue. And that is a modest value. There will be fatigue. The common 3d viewing formats out there are doing 50 /60 with the set refresh being 100 / 120hz.

Long ago, I utilized 3D viewing systems on SGI computers that would do it as low as 60Hz, meaning 30hz per eye. These were not really practical for more than a few minutes of viewing.

Unless the spec can be abused somehow, like say a 24p type pixel stream combined with a faster eye shutter, 3D may simply take 2x the pixel clock, meaning we need a 500Mhz P2.

I have not seen 24p 3D BluRay media out there. Maybe it exists and that kind of thing is possible.

Or maybe optically combining 2 displays like we can do now easily, could make some sense.

Wuerfel_21

I think 24Hz 3D is part of the spec - actually, I have some 3D movies and a usually-24Hz-capable 3DTV + player laying around, I could check if any of those are 24Hz.

rogloh wrote: »

Yes it does require you do go well beyond DVI. You will need a whole bunch of things including a TERC4 encoder, ability to send guard bands, data islands, info frame packets and do parity generation for the different error correcting codes sent over the link. TERC4 encoding is achievable (at SDTV resolution) on the P2 with a whole lot of work if you have all the information available and a good way to debug it.

Can you not just pre-bake a fully encoded data island containing the packets you want (i.e. enable stuff like YCbCr mode, 3D, etc, signal desired aspect ratio and all the other fun things that are possible) and then just send it using 32bit FIFO mode every time it is needed?

potatohead

If so, that is cool! 3D frames may be possible at the P2 pixel clock.

Edit, my nVidia will output 24p 3d. Should have just looked at the configuration options.

MSwann

Wuerfel_21 wrote: »

I think 24Hz 3D is part of the spec - actually, I have some 3D movies and a usually-24Hz-capable 3DTV + player laying around, I could check if any of those are 24Hz.

rogloh wrote: »

Yes it does require you do go well beyond DVI. You will need a whole bunch of things including a TERC4 encoder, ability to send guard bands, data islands, info frame packets and do parity generation for the different error correcting codes sent over the link. TERC4 encoding is achievable (at SDTV resolution) on the P2 with a whole lot of work if you have all the information available and a good way to debug it.

Can you not just pre-bake a fully encoded data island containing the packets you want (i.e. enable stuff like YCbCr mode, 3D, etc, signal desired aspect ratio and all the other fun things that are possible) and then just send it using 32bit FIFO mode every time it is needed?

@Wuerfel_21, My slightly educated answer is Yes.

MSwann

rogloh wrote: »

Yes it does require you do go well beyond DVI. You will need a whole bunch of things including a TERC4 encoder, ability to send guard bands, data islands, info frame packets and do parity generation for the different error correcting codes sent over the link. TERC4 encoding is achievable (at SDTV resolution) on the P2 with a whole lot of work if you have all the information available and a good way to debug it. I don't know about 3D stuff, those formats are likely to require pixel clocks much higher than what the P2 can output. You may also have to license different specs to be able to get access to all the information so you can figure out how to do it unless it is fully defined in the documents you already have. I think some more details of the Vendor specific info frames may be defined in CTA-861 specs, for example.

@rogloh, 3D formats can, but don't have to require higher pixel clocks. You can encode a 3D frame in the same space as a 2D frame. For example, you can use 720/480 over/under where the left and right images are sub-sampled to half vertical resolution of 240, or side-by-side where the sub-sampled horizontal resolution is 360.

evanh

Or halve both H and V resolutions and quad the field rate to get the frame rate real high. Possible?

Wuerfel_21

With VGA, most CRT monitors will take 640x240 120Hz no problem (if the monitor goes up to 120Hz to begin with), albeit with huge gaps between the lines (looks nice on photo, but is hell on your eyes). Most LCDs don't seem to like over 75Hz at all. (Don't have a high refresh rate LCD, so I have no idea if they like 240p120)

Many 3D monitors/TVs likely also support high frame rate, but obviously not at the same time as 3D.

MSwann

evanh wrote: »

Or halve both H and V resolutions and quad the field rate to get the frame rate real high. Possible?

The HDMI spec I have only allows three modes:
(1) Frame Packing
(2) Over/Under
(3) Side-by-side
Frame Packing is like over/under but the left and right images are not sub-sampled, so 2D 720/480 becomes 3D 720/960. The 3d-capable monitor or TV will render an effective ratio of 720/480 with no loss of vertical resolution but at twice the pixel rate.
(2) and (3) Don't need a higher pixel rate, but you sacrifice image definition along one axis or the other.

evanh

So, useless without upping the pixel rate then. Err ... Useless for high frame rates, period.

Tubular

Ok, this is getting really interesting. I had just guessed (insufficient googling) that this would be beyond the P2 capabilities, but those sacrificing definition is not a big deal if this can be made to work

rogloh

MSwann wrote: »

@rogloh, 3D formats can, but don't have to require higher pixel clocks. You can encode a 3D frame in the same space as a 2D frame. For example, you can use 720/480 over/under where the left and right images are sub-sampled to half vertical resolution of 240, or side-by-side where the sub-sampled horizontal resolution is 360.

Ok cool, then that opens up 3D formats perhaps as a possibility for the P2 to output if the TMDS bits can remain clocked at 270MHz for 480p and the rate doesn't need to double to 540MHz.

Wuerfel_21 wrote: »

Can you not just pre-bake a fully encoded data island containing the packets you want (i.e. enable stuff like YCbCr mode, 3D, etc, signal desired aspect ratio and all the other fun things that are possible) and then just send it using 32bit FIFO mode every time it is needed?

Yes you can pre-encode the data island content once and stream it if its source data remains static (you can't for audio for example, you have to that in real-time because the content changes). You will need to know when the H&V sync start and end within the packet as this also changes the input to be encoded in the island on the blue channel, but if you decide to send it either on the lines with the same VYSNC level at the same pixel offset, you only need one copy of the packet in the island, otherwise you would need two copies.

MSwann

Amazing. I'm actually beginning to understand it all. This is the most creative conversation of which I am honored to be a part. Or maybe it's all because I just finished my second gin tonic for the night.
Happily rendering in three dimensions. See you all in the A.M.

pilot0315

Is there a link that explains this step by step. Never tried this.

@cgracy
Thanks

cgracey

pilot0315 wrote: »

Is there a link that explains this step by step. Never tried this.

@cgracy
Thanks

I'm not sure what your question is about. What do you want step-by-step instructions for?

pilot0315

@cgracy
How does hdmi work. I understand the code to a good extent. But I have looked on the internet about hdmi and basically so far, need to more digging, about how does the hdmi work.
Looking for an explanation to get a basic idea of what the code is controlling?

cgracey

It uses 10-bit TMDS encoding to digitally send the 8-bit RED, GREEN, and BLUE channels, instead of using analog voltage levels, like VGA does. This is why it must signal at 10x the pixel rate:

https://en.m.wikipedia.org/wiki/Transition-minimized_differential_signaling

amock

You might also find https://github.com/hdl-util/hdmi interesting. It has some links to references at the bottom.

pilot0315

@cgracey
@amock

Thanks

pilot0315

MSwann wrote: »

@rogloh, thanks for that explanation. It's matching what I see in the HDMI pdf. It indicates that DVI is a subset of HDMI, if I got that correct.
Alright, now that I have some understanding, I want to encode stereoscopic frames.
I have a PDF showing the HDMI version 1.4A spec for extracting the 3D signal, but I have no clue how to properly encode the vendor-specific info-frame packets to tell what video format I'm using. Plus I thing all this requires I go beyond DVI and emit more things like guard bands.
Any ideas?

@MSwann

Is it possible you could send me a link to that pdf??

Thanks

MSwann

pilot0315 wrote: »

MSwann wrote: »

@rogloh, thanks for that explanation. It's matching what I see in the HDMI pdf. It indicates that DVI is a subset of HDMI, if I got that correct.
Alright, now that I have some understanding, I want to encode stereoscopic frames.
I have a PDF showing the HDMI version 1.4A spec for extracting the 3D signal, but I have no clue how to properly encode the vendor-specific info-frame packets to tell what video format I'm using. Plus I thing all this requires I go beyond DVI and emit more things like guard bands.
Any ideas?

@MSwann

Is it possible you could send me a link to that pdf??

Thanks

@pilot0315. Attached are two PDFs: one for HDMI spec 1.4, and another for how to extract the 3D signal.