Atsc working Draft Template

descriptor_length
– This 8-bit unsigned integer specifies the number of bytes of the descriptor that 
immediately follow the 
descriptor_length
field. 
dcc_arriving_request_type
– This 8-bit unsigned integer specifies the type of the DCC arriving 
request and shall have the values listed in Table 6.36. 
Table 6.36 DCC Arriving Request Type Assignments 
dcc_arriving_request_type Meaning 
0x00 
Reserved 
0x01* 
Display arriving request text in a centered window for a minimum of 10 seconds after 
performing the channel change requested by the viewer, or for a less amount of time if 
the viewer issues a "continue", "OK", "proceed", or equivalent command. 
0x02* 
Display arriving request text in a centered window indefinitely after performing a 
channel change request requested by the viewer until viewer issues a "continue", 
"OK", "proceed", or equivalent command. 
0x03-0xFF 
Reserved 
* Note: The above suggested behavior of the DCCRR’s implementation of Arriving Request types 0x01 and 0x02 
are within the discretion of DCCRR manufacturers. The DCCRR’s reaction to these commands may also be 
disabled by viewers through an interactive setup session. 
dcc_arriving_request_text_length
– An 8-bit unsigned integer number that specifies the total length in 
bytes of the 
dcc_arriving_request_text() 
field to follow. 
dcc_arriving_request_text()
– The arriving request window text in the format of a multiple string 
structure (see Section 6.10). 
6.9.12 Redistribution Control (RC) Descriptor 
The purpose of the Redistribution Control descriptor is to convey a certain type of redistribution 
information held by the program rightsholder for audio, video, or data events. The descriptor’s 
existence within the ATSC stream shall mean: “technological control of consumer redistribution 
is signaled.” 
The redistribution control information conveyed by the 
rc_descriptor()
defined in Table 6.37 
concerns the video/audio/data programming identified either by the 
event_id
within the EIT or the 
program_number
within the 
TS_program_map_section()
. 
For terrestrial broadcast transport, the 
rc_descriptor()
, when transmitted, shall be present in both 
the EIT and 
TS_program_map_section()
. For cable transport, the 
rc_descriptor()
, when transmitted, shall 
be present in the 
TS_program_map_section()
, and, when the EIT is carried, in the EIT. 
77 

---

ATSC A/65:2013 
Program and System Information Protocol 
7 August 2013 
The 
rc_descriptor(), 
when in the EIT, shall apply to a specific event associated with the Virtual 
Channel and the related MPEG-2 Program. It shall be placed within the descriptor loop after 
descriptors_length
for the 
event_id
for which this information is being signaled. The 
rc_descriptor(),
shall 
be placed within the descriptor loop after 
program_info_length
in the 
TS_program_map_section()
for the 
program_number
for which this information is being signaled. When the descriptor is placed in the 
TS_program_map_section()
, it shall also be placed in the current event of EIT-0 for the Virtual Channel 
associated with the MPEG-2 Program; and it should be placed in the EIT for this event as far in 
advance as possible (i.e., minimally EIT-1, EIT-2, and EIT-3). 
For data-only services
17
, the 
rc_descriptor()
shall be placed in the DET (whose syntax and 
semantics are defined in ATSC A/90 Data Broadcasting Standard [20]) under the same provisions 
described for the EIT. 
It is out of the scope of this standard to assert how any receiving device reacts when the 
rc_descriptor
is present. 
The bit stream syntax for the redistribution control descriptor shall be as shown in Table 6.37.