Half-Line Implications with Video and VBI Data
A half-line is generated when a Vsync occurs between two Hsyncs. The generation of half-lines by a decoder has always been a problem when receiving VBI because of the stringent accuracy requirements for line numbers. Different decoders and video ports handle half-lines differently. This article provides examples of how half-lines are currently managed and presents detailed information about several solutions.
On This Page
 | Management of Half-Lines in Current Devices |
| Solve the Half-Line Problem |
| How Capture Handles Half-Lines |
Management of Half-Lines in Current Devices
Lets first look at the way half-lines are generated and managed in devices today. When the video port on the graphics controller receives a half-line, it will either discard the half-line automatically so it doesnt get written to the frame buffer or capture the half-line to the frame buffer.
When a half-line is captured, the video port treats it as a full line so the remaining field data will be shifted down one line. Microsoft DirectX Video Port Extensions (VPE) will set the DDVPCONNECT_HALFLINE flag if the device captures the line; otherwise, this flag will be cleared. For more information about this flag, see VPE and Video Capture Products.
The Brooktree Bt829 decoder outputs exactly 15 lines between the trailing edge of VREF and the start of the real video data (line 22 for NTSC signals) in the odd field. In the even field, it outputs 15 lines in this same region. Therefore, if the video port discards the half-lines, each field contains the same number of lines and things are perfect. Otherwise, the data in the even field is shifted down one line from the corresponding data in the odd field. The video port will create a problem for displaying the data as well as for capturing it if the half-line is rounded up. If the Bt829 device is asked to crop the first n pixels of the video field, it will automatically drop the half-line in the even fieldbe aware that cropping is not available in VBI mode.
The Philips decoders output exactly 14 lines between the trailing edge of VREF and the start of the real video data (line 22 for NTSC signals) in the odd field. In the even field, it outputs 15 lines in this same region. Therefore, if the video port does not discard half-lines, each field contains the same number of lines and things are perfect. Otherwise, the data in the odd field is shifted down one line from the corresponding data in the odd fieldcreating a problem both for displaying the data as well as for capturing it.
Solve the Half-Line Problem
A number of ways to solve this problem are presented here. The following workarounds should only be performed by clients of VPEthat is, the Overlay Mixer and the VBI Surface Allocator. The HAL should not try to automatically compensate for anything itself unless its told to. Do not hard-code a driver that inverts polarities without being asked.
Although the information here might be of interest to IHVs, the only devices expected to perform the workarounds discussed are the Overlay Mixer, VBI surface allocator, and the various TV-in-a-window applications shipped by some IHVs. DirectShow (by way of the Overlay Mixer and VBI surface allocator) currently performs all of these adjustments.
Case 1: Equal number of lines
In the case where the frame buffer receives the same number of lines in the even and the odd fields, no compensation is necessary. This occurs either when using a Bt829 decoder with a video port that discards half-lines or when using a Philips decoder with a video port that does not discard half-lines.
Case 2: Round up on even field
When the data in the even field is shifted by one (the case when using a Bt829 decoder with a video port that does not discard lines), it contains a visual artifact as the following table shows:
| Data in the odd field | Data in the even field | When viewing the data together |
Line 1 | Half line | Line 1 |
Line 3 | Line 2 | Half line |
Line 5 | Line 4 | Line 3 |
Line 2 | ||
Line 5 | ||
Line 4 |
The workaround for this case is to invert the field polarities. In most cases, the graphics controller will allow you to do this. If it does not, you can usually invert the polarity using the decoder. Inverting the polarities makes the data appear as follows:
| Data in the odd field | Data in the even field | When viewing the data together |
Half line | Line 1 | Half line |
Line 2 | Line 3 | Line 1 |
Line 4 | Line 5 | Line 2 |
Line 3 | ||
Line 4 | ||
Line 5 |
Inverting the polarities will cause the data to be lined up correctly, the only issue being that the first line contains garbage. For display, this is handled by adjusting the source rectangle of the overlay to not show the garbage line. The capture solution is discussed later in this section.
Case 3: Round down on odd field
When the data in the odd field is shifted by one (the case when using a Philips decoder with a video port that discards half-lines), it contains a visual artifact as the following table shows:
| Data in the odd field | Data in the even field | When viewing the data together |
Line 3 | Line 2 | Line 3 |
Line 5 | Line 4 | Line 2 |
Line 7 | Line 6 | Line 5 |
Line 4 | ||
Line 7 | ||
Line 6 |
The workaround for this is to tell the video port to capture an extra line at the top of each field, and then to invert the polarities. This makes the data appear as follows:
| Data in the odd field | Data in the even field | When viewing the data together |
Half line | Line 1 | Half line |
Line 2 | Line 3 | Line 1 |
Line 4 | Line 5 | Line 2 |
Line 3 | ||
Line 4 | ||
Line 5 |
With the workaround in place, this looks exactly like the finished product of the workaround for rounding up of the even field. Adjusting the source overlay by one will cause the extra line to not be displayed.
Case 4: Round down on the even field
This case is when the odd field contains 15 lines and the even field contains 14 lines. If the video port counts the half-line, this looks fine (each field contains 15 lines), but if the video port discards half-lines, the odd field contains an extra line of garbage. We currently know of no decoders that output data like this.
In this case, there is no way to fix it so that it will appear correctly when the data is interleaved, so the Overlay Mixer and VBI surface allocator should not try to interleave the data. The field polarities do not need to be reversed. As with cases 2 and 3, the resulting odd field contains the garbage line.
Case 5: Round up on the odd field
This case is when the odd field contains 15 lines and the even field contains 15 lines. If the video port does not count the half-line, this looks fine (each field contains 15 lines), but if the video port counts the half-line, the odd field contains an extra line of garbage.
In this case, there is no way to fix it so that it will appear correctly when the data is interleaved; the clients should not try to interleave the data. The field polarities do not need to be reversed. As with cases 2, 3, and 4 cited earlier, the resulting odd field contains the garbage line.
How Capture Handles Half-Lines
Whenever the client encounters one of the half-line situations and compensates by inverting the polarities, it should set the DDVPCONNECT_HALFLINE flag when calling CreateVideoPort; otherwise, it should clear it.
In both cases 2 and 3 described earlier, the finished product of the workarounds produces the exact same resultsdata in the odd field are shifted down one line in the surface. When DirectDraw asks the miniVDD on Microsoft Windows 98 or the miniport for Windows 2000 or Windows XP to perform a transfer, it will set a new DDTRANSER_HALFLINES flag, indicating that a half-line work around is in place and that the data in the odd buffer has been shifted down one line. When performing the transfer, the miniVDD or miniport will know the polarity of the buffer being transferred and can make any necessary adjustments.