# How to calculate HDMI Bandwidth



## sk8conz

I'm sure I will feel very dumb the second someone answers this but :-


I can't seem to get the right answers when trying to calculate the bandwidth required for a given resolution/refresh etc.


Resolution X Refresh X Color Depth = Bandwidth


So for 1080p/60hz/8 Bits I get


(1920X1080) X 60 X 8 = 995,328,000


That is per channel so X 3 gives 2,985,984,000


But HDMI.org has 1080p/60/8 as 4.46Gbps (148.5 Mhz)



Where did I go wrong ??


----------



## KurtBJC

Well, for one thing, an eight-bit color signal rides in a ten-bit word, so you need to bump your calculation by 25%. That still doesn't get you there, because there are other issues, all of which can be rather difficult to sort through (I'm at home and don't have the spec document in front of me, and can't recall what all these little bits are called). Even if you get the formula right, it sometimes will get you the wrong answer because there are odd things in the spec; for example, if I recall correctly, 480i signal pixels are each sent twice, so that 480i and 480p wind up at exactly the same bitrate.


Kurt
Blue Jeans Cable


----------



## sk8conz

I have the whitepaper as well, and I guess the big thing I'm not accounting for is the audio stream which as I understand it is multiplexed into the video stream.


So if I factor in a "typical" audio stream of say 5 channels then I should get pretty close.


No biggie, as I can take the 4.46 Gbps baseline (1080p/60Hz/8 Bits) and work backwards.


Which means that the new "holy grail" of 1080p24 actually takes something less than 2 Gbps (roughly).


----------



## drewbowski




> Quote:
> Originally Posted by *sk8conz* /forum/post/13150287
> 
> 
> I'm sure I will feel very dumb the second someone answers this but :-
> 
> ...
> 
> Resolution X Refresh X Color Depth = Bandwidth
> 
> So for 1080p/60hz/8 Bits I get
> 
> (1920X1080) X 60 X 8 = 995,328,000
> 
> That is per channel so X 3 gives 2,985,984,000
> 
> ...



so, for a guidline of BW, is that the correct formula?

i'm trying to get straight pixel clock rate, BW, and what to use in my calculations.


i found some formula's ... Resolution x Refresh Rate x [1 + Blanking Period] ... and ... BW = [(TP x Vt) /2] x 3 ...

but would like to know what is correct, and where did the factors come from, such as the 2 divisor and 3 multiplier, and the 1+ blanking.


if anybody can at least point me to a white paper or table, i'd have much appreciation.


----------



## KurtBJC

You can download a free copy of the HDMI spec document, in .pdf format, from the HDMI Licensing people at hdmi.org -- as I mentioned, I'm out of the office this week so I don't have access to my copy right at hand, but as I recall it, there isn't a single fixed formula the way there is with DVI because of some of the oddities in the spec. For example, 1080i and 720p run the same bitrate despite the fact that the number of pixels per second is different, and 4:2:2 video is sent differently from 4:4:4, and some formats have pixels doubled, and that sort of thing.


Kurt
Blue Jeans Cable


----------



## balaji




> Quote:
> Originally Posted by *sk8conz* /forum/post/13150287
> 
> 
> Resolution X Refresh X Color Depth = Bandwidth
> 
> 
> So for 1080p/60hz/8 Bits I get
> 
> 
> (1920X1080) X 60 X 8 = 995,328,000
> 
> 
> That is per channel so X 3 gives 2,985,984,000
> 
> 
> But HDMI.org has 1080p/60/8 as 4.46Gbps (148.5 Mhz)
> 
> 
> Where did I go wrong ??



Besides the fact that you missed out the 8bto10b encoding, you also left out the hblank and vblank which changes your frame size.


Thus the math will look like this: (1920+280) * (1080+45) * 60 * 10 * 3 = 4.455 Gbps.


----------



## FiberOpticDude

Note that the video signal only sets the bit rate, the audio signal does not add to the bit rate. The audio is packed into the blanking interval inside data islands. The coding for the video is called TMDS or Transition Minimized Differential Signalling and takes 8bits and adds 2 overhead bits. The coding for the data islands is different. It uses TERC4 which takes 4bits and adds 6 overhead bits.


So the video signal (resolution, frequency) actually determines the upper bound on the total bit rate available for the audio signal. FYI


----------



## sk8conz




> Quote:
> Originally Posted by *FiberOpticDude* /forum/post/16524847
> 
> 
> Note that the video signal only sets the bit rate, the audio signal does not add to the bit rate. The audio is packed into the blanking interval inside data islands. The coding for the video is called TMDS or Transition Minimized Differential Signalling and takes 8bits and adds 2 overhead bits. The coding for the data islands is different. It uses TERC4 which takes 4bits and adds 6 overhead bits.
> 
> 
> So the video signal (resolution, frequency) actually determines the upper bound on the total bit rate available for the audio signal. FYI




Does this still hold true for the new uncompressed audio (DTS-MA and Dolby True-HD) ?


----------



## FiberOpticDude




