idnits 2.17.1 draft-ietf-payload-rtp-ttml-05.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 (29 October 2019) is 1639 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' -- Obsolete informational reference (is this intentional?): RFC 2733 (Obsoleted by RFC 5109) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 7 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 29 October 2019 5 Expires: 1 May 2020 7 RTP Payload for TTML Timed Text 8 draft-ietf-payload-rtp-ttml-05 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 1 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. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 12 71 11.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 13 72 11.3. Offer/Answer Considerations . . . . . . . . . . . . . . 13 73 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 76 15. Normative References . . . . . . . . . . . . . . . . . . . . 15 77 16. Informative References . . . . . . . . . . . . . . . . . . . 16 78 Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 17 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 TTML (Timed Text Markup Language)[TTML2] is a media type for 84 describing timed text such as closed captions and subtitles in 85 television workflows or broadcasts as XML. This document specifies 86 how TTML should be mapped into an RTP stream in live workflows 87 including, but not restricted to, those described in the television 88 broadcast oriented EBU-TT Part 3[TECH3370] specification. This 89 document does not define a media type for TTML but makes use of the 90 existing application/ttml+xml media type [TTML-MTPR]. 92 2. Conventions, Definitions, and Abbreviations 94 Unless otherwise stated, the term "document" refers to the TTML 95 document being transmitted in the payload of the RTP packet(s). 97 The term "word" refers to a data word aligned to a specified number 98 of bits in a computing sense and not to refer to linguistic words 99 that might appear in the transported text. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. Media Format Description 109 3.1. Relation to Other Text Payload Types 111 Prior payload types for text are not suited to the carriage of closed 112 captions in Television Workflows. RFC 4103 for Text Conversation 113 [RFC4103] is intended for low data rate conversation with its own 114 session management and minimal formatting capabilities. RFC 4734 115 Events for Modem, Fax, and Text Telephony Signals [RFC4734] deals in 116 large parts with the control signalling of facsimile and other 117 systems. RFC 4396 for 3rd Generation Partnership Project (3GPP) 118 Timed Text [RFC4396] describes the carriage of a timed text format 119 with much more restricted formatting capabilities than TTML. The 120 lack of an existing format for TTML or generic XML has necessitated 121 the creation of this payload format. 123 3.2. TTML2 125 TTML2 (Timed Text Markup Language, Version 2)[TTML2] is an XML-based 126 markup language for describing textual information with associated 127 timing metadata. One of its primary use cases is the description of 128 subtitles and closed captions. A number of profiles exist that adapt 129 TTML2 for use in specific contexts [TTML-MTPR]. These include both 130 file based and streaming workflows. 132 4. Payload Format 134 In addition to the required RTP headers, the payload contains a 135 section for the TTML document being transmitted (User Data Words), 136 and a field for the Length of that data. Each RTP payload contains 137 one or part of one TTML document. 139 A representation of the payload format for TTML is Figure 1. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 |V=2|P|X| CC |M| PT | Sequence Number | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Timestamp | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Synchronization Source (SSRC) Identifier | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Reserved | Length | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | User Data Words... 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Figure 1: RTP Payload Format for TTML 157 4.1. RTP Header Usage 159 RTP packet header fields SHALL be interpreted as per RFC 3550 160 [RFC3550], with the following specifics: 162 Marker Bit (M): 1 bit The Marker Bit is set to "1" to indicate the 163 last packet of a document. Otherwise set to "0". Note: The first 164 packet might also be the last. 166 Timestamp: 32 bits The RTP Timestamp encodes the epoch of the TTML 167 document in User Data Words. Further detail on its usage may be 168 found in Section 6. The clock frequency used is dependent on the 169 application and is specified in the media type rate parameter as 170 per Section 11.1. Documents spread across multiple packets MUST 171 use the same timestamp but different consecutive Sequence Numbers. 172 Sequential documents MUST NOT use the same timestamp. Because 173 packets do not represent any constant duration, the timestamp 174 cannot be used to directly infer packet loss. 176 Reserved: 16 bits These bits are reserved for future use and MUST be 177 set to 0x0 and ignored at receive. 179 Length: 16 bits The length of User Data Words in bytes. 181 User Data Words: The length of User Data Words MUST match the 182 value specified in the Length field User 183 Data Words contains the text of the whole document being 184 transmitted or a part of the document being transmitted. 185 Documents using character encodings where characters are not 186 represented by a single byte MUST be serialized in big endian 187 order, a.k.a. network byte order. Where a document will not fit 188 within the MTU, it may be fragmented across multiple packets. 189 Further detail on fragmentation may be found in Section 8. 191 4.2. Payload Data 193 TTML documents define a series of changes to text over time. TTML 194 documents carried in User Data Words are encoded in accordance with 195 one or more of the defined TTML profiles specified in the TTML 196 registry [TTML-MTPR]. These profiles specify the document structure 197 used, systems models, timing, and other considerations. TTML 198 profiles may restrict the complexity of the changes and operational 199 requirements may limit the maximum duration of TTML documents by a 200 deployment configuration. Both of these cases are out of scope of 201 this document. 203 Documents carried over RTP MUST conform to the following profile in 204 addition to any others used. 206 5. Payload content restrictions 208 This section defines constraints on the content of TTML documents 209 carried over RTP. 211 Multiple TTML subtitle streams MUST NOT be interleaved in a single 212 RTP stream. 214 The TTML document instance's root "tt" element in the 215 "http://www.w3.org/ns/ttml" namespace MUST include a "timeBase" 216 attribute in the "http://www.w3.org/ns/ttml#parameter" namespace 217 containing the value "media". 219 This is equivalent to the TTML2 content profile definition document 220 in Figure 2. 222 223 229 230 231 232 This document is a minimal TTML2 content profile 233 definition document intended to express the 234 minimal requirements to apply when carrying TTML 235 over RTP. 236 237 238 #timeBase-media 239 #timeBase-smpte 240 #timeBase-clock 241 242 244 Figure 2: TTML2 Content Profile Definition for Documents Carried 245 Over RTP 247 6. Payload processing requirements 249 This section defines constraints on the processing of the TTML 250 documents carried over RTP. 252 If a TTML document is assessed to be invalid then it MUST be 253 discarded. This includes empty documents, i.e. those of zero length. 254 When processing a valid document, the following requirements apply. 256 Each TTML document becomes active at its epoch E. E MUST be set to 257 the RTP Timestamp in the header of the RTP packet carrying the TTML 258 document. Computed TTML media times are offset relative to E in 259 accordance with Section I.2 of [TTML2]. 261 When processing a sequence of TTML documents each delivered in the 262 same RTP stream, exactly zero or one document SHALL be considered 263 active at each moment in the RTP time line. In the event that a 264 document D_(n-1) with E_(n-1) is active, and document D_(n) is 265 delivered with E_(n) where E_(n-1) < E_(n), processing of D_(n-1) 266 MUST be stopped at E_(n) and processing of D_(n) MUST begin. 268 When all defined content within a document has ended then processing 269 of the document MAY be stopped. This can be tested by constructing 270 the intermediate synchronic document sequence from the document, as 271 defined by [TTML2]. If the last intermediate synchronic document in 272 the sequence is both active and contains no region elements, then all 273 defined content within the document has ended. 275 As described above, the RTP Timestamp does not specify the exact 276 timing of the media in this payload format. Additionally, documents 277 may be fragmented across multiple packets. This renders the RTCP 278 jitter calculation unusable. 280 6.1. TTML Processor profile 282 6.1.1. Feature extension designation 284 This specification defines the following TTML feature extension 285 designation: 287 * urn:ietf:rfc:XXXX#rtp-relative-media-time 289 The namespace "urn:ietf:rfc:XXXX" is as defined by [RFC2648]. 291 A TTML content processor supports the "#rtp-relative-media-time" 292 feature extension if it processes media times in accordance with the 293 payload processing requirements specified in this document, i.e. that 294 the epoch E is set to the time equivalent to the RTP Timestamp as 295 detailed above in Section 6. 297 6.1.2. Processor profile document 299 The required syntax and semantics declared in the minimal TTML2 300 processor profile in Figure 3 MUST be supported by the receiver, as 301 signified by those "feature" or "extension" elements whose "value" 302 attribute is set to "required". 304 305 311 312 313 314 This document is a minimal TTML2 processor profile 315 definition document intended to express the 316 minimal requirements of a TTML processor able to 317 process TTML delivered over RTP according to 318 RFC XXXX. 319 320 321 #timeBase-media 322 323 #profile-full-version-2 324 325 326 327 328 #rtp-relative-media-time 329 330 331 333 Figure 3: TTML2 Processor Profile Definition for Processing 334 Documents Carried Over RTP 336 Note that this requirement does not imply that the receiver needs to 337 support either TTML1 or TTML2 profile processing, i.e. the TTML2 338 "#profile-full-version-2" feature or any of its dependent features. 340 6.1.3. Processor profile signalling 342 The "codecs" media type parameter MUST specify at least one processor 343 profile. Short codes for TTML profiles are registered at 344 [TTML-MTPR]. The processor profiles specified in "codecs" MUST be 345 compatible with the processor profile specified in this document. 346 Where multiple options exist in "codecs" for possible processor 347 profile combinations (i.e. separated by "|" operator), every 348 permitted option MUST be compatible with the processor profile 349 specified in this document. Where processor profiles other than the 350 one specified in this document are advertised in the "codecs" 351 parameter, the requirements of the processor profile specified in 352 this document MAY be signalled additionally using the "+" operator 353 with its registered short code. 355 A processor profile (X) is compatible with the processor profile 356 specified here (P) if X includes all the features and extensions in 357 P, identified by their character content, and the "value" attribute 358 of each is at least as restrictive as the "value" attribute of the 359 feature or extension in P that has the same character content. The 360 term "restrictive" here is as defined in [TTML2] Section 6. 362 7. Payload Examples 364 Figure 4 is an example of a valid TTML document that may be carried 365 using the payload format described in this document. 367 368 375 376 377 Timed Text TTML Example 378 The Authors (c) 2006 379 380 381 384