View Full Version : Vertical Blanking Interval
kieranrk
22nd April 2011, 19:02
Which specification specifies the number of lines in the VBI of NTSC and PAL digital formats? Is there any explanation of how the data is split over luma and chroma samples?
drmpeg
22nd April 2011, 20:11
VBI formats are a huge can of worms. There are many specifications from different specification bodies (SCTE, EIA, SMPTE, etc). You have to be more specific.
If you're just asking how many VBI lines there are, even that is not cast in concrete. For PAL, it's probably always 625 -576 = 49. For NTSC, it could be anywhere from 525 - 480 = 45 to 525 - 486 = 39.
Ron
kieranrk
22nd April 2011, 20:27
Thanks for the answer drmpeg.
What I don't really understand is how each VBI byte is presented in an uncompressed SDI stream. Does each VBI byte map to one luma sample (or is this dependent on the data itself)?
drmpeg
22nd April 2011, 22:00
SMPTE 334M defines how VBI data is mapped to luma and chroma samples. Most data formats use luma samples since chroma samples are more or less reserved for embedded audio.
The big pain with SMPTE 334M is that all 10 bits are used. The data byte is in bits 0 through 7 and bits 8 and 9 are used for parity. The problem is that if you're just capturing 8 bits for an 8-bit encode, then you will be capturing bits 2 through 9 (and dropping important data in bits 0 and 1). Of course, this is hardware dependent.
Here's a picture of what's in the blanking. This is from an MPEG-2 encoder that was capturing from EAV instead of SAV and the first capture line was moved up. You can see the embedded audio in the horizontal blanking and probably VITC in the VBI.
http://www.w6rz.net/blanking.png
Ron
kieranrk
22nd April 2011, 22:24
Thanks for the information. I'm not actually talking about "VBI in VANC" here but "pure VBI" (i.e lines that could be seen on a television if it had no overscan)
From what I gather it's quite common in SD to stick captions in "pure VBI", although some newer devices will let you put the streams in VANC.
drmpeg
22nd April 2011, 23:20
NTSC closed captions look like this.
Two NULL bytes:
http://www.w6rz.net/analogcc2.png
Two text bytes:
http://www.w6rz.net/analogcc17.png
Ron
jmac698
24th April 2011, 07:41
CEA-608 for analog and CEA-708 for DTV
ccextractor.sourceforge.net has a program to extract it, and lots of information on decoding.
ps drmpeg can you capture a full frame of video but b/w only (for example connect composite cable to luma of svideo input)
I'd like to see closed captioning, and try to decode color myself, and see the sync signals etc.
colorbars, and on VCR (with no TBC, so I can try to dejitter myself too)
I'd really love to see jitter including the hsync...
also are there any free programs to place cc into mpeg2? so I can produce it in analog off a dvd...
2Bdecided
26th April 2011, 12:17
Thanks for the information. I'm not actually talking about "VBI in VANC" here but "pure VBI" (i.e lines that could be seen on a television if it had no overscan)
From what I gather it's quite common in SD to stick captions in "pure VBI", although some newer devices will let you put the streams in VANC."pure VBI"? This is meaningless. The vertical blanking interval is from the end of active picture on the last active picture line on one field, to the start of active picture on the first active picture line on the next field.
The only part of this that a standard "TV with no overscan" will show you is the "other" half of the half lines - overscan is part of active picture - it doesn't include the VBI (or HBI).
Some monitors will show some of the VBI when you select "underscan" mode, but not all. Pulse Cross / H/V-sync-delay will show you everything.
FWIW standard NTSC closed captions are on line 21, and this isn't officially part of the NTSC VBI - it was an active picture line. That's why it was chosen - it should get through all equipment unscathed.
Cheers,
David.
kieranrk
26th April 2011, 13:34
"pure VBI"? This is meaningless. The vertical blanking interval is from the end of active picture on the last active picture line on one field, to the start of active picture on the first active picture line on the next field.
This term was chosen deliberately to clarify that the VBI data was not in the VANC but in the active picture. I appreciate these terms are not exact fits in the analogue to digital world.
drmpeg
26th April 2011, 20:26
By the way, I had Photoshop edited the pics with closed captions for clarity. The actual captures also have IEC61880 data on lines 20 and 283. On these two frames, the IEC61880 data is signaling 16:9 aspect ratio and CGMS-A = copy never, PSP off and not analog pre-recorded packaged medium.
http://www.w6rz.net/analogcc1.png
http://www.w6rz.net/analogcc16.png
The EIA-608 "1 bits" are at 50 IRE and the IEC61880 "1 bits" are at 70 IRE. Later today, I'll post the captured luma values.
Ron
drmpeg
27th April 2011, 06:02
Here's the captured luma samples for lines 20 and 21.
-> d 0x16c6aa50,720,1
16c6aa50: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6aa60: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 1e 83 *................*
16c6aa70: a8 a0 a3 a1 a3 a1 a1 a2 a1 a2 a2 a2 a2 a2 a2 a2 *................*
16c6aa80: a2 a2 a2 a2 a2 a1 a2 a2 a1 a3 a0 a6 82 1d 01 01 *................*
16c6aa90: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6aaa0: 01 01 01 01 01 01 01 01 01 01 1d 82 a8 a0 a3 a2 *................*
16c6aab0: a3 a2 a2 a2 a2 a2 a1 a2 a2 a2 a1 a1 a2 a2 a2 a2 *................*
16c6aac0: a2 a2 a2 a2 a1 a3 a0 a6 82 1e 01 01 01 01 01 01 *................*
16c6aad0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6aae0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6aaf0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ab00: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ab10: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ab20: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ab30: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ab40: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ab50: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 1c 81 *................*
16c6ab60: a7 9f a3 a1 a2 a1 a1 a2 a1 a1 a1 a1 a1 a1 a1 a1 *................*
16c6ab70: a1 a1 a1 a1 a2 a0 a1 a2 a1 a1 a1 a1 a1 a1 a1 a1 *................*
16c6ab80: a1 a1 a1 a2 a1 a1 a2 a1 a2 a1 a1 a1 a1 a2 a2 a1 *................*
16c6ab90: a2 a1 a1 a2 a1 a2 a1 a2 a0 a6 81 1d 01 01 01 01 *................*
16c6aba0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6abb0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6abc0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6abd0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6abe0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6abf0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ac00: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ac10: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ac20: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ac30: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ac40: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ac50: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ac60: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ac70: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ac80: 01 01 01 01 01 01 01 01 01 01 1c 81 a6 9f a2 a1 *................*
16c6ac90: a2 a0 a2 a1 a1 a1 a1 a1 a0 a1 a1 a1 a1 a1 a1 a1 *................*
16c6aca0: a1 a1 a1 a1 a0 a2 9f a6 81 1c 01 01 01 01 01 01 *................*
16c6acb0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6acc0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6acd0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ace0: 01 01 01 01 1c 81 a6 9f a2 a0 a1 a0 a1 a0 a1 a1 *................*
16c6acf0: a1 a1 a1 a1 a1 a1 a1 a1 a0 a1 a1 a0 a0 a1 a0 a2 *................*
16c6ad00: 9f a6 80 1c 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ad10: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
value = 268610560 = 0x1002ac00 = m + 0xe0
-> d
16c6ad20: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 06 *................*
16c6ad30: 0f 1a 25 33 41 4e 5a 63 6c 70 72 70 6c 65 5b 4f *..%3ANZclprple[O*
16c6ad40: 42 34 27 1a 10 06 01 01 01 01 08 10 1c 28 36 44 *B4'..........(6D*
16c6ad50: 51 5c 66 6d 72 72 70 6b 62 59 4d 3f 32 25 18 0d *Q\fmrrpkbYM?2%..*
16c6ad60: 06 01 01 01 03 09 13 1e 2b 39 46 52 5e 66 6d 71 *........+9FR^fmq*
16c6ad70: 72 6f 69 61 56 4a 3e 2e 21 16 0b 04 01 01 01 03 *roiaVJ>.!.......*
16c6ad80: 0a 15 21 2d 3a 48 55 5f 69 6e 71 72 6e 69 5f 54 *..!-:HU_inqrni_T*
16c6ad90: 48 3a 2e 20 14 0b 03 01 01 01 05 0c 17 23 30 3d *H:. .........#0=*
16c6ada0: 4a 58 62 69 6f 72 71 6d 67 5d 53 44 37 2a 1d 12 *JXbiorqmg]SD7*..*
16c6adb0: 08 02 01 01 01 06 0e 19 25 33 40 4d 58 63 6b 70 *........%3@MXckp*
16c6adc0: 72 70 6c 65 5b 4f 42 35 27 1c 10 07 01 01 01 01 *rple[OB5'.......*
16c6add0: 07 0f 1a 28 34 42 4f 5b 65 6b 70 71 6f 6b 63 59 *...(4BO[ekpqokcY*
16c6ade0: 4d 40 32 25 19 0e 06 01 01 01 01 01 01 01 01 01 *M@2%............*
16c6adf0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ae00: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6ae10: 01 01 01 01 01 01 01 14 5c 76 70 73 72 72 72 72 *........\vpsrrrr*
16c6ae20: 72 73 72 72 72 72 72 72 73 72 72 72 72 72 72 73 *rsrrrrrrsrrrrrrs*
16c6ae30: 71 76 5c 14 01 01 01 01 01 01 01 01 01 01 01 01 *qv\.............*
16c6ae40: 01 01 01 01 01 01 01 01 01 01 01 01 01 14 5c 76 *..............\v*
16c6ae50: 70 73 72 72 72 72 72 72 72 72 73 72 72 72 72 72 *psrrrrrrrrsrrrrr*
16c6ae60: 72 72 72 72 72 72 72 72 73 72 72 72 72 72 72 72 *rrrrrrrrsrrrrrrr*
16c6ae70: 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 *rrrrrrrrrrrrrrrr*
16c6ae80: 73 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 *srrrrrrrrrrrrrrr*
16c6ae90: 72 72 73 72 72 72 72 72 72 72 73 71 76 5c 14 01 *rrsrrrrrrrsqv\..*
16c6aea0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6aeb0: 01 01 01 01 01 01 01 01 13 5b 76 70 72 72 72 72 *.........[vprrrr*
16c6aec0: 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 *rrrrrrrrrrrrrrrr*
16c6aed0: 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 *rrrrrrrrrrrrrrrr*
16c6aee0: 72 72 72 72 72 72 72 72 72 72 72 73 71 76 5b 14 *rrrrrrrrrrrsqv[.*
16c6aef0: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6af00: 01 01 01 01 01 01 01 01 01 14 5b 76 70 72 72 72 *..........[vprrr*
16c6af10: 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 71 *rrrrrrrrrrrrrrrq*
16c6af20: 74 71 75 5c 13 01 01 01 01 01 01 01 01 01 01 01 *tqu\............*
16c6af30: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 12 5b *...............[*
16c6af40: 75 70 73 72 72 71 72 72 72 72 72 72 72 72 72 72 *upsrrqrrrrrrrrrr*
16c6af50: 72 72 72 72 72 72 72 70 75 5c 13 01 01 01 01 01 *rrrrrrrpu\......*
16c6af60: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6af70: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
16c6af80: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 13 *................*
16c6af90: 5b 76 70 72 72 72 72 72 72 72 72 72 72 72 72 72 *[vprrrrrrrrrrrrr*
16c6afa0: 72 72 72 72 72 71 72 72 72 72 72 72 71 72 72 72 *rrrrrqrrrrrrqrrr*
16c6afb0: 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 72 *rrrrrrrrrrrrrrrr*
16c6afc0: 72 72 72 72 72 72 72 72 72 71 72 72 71 72 72 72 *rrrrrrrrrqrrqrrr*
16c6afd0: 72 72 72 72 72 72 72 72 72 72 72 72 72 70 75 5b *rrrrrrrrrrrrrpu[*
16c6afe0: 12 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 *................*
value = 268610560 = 0x1002ac00 = m + 0xe0
->
Same IEC61880 data as the images previously posted. The two CC bytes are 0x6e and 0xe5 (the characters n and e).
Ron
kieranrk
4th May 2011, 23:41
I'm using libzvbi to parse CEA-608 data, which works sucessfully. I modified the settings for PAL that come in the example application. The appropriate settings for NTSC can be found in BT601 apart from a value called "offset". This is defined in the documentation here: http://zapping.sourceforge.net/doc/libzvbi/structvbi__raw__decoder.html#o6 .
The value for PAL is 9.5e-6 * 13.5e6. The latter number is the sampling frequency of luma and the former is presumably a proportion of that.
How would I go about calculating the correct value for NTSC?
Thanks in advance.
drmpeg
6th May 2011, 14:09
I'm using libzvbi to parse CEA-608 data, which works sucessfully. I modified the settings for PAL that come in the example application. The appropriate settings for NTSC can be found in BT601 apart from a value called "offset". This is defined in the documentation here: http://zapping.sourceforge.net/doc/libzvbi/structvbi__raw__decoder.html#o6 .
The value for PAL is 9.5e-6 * 13.5e6. The latter number is the sampling frequency of luma and the former is presumably a proportion of that.
How would I go about calculating the correct value for NTSC?
Thanks in advance.
It looks like "offset" is just the number of pixels from the start of the horizontal sync pulse to active video. The correct numbers are in BT601 figures 1 and 2. For PAL, it's 132 and for NTSC it's 122.
9.5e-6 * 13.5e6 = 128.25, but "offset" is an int, so it will get set to 128. Apparently they want to start the capture a little early as indicated by the comment "You want an offset small enough not to miss the start of the data transmitted."
sp.offset = 9.5e-6 * 13.5e6; is as clear as mud. sp.offset = (132 - 4); would have been much better IMHO.
So for NTSC, (122 - 4) would probably work well.
Ron
kieranrk
6th May 2011, 20:12
Great, thanks for the explanation.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.