idnits 2.17.1 draft-ietf-payload-rtp-ttml-02.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 (June 11, 2019) is 1774 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 June 11, 2019 5 Expires: December 13, 2019 7 RTP Payload for TTML Timed Text 8 draft-ietf-payload-rtp-ttml-02 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 December 13, 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 3.2. TTML2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . 5 59 4.2.1. TTML Profile for RTP Carriage . . . . . . . . . . . . 5 60 5. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 9 61 6. Congestion Control Considerations . . . . . . . . . . . . . . 10 62 7. Payload Format Parameters . . . . . . . . . . . . . . . . . . 11 63 7.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 11 64 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 11 65 7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 12 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 11.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 16 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 TTML (Timed Text Markup Language)[TTML2] is a media type for 78 describing timed text such as closed captions (also known as 79 subtitles) in television workflows or broadcasts as XML. This 80 document specifies how TTML should be mapped into an RTP stream in 81 live workflows including, but not restricted to, those described in 82 the television broadcast oriented EBU-TT Part 3[TECH3370] 83 specification. This document does not define a media type for TTML 84 but makes use of the existing application/ttml+xml media type 85 [TTML-MTPR]. 87 2. Conventions, Definitions, and Abbreviations 89 Unless otherwise stated, the term "document" is used in this draft to 90 refer to the TTML document being transmitted in the payload of the 91 RTP packet(s). 93 Where the term "word" is used in this draft, it is to refer to byte 94 aligned or 32-bit aligned words of data in a computing sense and not 95 to refer to linguistic words that might appear in the transported 96 text. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in BCP14 [RFC2119] 101 [RFC8174] when, and only when, they appear in all capitals, as shown 102 here. 104 3. Media Format Description 106 3.1. Relation to Other Text Payload Types 108 Prior payload types for text are not suited to the carriage of closed 109 captions in Television Workflows. RFC 4103 for Text Conversation 110 [RFC4103] is intended for low data rate conversation with its own 111 session management and minimal formatting capabilities. RFC 4734 112 Events for Modem, Fax, and Text Telephony Signals [RFC4734] deals in 113 large parts with the control signalling of facsimile and other 114 systems. RFC 4396 for 3rd Generation Partnership Project (3GPP) 115 Timed Text [RFC4396] describes the carriage of a timed text format 116 with much more restricted formatting capabilities than TTML. The 117 lack of an existing format for TTML or generic XML has necessitated 118 the creation of this payload format. 120 3.2. TTML2 122 TTML2 (Timed Text Markup Language, Version 2)[TTML2] is an XML-based 123 markup language for describing textual information with associated 124 timing metadata. One of its primary use cases is the description of 125 subtitles and closed captions. A number of profiles exist that adapt 126 TTML2 for use in specific contexts [TTML-MTPR]. These include both 127 file based and streaming workflows. 129 4. Payload Format 131 In addition to the required RTP headers, the payload contains a 132 section for the TTML document being transmitted (User Data Words), 133 and a field for the Length of that data. Each RTP payload contains 134 one or part of one TTML document. 136 A representation of the payload format for TTML is Figure 1. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 |V=2|P|X| CC |M| PT | Sequence Number | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Timestamp | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Synchronization Source (SSRC) Identifier | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Reserved | Length | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | User Data Words... 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 Figure 1: RTP Payload Format for TTML 154 4.1. RTP Header Usage 156 RTP packet header fields SHALL be interpreted as per RFC 3550 157 [RFC3550], with the following specifics: 159 Marker Bit (M): 1 bit 160 The Marker Bit is set to "1" to indicate the last packet of a 161 document. Otherwise set to "0". Note: The first packet might 162 also be the last. 164 Timestamp: 32 bits 165 The RTP Timestamp encodes the time of the text in the packet. The 166 clock frequency used is dependent on the application and is 167 specified in the media type rate parameter as per Section 7.1. 168 Documents spread across multiple packets MUST use the same 169 timestamp but different consecutive Sequence Numbers. Sequential 170 documents MUST NOT use the same timestamp. Because packets do not 171 represent any constant duration, the timestamp cannot be used to 172 directly infer packet loss. 174 Reserved: 16 bits 175 These bits are reserved for future use and MUST be set to 0x0. 177 Length: 16 bits 178 The length of User Data Words in bytes. 180 User Data Words: integer number of data words 181 User Data Words contains the text of the whole document being 182 transmitted or a part of the document being transmitted. 183 Documents using character encodings where characters are not 184 represented by a single byte MUST be serialized in big endian 185 order, a.k.a. network byte order. When the document spans more 186 than one RTP packet, the entire document is obtained by 187 concatenating User Data Words from each contributing packet in 188 ascending order of Sequence Number. Note that the length of data 189 words will depend on the character encoding used (e.g. 8 bit words 190 for UTF-8, 16 bit words for UTF-16). 192 4.2. Payload Data 194 Documents carried in User Data Words are encoded in accordance with 195 one of the defined TTML profiles specified in its registry 196 [TTML-MTPR]. These profiles specify the document structure used, 197 systems models, timing, and other considerations. 199 Additionally, documents carried over RTP MUST conform to the 200 following profile. 202 4.2.1. TTML Profile for RTP Carriage 204 This section defines constraints on the content and processing of the 205 TTML payload for RTP carriage. 207 4.2.1.1. Payload content restrictions 209 Multiple TTML subtitle streams MUST NOT be interleaved in a single 210 RTP stream. 212 The TTML document instance MUST use the "media" value of the 213 "ttp:timeBase" parameter attribute on the root element. 215 This is equivalent to the following TTML2 content profile definition 216 document: 218 219 225 226 227 228 This document is a minimal TTML2 content profile 229 definition document intended to express the minimal 230 requirements to apply when carrying TTML over RTP. 231 232 233 #timeBase-media 234 #timeBase-smpte 235 #timeBase-clock 236 237 239 4.2.1.2. Payload processing requirements 241 If the TTML document payload is assessed to be invalid then it MUST 242 be discarded. When processing a valid document, the following 243 requirements apply. 245 Each TTML document becomes active at the epoch E. E MUST be set to 246 the RTP Timestamp in the header of the RTP packet carrying the TTML 247 document. Computed TTML media times are offset relative to E. 249 When processing a sequence of TTML documents each delivered in the 250 same RTP stream, exactly zero or one document SHALL be considered 251 active at each moment in the RTP time line. In the event that a 252 document D_(n-1) with E_(n-1) is active, and document D_(n) is 253 delivered with E_(n) where E_(n-1) < E_(n), processing of D_(n-1) 254 MUST be stopped at E_(n) and processing of D_(n) MUST begin. 256 When all defined content within a document has ended then processing 257 of the document MAY be stopped. This can be tested by constructing 258 the intermediate synchronic document sequence from the document, as 259 defined by TTML2. If the last intermediate synchronic document in 260 the sequence is both active and contains no region elements, then all 261 defined content within the document has ended. 263 4.2.1.2.1. TTML Processor profile 265 4.2.1.2.1.1. Feature extension designation 267 This specification defines the following TTML feature extension 268 designation: 270 o urn:ietf:rfc:XXXX#rtp-relative-media-time 272 The namespace "urn:ietf:rfc:XXXX" is as defined by [RFC2648]. 274 A TTML content processor supports the "#rtp-relative-media-time" 275 feature extension if it processes media times in accordance with the 276 payload processing requirements specified in this document, i.e. that 277 the epoch E is set to the time equivalent to the RTP Timestamp as 278 detailed above in Section 4.2.1.2. 280 4.2.1.2.1.2. Processor profile document 282 The required syntax and semantics declared in the following minimal 283 TTML2 processor profile MUST be supported by the receiver, as 284 signified by those "feature" or "extension" elements whose "value" 285 attribute is set to "required": 287 288 294 295 296 297 This document is a minimal TTML2 processor profile 298 definition document intended to express the minimal 299 requirements of a TTML processor able to process TTML 300 delivered over RTP according to RFC XXXX. 301 302 303 #timeBase-media 304 #profile-full-version-2 305 306 307 308 #rtp-relative-media-time 309 310 311 313 Note that this requirement does not imply that the receiver needs to 314 support either TTML1 or TTML2 profile processing, i.e. the TTML2 315 "#profile-full-version-2" feature or any of its dependent features. 317 4.2.1.2.1.3. Processor profile signalling 319 The "codecs" media type parameter MUST specify at least one processor 320 profile. Short codes for TTML profiles are registered at 321 [TTML-MTPR]. The processor profiles specified in "codecs" MUST be 322 compatible with the processor profile specified in this document. 323 Where multiple options exist in "codecs" for possible processor 324 profile combinations (i.e. separated by "|" operator), every 325 permitted option MUST be compatible with the processor profile 326 specified in this document. Where processor profiles other than the 327 one specified in this document are advertised in the "codecs" 328 parameter, the requirements of the processor profile specified in 329 this document MAY be signalled additionally using the "+" operator 330 with its registered short code. 332 A processor profile (X) is compatible with the processor profile in 333 this document (P) if X includes all the features and extensions in P, 334 identified by their character content, and the "value" attribute of 335 each is at least as restrictive as the "value" attribute of the 336 feature or extension in P that has the same character content. The 337 term "restrictive" here is as defined in [TTML2] Section 6. 339 5. Payload Examples 341 The following is an example of a valid TTML document that may be 342 carried using the payload format described in this document: 344 345 352 353 354 Timed Text TTML Example 355 The Authors (c) 2006 356 357 358 359