1、 Recommendation ITU-R BT.1364-3 (10/2015) Format of ancillary data signals carried in digital component studio interfaces BT Series Broadcasting service (television) ii Rec. ITU-R BT.1364-3 Foreword The role of the Radiocommunication Sector is to ensure the rational, equitable, efficient and economi
2、cal use of the radio-frequency spectrum by all radiocommunication services, including satellite services, and carry out studies without limit of frequency range on the basis of which Recommendations are adopted. The regulatory and policy functions of the Radiocommunication Sector are performed by Wo
3、rld and Regional Radiocommunication Conferences and Radiocommunication Assemblies supported by Study Groups. Policy on Intellectual Property Right (IPR) ITU-R policy on IPR is described in the Common Patent Policy for ITU-T/ITU-R/ISO/IEC referenced in Annex 1 of Resolution ITU-R 1. Forms to be used
4、for the submission of patent statements and licensing declarations by patent holders are available from http:/www.itu.int/ITU-R/go/patents/en where the Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC and the ITU-R patent information database can also be found. Serie
5、s of ITU-R Recommendations (Also available online at http:/www.itu.int/publ/R-REC/en) Series Title BO Satellite delivery BR Recording for production, archival and play-out; film for television BS Broadcasting service (sound) BT Broadcasting service (television) F Fixed service M Mobile, radiodetermi
6、nation, amateur and related satellite services P Radiowave propagation RA Radio astronomy RS Remote sensing systems S Fixed-satellite service SA Space applications and meteorology SF Frequency sharing and coordination between fixed-satellite and fixed service systems SM Spectrum management SNG Satel
7、lite news gathering TF Time signals and frequency standards emissions V Vocabulary and related subjects Note: This ITU-R Recommendation was approved in English under the procedure detailed in Resolution ITU-R 1. Electronic Publication Geneva, 2015 ITU 2015 All rights reserved. No part of this public
8、ation may be reproduced, by any means whatsoever, without written permission of ITU. Rec. ITU-R BT.1364-3 1 RECOMMENDATION ITU-R BT.1364-3 Format of ancillary data signals carried in digital component studio interfaces (Question ITU-R 130/6) (1998-2005-2010-2015) Scope This Recommendation defines th
9、e data structure for ancillary data signal that may be carried as part of the payload in serial digital interfaces as defined in Recommendations ITU-R BT.656, ITU-R BT.799, ITU-R BT.1120 and ITU-R BT.2077. Applications defining the content of the ancillary data packets are defined by other ITU Recom
10、mendations as listed in Attachment 4. Keywords Ancillary data, DID (Data Identifier), SDID (Secondary Data Identifier) The ITU Radiocommunication Assembly, considering a) that most digital television production facilities are based on the use of digital video components conforming to Recommendations
11、 ITU-R BT.601, ITU-R BT.709, and ITU-R BT.2020; b) that HDTV production systems are using digital interfaces based on interfaces conforming to Recommendation ITU-R BT.1120; c) that there exists the capacity within the serial digital interfaces conforming to Recommendations ITU-R BT.656, ITU-R BT.799
12、, ITU-R BT.1120 and ITU-R BT.2077 for additional data signals to be multiplexed along with the video data; d) that there are operational and economic benefits to be achieved by the multiplexing of ancillary data signals within the serial digital interface; e) that the operational benefits are increa
13、sed if a minimum of different formats are used for ancillary data signals; f) that many applications are already using ancillary data signals carried in the serial digital interface, recommends 1 that the ancillary data signal format described in Annex 1 should be used; 2 that compliance with this R
14、ecommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure e.g. interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall” or some other obligatory language s
15、uch as “must” and the negative equivalents are used to express requirements. The use of such words shall in no way be construed to imply partial or total compliance with this Recommendation. 2 Rec. ITU-R BT.1364-3 Annex 1 Ancillary data signal format 1 General description of the ancillary data signa
16、l format The format specified provides a mechanism for the transport of ancillary data signals through digital video component interfaces in the digital blanking portion of the digital video data signal. The ancillary data is carried in packets, each packet carrying its own identification. A packet
17、comprises: a fixed preamble to enable an ancillary data packet to be detected; data identification to enable packets carrying a particular type of ancillary signal to be identified; a packet length indication; a continuity indication; the ancillary data, up to 255 words in each packet; a checksum to
18、 permit error detection. Provision is made for ancillary data exceeding 255 words to be carried in two or more linked packets, not necessarily contiguous with each other. A protocol is described which permits a number of different ancillary data packets to be carried within the space available in th
19、e digital blanking intervals of the digital component interface signal and allows for the insertion and deletion of ancillary data packets. The ancillary data packets may either be in horizontal ancillary data space, or vertical ancillary data space. During a horizontal interval of every television
20、line, the ancillary data space that is located between EAV and SAV markers is called horizontal ancillary data space (HANC space). During a vertical interval of each frame, the ancillary data space located between SAV and EAV markers is called vertical ancillary data space (VANC space). NOTE 1 Atten
21、tion is drawn to the existence of other ancillary data signals, such as digitized time code and checksum, for error detection and status information, which occupy specific locations in the digital line- and field-blanking areas. These locations should not be used for the insertion of further ancilla
22、ry data signals. Attention is drawn to the fact that signal switching disturbances will affect certain parts on the field and line-blanking areas and these locations should also not be used for the insertion of ancillary data signals (see Attachment 3). NOTE 2 The integrity of a data path for ancill
23、ary signals through all equipment cannot be assumed. NOTE 3 To avoid confusion between 8-bit and 10-bit representations of word values, the eight most-significant bits are considered to be an integer part while the two additional bits, if present, are considered to be fractional parts. For example,
24、the bit pattern 10010001 would be expressed as 145d or 91h, whereas the pattern 1001000101 would be expressed as 145.25d or 91.4h. Where no fractional part is shown, it can be assumed to have the binary value 00. 2 Legacy 8-bit considerations The parallel and serial digital video component interface
25、s described in Recommendation ITU-R BT.656 are capable of passing 10-bit data words. Some legacy interfaces may only pass 8 bits. Rec. ITU-R BT.1364-3 3 The passage of a 10-bit signal through such an 8-bit equipment results in truncation and the loss of the two LSBs, while serializing an 8-bit signa
26、l for transmission through the 10-bit serial interface results in two additional bits usually zeros being appended to the signal data bits. By taking the above considerations into account, provision is made for a limited number of applications in which ancillary data will not be corrupted by either
27、truncation or setting the two LSBs to zero (see Attachment 1). For digital HDTV interfaces conforming to Recommendation ITU-R BT.1120 and ITU-R BT.2077 only 10-bit operation is suggested for ancillary data signals. See Recommendation ITU-R BT.2077 part 2 for ANC data packet mapping. 3 Ancillary data
28、 packet format 3.1 Ancillary data packet types Ancillary data packets are divided into Type 1 and Type 2, where Type 1 uses a single word for data identification and Type 2 uses two words for this purpose: this allows a wide range of identification values to be used. A total of 189 data identificati
29、on values are reserved for 8-bit applications, as described in 3.4, whereas approximately 29 000 values are provided for 10-bit applications. The two types are shown in Fig. 1. The two types of data identification in the ancillary data packet format are specified below: Type 1: Uses a single word da
30、ta identification, defined as data ID (DID), which is followed by data block number (DBN) and data count (DC). Type 2: Uses a two word data identification, defined as a combination of data ID (DID) and a secondary data ID (SDID) which is followed by a data count (DC). Ancillary data is defined as 10
31、-bit words. This is required by the structure of the signal format and its interface. FIGURE 1 Ancillary data packet types B T .1 3 6 4 - 0 1D a t a I D ( t y p e 1 ) D a t a b l o c k n u m b e rA n c i l l a ry d a t a fl a g D a t a c o u n t C h e c k -s u mu s e r d a t aw o rd s(m a x . 2 5 5
32、)a ) T y p e 1A n c i l l a ry d a t a p a c k e tD a t a I D ( t y p e 2 ) S e c o n d a r y d a t a I DA n c i l l a ry d a t a fl a g D a t a c o u n t C h e c k -s u mu s e r d a t aw o rd s(m a x . 2 5 5 )b ) T y p e 2A n c i l l a ry d a t a p a c k e t3.1.1 Type 1 ancillary data packets Ancil
33、lary data packets of Type 1 are composed of: an ancillary data flag (ADF) which marks the beginning of the ancillary data packet; a data ID (DID) which defines the nature of the data carried in the user data words of the ancillary data packet; a data block number (DBN) word for Type 1 only, which di
34、stinguishes successive ancillary data packets with a common data ID; 4 Rec. ITU-R BT.1364-3 a data count (DC) number which defines the quantity of user data words in the ancillary data packet; the user data words (UDW), maximum of 255 words in each ancillary data packet: the user data format is defi
35、ned in a specific application text; a checksum (CS) word. 3.1.2 Type 2 ancillary data packets Ancillary data packets of Type 2 are composed of the same elements as Type 1 ancillary data packets except for the DBN, which is replaced by a secondary data identification word (SDID). 3.2 Ancillary data f
36、lag The ancillary data flag (ADF) consists of a three-word sequence having the values: 00.0h FF.Ch FF.Ch. NOTE 1 To maximize compatibility between 8-bit and 10-bit equipment, it is recommended that data values of 00.0h-00.Ch and FF.0h-FF.Ch be processed identically. References in this Recommendation
37、 to specific data values in either of those two ranges should apply to all data values within the same range (see Attachment 1). 3.3 Data identification word The data identification word (DID) consists of 10 bits, of which 8-bits carry the identification value, as shown in Table 1, and the remaining
38、 bits carry even parity and its inverse as shown: bits b7 (MSB)-b0 (LSB) form the identification value (00h-FFh); bit b8 is even parity for b7-b0; bit b9 = not b8. DID words are divided into Type 1 and Type 2 categories. In general, the setting of bit b7=1 indicates Type 1 and b70 indicates Type 2 d
39、ata identification. The exception to this categorization is word 00h which identifies an undefined format (see 3.4.1). 3.3.1 Reserved data identification words DID words shown in Table 1 as “internationally registered” are for ancillary data packets of interest to most organizations and are register
40、ed with the standards-setting organizations listed in Attachment 2. DID words shown as “user application” are not registered and are restricted to values in the range shown. They may be assigned by the user and/or by the manufacturer of the specified equipment. DID words shown as “reserved for 8-bit
41、 applications” are restricted to three values in the range shown. Out of the values 04h-0Fh reserved for 8-bit applications, the only valid values are 04h, 08h, and 0Ch. Other values in the reserved range would be truncated to these three values DID words shown as “reserved” are reserved for future
42、use. Rec. ITU-R BT.1364-3 5 TABLE 1 Identification value assignment D a t a T y p eD a t a V a l u eD I DD a t a A s s i g n m e n t 8 Ch9 FhA 0hA FhB 0hB FhC 0hC FhD 0hD FhE 0hE FhF 0hF FhT y p e1W o r dI D )R e s e r v e dU s e r A p p l i c a t i o n( 1D a t a T y p eD a t a V a l u eD I DD a t a
43、 A s s i g n m e n t 0 0h8 0h8 1h8 3h8 4h8 5h8 7h8 8h8 9h8B hT y p e1( 1W o r dI D )R e s e r v e dR e s e r v e d R e s e r v e dR e s e r v e dR e s e r v e d P a c k e t M a r k e d f o r D e l e t i o nI n t e r n a t i o n a l R e g i s t r yI n t e r n a t i o n a l R e g i s t r yI n t e r n
44、a t i o n a l R e g i s t r yI n t e r n a t i o n a l R e g i s t r yI n t e r n a t i o n a l R e g i s t r yR e s e r v e dD a t a T y p eD a t a V a l u eS D I DD a t a A s s i g n m e n t 0 0h0 1hF FhT y p e2( 2W o r dI D )R e s e r v e dU s e d b yS p e c i f i c A p p l i c a t i o nD a t a T
45、 y p eD a t a V a l u eD I DD a t a A s s i g n m e n t 0 0h0 1h0 3h0 4h0 Fh1 0h1 Fh2 0h3 Fh4 0h4 Fh5 0h5 FhT y p e2( 2W o r dI D )6 0h7 FhU s e r A p p l i c a t i o n s I n t e r n a t i o n a l R e g i s t r yI n t e r n a t i o n a l R e g i s t r yR e s e r v e dR e s e r v e dR e s e r v e dR
46、e s e r v e d f o r 8 - b i t A p p l i c a t i o nR e g i s t e r e d E x t e r n a lE n t i t y 3.4 Secondary data identification word (Type 2 data only) The secondary data identification (SDID) word consists of 10 bits, comprising an 8-bit identification value plus parity and its inverse as shown
47、: bits b7 (MSB)-b0 (LSB) form the identification 8-bit value (00h-FFh); bit b8 is even parity for b7-b0; bit b9 not b8. For 10-bit applications, SDID words which are part of the Type 2 data identification format may be in the range from 01h-FFh as shown in Table 1. Value 00h is reserved. 6 Rec. ITU-
48、R BT.1364-3 In 8-bit applications, only six bits are available in the SDID, giving 64 possible values, as indicated below: x0h, x4h, x8h, xCh where x may be any value in the range 0h-Fh. Setting aside the value 00h (Reserved) (see Table 1), the remaining 63 values, combined with the 3 values availab
49、le in the DID, give a maximum of 189 different identification values. 3.5 Data block number (Type 1 data only) The data block number (DBN) is incremented by 1 for each consecutive, related Type 1 data packet sharing a common DID and requiring continuity indication. The DBN value in the Type 1 data identification system is carried in 8 bits and is incremented from 1 to 255 where: bits b7 (MSB)-b0 (LSB), carry the data block (packet) number value; bit b8 is even parity for b7-b0; bit b9 not b8. NOTE 1 If more than 255 packe