> Quote:
> Originally Posted by *sk8conz* /forum/post/16525711
> 
> 
> Does this still hold true for the new uncompressed audio (DTS-MA and Dolby True-HD) ?



Yes, this still holds for the new audio formats. Note that the high resolution video allows for a lot of audio bandwidth. For example, a 720p or 1080i 60Hz signal allows 8 channels of uncompressed, 192kHz sample rate, 24bit resolution audio. At 480p 60Hz you can have 8 channels of uncompressed audio at only 48KHz sample rate -- unless the signal has pixel repetition, in that case, with 4x pixel repetition you can have the 192kHz sample rate. This is because using pixel repetition the data rate is increased by 4x and the resulting audio "bandwidth" is increased by 4x.


I don't have the latest and greatest information, but I imagine that 1080p 60Hz allows for more than 8 channels of uncompressed audio - the bandwidth is there I just don't know if it is written into the specs.


----------



## dobyblue




> Quote:
> Originally Posted by *balaji* /forum/post/16506588
> 
> 
> Besides the fact that you missed out the 8bto10b encoding, you also left out the hblank and vblank which changes your frame size.
> 
> 
> Thus the math will look like this: (1920+280) * (1080+45) * 60 * 10 * 3 = 4.455 Gbps.



Can you tell me where my maths is wrong?


2200 * 1125 = 2475000 number of pixels

2475000 * 30 = 74250000 (8-bit color)

74250000 * 60 = 4455000000 (60 frames per second)

4455000000 / 8 = 556875000 convert to bytes/sec

= 4.14904207 Gbps?


----------



## MichaelJHuman

And you seem to be ignoring the fact that there are three data lines. Audio and video share the three lines. I forget the exact details. It's in the HDMI document.


----------



## fjlin19710610

HSYNC: 1920+280 (horizontal blanking pixel No.)

VSYNC: 1200+50 (vertical blanking line No.)

total pixel per frame = 2200x1250 = 2.75 Mpx/frame

Bit rate = 2.75 Mpx/frame x 24 (= 3x8) bit/px x 60 frame/s = 3.96 Gbit/s

TMDS: 8 bit -> 10 bit

TMDS bit rate = 3.96 Gbit/s x 10/8 = 4.95 Gbit/s


----------



## nded

Aren't you over-inflating the bandwidth, when movies (the predominant 1080p content) are encoded on Blu-Ray and other formats like Vudu at 24fps?


----------



## FiberOpticDude

Nope, fjlin's got it right. The HDMI link is uncompressed video. Content encoded on a Blu-ray or for Vudu is highly compressed. It is uncompressed and delivered to your television via a very fat pipe - HDMI. The 1x data rate for reading a Blu-ray maxes out around 36Mbps. I'm sure a Vudu stream is less than that.


----------



## kasabe23

I think fjlins correct and I understand it. fjilns caculation has the vertical resolution at 1200. Why? If I use 1125(1080+45) in fjiln's equation I get 4.45Gbps. I am assuming is 1200 for computer resolutions?


So as long as a cable can pass 4.95Gbps or higher it will easily pass a bluray 1080p/60hz image. Based on that calculation then for 1080p/24fs

[(1920+280)*(1080+50)*(8bitscolorx3)*24frames/sec]*10/8=1.78Gbps. So is that to say if I output 1080p24 from a bluray player to a TV that accepts 1080p/24, Then I will be technically only passing 1.78Gbps through the the HDMI cable. Thus not needing a cable with a speed higher than 4.95Gbps.


This also sounds like at the current moment (and under 6ft length) we only need HDMI cable to pass a 4.95Gbps, as our highest "current source" (bluray) does not currently exceed that. Correct?


----------



## kasabe23

I want to test my understanding on th HDMI 1.3 Category 1 vs Category 2 differences. Moreso to make sure I am explaining it correctly.


HDMI 1.3 Category 1 certifies that a cable "At minimum" passes 75Mhz(2.25Gbps). That is not to say it cannot pass a 1.65MHz(4.95Gbps) signal needed for the bandwith of Bluray. Just that "at minimum" it is certified to pass 75Mhz.


HDMI 1.3 Category 2 CERTIFIES that a cable "At minimum" passes 340Mhz(10.2Gbps). THis is way pass what is needed for Blu-ray. Obviously, Category 2 are undisputed to pass the 1080p of bluray.


So somewhere in-between this two certified standards are Category 1 cables that don't quite hit the 340Mhz mark, to be Category 2, but easily just as good for bluray.


----------



## FiberOpticDude

Kasabe23,


Yep, essentially you are correct... except where you say 1.65MHz (you mean 165MHz).


Category 1 certifies at least 720p/1080i performance which computes to 742.5Mbps on each of the three TMDS data lines in the cable... or a total data transfer rate of 2.23Gbps.


Category 2 certifies at least 3.4Gbps on each data lane or a total of 10.2Gbps data transfer.


