ATIS 0800013-2012 Media Formats and Protocols for IPTV Services (Version 2 0 Includes Access to Additional Content).pdf

《ATIS 0800013-2012 Media Formats and Protocols for IPTV Services (Version 2 0 Includes Access to Additional Content).pdf》由会员分享，可在线阅读，更多相关《ATIS 0800013-2012 Media Formats and Protocols for IPTV Services (Version 2 0 Includes Access to Additional Content).pdf（45页珍藏版）》请在麦多课文档分享上搜索。

1、 Access to Additional Content For ATIS-0800013.v002, Dated: April 23, 2012 (Click here to view the publication) This Page is not part of the original publication This page has been added by IHS as a convenience to the user in order to provide access to additional content as authorized by the Copyrig

2、ht holder of this document Click the link(s) below to access the content and use normal procedures for downloading or opening the files. ATIS-0800013.v002 Zip File Information contained in the above is the property of the Copyright holder and all Notice of Disclaimer updated to include new material

3、on the FLUTE protocol, the DTS-HD audio codec, and adaptive HTTP streaming (“ATIS-DASH”). ATIS-0800013.v002 iii Table of Contents 1 SCOPE, PURPOSE, Implementation guidelines for the use of Video and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream, 2011.821 ETSI TS 102

4、822-3-1 v1.4.1, Broadcast and On-line Services: Search, select and rightful use of content on personal storage systems (“TV-Anytime”); Part 3: Metadata; Sub-part 1: Phase 1 Metadata schemas, 2007.822 IETF RFC 2250, RTP Payload Format for MPEG1/MPEG2 Video, 1998.623 IETF RFC 3926, FLUTE - File Delive

5、ry over Unidirectional Transport, 2004.624 IETF RFC 3450, Asynchronous Layered Coding (ALC) Protocol Instantiation, 2002.625 IETF RFC 3451, Layered Coding Transport (LCT) Building Block, 2002.626 IETF RFC 5052, Forward Error Correction (FEC) Building Block, 2007.627 IETF RFC 3695, Compact Forward Er

6、ror Correction (FEC) Schemes, 2004.62This document is available from the Advanced Television Systems Committee. 3This document is available from the Consumer Electronics Association. 4This document is available from the Society of Motion Picture and Television Engineers. 5This document is available

7、at the Society for Cable Telecommunications Engineers (SCTE) at . 6RFC text is available at . 7This document will be published in early 2009. Until then, it is available from Digital Video Broadcasting as DVB A086 Rev. 7. 8This document is available from the European Telecommunications Standards Ins

8、titute (ETSI). ATIS-0800013.v002 3 28 ATIS-0800019, Multicast Network Service Specification, 2009.929 ATIS-0800005, IPTV Packet Loss Issue Report, 2007.930 SMPTE 2022-1, Forward Error Correction for Real-Time Video/Audio Transport Over IP Networks, 2007.431 IETF RFC 2236, Internet Group Management P

9、rotocol, Version 2, 1997.632 IETF RFC 3376, Internet Group Management Protocol, Version 3, 2002.633 IETF RFC 4607, Source-Specific Multicast for IP, 2006.634 IETF RFC 4608, Source-Specific Protocol Independent Multicast in 232/8, 2006.635 IETF RFC 4604, Using Internet FGroup Management Protocol Vers

10、ion 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for SourceSpecific Multicast, 2006.636 IETF RFC 3810, Multicast Listener Discovery Version 2 (MLDv2) for IPv6, 2004.637 IETF RFC 2710, Multicast Listener Discovery (MLD) for IPv6, 1999.638 IETF RFC 4566, SDP: Session Descript

11、ion Protocol, 2006.639 IETF RFC 3261, SIP: Session Initiation Protocol, 2002.640 IETF RFC 1305, Network Time Protocol (Version 3), Specification, Implementation and Analysis, March 1992.641 IETF RFC 1350, The TFTP Protocol (Revision 2), 1992.642 ITU-T Recommendation Y.2111R1, Resource and Admission

12、Control Functions in Next Generation Networks, 2008.1043 ETSI 102 824 v1.1.1, Remote Management and Firmware Update System For DVB IP Services, July 2008.844 IETF RFC 2326, Real Time Streaming Protocol (RTSP), 1998.645 IETF RFC 3890, A Transport Independent Bandwidth Modifier for the Session Descrip

13、tion Protocol, 2004.646 IEFC RFC 2616, Hypertext Transfer Protocol HTTP/1.1, 1999.647 W3C Recommendation, XML Schema Part 1: Structures Second Edition, 2004.1148 W3C Recommendation, XML Schema Part 2: Datatypes Second Edition, 2004.1149 IETF RFC 2373, IP Version 6 Addressing Architecture, 1998.650 I

14、ETF RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, 1998.651 ATIS-0800027.v002, IPTV Glossary, 2011.952 ETSI TS 102 472 v1.2.1, Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols, 2006.853 DLNA, DLNA Networked Device Interoperability Guidelines, Volume

