Understanding 720p video timings
Matthieu Poullet
I'd like to sum up the latest discussions on IRC regarding the
720p@50/60Hz video timings.
720p video timings are formally defined in the SMPTE 296M standard,
available at [1].
A typical display device support many different video timings which
have been defined by different standard bodies like e.g. SMPTE, ITU-R,
VESA...
The CEA-861-E standard, available at [2], brings order in this chaos
by assigning to all these video timings a unique mode number:
720p@50Hz => mode 19
720p@60Hz => mode 4
When a new version of the CEA-861 standard is released, the last
letter is increased, so that the next release will be CEA-861-F.
These video modes are normally available through the EDID of the TV
sets, see [3].
Tomi Valkeinen has posted some code allowing to read the EDID here [4].
Frans Meulenbroeks has also suggested the program "moninfo" to read
EDID under Windows [5].
As I'm not a lawyer, I don't know if publishing the timings available
in [1] and [2] is allowed.
If you buy them, there's a "No reproduction or networking permitted
without license" clause on them.
However, others have already made some of them available [6] and I
confirm that they are conformed with the CEA-861-E standard.
As it might interest others, I'd like to explain how to read the
modeline from [6]:
"hd720", 60, 1280, 720, 13468, 220, 110, 20, 5, 40, 5,
60: 60Hz, the refresh rate
1280,720: width x height of the active video area, that it the area
which is displayed on the screen
13468: 13468 picoseconds is the pixel clock, that is, it takes 13468ps
for the video controller to draw a single pixel
So you should object that then it takes 1280x720x13468x10^(-12) =
0.01241s to refresh the screen.
That is the refresh rate is about 80Hz, but it's a 60Hz mode ?!
If you've read carefully before, you remember that the 1280x720 pixels
represent only the active video area.
That's why the previous calculation is wrong: we need to take care of
both vertical and horizontal blanking areas.
In SMPTE 720p modes, the vertical blanking area is constant: 30
pixels, so that the total vertical length is 720+30=750 pixels
So the only possibility to get different refresh rates is to play with
the horizontal blanking area:
720p@50Hz: 700 pixels
720p@60Hz: 370 pixels
Let's redo the maths now:
(1280+700)x(720+30)x13468x10^(-12)=0.02s => 50Hz
(1280+370)x(720+30)x13468x10^(-12)=0.016s => 60Hz
and we're almost done.
You now see the primary advantage of these video timings: it can
generate different refresh rates by using the same pixelclock of
13468ps/74.25MHz.
To keep the TV sets synchronized there are an horizontal/vertical sync
pulse in the horizontal/vertical blanking, so we need to know:
1 - how long are these pulses?
2 - where to place them in the horizontal/vertical blanking?
Answers (720p@60Hz):
1 - hsync: 40 pixels / vsync: 5 pixels
2 - using the terminology of [7], the blanking areas are organized as follow:
horizontal blanking: right margin <-> hysnc length <-> left margin
vertical blanking: lower margin <-> vsync <-> upper margin
left margin and upper margin are constant in the 720p timings:
left margin: 220 pixels
upper margin: 5 pixels
and we're completely done this time:
right margin: 370-40-220 = 110 pixels
lower margin: 30-5-5 = 20 pixels
To sum up:
"hd720", 60, 1280, 720, 13468, 220, 110, 20, 5, 40, 5,
60: 60Hz, the refresh rate
1280,720: width x height of the active video area, that it the area
which is displayed on the screen
13468: 13468 picoseconds is the pixel clock, that is, it takes 13468ps
for the video controller to draw a single pixel
220: left margin
110: right margin
20: lower margin
5: upper margin
40: hsync length
5: vsync length
The last issue is the polarity of the sync pulses, they must be
positive according to standard, whereas they are negative per default
for the SD video timings.
Tomi Valkeinen's latest DSS2 driver [8] support wider timing registers
and so could be used with both 720p@50Hz and 720p@60Hz timings.
I hope that it helps the community getting most HDTV sets running by
tweaking the DSS2 appropriately.
Remarks/corrections and/or comments are welcome.
Regards,
Matthieu.
PS: Thanks to tomba, mru, AV500, eFfeM, Koen and recalcati on #beagle.
[1] http://store.smpte.org/product-p/smpte%200296m-2001.htm
[2] http://www.ce.org/Standards/browseByCommittee_2641.asp
[3] http://en.wikipedia.org/wiki/Extended_display_identification_data
[4] http://groups.google.com/group/beagleboard/browse_thread/thread/5274e1527067d88e/99e2af82cba3d50f?lnk=gst&q=EDID#99e2af82cba3d50f
[5] http://www.entechtaiwan.com/util/moninfo.shtm
[6] http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=687a7700eabaa53b1187947b6f3b4f1662b9bbb6
[7] http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=Documentation/fb/framebuffer.txt;h=b3e3a035683993edc8391cefd11ea3ef6be9eb08;hb=HEAD
[8] http://www.bat.org/~tomba/linux-omap.html
Koen Kooi
Op 8 apr 2009, om 22:48 heeft Matthieu Poullet het volgende geschreven:
> The last issue is the polarity of the sync pulses, they must be
> positive according to standard, whereas they are negative per default
> for the SD video timings.
So we need a syncpol flag to change those at runtime?
regards,
Koen
Russ Dill
> tweaking the DSS2 appropriately.
>
> Remarks/corrections and/or comments are welcome.
>
Did you look into 24Hz modes at all? I would think that this would
reduce the memory bandwidth required for display refresh and also has
the possibility of reducing DVI power consumption.
mpoullet
The DSS2 has already such flags in place:
OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS | OMAP_DSS_LCD_IPC
AFAIR you can simply put this in the generic panel driver and give a
try, but it's only a hack.
Haven't tried with the latest DSS2, but it should work.
Regards,
Matthieu.
> < 1 KBAnzeigenHerunterladen
mpoullet
On 8 Apr., 23:00, Russ Dill <russ.d...@gmail.com> wrote:
> > I hope that it helps the community getting most HDTV sets running by
> > tweaking the DSS2 appropriately.
>
> > Remarks/corrections and/or comments are welcome.
>
> Did you look into 24Hz modes at all?
> I would think that this would
> reduce the memory bandwidth required for display refresh and also has
> the possibility of reducing DVI power consumption.
The problem is that only the most recent TV sets support 720p@24Hz
correctly and most of the available contents aren't 24Hz friendly.
Regards,
Matthieu.
Brett Kuehner
<matthieu...@gmail.com> wrote:
>
> Hi,
>
> I'd like to sum up the latest discussions on IRC regarding the
> 720p@50/60Hz video timings.
>
Thank you very much for writing this up, it is very informative.
Brett
Frans Meulenbroeks
Thanks for the nice writeup.
Maybe once this is fully resolved we should write this in the wiki or
in the omap video driver documentation.
Meanwhile I did a small experiment yesterday evening (as you
suggested).
Standard video driver: works on my iiyama IVM560D monitor, does not
work on my TV (Philips 42PF9731D/10).
The patch you gave changes the horizontal front and back porch values
and the vertical ones too.
The resulting video driver works on my TV but not on my monitor any
more.
Key difference is that the iiyama has -hsync and the tv has +hsync
I guess what happens is that by swapping the hor front and back porch
values actually the sync signal is inverted (but I did not verify with
a scope or signal analyser).
Wrt Koen's remark:
The sync info is in the EDID info of the monitor. I would expect the
driver to take care of that. Didn't have time to dive into that
though. Alternately sync info should be added to modefb (fbmode?) (if
it is not there, didn't look into that part)
Frans/eFfeM
Leon Woestenberg
On Wed, Apr 8, 2009 at 10:48 PM, Matthieu Poullet
<matthieu...@gmail.com> wrote:
>
> 2 - using the terminology of [7], the blanking areas are organized as follow:
> horizontal blanking: right margin <-> hysnc length <-> left margin
> vertical blanking: lower margin <-> vsync <-> upper margin
>
I think the VESA "reduced blanking" should be added for completeness.
Many displays support reduced blanking:
http://linux.die.net/man/1/cvt
http://www.vesa.org/Public/CVT/CVTd6r1.xls
Regards,
--
Leon