A lot of Category 1 cables are perfectly capable of 1080p @ 60Hz with 36bit color which equates to 2.23Gbps per lane or approximately 6.7Gbps total. But you will have to try to find out. I have a system at work which works perfectly (no errors) at this rate through a 50m (165ft) HDMI cable using an equalizer at the end. The sad thing is that this setup can only be certified as Category 1 because it will not operate at 3.4Gbps (10.2Gbps total). So it can only be certified at 742.5Mbps when it is capable of 2.23Gbps.


----------



## kasabe23

Thanks FiberopticDude. Type0 on the 165. Here is how I understand the the bandwidth calculated for for HDMI bandwith.

HDMI TDMS Bandwith= [(Hsync+Hor blank pixels)*(Vsync+Ver blank Pixels)*Colorspace(ie8bitsx3ch)*refresh rate]*10/8=Total Gbps bandwith


For 1920x1080,8bitcolor,60hz refresh rate (assuming I have the verblanking pixels correct):


[(1920+280)+(1080+50)]*24*60]*10/8=4.47 Gbps.


How do I calculate the Mhz Date rate (ie. 4.95Gpbs=165Mhz) How do I calculate the to get 165Mhz?


----------



## FiberOpticDude

Yep, your equation is correct. The problem is knowing what the horizontal and vertical blanking is. It is not some percentage of the active video area, it is purely a number that you look-up once you know the resolution and frame rate.


Note that we don't ever really talk about the total bit rate (except for advertising purposes), we focus on the bit rate for each lane.


So for 1080p, 60Hz, 24bit color the data rate of each lane is:

[(1920+280)*(1080+*45*)*8*60]*10/8 = 1.485Gbps


The MHz rate is the pixel rate so for 24bit color (8 bits per R, G, B) all you have to do is divide the above rate by 10 so the pixel frequency is 148.5MHz. Note that this relates back to analog raster scanning. Also when I say pixel rate above I don't mean active pixels, I mean total pixels including blanking intervals.


Now when you talk about 1080p at 24fps. The blanking intervals change in size. This was done to make the data rate of 1080p24 = 1080i. I don't have the blanking interval sizes with me so I can't write down the exact equation but I believe it is something like:


[(1920+830)*(1080+45)*8*24]*10/8 = 742.5Mbps


I believe the horizontal blanking was increased so the data rate would match up with 1080i/720p data rate. This is probably done to reduce the number of data rates the circuitry has to deal with.


Now let's look at 36bit color at 1080p 60Hz.

[(1920+280)*(1080+45)*12*60]*10/8 = 2.23Gbps


Note that all my examples assume that the color coding is in a 4:4:4 scheme and not 4:2:2. I really don't know if much equipment operates with a YCbCr 4:2:2 so I'll stay away from that discussion.


----------



## av_phile

Curious regarding HDMI 1.4. Would appreciate your thoughts why do you need one for 3D when HDMI 1.3 has a maximum of 10.2 Gbps? A single 1080p eats only 4.9Gbps, so to send two 1080ps for 3D you only eat 9.8 Gbps.


Another question: will 1080i eat less bandwidth than 1080p? Thanks.


----------



## Richard Paul




> Quote:
> Originally Posted by *av_phile* /forum/post/18023701
> 
> 
> Curious regarding HDMI 1.4. Would appreciate your thoughts why do you need one for 3D when HDMI 1.3 has a maximum of 10.2 Gbps? A single 1080p eats only 4.9Gbps, so to send two 1080ps for 3D you only eat 9.8 Gbps.



Just a small correction but 4.95 Gbps would be for 1920x1200 and 4.45 Gbps would be for 1920x1080. As for HDMI 1.4 I think the maximum bandwidth remains the same as HDMI 1.3 and the difference in 3D support is that they defined the signaling formats which are used to deliver 3D video over HDMI. Here is an interview with the President of HDMI Licensing about HDMI 1.4 .


----------



## av_phile

Okay so the bandwidth is the same for both. Wikipedia confirms that. But why is the PS3 implementation of 3D after its firmware update require sequential 1080i to be sent over hdmi 1.3 if it just a matter of signaling difference. Whereas other 3D implementation can send the full 1080p for each eye over 1.4?


----------



## Richard Paul




> Quote:
> Originally Posted by *av_phile* /forum/post/18032884
> 
> 
> But why is the PS3 implementation of 3D after its firmware update require sequential 1080i to be sent over hdmi 1.3 if it just a matter of signaling difference. Whereas other 3D implementation can send the full 1080p for each eye over 1.4?



There are many rumors about what the PS3 will be capable of in terms of 3D output over HDMI 1.3 and HDMI 1.4 but last I checked Sony has not yet made an official announcement.


----------



## HarryHydro


Hi:

  This should give a good count for 8 bits per pixel, but each pixel I think can be red, green, or blue, or any combination. So, it might be 24 bits/pixel.  Cameras are not measured the same way.. Cameras I think have 2 greens, a red, and a blue, in a 4 byte block. (2X2) So, a camera resolution needs to be 2X and 2Y the size of the monitor the pictures are displayed on to be perfect.

 I think HDMI might just be 30FPS at the high pixel sizes..

Harry


----------



## Otto Pylot

Huh? This is a 4 year old thread. We're now at HDMI 1.4b and 2.0 is coming.


----------