15、 2: Media Format Profiles, expanded October 2006.1254 IETF RFC 2246, The TLS Protocol Version 1.0, 1999.655 IETF RFC 4346, The Transport Layer Security (TLS) Protocol Version 1.1, 2006.656 IETF RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2, 2008.657 IETF RFC 2818, HTTP Over TLS,

16、2000.658 ISO/IEC 23003-1:2007, Information technology MPEG audio technologies Part 1: MPEG Surround, 2007.159 IETF Internet-Draft draft-mehta-rmt-flute-sdp-05, SDP Descriptors for FLUTE, 2006.139This document is available from the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Str

17、eet N.W., Suite 500, Washington, DC 20005. 10This document will be available from the International Telecommunications Union. 11This document is available from the World Wide Web Consortium. 12This document is available from the Digital Living Network Alliance (DLNA). 13This document is available fr

18、om the IETF. ATIS-0800013.v002 4 60 3GPP TS 24.229 Version 8.4.1, IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3, 2008.1461 IETF RFC 3388, Grouping of Media Lines in the Session Description Protocol, 2002.662 IETF RFC 29

19、74, Session Announcement Protocol, 2000.663 ISO/IEC 14496-14, MP4 File Format, 2003.164 ISO/IEC 14496-12 ISO Base Media File Format, 2005.165 ETSI TS 102 114 v1.3.1, DTS Coherent Acoustics; Core and Extensions with Additional Profiles, 2011.866 ETSI EN 300 468, Version 1.11.1, Digital Video Broadcas

20、t (DVB); Specification for Service Information (SI) in DVB Systems, 2010.867 ISO/IEC 23009-1, Dynamic Adaptive Streaming over HTTP, 2012.168 ISO/IEC639-2, Codes for the representation of names of languages - Part 2: Alpha-3 code, 1998.13 Definitions, Acronyms, 8 uimsbf descriptor_length 8 uimsbf sub

21、stream_core_flag; 1 bslbf substream_0_flag; 1 bslbf substream_1_flag; 1 bslbf substream_2_flag; 1 bslbf substream_3_flag; 1 bslbf reserved; 3 bslbf if (core_substream_flag) substream.(substream_core); See Table 2. if (substream_0_flag) substream.(substream_0); See Table 2. if (substream_1_flag) subs

22、tream.(substream_1); See Table 2. if (substream_2_flag) substream.(substream_2); See Table 2. if (substream_3_flag) substream.(substream_3); See Table 2. for (i=0; i2 channels) 1 0 1 Reserved1 1 0 Reserved 1 1 1 Reservedlanguage_code_flag: This flag shall be set to 1 when ISO_639_language_code field

23、 is present. ISO_639_language_code: This 24-bit language code conforms to the ASCII language codes described in ISO/IEC 639-2 68. 6.1.1.4 DTS-HD PES packet 6.1.1.4.1 Stream ID All DTS-HD elementary streams shall use a stream_id = 0xBD, indicating private stream 1, in accordance with ITU-T Recommenda

24、tion H.222.0 / ISO/IEC 13818-1 14. Multiple DTS / DTS-HD streams may share the same ATIS-0800013.v002 16 value of stream_id since each stream is carried with a unique PID value. The mapping of values of PID to stream_type is indicated in the transport stream PMT. 6.1.1.4.2 Audio Access Unit Alignmen

25、t in the PES Packet A valid sync word shall be aligned with the start of the PES packet data area. Valid DTS sync words are listed in Table 10. Data_Alignment_Indicator in the PES packet header shall indicate sync word alignment. Table 10: DTS-HD Sync Words Name Sync Word Description DTS_SYNCWORD_CO

26、RE 0x7ffe8001 core substream DTS_SYNCWORD_SUBSTREAM 0x64582025 extension substream When a core substream is present, DTS_SYNCWORD_CORE shall be aligned with the beginning of the PES payload. When only an extension substream is present, DTS_SYNCWORD_SUBSTREAM shall be aligned to the beginning of the

27、PES payload. A PES packet of DTS audio shall contain at least one complete audio access unit. Multiple complete access units are permitted in a PES packet only when the ES consists of a single substream. The DTS-HD audio descriptor parameter substream_length describes the number of bytes in the core

28、 substream and extension substream (respectively). If multiple substreams are present, the access units shall maintain an interleaved order of presentation, as illustrated in Figure 2. Figure 2: PES Packet Payload 6.2 Real Time Protocol (RTP) RTP improves the robustness of IPTV delivery through its

29、use in packet loss recovery (application FEC and retransmission) and improved tolerance to delay variation. It is also beneficial for QoS metrics. When used with direct encapsulation of encoded media, RTP simplifies the differential treatment of packets. Encoded media using multicast shall be encaps

30、ulated in RTP according to IETF RFC 3550 16 and 3551 17. The use of RTP header extensions provides a relatively simple way to provide information associated with the RTP packet. When header extensions are used they should comply with RFC 5285 18. 6.3 Transport of MPEG-2 Transport Streams over RTP Th

