From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8759.txt | 743 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 743 insertions(+) create mode 100644 doc/rfc/rfc8759.txt (limited to 'doc/rfc/rfc8759.txt') diff --git a/doc/rfc/rfc8759.txt b/doc/rfc/rfc8759.txt new file mode 100644 index 0000000..0f4001c --- /dev/null +++ b/doc/rfc/rfc8759.txt @@ -0,0 +1,743 @@ + + + + +Internet Engineering Task Force (IETF) J. Sandford +Request for Comments: 8759 British Broadcasting Corporation +Category: Standards Track March 2020 +ISSN: 2070-1721 + + + RTP Payload for Timed Text Markup Language (TTML) + +Abstract + + This memo describes a Real-time Transport Protocol (RTP) payload + format for Timed Text Markup Language (TTML), an XML-based timed text + format from W3C. This payload format is specifically targeted at + streaming workflows using TTML. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8759. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 2. Conventions and Definitions + 3. Media Format Description + 3.1. Relation to Other Text Payload Types + 3.2. TTML2 + 4. Payload Format + 4.1. RTP Header Usage + 4.2. Payload Data + 5. Payload Content Restrictions + 6. Payload Processing Requirements + 6.1. TTML Processor Profile + 6.1.1. Feature Extension Designation + 6.1.2. Processor Profile Document + 6.1.3. Processor Profile Signalling + 7. Payload Examples + 8. Fragmentation of TTML Documents + 9. Protection against Loss of Data + 10. Congestion Control Considerations + 11. Payload Format Parameters + 11.1. Clock Rate + 11.2. Session Description Protocol (SDP) Considerations + 11.2.1. Examples + 12. IANA Considerations + 13. Security Considerations + 14. Normative References + 15. Informative References + Acknowledgements + Author's Address + +1. Introduction + + TTML (Timed Text Markup Language) [TTML2] is a media type for + describing timed text, such as closed captions and subtitles in + television workflows or broadcasts, as XML. This document specifies + how TTML should be mapped into an RTP stream in streaming workflows, + including (but not restricted to) those described in the television- + broadcast-oriented European Broadcasting Union Timed Text (EBU-TT) + Part 3 [TECH3370] specification. This document does not define a + media type for TTML but makes use of the existing application/ + ttml+xml media type [TTML-MTPR]. + +2. Conventions and Definitions + + Unless otherwise stated, the term "document" refers to the TTML + document being transmitted in the payload of the RTP packet(s). + + The term "word" refers to a data word aligned to a specified number + of bits in a computing sense and not to linguistic words that might + appear in the transported text. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Media Format Description + +3.1. Relation to Other Text Payload Types + + Prior payload types for text are not suited to the carriage of closed + captions in television workflows. "RTP Payload for Text + Conversation" [RFC4103] is intended for low data rate conversation + with its own session management and minimal formatting capabilities. + "Definition of Events for Modem, Fax, and Text Telephony Signals" + [RFC4734] deals in large parts with the control signalling of + facsimile and other systems. "RTP Payload Format for 3rd Generation + Partnership Project (3GPP) Timed Text" [RFC4396] describes the + carriage of a timed text format with much more restricted formatting + capabilities than TTML. The lack of an existing format for TTML or + generic XML has necessitated the creation of this payload format. + +3.2. TTML2 + + TTML2 (Timed Text Markup Language, Version 2) [TTML2] is an XML-based + markup language for describing textual information with associated + timing metadata. One of its primary use cases is the description of + subtitles and closed captions. A number of profiles exist that adapt + TTML2 for use in specific contexts [TTML-MTPR]. These include both + file-based and streaming workflows. + +4. Payload Format + + In addition to the required RTP headers, the payload contains a + section for the TTML document being transmitted (User Data Words) and + a field for the length of that data. Each RTP payload contains one + or part of one TTML document. + + A representation of the payload format for TTML is Figure 1. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |V=2|P|X| CC |M| PT | Sequence Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Synchronization Source (SSRC) Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | User Data Words... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: RTP Payload Format for TTML + +4.1. RTP Header Usage + + RTP packet header fields SHALL be interpreted, as per [RFC3550], with + the following specifics: + + Marker Bit (M): 1 bit + The marker bit is set to "1" to indicate the last packet of a + document. Otherwise, set to "0". Note: The first packet might + also be the last. + + Timestamp: 32 bits + The RTP Timestamp encodes the epoch of the TTML document in User + Data Words. Further detail on its usage may be found in + Section 6. The clock frequency used is dependent on the + application and is specified in the media type rate parameter, as + per Section 11.1. Documents spread across multiple packets MUST + use the same timestamp but different consecutive Sequence Numbers. + Sequential documents MUST NOT use the same timestamp. Because + packets do not represent any constant duration, the timestamp + cannot be used to directly infer packet loss. + + Reserved: 16 bits + These bits are reserved for future use and MUST be set to 0x0 and + ignored upon reception. + + Length: 16 bits + The length of User Data Words in bytes. + + User Data Words: The length of User Data Words MUST match the + value specified in the Length field + The User Data Words section contains the text of the whole + document being transmitted or a part of the document being + transmitted. Documents using character encodings where characters + are not represented by a single byte MUST be serialised in big- + endian order, a.k.a., network byte order. Where a document will + not fit within the Path MTU, it may be fragmented across multiple + packets. Further detail on fragmentation may be found in + Section 8. + +4.2. Payload Data + + TTML documents define a series of changes to text over time. TTML + documents carried in User Data Words are encoded in accordance with + one or more of the defined TTML profiles specified in the TTML + registry [TTML-MTPR]. These profiles specify the document structure + used, systems models, timing, and other considerations. TTML + profiles may restrict the complexity of the changes, and operational + requirements may limit the maximum duration of TTML documents by a + deployment configuration. Both of these cases are out of scope of + this document. + + Documents carried over RTP MUST conform to the following profile, in + addition to any others used. + +5. Payload Content Restrictions + + This section defines constraints on the content of TTML documents + carried over RTP. + + Multiple TTML subtitle streams MUST NOT be interleaved in a single + RTP stream. + + The TTML document instance's root "tt" element in the + "http://www.w3.org/ns/ttml" namespace MUST include a "timeBase" + attribute in the "http://www.w3.org/ns/ttml#parameter" namespace + containing the value "media". + + This is equivalent to the TTML2 content profile definition document + in Figure 2. + + + + + + + This document is a minimal TTML2 content profile + definition document intended to express the + minimal requirements to apply when carrying TTML + over RTP. + + + #timeBase-media + #timeBase-smpte + #timeBase-clock + + + + Figure 2: TTML2 Content Profile Definition for Documents Carried + over RTP + +6. Payload Processing Requirements + + This section defines constraints on the processing of the TTML + documents carried over RTP. + + If a TTML document is assessed to be invalid, then it MUST be + discarded. This includes empty documents, i.e., those of zero + length. When processing a valid document, the following requirements + apply. + + Each TTML document becomes active at its epoch E. E MUST be set to + the RTP Timestamp in the header of the RTP packet carrying the TTML + document. Computed TTML media times are offset relative to E, in + accordance with Section I.2 of [TTML2]. + + When processing a sequence of TTML documents, where each is delivered + in the same RTP stream, exactly zero or one document SHALL be + considered active at each moment in the RTP time line. In the event + that a document D_(n-1) with E_(n-1) is active, and document D_(n) is + delivered with E_(n) where E_(n-1) < E_(n), processing of D_(n-1) + MUST be stopped at E_(n) and processing of D_(n) MUST begin. + + When all defined content within a document has ended, then processing + of the document MAY be stopped. This can be tested by constructing + the intermediate synchronic document sequence from the document, as + defined by [TTML2]. If the last intermediate synchronic document in + the sequence is both active and contains no region elements, then all + defined content within the document has ended. + + As described above, the RTP Timestamp does not specify the exact + timing of the media in this payload format. Additionally, documents + may be fragmented across multiple packets. This renders the RTCP + jitter calculation unusable. + +6.1. TTML Processor Profile + +6.1.1. Feature Extension Designation + + This specification defines the following TTML feature extension + designation: + + "urn:ietf:rfc:8759#rtp-relative-media-time" + + The namespace "urn:ietf:rfc:8759" is as defined by [RFC2648]. + + A TTML content processor supports the "#rtp-relative-media-time" + feature extension if it processes media times in accordance with the + payload processing requirements specified in this document, i.e., + that the epoch E is set to the time equivalent to the RTP Timestamp, + as detailed above in Section 6. + +6.1.2. Processor Profile Document + + The required syntax and semantics declared in the minimal TTML2 + processor profile in Figure 3 MUST be supported by the receiver, as + signified by those "feature" or "extension" elements whose "value" + attribute is set to "required". + + + + + + + This document is a minimal TTML2 processor profile + definition document intended to express the + minimal requirements of a TTML processor able to + process TTML delivered over RTP according to + RFC 8759. + + + #timeBase-media + + #profile-full-version-2 + + + + + #rtp-relative-media-time + + + + + Figure 3: TTML2 Processor Profile Definition for Processing + Documents Carried over RTP + + Note that this requirement does not imply that the receiver needs to + support either TTML1 or TTML2 profile processing, i.e., the TTML2 + "#profile-full-version-2" feature or any of its dependent features. + +6.1.3. Processor Profile Signalling + + The "codecs" media type parameter MUST specify at least one processor + profile. Short codes for TTML profiles are registered at + [TTML-MTPR]. The processor profiles specified in "codecs" MUST be + compatible with the processor profile specified in this document. + Where multiple options exist in "codecs" for possible processor + profile combinations (i.e., separated by "|" operator), every + permitted option MUST be compatible with the processor profile + specified in this document. Where processor profiles (other than the + one specified in this document) are advertised in the "codecs" + parameter, the requirements of the processor profile specified in + this document MAY be signalled, additionally using the "+" operator + with its registered short code. + + A processor profile (X) is compatible with the processor profile + specified here (P) if X includes all the features and extensions in P + (identified by their character content) and the "value" attribute of + each is, at least, as restrictive as the "value" attribute of the + feature or extension in P that has the same character content. The + term "restrictive" here is as defined in Section 6 of [TTML2]. + +7. Payload Examples + + Figure 4 is an example of a valid TTML document that may be carried + using the payload format described in this document. + + + + + + Timed Text TTML Example + The Authors (c) 2006 + + + +