Goto Section: 15.121 | 15.123 | Table of Contents
FCC 15.122
Revised as of October 1, 2005
Goto Year:2004 |
2006
Sec. 15.122 Closed caption decoder requirements for digital television receivers
and converter boxes.
(a)(1) Effective July 1, 2002, all digital television receivers with picture
screens in the 4:3 aspect ratio with picture screens measuring 13 inches or
larger diagonally, all digital television receivers with picture screens in
the 16:9 aspect ratio measuring 7.8 inches or larger vertically and all
separately sold DTV tuners shipped in interstate commerce or manufactured in
the United States shall comply with the provisions of this section.
Note to paragraph (a)(1): This paragraph places no restrictions on the
shipping or sale of digital television receivers that were manufactured
before July 1, 2002.
(2) Effective July 1, 2002, DTV converter boxes that allow digitally
transmitted television signals to be displayed on analog receivers shall
pass available analog caption information to the attached receiver in a form
recognizable by that receiver's built-in caption decoder circuitry.
Note to paragraph (a)(2): This paragraph places no restrictions on the
shipping or sale of DTV converter boxes that were manufactured before July
1, 2002.
(b) Digital television receivers and tuners must be capable of decoding
closed captioning information that is delivered pursuant to EIA–708–B:
“Digital Television (DTV) Closed Captioning” (incorporated by reference, see
Sec. 15.38).
(c) Services. (1) Decoders must be capable of decoding and processing data
for the six standard services, Caption Service #1 through Caption Service
#6.
(2) Decoders that rely on Program and System Information Protocol data to
implement closed captioning functions must be capable of decoding and
processing the Caption Service Directory data. Such decoders must be capable
of decoding all Caption Channel Block Headers consisting of Standard Service
Headers, Extended Service Block Headers, and Null Block headers. However,
decoding of the data is required only for Standard Service Blocks (Service
IDs <-6), and then only if the characters for the corresponding language are
supported. The decoders must be able to display the directory for services 1
through 6.
(d) Code space organization. (1) Decoders must support Code Space C0, G0,
C1, and G1 in their entirety.
[er29se00.000.gif]
View or download PDF
(2) The following characters within code space G2 must be supported:
(i) Transparent space ([TSP]).
(ii) Non-breaking transparent space ([NBTSP]).
(iii) Solid block ( ).
(iv) Trademark symbol ( ^TM ).
(v) Latin-1 characters Š, Œ, š, œ, Ÿ.
(3) The substitutions in Table 2 are to be made if a decoder does not
support the remaining G2 characters.
Table 2_G2 Character Substitution Table
------------------------------------------------------------------------
G2 Character Substitute with
------------------------------------------------------------------------
Open single quote (`), G2 char G0 single quote (`), char code 0x27
code 0x31.
Close single quote ('), G2 char G0 single quote ('), char code 0x27
code 0x32.
Open double quote (``), G2 char G0 double quote (``), char code 0x22
code 0x33.
Close double quote (''), G2 char G0 double quote (''), char code 0x22
code 0x34.
Bold bullet (•), G2 char G1 bullet (•), char code 0xB7
code 0x35.
Elipsis (. . .), G2 char code G0 underscore (_), char code 0x5F
0x25.
One-eighth (\1/8\), G2 char code G0 percent sign (%), char code 0x25
0x76.
Three-eighths (\3/8\), G2 char G0 percent sign (%), char code 0x25
code 0x77.
Five-eighths (\5/8\), G2 char G0 percent sign (%), char code 0x25
code 0x78.
Seven-eighths (\7/8\), G2 char G0 percent sign (%), char code 0x25
code 0x79.
Vertical border ([verbar]), G2 G0 stroke ([verbar]), char code 0x7C
char code 0x7A.
Upper-right border ([rceil]), G2 G0 dash (-), char code 0x2D
char code 0x7B.
Lower-left border ([lfloor]), G2 G0 dash (-), char code 0x2D
char code 0x7C.
Horizontal border ([horbar]), G2 G0 dash (-), char code 0x2D
char code 0x7D.
Lower-right border ([rfloor]), G2 G0 dash (-), char code 0x2D
char code 0x7E.
Upper-left border ([lceil]), G2 G0 dash (-), char code 0x2D
char code 0x7F.
------------------------------------------------------------------------
(4) Support for code spaces C2, C3, and G3 is optional. All unsupported
graphic symbols in the G3 code space are to be substituted with the G0
underscore character (_), char code 0×5F.
(e) Screen coordinates. Table 3 specifies the screen coordinate resolutions
and limits for anchor point positioning in 4:3 and 16:9 display formats, and
the number of characters per row.
Table 3_Screen Coordinate Resolutions and Limit
s
-------------------------------------------------------------------------------
---------------------------------
Maximum Maximum
Screen aspect ratio Maximum anchor position Minimum anchor po
sition displayed characters
resolution resolution
rows per row
-------------------------------------------------------------------------------
---------------------------------
4:3.......................... 75vx160h................... 15vx32h............
........ 4 32
16:9......................... 75vx210h................... 15vx42h............
........ 4 42
Other........................ 75vx(5xH).................. 15vxH*.............
........ 4 \1\
-------------------------------------------------------------------------------
---------------------------------
\1\H = 32 x (the width of the screen in relation to a 4:3 display). For example
, the 16:9 format is \1/3\ wider
than a 4:3 display; thus, H = 32 * \4/3\ = 42.667, or 42.
(1) This means that the minimum grid resolution for a 4:3 aspect ratio
instrument is 15 vertical positions × 32 horizontal positions. This minimum
grid resolution for 16:9 ratio instrument is 15 vertical positions × 42
horizontal positions. These minimum grid sizes are to cover the entire
safe-title area of the corresponding screen.
(2) The minimum coordinates equate to a 1/5 reduction in the maximum
horizontal and vertical grid resolution coordinates. Caption providers are
to use the maximum coordinate system values when specifying anchor point
positions. Decoders using the minimum resolution are to divide the provided
horizontal and vertical screen coordinates by 5 to derive the equivalent
minimum coordinates.
(3) Any caption targeted for both 4:3 and 16:9 instruments is limited to 32
contiguous characters per row. If a caption is received by a 4:3 instrument
that is targeted for a 16:9 display only, or requires a window width greater
than 32 characters, then the caption may be completely disregarded by the
decoder. 16:9 instruments should be able to process and display captions
intended for 4:3 displays, providing all other minimum recommendations are
met.
(4) If the resulting size of any window is larger than the safe title area
for the corresponding display's aspect ratio, then this window will be
completely disregarded.
(f) Caption windows. (1) Decoders need to display no more than 4 rows of
captions on the screen at any given time, regardless of the number of
windows displayed. This implies that no more than 4 windows can be displayed
at any given time (with each having only one caption row). However, decoders
should maintain storage to support a minimum total of 8 rows of captions.
This storage is needed for the worst-case support of a displayed window with
4 rows of captioning and a non-displayed window which is buffering the
incoming rows for the next 4-row caption. As implied above, the maximum
number of windows that may be displayed at any one time by a minimum decoder
implementation is 4. If more than 4 windows are defined in the caption
stream, the decoder may disregard the youngest and lowest priority window
definition(s). Caption providers must be aware of this limitation, and
either restrict the total number of windows used or accept that some windows
will not be displayed.
(2) Decoders do not need to support overlapped windows. If a window overlaps
another window, the overlapped window need not be displayed by the decoder.
(3) At a minimum, decoders will assume that all windows have rows and
columns “locked”. This implies that if a decoder implements the SMALL
pen-size, then word-“un”wrapping, when shrinking captions, need not be
implemented. Also, if a decoder implements the LARGE pen size, then word
wrapping (when enlarging captions) need not be implemented.
(4) Whenever possible, the receiver should render embedded carriage returns
as line breaks, since these carriage returns indicate an important aspect of
the caption's formatting as determined by the service provider. However, it
may sometimes be necessary for the receiver to ignore embedded line breaks.
For example, if a caption is to appear in a larger font, and if its window's
rows and/or columns are unlocked, the rows of text may need to become longer
or shorter to fit within the allocated space. Such automatic reformatting of
a caption is known as “word wrap.” If decoders support word-wrapping, it
must be implemented as follows:
(i) The receiver should follow standard typographic practice when
implementing word wrap. Potential breaking points (word-wrapping points) are
indicated by the space character (20h) and by the hyphen character (2Dh).
(ii) If a row is to be broken at a space, the receiver should remove the
space from the caption display. If a row is to be broken after a hyphen, the
hyphen should be retained.
(iii) If an embedded return is to be removed, it should usually be replaced
with a space. However, if the character to the left of the embedded return
is a hyphen, the embedded return should be removed but NOT replaced with a
space.
(iv) This specification does not include optional hyphens, nor does it
provide for any form of automatic hyphenation. No non-breaking hyphen is
defined. The non-breaking space (A0h in the G1 code set) and the
non-breaking transparent space (21h in the G2 code set) should not be
considered as potential line breaks.
(v) If a single word exceeds the length of a row, the word should be placed
at the start of a new row, broken at the character following the last
character that fits on the row, and continued with further breaks if needed.
(g) Window text painting. (1) All decoders should implement “left”,
“right”, and “center” caption-text justification. Implementation of “full”
justification is optional. If “full” justification is not implemented, fully
justified captions should be treated as though they are “left” justified.
(i) For “left” justification, decoders should display any portion of a
received row of text when it is received. For “center”, “right”, and
“full” justification, decoders may display any portion of a received row of
text when it is received, or may delay display of a received row of text
until reception of a row completion indicator. A row completion indicator is
defined as receipt of a CR, ETX or any other command, except SetPenColor,
SetPenAttributes, or SetPenLocation where the pen relocation is within the
same row.
(ii) Receipt of a character for a displayed row which already contains text
with “center”, “right” or “full” justification will cause the row to be
cleared prior to the display of the newly received character and any
subsequent characters. Receipt of a justification command which changes the
last received justification for a given window will cause the window to be
cleared.
(2) At a minimum, decoders must support LEFT_TO_RIGHT printing.
(3) At a minimum, decoders must support BOTTOM_TO_TOP scrolling. For windows
sharing the same horizontal scan lines on the display, scrolling may be
disabled.
(4) At a minimum, decoders must support the same recommended practices for
scroll rate as is provided for NTSC closed-captioning.
(5) At a minimum, decoders must support the same recommended practices for
smooth scrolling as is provided for NTSC closed-captioning.
(6) At a minimum, decoders must implement the “snap” window display effect.
If the window “fade” and “wipe” effects are not implemented, then the
decoder will “snap” all windows when they are to be displayed, and the
“effect speed” parameter is ignored.
(h) Window colors and borders. At a minimum, decoders must implement
borderless windows with solid, black backgrounds (i.e., border type = NONE,
fill color = (0,0,0), fill opacity = SOLID), and borderless transparent
windows (i.e., border type = NONE, fill opacity = TRANSPARENT).
(i) Predefined window and pen styles. Predefined Window Style and Pen Style
ID's may be provided in the DefineWindow command. At a minimum, decoders
should implement Predefined Window Attribute Style 1 and Predefined Pen
Attribute Style 1, as shown in Table 4 and Table 5, respectively.
T
able 4_Predefined Window Style ID's
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
----------------------------------
Print Scroll Wo
rd Display Effect Effect Fill
Border
Style ID # Justify direction direction wr
ap effect direction speed Fill color opacity Border
type color Usage
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
----------------------------------
1............................ Left........ Left-to-right Bottom-to-top No..
... Snap........ n/a......... n/a........ (0,0,0) Solid...... None..
..... n/a........ NTSC Style
Black.
PopUp
Captions
2............................ Left........ Left-to-right Bottom-to-top No..
... Snap........ n/a......... n/a........ n/a......... Transparent None..
..... n/a........ PopUp Captions
w/o Black
Background
3............................ Cntr........ Left-to-right Bottom-to-top No..
... Snap........ n/a......... n/a........ (0,0,0) Solid...... None..
..... n/a........ NTSC Style
Black.
Centered
PopUp
Captions
4............................ Left........ Left-to-right Bottom-to-top Yes.
... Snap........ n/a......... n/a........ (0,0,0) Solid...... None..
..... n/a........ NTSC Style
Black.
RollUp
Captions
5............................ Left........ Left-to-right Bottom-to-top Yes.
... Snap........ n/a......... n/a........ n/a......... Transparent None..
..... n/a........ RollUp
Captions w/o
Black
Background
6............................ Cntr........ Left-to-right Bottom-to-top Yes.
... Snap........ n/a......... n/a........ (0,0,0) Solid...... None..
..... n/a........ NTSC Style
Black.
Centered
RollUp
Captions
7............................ Left........ Top-to-bottom Right-to-left No..
... Snap........ n/a......... n/a........ (0,0,0) Solid...... None..
..... n/a........ Ticker Tape
Black.
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
----------------------------------
Table 5_Predefined Pen Style ID's
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
----------------------------------
Foregrnd Foregrnd Backgrnd Ba
ckgrnd
Predefined style ID Pen size Font style Offset I
talics Underline Edge type color opacity color op
acity Edge color Usage
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
----------------------------------
1............................. Stndr........ 0............ Normal....... No
....... No.......... None....... (2,2,2) Solid...... (0,0,0) Soli
d...... n/a........ Default NTSC
White. Black.
Style*
2............................. Stndr........ 1............ Normal....... No
....... No.......... None....... (2,2,2).... Solid...... (0,0,0) Soli
d...... n/a........ NTSC Style*
White.
Mono w/
Serif
3............................. Stndr........ 2............ Normal....... No
....... No.......... None....... (2,2,2) Solid...... (0,0,0) Soli
d...... n/a........ NTSC Style*
White. Black.
Prop w/
Serif
4............................. Stndr........ 3............ Normal....... No
....... No.......... None....... (2,2,2) Solid...... (0,0,0) Soli
d...... n/a........ NTSC Style*
White. Black.
Mono w/o
Serif
5............................. Stndr........ 4............ Normal....... No
....... No.......... None....... (2,2,2) Solid...... (0,0,0) Soli
d...... n/a........ NTSC Style*
White. Black.
Prop w/o
Serif
6............................. Stndr........ 3............ Normal....... No
....... No.......... Unifrm..... (2,2,2) Solid...... n/a........ Tran
sparent (0,0,0) Mono w/o
White.
Black. Serif,
Bordered
Text, No BG
7............................. Stndr........ 4............ Normal....... No
....... No.......... Unifrm..... (2,2,2) Solid...... n/a........ Tran
sparent (0,0,0) Prop. w/o
White.
Black. Serif,
Bordered
Text, No BG
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
----------------------------------
*``NTSC Style''_White Text on Black Background
(j) Pen size. (1) Decoders must support the standard, large, and small pen
sizes and must allow the caption provider to choose a pen size and allow the
viewer to choose an alternative size. The STANDARD pen size should be
implemented such that the height of the tallest character in any implemented
font is no taller than 1/15 of the height of the safe-title area, and the
width of the widest character is no wider than 1/32 of the width of the
safe-title area for 4:3 displays and 1/42 of the safe-title area width for
16:9 displays.
(2) The LARGE pen size should be implemented such that the width of the
widest character in any implemented font is no wider than 1/32 of the
safe-title area for 16:9 displays. This recommendation allows for captions
to grow to a LARGE pen size without having to reformat the caption since no
caption will have more than 32 characters per row.
(k) Font styles. (1) Decoders must support the eight fonts listed below.
Caption providers may specify 1 of these 8 font styles to be used to write
caption text. The styles specified in the “font style” parameter of the
SetPenAttributes command are numbered from 0 through 7. The following is a
list of the 8 required font styles. For information purposes only, each font
style references one or more popular fonts which embody the characteristics
of the style:
(i) 0—Default (undefined)
(ii) 1—Monospaced with serifs (similar to Courier)
(iii) 2—Proportionally spaced with serifs (similar to Times New Roman)
(iv) 3—Monospaced without serifs (similar to Helvetica Monospaced)
(v) 4—Proportionally spaced without serifs (similar to Arial and Swiss)
(vi) 5—Casual font type (similar to Dom and Impress)
(vii) 6—Cursive font type (similar to Coronet and Marigold)
(viii) 7—Small capitals (similar to Engravers Gothic)
(2) Font styles may be implemented in any typeface which the decoder
manufacturer deems to be a readable rendition of the font style, and need
not be in the exact typefaces given in the example above. Decoders must
include the ability for consumers to choose among the eight fonts. The
decoder must display the font chosen by the caption provider unless the
viewer chooses a different font.
(l) Character offsetting. Decoders need not implement the character
offsetting (i.e., subscript and superscript) pen attributes.
(m) Pen styles. At a minimum, decoders must implement normal, italic, and
underline pen styles.
(n) Foreground color and opacity. (1) At a minimum, decoders must implement
transparent, translucent, solid and flashing character foreground type
attributes.
(2) At a minimum, decoders must implement the following character foreground
colors: white, black, red, green, blue, yellow, magenta and cyan.
(3) Caption providers may specify the color/opacity. Decoders must include
the ability for consumers to choose among the color/opacity options. The
decoder must display the color/opacity chosen by the caption provider unless
the viewer chooses otherwise.
(o) Background color and opacity. (1) Decoders must implement the following
background colors: white, black, red, green, blue, yellow, magenta and cyan.
It is recommended that this background is extended beyond the character
foreground to a degree that the foreground is separated from the underlying
video by a sufficient number of background pixels to insure the foreground
is separated from the background.
(2) Decoders must implement transparent, translucent, solid and flashing
background type attributes. Caption providers may specify the color/opacity.
Decoders must include the ability for consumers to choose among the
color/opacity options. The decoder must display the color/opacity chosen by
the caption provider unless the viewer chooses otherwise.
(p) Character edges. Decoders must implement separate edge color and type
attribute control.
(q) Color representation. (1) At a minimum, decoders must support the 8
colors listed in Table 6.
Table 6_Minimum Color List Table
------------------------------------------------------------------------
Color Red Green Blue
------------------------------------------------------------------------
Black........................................ 0 0 0
White........................................ 2 2 2
Red.......................................... 2 0 0
Green........................................ 0 2 0
Blue......................................... 0 0 2
Yellow....................................... 2 2 0
Magenta...................................... 2 0 2
Cyan......................................... 0 2 2
------------------------------------------------------------------------
(2)(i) When a decoder supporting this Minimum Color List receives an RGB
value not in the list, it will map the received value to one of the values
in the list via the following algorithm:
(A) All one (1) values are to be changed to 0.
(B) All two (2) values are to remain unchanged.
(C) All three (3) values are to be changed to 2.
(ii) For example, the RGB value (1,2,3) will be mapped to (0,2,2), (3,3,3)
will be mapped to (2,2,2) and (1,1,1) will be mapped to (0,0,0).
(3) Table 7 is an alternative minimum color list table supporting 22 colors.
Table 7_Alternative Minimum Color List Table
------------------------------------------------------------------------
Color Red Green Blue
------------------------------------------------------------------------
Black........................................ 0 0 0
Gray......................................... 1 1 1
White........................................ 2 2 2
Bright White................................. 3 3 3
Dark Red..................................... 1 0 0
Red.......................................... 2 0 0
Bright Red................................... 3 0 0
Dark Green................................... 0 1 0
Green........................................ 0 2 0
Bright Green................................. 0 3 0
Dark Blue.................................... 0 0 1
Blue......................................... 0 0 2
Bright Blue.................................. 0 0 3
Dark Yellow.................................. 1 1 0
Yellow....................................... 2 2 0
Bright Yellow................................ 3 3 0
Dark Magenta................................. 1 0 1
Magenta...................................... 2 0 2
Bright Magenta............................... 3 0 3
Dark Cyan.................................... 0 1 1
Cyan......................................... 0 2 2
Bright Cyan.................................. 0 3 3
------------------------------------------------------------------------
(i) When a decoder supporting the Alternative Minimum Color List in Table 7
receives an RGB value not in the list (i.e., an RGB value whose non-zero
elements are not the same value), it will map the received value to one of
the values in the list via the following algorithm:
(A) For RGB values with all elements non-zero and different—e.g., (1,2,3),
(3,2,1), and (2,1,3), the 1 value will be changed to 0, the 2 value will
remain unchanged, and the 3 value will be changed to 2.
(B) For RGB values with all elements non-zero and with two common
elements—e.g. (3,1,3), (2,1,2), and (2,2,3), if the common elements are 3
and the uncommon one is 1, then the 1 elements is changed to 0; e.g. (3,1,3)
→ (3,0,3). If the common elements are 1 and the uncommon element is 3, then
the 1 elements are changed to 0, and the 3 element is changed to 2; e.g.
(1,3,1) → (0,2,0). In all other cases, the uncommon element is changed to
the common value; e.g., (2,2,3) → (2,2,2), (1,2,1) → (1,1,1), and (3,2,3)
→ (3,3,3).
(ii) All decoders not supporting either one of the two color lists described
above, must support the full 64 possible RGB color value combinations.
(r) Character rendition considerations. In NTSC Closed Captioning, decoders
were required to insert leading and trailing spaces on each caption row.
There were two reasons for this requirement:
(1) To provide a buffer so that the first and last characters of a caption
row do not fall outside the safe title area, and
(2) To provide a black border on each side of a character so that the
“white” leading pixels of the first character on a row and the trailing
“white” pixels of the last character on a row do not bleed into the
underlying video.
(i) Since caption windows are required to reside in the safe title area of
the DTV screen, reason 1 (above) is not applicable to DTVCC captions.
(ii) The attributes available in the SetPenAttributes command for character
rendition (e.g., character background and edge attributes) provide unlimited
flexibility to the caption provider when describing caption text in an ideal
decoder implementation. However, manufacturers need not implement all pen
attributes. Thus it is recommended that no matter what the level of
implementation, decoder manufacturers should take into account the
readability of all caption text against a variety of all video backgrounds,
and should implement some automatic character delineation when the
individual control of character foreground, background and edge is not
supported.
(s) Service synchronization. Service Input Buffers must be at least 128
bytes in size. Caption providers must keep this lower limit in mind when
following Delay commands with other commands and window text. In other
words, no more than 128 bytes of DTVCC commands and text should be
transmitted (encoded) before a pending Delay command's delay interval
expires.
(t) Settings. Decoders must include an option that permits a viewer to
choose a setting that will display captions as intended by the caption
provider (a default). Decoders must also include an option that allows a
viewer's chosen settings to remain until the viewer chooses to alter these
settings, including periods when the television is turned off.
[ 65 FR 58471 , Sept. 29, 2000, as amended at 69 FR 2849 , Jan. 21, 2004]
Goto Section: 15.121 | 15.123
Goto Year: 2004 |
2006
CiteFind - See documents on FCC website that
cite this rule
Want to support this service?
Thanks!
Report errors in
this rule. Since these rules are converted to HTML by machine, it's possible errors have been made. Please
help us improve these rules by clicking the Report FCC Rule Errors link to report an error.
hallikainen.com
Helping make public information public