31、e transporting of MPEG-2 Transport Streams over RTP shall be done as described in ETSI TS 102 034 19. As specified in TS 102 034, all Transport Streams shall be encapsulated in RTP according to RFC 3550 16 in conjunction with RFC 2250 22. ATIS-0800013.v002 17 6.4 Transport of MPEG-2 Transport Stream

32、s over HTTP HTTP can be used to deliver encoded content in MPEG2 Transport Stream such as, but not limited to: A single file using a single HTTP GET request. A single file using a sequence of HTTP GET requests, including HTTP Range headers. A sequence of files using a sequence of HTTP GET requests w

33、ith each file containing a segment of the content. The transport stream files are identified by a URI, a URI playlist, or a URI template for the generation of the URIs. The format of the URI playlist and URI template are for further study. When content is encoded in several representations, HTTP can

34、 be used to deliver content segments chosen sequentially from among the available representations in order to adapt to changes in available bandwidth or other factors. Adaptive HTTP streaming is specified as ATIS-DASH (section 6.7). 6.5 MP4 MP4, also known as MPEG 4 part 14, is a multimedia containe

35、r format standard specified in ISO/IEC 14496-14, MP4 File Format 63. MP4, and several other popular multimedia container formats, are based on ISO/IEC 14496-12, ISO Base Media File Format 64. The ISO Base Media File Format is designed to contain timed media information for a presentation in a flexib

36、le, extensible format that facilitates interchange, management, editing, and presentation of the media. Files are formed as a series of objects, called boxes. All data is contained in boxes; there is no other data within the file. The file format is designed to support random access and may be copie

37、d completely to a device before playback is started, or it may be progressively downloaded for playback as soon as the first portion of the file is received. MP4 extends the Base File Format to support MPEG 4 elementary streams. MP4 can be further extended to support additional capabilities such as

38、security or multiple representations. ATIS IIF extensions to MP4 are for further study. 6.6 Transport of MP4 over HTTP HTTP can be used to deliver content in MP4 containers such as, but not limited to: A single file using a single HTTP GET request. A single file using a sequence of HTTP GET requests

39、 including HTTP Range headers. A sequence of files using a sequence of HTTP GET requests with each file containing a segment of the content. MP4 files are identified by a URI, a URI playlist, or a URI template for the generation of the URIs. The format of the URI playlist and URI template are for fu

40、rther study. When content is encoded in several representations, HTTP can be used to deliver content segments chosen sequentially from among the representations in order to adapt to changes in available bandwidth or other factors. Adaptive HTTP streaming of encoded content in MP4 containers is speci

41、fied as ATIS-DASH (section 6.7). 6.7 ATIS-DASH ATIS-DASH shall be ISO/IEC 23009-1 67, which defines the formats (MPD and Segment) that enable delivery of media content from standard HTTP servers to HTTP clients and enable caching of content by standard HTTP caches. ATIS-0800013.v002 18 7 Ancillary P

42、rotocols 7.1 File Delivery Over Unidirectional Transport Unidirectional file delivery in ATIS IPTV standards is based on the FLUTE (File Delivery over Unidirectional Transport) protocol as specified in IETF RFC 3926 23, with certain constraints and extensions as described in the following subsection

43、s. 7.1.1 Overview of the FLUTE Protocol FLUTE is a protocol for the delivery of files over a unidirectional UDP/IP network. It can also be used for continuous delivery of segmented data such as for data carousels. It is independent of the IP version and the underlying link layers used. It can be use

44、d with both multicast and unicast delivery, but its primary application is for multicast file delivery. FLUTE requires connectivity between a sender and receivers, but does not require connectivity from receivers to a sender. FLUTE works with both multicast models: Any-Source Multicast (ASM) and Sou

45、rce-Specific Multicast (SSM). It should be noted, however, that the source IP address is a required part of the identification of a FLUTE session. FLUTE is a hierarchical protocol offering a number of multiplexing capabilities for highly efficient transport of files, including very large files, from

46、 a sender to a large community of receivers. A FLUTE session can span across a set of logically grouped channels, each of which is identified by the source IP address of the sender (S), an IP multicast group address (G), and a UDP port. It is possible, although unusual, for a single channel to conta

47、in packets belonging to multiple FLUTE sessions, with each session distinguished by a unique “Transport Session Identifier” (TSI) in each FLUTE packet header. Typically an application would be interested in just one of these FLUTE sessions and would discard packets belonging to the others. A FLUTE s

48、ession may carry multiple files, which may be distributed among the channels of the session in a variety of ways. The FLUTE conceptual hierarchy and relationships among sessions, channels, objects, files, file delivery tables, and file description entries are depicted in the UML class diagram shown

49、below. Please note that a star indicates a “many” relationship and a triangle represents inheritance. For example, a single FLUTE/ALC/LCT Session can be associated with multiple Transport Objects while a given Transport Object is associated with a single FLUTE/ALC/LCT Session. The kinds of Transport Objects associated with a FLUTE/ALC/LCT Session are either Files or File Delivery Tables. ATIS-0800013.v002 19 Figure 3: FLUTE Hierarchy FLUTE bui