idnits 2.17.1 draft-ietf-payload-rtp-ttml-06.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 (19 November 2019) is 1619 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'TECH3370' -- Possible downref: Non-RFC (?) normative reference: ref. 'TTML-MTPR' -- Possible downref: Non-RFC (?) normative reference: ref. 'TTML2' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 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: Standards Track 19 November 2019 5 Expires: 22 May 2020 7 RTP Payload for TTML Timed Text 8 draft-ietf-payload-rtp-ttml-06 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 22 May 2020. 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 (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions, Definitions, and Abbreviations . . . . . . . . . 2 52 3. Media Format Description . . . . . . . . . . . . . . . . . . 3 53 3.1. Relation to Other Text Payload Types . . . . . . . . . . 3 54 3.2. TTML2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 3 56 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 4 57 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Payload content restrictions . . . . . . . . . . . . . . . . 5 59 6. Payload processing requirements . . . . . . . . . . . . . . . 6 60 6.1. TTML Processor profile . . . . . . . . . . . . . . . . . 7 61 6.1.1. Feature extension designation . . . . . . . . . . . . 7 62 6.1.2. Processor profile document . . . . . . . . . . . . . 7 63 6.1.3. Processor profile signalling . . . . . . . . . . . . 8 64 7. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 9 65 8. Fragmentation of TTML Documents . . . . . . . . . . . . . . . 11 66 9. Protection Against Loss of Data . . . . . . . . . . . . . . . 11 67 10. Congestion Control Considerations . . . . . . . . . . . . . . 12 68 11. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12 69 11.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 12 70 11.2. SDP Considerations . . . . . . . . . . . . . . . . . . . 12 71 11.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 13 72 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 75 15. Normative References . . . . . . . . . . . . . . . . . . . . 14 76 16. Informative References . . . . . . . . . . . . . . . . . . . 16 77 Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 17 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 80 1. Introduction 82 TTML (Timed Text Markup Language)[TTML2] is a media type for 83 describing timed text such as closed captions and subtitles in 84 television workflows or broadcasts as XML. This document specifies 85 how TTML should be mapped into an RTP stream in live workflows 86 including, but not restricted to, those described in the television 87 broadcast oriented EBU-TT Part 3[TECH3370] specification. This 88 document does not define a media type for TTML but makes use of the 89 existing application/ttml+xml media type [TTML-MTPR]. 91 2. Conventions, Definitions, and Abbreviations 93 Unless otherwise stated, the term "document" refers to the TTML 94 document being transmitted in the payload of the RTP packet(s). 96 The term "word" refers to a data word aligned to a specified number 97 of bits in a computing sense and not to refer to linguistic words 98 that might appear in the transported text. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 3. Media Format Description 108 3.1. Relation to Other Text Payload Types 110 Prior payload types for text are not suited to the carriage of closed 111 captions in Television Workflows. RFC 4103 for Text Conversation 112 [RFC4103] is intended for low data rate conversation with its own 113 session management and minimal formatting capabilities. RFC 4734 114 Events for Modem, Fax, and Text Telephony Signals [RFC4734] deals in 115 large parts with the control signalling of facsimile and other 116 systems. RFC 4396 for 3rd Generation Partnership Project (3GPP) 117 Timed Text [RFC4396] describes the carriage of a timed text format 118 with much more restricted formatting capabilities than TTML. The 119 lack of an existing format for TTML or generic XML has necessitated 120 the creation of this payload format. 122 3.2. TTML2 124 TTML2 (Timed Text Markup Language, Version 2)[TTML2] is an XML-based 125 markup language for describing textual information with associated 126 timing metadata. One of its primary use cases is the description of 127 subtitles and closed captions. A number of profiles exist that adapt 128 TTML2 for use in specific contexts [TTML-MTPR]. These include both 129 file based and streaming workflows. 131 4. Payload Format 133 In addition to the required RTP headers, the payload contains a 134 section for the TTML document being transmitted (User Data Words), 135 and a field for the Length of that data. Each RTP payload contains 136 one or part of one TTML document. 138 A representation of the payload format for TTML is Figure 1. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 |V=2|P|X| CC |M| PT | Sequence Number | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Timestamp | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Synchronization Source (SSRC) Identifier | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Reserved | Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | User Data Words... 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Figure 1: RTP Payload Format for TTML 156 4.1. RTP Header Usage 158 RTP packet header fields SHALL be interpreted as per RFC 3550 159 [RFC3550], with the following specifics: 161 Marker Bit (M): 1 bit 162 The Marker Bit is set to "1" to indicate the last packet of a 163 document. Otherwise set to "0". Note: The first packet might 164 also be the last. 166 Timestamp: 32 bits 167 The RTP Timestamp encodes the epoch of the TTML document in User 168 Data Words. Further detail on its usage may be found in 169 Section 6. The clock frequency used is dependent on the 170 application and is specified in the media type rate parameter as 171 per Section 11.1. Documents spread across multiple packets MUST 172 use the same timestamp but different consecutive Sequence Numbers. 173 Sequential documents MUST NOT use the same timestamp. Because 174 packets do not represent any constant duration, the timestamp 175 cannot be used to directly infer packet loss. 177 Reserved: 16 bits 178 These bits are reserved for future use and MUST be set to 0x0 and 179 ignored at receive. 181 Length: 16 bits 182 The length of User Data Words in bytes. 184 User Data Words: The length of User Data Words MUST match the 185 value specified in the Length field 186 User Data Words contains the text of the whole document being 187 transmitted or a part of the document being transmitted. 189 Documents using character encodings where characters are not 190 represented by a single byte MUST be serialized in big endian 191 order, a.k.a. network byte order. Where a document will not fit 192 within the Path MTU, it may be fragmented across multiple packets. 193 Further detail on fragmentation may be found in Section 8. 195 4.2. Payload Data 197 TTML documents define a series of changes to text over time. TTML 198 documents carried in User Data Words are encoded in accordance with 199 one or more of the defined TTML profiles specified in the TTML 200 registry [TTML-MTPR]. These profiles specify the document structure 201 used, systems models, timing, and other considerations. TTML 202 profiles may restrict the complexity of the changes and operational 203 requirements may limit the maximum duration of TTML documents by a 204 deployment configuration. Both of these cases are out of scope of 205 this document. 207 Documents carried over RTP MUST conform to the following profile in 208 addition to any others used. 210 5. Payload content restrictions 212 This section defines constraints on the content of TTML documents 213 carried over RTP. 215 Multiple TTML subtitle streams MUST NOT be interleaved in a single 216 RTP stream. 218 The TTML document instance's root "tt" element in the 219 "http://www.w3.org/ns/ttml" namespace MUST include a "timeBase" 220 attribute in the "http://www.w3.org/ns/ttml#parameter" namespace 221 containing the value "media". 223 This is equivalent to the TTML2 content profile definition document 224 in Figure 2. 226 227 233 234 235 236 This document is a minimal TTML2 content profile 237 definition document intended to express the 238 minimal requirements to apply when carrying TTML 239 over RTP. 240 241 242 #timeBase-media 243 #timeBase-smpte 244 #timeBase-clock 245 246 248 Figure 2: TTML2 Content Profile Definition for Documents Carried 249 Over RTP 251 6. Payload processing requirements 253 This section defines constraints on the processing of the TTML 254 documents carried over RTP. 256 If a TTML document is assessed to be invalid then it MUST be 257 discarded. This includes empty documents, i.e. those of zero length. 258 When processing a valid document, the following requirements apply. 260 Each TTML document becomes active at its epoch E. E MUST be set to 261 the RTP Timestamp in the header of the RTP packet carrying the TTML 262 document. Computed TTML media times are offset relative to E in 263 accordance with Section I.2 of [TTML2]. 265 When processing a sequence of TTML documents each delivered in the 266 same RTP stream, exactly zero or one document SHALL be considered 267 active at each moment in the RTP time line. In the event that a 268 document D_(n-1) with E_(n-1) is active, and document D_(n) is 269 delivered with E_(n) where E_(n-1) < E_(n), processing of D_(n-1) 270 MUST be stopped at E_(n) and processing of D_(n) MUST begin. 272 When all defined content within a document has ended then processing 273 of the document MAY be stopped. This can be tested by constructing 274 the intermediate synchronic document sequence from the document, as 275 defined by [TTML2]. If the last intermediate synchronic document in 276 the sequence is both active and contains no region elements, then all 277 defined content within the document has ended. 279 As described above, the RTP Timestamp does not specify the exact 280 timing of the media in this payload format. Additionally, documents 281 may be fragmented across multiple packets. This renders the RTCP 282 jitter calculation unusable. 284 6.1. TTML Processor profile 286 6.1.1. Feature extension designation 288 This specification defines the following TTML feature extension 289 designation: 291 * urn:ietf:rfc:XXXX#rtp-relative-media-time 293 The namespace "urn:ietf:rfc:XXXX" is as defined by [RFC2648]. 295 A TTML content processor supports the "#rtp-relative-media-time" 296 feature extension if it processes media times in accordance with the 297 payload processing requirements specified in this document, i.e. that 298 the epoch E is set to the time equivalent to the RTP Timestamp as 299 detailed above in Section 6. 301 6.1.2. Processor profile document 303 The required syntax and semantics declared in the minimal TTML2 304 processor profile in Figure 3 MUST be supported by the receiver, as 305 signified by those "feature" or "extension" elements whose "value" 306 attribute is set to "required". 308 309 315 316 317 318 This document is a minimal TTML2 processor profile 319 definition document intended to express the 320 minimal requirements of a TTML processor able to 321 process TTML delivered over RTP according to 322 RFC XXXX. 323 324 325 #timeBase-media 326 327 #profile-full-version-2 328 329 330 331 332 #rtp-relative-media-time 333 334 335 337 Figure 3: TTML2 Processor Profile Definition for Processing 338 Documents Carried Over RTP 340 Note that this requirement does not imply that the receiver needs to 341 support either TTML1 or TTML2 profile processing, i.e. the TTML2 342 "#profile-full-version-2" feature or any of its dependent features. 344 6.1.3. Processor profile signalling 346 The "codecs" media type parameter MUST specify at least one processor 347 profile. Short codes for TTML profiles are registered at 348 [TTML-MTPR]. The processor profiles specified in "codecs" MUST be 349 compatible with the processor profile specified in this document. 350 Where multiple options exist in "codecs" for possible processor 351 profile combinations (i.e. separated by "|" operator), every 352 permitted option MUST be compatible with the processor profile 353 specified in this document. Where processor profiles other than the 354 one specified in this document are advertised in the "codecs" 355 parameter, the requirements of the processor profile specified in 356 this document MAY be signalled additionally using the "+" operator 357 with its registered short code. 359 A processor profile (X) is compatible with the processor profile 360 specified here (P) if X includes all the features and extensions in 361 P, identified by their character content, and the "value" attribute 362 of each is at least as restrictive as the "value" attribute of the 363 feature or extension in P that has the same character content. The 364 term "restrictive" here is as defined in [TTML2] Section 6. 366 7. Payload Examples 368 Figure 4 is an example of a valid TTML document that may be carried 369 using the payload format described in this document. 371 372 379 380 381 Timed Text TTML Example 382 The Authors (c) 2006 383 384 385 388