How to calculate pixel clock
Worked examples
| Format | H total | V total | Refresh | Pixel clock |
|---|---|---|---|---|
| 1080p60 (VIC 16) | 2200 | 1125 | 60 | 148.5 MHz |
| 1080p59.94 (VIC 16) | 2200 | 1125 | 60 × 1000/1001 | 148.352 MHz |
| 2160p60 (VIC 97) | 4400 | 2250 | 60 | 594 MHz |
59.94 Hz formats use the same totals as 60 Hz with the clock × 1000/1001: 148.5 ÷ 1.001 = 148.3516 MHz.
The numbers that follow from it
- Horizontal frequency = pixel clock ÷ H total. 1080p60: 148.5 MHz ÷ 2200 = 67.5 kHz.
- Refresh rate = horizontal frequency ÷ V total. 67.5 kHz ÷ 1125 = 60 Hz.
- Data rate = pixel clock × bits per pixel. At 1080p60: 8-bit RGB (24 bits) = 3.56 Gbit/s; 8-bit YCbCr 4:2:2 (16 bits) = 2.38 Gbit/s; 8-bit YCbCr 4:2:0 (12 bits) = 1.78 Gbit/s.
- HDMI TMDS character rate = pixel clock × bits per component ÷ 8. 10-bit RGB runs at 1.25 × the pixel clock; YCbCr 4:2:2 always runs at the pixel clock; YCbCr 4:2:0 halves it. HDMI 1.4 tops out at 340 MHz, HDMI 2.0 at 600 MHz.
Why a custom timing shows 59.939 Hz, not 59.94
An EDID stores the pixel clock in 10 kHz steps, so the refresh can't always land exactly. For 1080p59.94 with CVT blanking (2576 × 1120), the ideal clock is 172.9341 MHz. The closest an EDID can store is 172.93 MHz, which gives 59.939 Hz. That's what PixelTach's "Exact refresh" mode does, like the Pixera and Analog Way EDID editors.
The VESA CVT standard's own method rounds the clock down to a 0.25 MHz step instead: 172.75 MHz and 59.876 Hz. That's PixelTach's "CVT strict" mode.
An EDID detailed timing also has a ceiling: 655.35 MHz. Faster timings go into a DisplayID block, with a simpler timing as a fallback for sources that don't read it.