idnits 2.17.1 draft-ietf-payload-rtp-ttml-00.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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 5, 2019) is 1869 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 A/V Transport Payloads Workgroup J. Sandford 3 Internet-Draft British Broadcasting Corporation 4 Intended status: Informational March 5, 2019 5 Expires: September 6, 2019 7 RTP Payload for TTML Timed Text 8 draft-ietf-payload-rtp-ttml-00 10 Abstract 12 This memo describes a Real-time Transport Protocol (RTP) payload 13 format for TTML, an XML based timed text format for live and file 14 based workflows from W3C. This payload format is specifically 15 targeted at live workflows using TTML. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 6, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions, Definitions, and Abbreviations . . . . . . . . . 2 53 3. Media Format Description . . . . . . . . . . . . . . . . . . 3 54 3.1. Relation to Other Text Payload Types . . . . . . . . . . 3 55 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 4 57 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2.1. TTML Profile for RTP Carriage . . . . . . . . . . . . 5 59 5. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 8 60 6. Congestion Control Considerations . . . . . . . . . . . . . . 9 61 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 10 62 7.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 10 63 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 10 64 7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 10.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 14 71 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 74 1. Introduction 76 TTML (Timed Text Markup Language)[TTML2] is a media type for 77 describing timed text such as closed captions (also known as 78 subtitles) in television workflows or broadcasts as XML. This 79 document specifies how TTML should be mapped into an RTP stream in 80 live workflows including, but not restricted to, those described in 81 the television broadcast oriented EBU-TT Part 3[TECH3370] 82 specification. This document does not define a media type for TTML 83 but makes use of the existing application/ttml+xml media type 84 [TTML-MTPR]. 86 2. Conventions, Definitions, and Abbreviations 88 Unless otherwise stated, the term "document" is used in this draft to 89 refer to the TTML document being transmitted in the payload of the 90 RTP packet(s). 92 Where the term "word" is used in this draft, it is to refer to byte 93 aligned or 32-bit aligned words of data in a computing sense and not 94 to refer to linguistic words that might appear in the transported 95 text. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in BCP14 [RFC2119] 100 [RFC8174] when, and only when, they appear in all capitals, as shown 101 here. 103 3. Media Format Description 105 3.1. Relation to Other Text Payload Types 107 Prior payload types for text are not suited to the carriage of closed 108 captions in Television Workflows. RFC 4103 for Text Conversation 109 [RFC4103] is intended for low data rate conversation with its own 110 session management and minimal formatting capabilities. RFC 4734 111 Events for Modem, Fax, and Text Telephony Signals [RFC4734] deals in 112 large parts with the control signalling of facsimile and other 113 systems. RFC 4396 for 3rd Generation Partnership Project (3GPP) 114 Timed Text [RFC4396] describes the carriage of a timed text format 115 with much more restricted formatting capabilities than TTML. The 116 lack of an existing format for TTML or generic XML has necessitated 117 the creation of this payload format. 119 4. Payload Format 121 In addition to the required RTP headers, the payload contains a 122 section for the TTML document being transmitted (User Data Words), 123 and a field for the Length of that data. Each RTP payload contains 124 one or part of one TTML document. 126 A representation of the payload format for TTML is Figure 1. 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |V=2|P|X| CC |M| PT | Sequence Number | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Timestamp | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Synchronization Source (SSRC) Identifier | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Reserved | Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | User Data Words... 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: RTP Payload Format for TTML 144 4.1. RTP Header Usage 146 RTP packet header fields SHALL be interpreted as per RFC 3550 147 [RFC3550], with the following specifics: 149 Marker Bit (M): 1 bit 150 The Marker Bit is set to "1" to indicate the last packet of a 151 document. Otherwise set to "0". Note: The first packet might 152 also be the last. 154 Timestamp: 32 bits 155 The RTP Timestamp encodes the time of the text in the packet. The 156 clock frequency used is dependent on the application and is 157 specified in the media type rate parameter as per Section 7.1. 158 Documents spread across multiple packets MUST use the same 159 timestamp but different consecutive Sequence Numbers. Sequential 160 documents MUST NOT use the same timestamp. Because packets do not 161 represent any constant duration, the timestamp cannot be used to 162 directly infer packet loss. 164 Reserved: 16 bits 165 These bits are reserved for future use and MUST be set to 0x0. 167 Length: 16 bits 168 The length of User Data Words in bytes. 170 User Data Words: integer number of words whose length is defined by 171 the character encoding 172 User Data Words contains the text of the whole document being 173 transmitted or a part of the document being transmitted. 174 Documents using character encodings where characters are not 175 represented by a single byte MUST be serialized in big endian 176 order, a.k.a. network byte order. When the document spans more 177 than one RTP packet, the entire document is obtained by 178 concatenating User Data Words from each contributing packet in 179 ascending order of Sequence Number. 181 4.2. Payload Data 183 Documents carried in User Data Words are encoded in accordance with 184 one of the defined TTML profiles specified in its registry 185 [TTML-MTPR]. These profiles specify the document structure used, 186 systems models, timing, and other considerations. 188 Additionally, documents carried over RTP MUST conform to the 189 following profile. 191 4.2.1. TTML Profile for RTP Carriage 193 This section defines constraints on the content and processing of the 194 TTML payload for RTP carriage. 196 4.2.1.1. Payload content restrictions 198 Multiple TTML subtitle streams MUST NOT be interleaved in a single 199 RTP stream. 201 The TTML document instance MUST use the "media" value of the 202 "ttp:timeBase" parameter attribute on the root element. 204 This is equivalent to the following TTML2 content profile definition 205 document: 207 208 214 215 216 217 This document is a minimal TTML2 content profile 218 definition document intended to express the minimal 219 requirements to apply when carrying TTML over RTP. 220 221 222 #timeBase-media 223 #timeBase-smpte 224 #timeBase-clock 225 226 228 4.2.1.2. Payload processing requirements 230 If the TTML document payload is assessed to be invalid then it MUST 231 be discarded. When processing a valid document, the following 232 requirements apply. 234 The epoch E relative to which computed TTML media times are offset 235 MUST be set to the RTP Timestamp in the header of the RTP packet in 236 which the TTML document instance is carried. 238 When processing a sequence of TTML documents each delivered in the 239 same RTP stream, exactly zero or one document SHALL be considered 240 active at each moment in the RTP time line. 242 Each TTML document becomes active at E. In the event that a document 243 D_(n-1) with E_(n-1) is active, and document D_(n) is delivered with 244 E_(n) where E_(n-1) < E_(n), processing of D_(n-1) MUST be stopped at 245 E_(n) and processing of D_(n) MUST begin. 247 When all defined content within a document has ended, i.e. the active 248 intermediate synchronic document contains no content, then processing 249 of the document MAY be stopped. 251 4.2.1.2.1. TTML Processor profile 253 4.2.1.2.1.1. Feature extension designation 255 This specification defines the following TTML feature extension 256 designation: 258 o urn:ietf:rfc:XXXX#rtp-relative-media-time 260 The namespace "urn:ietf:rfc:XXXX" is as defined by [RFC2648]. 262 A TTML content processor supports the "#rtp-relative-media-time" 263 feature extension if it processes media times in accordance with the 264 payload processing requirements specified in this document, i.e. that 265 the epoch E is set to the time equivalent to the RTP Timestamp as 266 detailed above in Section 4.2.1.2. 268 4.2.1.2.1.2. Processor profile document 270 The required syntax and semantics declared in the following minimal 271 TTML2 processor profile MUST be supported by the receiver, as 272 signified by those "feature" or "extension" elements whose "value" 273 attribute is set to "required": 275 276 282 283 284 285 This document is a minimal TTML2 processor profile 286 definition document intended to express the minimal 287 requirements of a TTML processor able to process TTML 288 delivered over RTP according to RFC XXXX. 289 290 291 #timeBase-media 292 #profile-full-version-2 293 294 295 296 #rtp-relative-media-time 297 298 299 301 Note that this requirement does not imply that the receiver needs to 302 support either TTML1 or TTML2 profile processing, i.e. the TTML2 303 "#profile-full-version-2" feature or any of its dependent features. 305 4.2.1.2.1.3. Processor profile signalling 307 The "codecs" media type parameter MUST specify at least one processor 308 profile. The processor profiles specified in "codecs" MUST be 309 compatible with the processor profile specified in this document. 310 Where multiple options exist in "codecs" for possible processor 311 profile combinations (i.e. separated by "|" operator), every 312 permitted option MUST be compatible with the processor profile 313 specified in this document. Where processor profiles other than the 314 one specified in this document are advertised in the "codecs" 315 parameter, the requirements of the processor profile specified in 316 this document MAY be signalled additionally using the "+" operator 317 with its registered short code. 319 A processor profile (X) is compatible with the processor profile in 320 this document (P) if X includes all the features and extensions in P, 321 identified by their character content, and the "value" attribute of 322 each is at least as restrictive as the "value" attribute of the 323 feature or extension in P that has the same character content. The 324 term "restrictive" here is as defined in [TTML2] Section 6. 326 Note that short codes for TTML profiles are registered at 327 [TTML-MTPR]. 329 4.2.1.2.2. EBU-TT Live considerations 331 EBU-TT Live is a profile of TTML intended to support live 332 contribution of TTML documents as a stream independently of the 333 carriage mechanism. When EBU-TT Live documents are carried in an RTP 334 stream, or when the TTML documents being transferred over RTP use 335 EBU-TT Live semantics, the following considerations apply: 337 E is considered to be the Availability Time as defined by EBU-TT 338 Live. It is an error if two documents are delivered such that 339 E_(n-1) < E_(n) and the "ebuttp:sequenceNumber" of E_(n-1) is greater 340 than the "ebuttp:sequenceNumber" of E_(n). Every EBU-TT Live 341 document in a single RTP stream MUST have a 342 "ebuttp:sequenceIdentifier" with the same value. 344 5. Payload Examples 346 The following is an example of a valid TTML document that may be 347 carried using the payload format described in this document: 349 350 357 358 359 Timed Text TTML Example 360 The Authors (c) 2006 361 362 363 364