idnits 2.17.1 draft-wei-payload-has-over-rtp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 529 has weird spacing: '...managed netwo...' -- The document date (October 29, 2016) is 2735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5109' is mentioned on line 410, but not defined == Missing Reference: 'RFC4585' is mentioned on line 411, but not defined == Missing Reference: 'RFC6184' is mentioned on line 430, but not defined == Missing Reference: 'RFC6838' is mentioned on line 488, but not defined == Missing Reference: 'RFC4855' is mentioned on line 464, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'CableLabs' Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Q. Wei 3 Intended Status: Standard Track R. Huang 4 Expires: May 2, 2017 H. Zheng 5 Huawei 6 October 29, 2016 8 RTP Payload Format for HTTP Adaptive Streaming 9 draft-wei-payload-has-over-rtp-01 11 Abstract 13 whis document introduces a new RTP payload format for encapsulating 14 the HTTP Adaptive Streaming (HAS) data into RTP, so that current RTP 15 schemes can be leveraged into OTT video delivery services. For 16 example, operators can easily deliver OTT live content through 17 multicast eliminating the impact of live content consumption peaks. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Existing Technologies . . . . . . . . . . . . . . . . . . . . 3 60 3.1 HTTP Adaptive Streaming . . . . . . . . . . . . . . . . . . 3 61 3.2 Multicast Adaptive Bit Rate (Multicast-ABR) . . . . . . . . 4 62 4. HAS Over RTP Use Scenarios . . . . . . . . . . . . . . . . . . 5 63 5. Overview of HTTP Adaptive Streaming over RTP . . . . . . . . . 5 64 6. HTTP Adaptive Streaming Payload . . . . . . . . . . . . . . . 7 65 6.1 RTP Payload Format for HAS Content . . . . . . . . . . . . 7 66 6.2 Use Existing RTP Payload Format for HAS Content . . . . . . 10 67 6.3 Manifest file and Initial Information Consideration . . . . 10 68 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11 69 7.1 Media Type Definition . . . . . . . . . . . . . . . . . . . 11 70 7.2 SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . 12 71 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 12 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 12.1 Normative References . . . . . . . . . . . . . . . . . . . 13 77 12.2 Informative References . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 Video consumption has exploded over the last few years as more and 83 more consumers are watching live Over-the-Top (OTT) content on 84 smartphones, tablets, PCs and other IP connected devices. Since OTT 85 video services rely on HTTP adaptive streaming (HAS) technology, 86 e.g., DASH and HTTP Live Streaming (HLS), to deliver content, so 87 every time a user requests a piece of content, a stream is sent 88 throughout the entire network. If a significant number of users are 89 requesting content, the operator's bandwidth is drained. It is 90 usually difficult for operators to predict the popularity of live 91 video content, especially for some major sporting events. For such an 92 event, millions of users will be watching the content simultaneously, 93 and causing peak traffic in the network. Even when Content Delivery 94 Network (CDN) is used to help distribute the traffic load over 95 network edge nodes, it might still not be sufficient. Since CDNs 96 cannot be deployed close enough to the users, its scalability is in 97 question. Furthermore, using CDN may also incur a very high expense, 98 especially for the new video services like 4K live, or VR live. All 99 of this leads to a poor Quality of Experience (QoE) for the users, 100 and a high cost for the service providers. The most effective 101 solution is to use multicast technology, even for OTT live content 102 delivery. Through multicast technology, operators can stream live 103 content only once in their network, regardless of the number of 104 viewers watching, which eliminates the impact of live content 105 consumption peaks. 107 This document introduces a new RTP payload format for encapsulating 108 the HAS data into RTP, so that current RTP schemes can be leveraged 109 into OTT video delivery services. For example, operators can easily 110 deliver OTT live content through multicast to eliminating the impact 111 of live content consumption peaks. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 3. Existing Technologies 121 3.1 HTTP Adaptive Streaming 123 HTTP adaptive streaming has become a popular approach in video 124 commercial deployments. The multimedia content is captured, divided 125 into small segments, and stored on an HTTP server. The consuming user 126 first obtains the manifest file, e.g., the Media Presentation 127 Description (MPD), which describes a manifest of the available 128 segments information, corresponding bitrates, their URL addresses, 129 and other characteristics. Based on this, the consuming user selects 130 the appropriate encoded alternative and starts streaming of the 131 content by fetching the segments using HTTP GET requests in unicast. 133 MPEG developed the specification, known as MPEG Dynamic Adaptive 134 Streaming over HTTP (DASH) [DASH], to standardize the MPD and the 135 segment formats. Other private mechanisms like Apple's HTTP Live 136 Streaming (HLS) [HLS] are also popular. 138 HAS is a typical client pull model. All the manifest files, HAS 139 segments, and etc., are pulled from the HTTP server one after another 140 by the clients issuing HTTP requests. 142 HTTP adaptive streaming is very efficient for the usage of Video on 143 Demand (VOD). However, when delivering live content simultaneously to 144 millions of users, this becomes quite a problem. The peak bandwidth 145 in video consumption is simply too much for an operator to handle 146 since each viewer counts as a separate unicast session. As live OTT 147 multi-screen video consumption shows no signs of slowing down, a 148 traditional unicast delivery method is becoming too expensive in 149 terms of bandwidth and investments that must be made to maintain the 150 network. Partnering with a CDN provider only helps optimize the 151 traffic on the backbone for known content. Additional infrastructure 152 investment is still required at the edge of the network to absorb the 153 load, but is too costly of an undertaking and would only be a 154 temporary solution, as there would always be a need for more servers 155 when live OTT consumption increases. 157 3.2 Multicast Adaptive Bit Rate (Multicast-ABR) 159 Operators are seeking ways to improve the quality of services 160 available, while also creating more balanced and effective delivery 161 of data to enhance the operators' cost-efficiency, and reduce wastage 162 across increasingly constrained bandwidths. Multicast-ABR, specified 163 in [CableLabs], is one of the innovations. 165 Multicast-ABR leverages HTTP streaming into multicast by keeping the 166 different alternatives in separate multicast groups, so that smart 167 network nodes or clients are able to select an appropriate rate by 168 joining the correct multicast and delivering these segments to 169 clients. And multicast-ABR uses NACK-Oriented Reliable Multicast 170 (NORM) [RFC5740] to deliver HTTP adaptive streaming data in 171 multicast. 173 Multicast-ABR is a low cost and easy to deploy solution that allows 174 operators to see multicast gains on all in-home devices leveraging 175 their TV Everywhere infrastructure. However, using NORM to convey 176 HTTP adaptive streaming data has 3 shortcomings: Firstly, NORM has no 177 fast channel change (FCC) mechanisms, like [RFC6285], so that 178 changing different video resolutions may take some time and cause 179 video frame freeze. Secondly, some telecom operators only have IPTV 180 multicast platform, which may not support NORM protocol. Thirdly, 181 NORM is not aware of the media timing in a way that RTP is as RTP is 182 nature to handle multimedia. 184 Based on this, using RTP to deliver HTTP adaptive streaming data 185 could be an alternative. 187 4. HAS Over RTP Use Scenarios 189 Network operators running IPTV have already built up an RTP over IP 190 multicast infrastructure to deliver IPTV content. With the 191 introduction of HAS payload for RTP, network operators can reuse the 192 existing infrastructure for the delivery of OTT content using HAS. 193 The benefit is that it can greatly reduce the investment for IPTV 194 headend devices and simplify the whole architecture. 196 From the perspective of OTT content providers, HAS over RTP will 197 provide them with another means other than CDN for content delivery. 198 OTT content providers can deliver their in high-demand videos through 199 multicast, thus ensuring the Quality of Experience (QoE) for the end 200 users. This would not only help save the bandwidth for network 201 operators, but also provide them with more opportunities for revenue. 202 They can offer the multicast as a service to OTT providers. 204 5. Overview of HTTP Adaptive Streaming over RTP 206 Figure 1 shows the architecture for HTTP adaptive streaming over RTP, 207 which is similar to the ones defined in Multicast-ABR. 209 +---------+ 210 | Content | 211 | Source | 212 +---------+ 213 | ----- Unicast 214 -------------------| 215 | | ***** Multicast 216 +-----------+ +------------+ 217 | HAS | | Multicast | 218 | Consumer | | Gateway | 219 +-----------+ +------------+ 220 * 221 * 222 * 223 **************************************** 224 * * 225 * * 226 +------------+ +------------+ 227 | Multicast | ................ | M2U | 228 | Consumer | +------------+ 229 +------------+ | 230 | 231 | 232 +------------+ 233 | Unicast | 234 | Consumer | 235 +------------+ 237 Figure 1: HTTP Adaptive Streaming over RTP with Multicast 239 In the above figure, a HAS Consumer can access the Content Source 240 using HTTP as normal. This memo considers only the operation of the 241 Multicast Gateway, the packetisation of HAS content within Multicast 242 RTP, the operation of the Multicast Consumer that receives that 243 content, and the operation of the Unicast Consumer that receives the 244 content by Unicast RTP. A Multicast Gateway receives the unicast HAS 245 streams of various bitrates from the Content Source, and converts 246 each unicast stream to multicast to pass on a specific multicast 247 group. Multicast Consumers subscribe to a multicast group to receive 248 data from the specific bit-rate stream. Unicast Consumers don't 249 support multicast but unicast RTP. Therefore, an intermediate node 250 M2U (multicast-to-unicast) can be introduced to help terminate the 251 multicast and convert the stream back to unicast for further 252 delivery. 254 Multicast Gateway: It is responsible for converting the HAS 255 streams from unicast to multicast, and providing the multicast 256 service to its receivers. It will directly pass through the live 257 content. 259 HAS Consumer: It is a standard HAS end point. It could be an 260 application, or just a user device. 262 Multicast Consumer: It is an end point supporting HAS RTP by 263 receiving the content in multicast. 265 Unicast Consumer: It is an end point supporting HAS RTP by 266 receiving the content in unicast. 268 M2U: It stands for multicast-to-unicast. It helps convert 269 multicast to unicast if the consumer doesn't support multicast. 271 HAS over RTP will be used throughout Multicast Server, M2U, Multicast 272 Consumer, and Unicast Consumer. 274 6. HTTP Adaptive Streaming Payload 276 This section specifies the format of the RTP payload of HTTP adaptive 277 streaming data. The structure of the payload is illustrated as Figure 278 2. This payload format uses the fields of the header in a manner 279 consistent with that specification. 281 +----------+------------+ 282 |RTP Header|HAS Payload | 283 +----------+------------+ 285 Figure 2: Packet Structure with RTP Header 287 There are two ways in which HAS content can be encoded in RTP 288 packets: The HAS Payload can be a new RTP Payload Format, specially 289 designed to carry HAS Content in RTP. Alternatively, an existing RTP 290 payload format can be used if the HAS Content uses a codec with an 291 existing format. We describe a new RTP payload format for HAS content 292 in section 6.1, and discuss using existing formats in Section 6.2. 294 6.1 RTP Payload Format for HAS Content 296 The format of RTP header is specified in [RFC3550] and is shown as 297 Figure 3 for convenience. 299 0 1 2 3 300 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |V=2|P|X| CC |M| PT | sequence number | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | timestamp | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | synchronization source (SSRC) identifier | 307 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 308 | [ contributing source (CSRC) identifiers ] | 309 | .... | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Figure 3: RTP Header Defined in [RFC3550] 314 The RTP header information to be set according to this RTP payload 315 format is set as followings: 317 Marker bit (M): 1 bits 319 The marker bit set "1" SHALL indicate the last RTP packet of the 320 media segment, carried in the current RTP stream. This is in line 321 with the normal use of the M bit in video formats to allow an 322 efficient playout buffer handling. 324 Payload Type (PT): 7 bits 326 The assignment of an RTP payload type for this new packet format 327 is outside of the scope of this document and will not be specified 328 here. The assignment of a payload type has to be performed either 329 through the profile used or in a dynamic way. 331 Sequence Number (SN): 16 bits 333 Set and used in accordance with [RFC3550]. 335 Timestamp: 16 bits 337 The RTP timestamp is set to the sampling timestamp of the content. 338 The clock rate is specified dynamically through non-RTP means. If 339 no clock rate is signaled, 90 kHz MUST be used. 341 When a media segment is encapsulated into several RTP packets, 342 each of them shares the same timestamp. 344 The format of the HAS payload is illustrated in Figure 4. 346 0 1 2 3 347 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 |F| RSV | Length | [URL Length] | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Offset | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | [ URL ...] | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | | 356 | HAS data | 357 | | 358 | . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | :...OPTIONAL RTP padding | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 4: Format for HTTP Adaptive Streaming Payload 364 Fragmentation (F): 1 bit 366 If the fragmentation is set, it indicates the received packet is a 367 part of a decodable fragment and can not be decoded correctly 368 until the whole decodable segment is received. The different parts 369 belong to the same decodable segment are ordered by their sequence 370 numbers, and share the same timestamp. 372 If the fragmentation is set, URL length field and URL field will 373 be omitted. 375 RSV : 7 bits 377 These bits are reserved for future use. They MUST be set to zero 378 by senders and ignored by receivers. 380 Length: 16 bits 382 The size of the RTP payload in bytes, excluding the RTP header but 383 including the payload header. 385 URL length: 8 bits 387 The size of the URL field in bytes, including the URL length. 389 Offset: 32 bits 391 The offset of this fragment in current decodable segment. 393 URL: bits defined by URL length. 395 This field indicates the URL of the content. Examples would be 396 "/PLTV/88888888/224/3221225484/3221225484.mpd", or 397 "Stream_1_1944000". It facilitates associating the content with 398 HTTP request so that receivers can easily turn it into HAS scheme 399 when receiving it. It is used to relate the RTP packet with 400 corresponding HAS segment specified in the manifest. 402 Basically, it is required to split application data into RTP packets 403 so that each packet is usable, no matter what is lost. This is 404 possible when the multicast server has the ability and is authorized 405 to access the HAS content. However, when OTT content is encrypted to 406 the multicast server, the frame boundary that can be decoded 407 independently is hardly figured out. Accordingly, one fragment of the 408 HAS segment lost will lead to the whole segment undecodable, and the 409 receivers joining the multicast randomly cannot view the content 410 immediately. In this case, mechanisms like FEC [RFC5109], or 411 retransmission [RFC4585] MUST be used to alleviate packet losses. And 412 FCC [RFC6285] SHOULD be used to ensure endpoints who joins the 413 multicast randomly can view the content immediately. 415 Another possible way to do smart fragmenting is to extend the 416 manifest files, e.g. MPD, to allow the OTT content providers indicate 417 the fragmentation points where independently decodable application 418 data can be extracted. Thus, the multicast server bridging HAS into 419 RTP would fetch the extended manifest file, then use these hints to 420 determine how to fragment each segment into RTP packets. Since DASH 421 is the standard in MPEG, this method requires the work in MPEG to 422 specify the extended fragmentation points. 424 6.2 Use Existing RTP Payload Format for HAS Content 426 It is also possible to use existing RTP payload format to transport 427 HAS content. For example, if the HAS content is H.264, the multicast 428 gateway will parse the HAS segments to find the boundaries, extract 429 the NAL units, and generates RTP packets using H.264 RTP format 430 [RFC6184]. This approach has its advantage that the resulting RTP 431 stream will be more robust to packet loss, since it uses a loss 432 tolerant encoding, and will use a standard RTP payload format, that 433 many existing RTP clients can decode. 435 However, it has several limitations: It is only possible when the 436 multicast server has the ability and is authorized to access the HAS 437 content; It will complicate the multicast gateway; And also the 438 multicast gateway is required to support multiple existing RTP 439 formats to enable flexibility since HAS content usually uses 440 container, e.g., MP4 [MPEG-4 Part 14], which can support multiple 441 encodings. 443 6.3 Manifest file and Initial Information Consideration 445 HAS comes with manifest files to describe the segments and initial 446 information to setup the session. Since these data needs reliable 447 ways to delivery, we do not consider transporting them in-band over 448 RTP with HAS segments. In fact, the end devices may not need the 449 manifest files as HAS over RTP is a push model and allows some 450 packets to be dropped. When the manifest files and initial 451 information are needed, they can be acquired using out of band method 452 like HTTP or SDP. Especially when the receiver joins the multicast, 453 it's better to obtain the manifest or initial information by out of 454 band ways in advance. 456 7. Payload Format Parameters 458 This section specifies the media type and the parameters identifying 459 this RTP payload format. 461 7.1 Media Type Definition 463 This registration is done using the template defined in [RFC6838] and 464 following [RFC4855]. 466 Type name: video 468 Subtype name: HAS 470 Required parameter: 472 has-type: This parameter indicates the HTTP adaptive streaming 473 protocol. The value of has-type MUST be in the range of 0 to 7, 474 inclusive. The detailed value can be seen as following. 476 HSPT=0: DASH 477 HSPT=1: Http Live Streaming (HLS) 478 HSPT=2-6: Reserved 479 HSPT=7: Profile-specific HTTP adaptive streaming 481 Optional parameters: 483 bitrate: This parameter can be used to signal receiver the bitrate 484 of the stream. How to use it is up to the receiver. The value of 485 this parameter is an integer in units of kilo-bits per second. 487 Encoding considerations: This media type is framed in RTP and 488 contains binary data; see Section 4.8 of [RFC6838]. 490 Security considerations: See section 7 of RFCXXXX. 492 Published specification: N/A 494 Additional information: None 495 File extensions: none 497 Macintosh file type code: none 499 Object identifier or OID: none 501 Person & email address to contact for further information: Rachel 502 Huang (rachel.huang@huawei.com) 504 Intended usage: COMMON 506 Author: See Authors' Addresses section of RFCxxxx. 508 Change controller: IETF Audio/Video Transport Payloads working group 509 delegated from the IESG. 511 7.2 SDP Signaling 513 TBD. 515 Negotiation of the new RTP payload is required. Further details will 516 be provided in the next versions. 518 8. Congestion Control 520 Current DASH clients do congestion control individually. When using 521 multicast to transport HAS data, it is expected that multicast 522 receivers have the ability to dynamically join the corresponding 523 multicast group based on different network conditions. Multicast 524 receivers share the same stream in one multicast group, but HAS 525 receivers compete each other with different streams, which means the 526 congestion control mechanisms used in HAS don't work for multicast. 528 However, it is expected that HAS over RTP for multicast is deployed 529 in a managed network, hence the congestion can be well controlled. 530 In the future, when it is deployed on the Internet, a new congestion 531 control mechanism may be required to coordinate the multicast 532 receivers with same congestion problem, so that they can share the 533 stream to obtain the best quality they can have. 535 9. Security Considerations 537 TBD. 539 10. IANA Considerations 540 TBD. 542 11. Acknowledgments 544 The authors would like to thank the following individuals who help to 545 review this document and provide very valuable comments: Colin 546 Perkins, Roni Even, Yuping Jiang. 548 12. References 550 12.1 Normative References 552 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, March 1997. 555 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 556 Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 557 64, RFC 3550, July 2003. 559 [CableLabs] "IP Multicast Adaptive Bit Rate Architecture Technical 560 Report" http://www.cablelabs.com/wp-content/uploads/specdocs/OC-TR- 561 IP-MULTI-ARCH-V01-1411121.pdf 563 12.2 Informative References 565 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker 566 "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 567 5740, November 2009. 569 [RFC6285] Steeg, B., Begen, A., Caenegem, T., and Z. Vax "Unicast- 570 Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 571 2011. 573 [DASH] ISO/IEC 23009-1:2014 Information technology -- Dynamic 574 adaptive streaming over HTTP (DASH) -- Part 1: Media presentation 575 description and segment format. 577 [HLS] Pantos, R. and W. May, "HTTP Live Streaming", 578 https://tools.ietf.org/html/draft-pantos-http-live-streaming-20, 579 September 2016. 581 [MPEG-4 Part 14] "Information technology - Coding of audio-visual 582 objects - Part 14:MP4 file format", ISO/IEC 14496-14, November 2003. 584 Authors' Addresses 586 Qikun Wei 587 Huawei 589 Email: weiqikun@huawei.com 591 Rachel Huang 592 Huawei 594 Email: rachel.huang@huawei.com 596 Hui Zheng 597 Huawei 599 Email: marvin.zhenghui@huawei.com 601 Yong Xia 602 China SARFT 604 Email: xiayong@abs.ac.cn