1、 International Telecommunication Union ITU-T J.285TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (12/2007) SERIES J: CABLE NETWORKS AND TRANSMISSION OF TELEVISION, SOUND PROGRAMME AND OTHER MULTIMEDIA SIGNALS Digital transmission of television signals Architecture for synchronised programme transfe
2、r with pull operation over IP-based networks ITU-T Recommendation J.285 ITU-T Rec. J.285 (12/2007) i ITU-T Recommendation J.285 Architecture for synchronised programme transfer with pull operation over IP-based networks Summary ITU-T Recommendation J.285 defines requirements of IP-based material tra
3、nsfer from remote sites to a broadcast station controlled by the broadcast station side. The requirements are based on the generic requirements defined in ITU-T Recommendation J.284 with the analysis of several use cases which are also described in this Recommendation. To satisfy the requirements, t
4、his Recommendation also defines the architecture for programme material transfer in synchronization with pull operation. The architecture is only relevant to transfer of file-based materials such as computer files. That is, transfer of unfiled materials such as signals from equipment like cameras an
5、d microphones are not taken into account in this Recommendation. The architecture also enables synchronized transfer of multiple files simultaneously, which offers the opportunity for the receiver to switch receiving files from one to the others according to an edit decision list (EDL). Source ITU-T
6、 Recommendation J.285 was approved on 14 December 2007 by ITU-T Study Group 9 (2005-2008) under the ITU-T Recommendation A.8 procedure. ii ITU-T Rec. J.285 (12/2007) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications,
7、information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on
8、a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid dow
9、n in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication
10、administration and a recognized operating agency. Compliance with this Recommendation 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 p
11、rovisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attenti
12、on to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others o
13、utside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the lat
14、est information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2008 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. ITU-T Rec. J.285 (12/2007) iii CONTE
15、NTS Page 1 Scope 1 2 References. 1 3 Definitions 2 3.1 Terms defined elsewhere 2 3.2 Terms defined in this Recommendation. 2 4 Abbreviations and acronyms 2 5 Conventions 2 6 The Recommendation. 2 6.1 Use cases 2 6.2 Requirements 4 6.3 Architecture 5 Appendix I Example packet structures . 9 I.1 Examp
16、le data packet structure 9 I.2 Example synchronization packet structure. 10 iv ITU-T Rec. J.285 (12/2007) Introduction Broadband IP network infrastructure is being promoted and becoming more widely used for transfer of broadcast materials, and computerised equipment for producing news and other prog
17、rammes is becoming widely implemented. Therefore, the IP-based transfer of programme materials with compatibility for computers is considered to be another major transfer method in addition to other conventional methods such as satellite news gathering (SNG) transmission. The editing process usually
18、 requires storing materials locally prior to edit. However, an IP network can be used to establish a relatively simple technique which enables to edit materials even while transferring them. ITU-T Rec. J.285 (12/2007) 1 ITU-T Recommendation J.285 Architecture for synchronised programme transfer with
19、 pull operation over IP-based networks 1 Scope This Recommendation defines requirements of IP-based material transfer from remote sites to a broadcast station controlled by the broadcast station side. The requirements are based on the generic requirements defined in ITU-T J.284 with the analysis of
20、several use cases which are also described in this Recommendation. To satisfy the requirements, this Recommendation also defines the architecture for programme material transfer in synchronization with pull operation. The architecture is only relevant to transfer of file-based materials such as comp
21、uter files. That is, transfer of unfiled materials such as signals from equipment like cameras and microphones are not taken into account in this Recommendation. The architecture also enables synchronized transfer of multiple files simultaneously, which offers the opportunity for the receiver to swi
22、tch receiving files from one to the others according to an edit decision list (EDL). 2 References The following ITU-T Recommendations and other references contain provisions which, through reference in this text, constitute provisions of this Recommendation. At the time of publication, the editions
23、indicated were valid. All Recommendations and other references are subject to revision; users of this Recommendation are therefore encouraged to investigate the possibility of applying the most recent edition of the Recommendations and other references listed below. A list of the currently valid ITU
24、-T Recommendations is regularly published. The reference to a document within this Recommendation does not give it, as a stand-alone document, the status of a Recommendation. ITU-T J.284 ITU-T Recommendation J.284 (2007), Requirements and framework for gathering electronic content over IP-based netw
25、ork. ITU-R BT.1563 Recommendation ITU-R BT.1563 (2002), Data encoding protocol using key-length-value. ITU-R BT.1775 Recommendation ITU-R BT.1775 (2006), File format with editing capability, for the exchange of metadata, audio, video, data essence and ancillary data for use in broadcasting. IETF RFC
26、 768 IETF Request for Comments 768 (1980), User Datagram Protocol. IETF RFC 791 IETF Request for Comments 791 (1981), Internet Protocol. IETF RFC 793 IETF Request for Comments 793 (1981), Transmission Control Protocol. IETF RFC 959 IETF Request for Comments 959 (1985), File Transfer Protocol. IETF R
27、FC 3550 IETF Request for Comments 3550 (2003), RTP: A Transport Protocol for Real-Time Applications. 3 Definitions 3.1 Terms defined elsewhere None 2 ITU-T Rec. J.285 (12/2007) 3.2 Terms defined in this Recommendation This Recommendation defines the following terms: 3.2.1 synchronization packet: A T
28、CP packet that controls a senders transfer rate in the application layer. The packet is transmitted from a receiver to a sender. NOTE The packet is not the TCP SYN segment. 3.2.2 acknowledge data: Transfer control data transmitted by a receiver as an affirmative response to the sender. The acknowled
29、ge data is included in the synchronization packet. 4 Abbreviations and acronyms This Recommendation uses the following abbreviations and acronyms: EDL Edit Decision List FS File Server KLV Key-Length-Value coding MXF Material Exchange Format MXF-GC Material Exchange Format Generic Container PM Progr
30、amme Material TC Time Code 5 Conventions None. 6 The Recommendation 6.1 Use cases This clause describes use cases for transfer of programme materials from one or more remote sites to a broadcast station over IP networks, as shown in Figure 1. In all cases, the transfers are controlled by the receive
31、r side. Figure 1 Programme material transfer over IP networks 6.1.1 File transfer File transfer is the transfer of material files from a remote server over an IP network, as shown in Figure 2-a. File transfer requires processing to recover lost packets but does not require the real-time characterist
32、ic. ITU-T Rec. J.285 (12/2007) 3 For simultaneous multiple file transfers from remote servers to one broadcast station, the receiver side may control the bit rate of the material transmission at the application layer to prioritize the file transfer as shown in Figure 2-b. Figure 2 File transfer 6.1.
33、2 Real-time streaming transfer Real-time streaming transfer is used to display material from a server directly on a display, as shown in Figure 3. Real-time streaming requires the real-time characteristic for the time line of the receiving side. It does not require processing to recover lost packets
34、. Certain latency from the start time of transfer at the sender side to the start time of playing the stream at the receiver side may be allowed. Therefore, conditional recovery processing can be optionally used unless it degrades the real-time characteristic of playing the audiovisual stream at the
35、 receiver side. Figure 3 Real-time streaming transfer 6.1.3 Synchronized transfer Synchronized transfer is the transfer of multiple materials from remote servers in synchronization, as shown in Figure 4-a. It is used to play video and sound with a synchronized time line when the video and sound file
36、s are stored on separate servers. It synchronizes multiple data streams transferred to receiving application in order to prevent overflow and underflow of the reception buffer. It needs to keep synchronization between the video and sounds (lip-sync). Synchronized transfer is used to directly edit pr
37、ogrammes with materials from distant servers according to an edit decision list (EDL), which is created prior to processing, as shown in Figure 4-b. There are two types of synchronized transfer. One is non-real-time processing in which 4 ITU-T Rec. J.285 (12/2007) multiple materials are processed an
38、d stored as a file, and the other is real-time processing in which multiple materials are processed and displayed on a monitor. Non-real-time processing requires the recovering of lost packets, whereas real-time processing can optionally support conditional recovery processing unless such recovery d
39、egrades the real-time characteristic of the audiovisual streams playing at the receiving side. Figure 4 Synchronized transfer 6.2 Requirements The architecture for synchronized material transfer is required to satisfy the following requirements: Applicable to all types of transfer applications descr
40、ibed in clause 6.1. Maintains transfer performance, even over a long-distance network. Transfer upon standard TCP/IP and UDP/IP protocol stacks. Applicable to any encoding scheme of the material files. And additional requirements of which applicability varies with applications are listed below: Reco
41、very processing against data packet loss. Flow control from the receiver side for the prioritized file transfer. Flow control from the receiver side for synchronized reception. Table 1 classifies the applicability of the additional requirements for the transfer applications described in clause 6.1.
42、ITU-T Rec. J.285 (12/2007) 5 Table 1 Classification of the additional requirements for synchronized transfer applications Synchronized transfer Synchronized editing File transfer Real-time streaming transfer Synchronized streaming Real-time Non-real-time Recovery processing against data packet loss
43、required optional optional optional required Flow control for prioritized transfer required n/a n/a n/a n/a Flow control for synchronization n/a n/a required required required 6.3 Architecture This clause defines the architecture for synchronized programme transfer with pull operation that meets the
44、 requirements described in clause 6.2. 6.3.1 Structure of programme materials The transfer of programme materials is controlled video frame by video frame. ITU-R BT.1775 defines the file format called material exchange format (MXF) for use in a broadcasting environment and the methods to wrap many t
45、ypes of encoded essence data for exchanging programme materials. Figure 5 shows the structure of frame-based wrapping in the MXF generic container (MXF-GC). The MXF-GC contains video, sound, data and compound essence all together for which the encoding methods are independent of the MXF, and these i
46、tems are encoded frame by frame by using the key-length-value (KLV) coding protocol ITU-R BT.1563. The MXF-GC frame-based wrapping covers the structure of programme materials in the architecture. This makes it possible to transfer the data frame by frame regardless of the differences in the encoding
47、 methods. K L V K L V K: SMPTE universal label L: Data length V: Value (frame data) Figure 5 The structure of MXF-GC frame-based wrapping 6.3.2 Transfer model Figure 6 shows the transfer model. The senders have programme materials. 6 ITU-T Rec. J.285 (12/2007) Figure 6 An example of transfer model T
48、he transfer model consists of signal flows and controls. The sender produces data packets from material data, and transfers them on a signal flow. The signal flow goes from the sender to the receiver. The receiver controls the transfer rate from each sender by synchronization packets. Figure 7 shows
49、 the protocol stack for the architecture. Transfer applications Transfer applications Signal flow RTP Control UDP TCP IP IP Figure 7 Protocol stack The TCP and UDP are widely used as standard transport protocols for IP networks. Because of their compatibility with computer environments, these protocols are suitable for transferring IP-based programme materials. However, TCP/IP may not be suitable for file transfers over a long-distance network because TCP congestion control may not provide enough bandwidth for large siz
