--- 1/draft-ietf-payload-rtp-ttml-04.txt 2019-10-29 08:13:13.094199298 -0700 +++ 2/draft-ietf-payload-rtp-ttml-05.txt 2019-10-29 08:13:13.134200309 -0700 @@ -1,18 +1,18 @@ A/V Transport Payloads Workgroup J. Sandford Internet-Draft British Broadcasting Corporation -Intended status: Standards Track 25 October 2019 -Expires: 27 April 2020 +Intended status: Standards Track 29 October 2019 +Expires: 1 May 2020 RTP Payload for TTML Timed Text - draft-ietf-payload-rtp-ttml-04 + draft-ietf-payload-rtp-ttml-05 Abstract This memo describes a Real-time Transport Protocol (RTP) payload format for TTML, an XML based timed text format for live and file based workflows from W3C. This payload format is specifically targeted at live workflows using TTML. Status of This Memo @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 27 April 2020. + This Internet-Draft will expire on 1 May 2020. Copyright Notice Copyright (c) 2019 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 @@ -57,30 +57,30 @@ 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . 5 5. Payload content restrictions . . . . . . . . . . . . . . . . 5 6. Payload processing requirements . . . . . . . . . . . . . . . 6 6.1. TTML Processor profile . . . . . . . . . . . . . . . . . 7 6.1.1. Feature extension designation . . . . . . . . . . . . 7 6.1.2. Processor profile document . . . . . . . . . . . . . 7 6.1.3. Processor profile signalling . . . . . . . . . . . . 8 7. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 9 8. Fragmentation of TTML Documents . . . . . . . . . . . . . . . 11 9. Protection Against Loss of Data . . . . . . . . . . . . . . . 11 - 10. Congestion Control Considerations . . . . . . . . . . . . . . 11 + 10. Congestion Control Considerations . . . . . . . . . . . . . . 12 11. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12 11.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 12 11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 12 11.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 13 11.3. Offer/Answer Considerations . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 - 15. Normative References . . . . . . . . . . . . . . . . . . . . 14 + 15. Normative References . . . . . . . . . . . . . . . . . . . . 15 16. Informative References . . . . . . . . . . . . . . . . . . . 16 Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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 live workflows @@ -243,22 +243,22 @@ 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. When processing a valid document, the following - requirements apply. + 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 each 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 @@ -423,22 +423,30 @@ * Text strings MUST split at character boundaries. This enables decoding of partial documents. As a consequence, document fragmentation requires knowledge of the UTF-8/UTF-16 encoding formats to determine character boundaries. * Document fragments SHOULD be protected against packet losses. More information can be found in Section 9 When a document spans more than one RTP packet, the entire document - is obtained by concatenating User Data Words from each contributing - packet in ascending order of Sequence Number. + is obtained by concatenating User Data Words from each consecutive + contributing packet in ascending order of Sequence Number. + + As described in Section 6, only zero or one TTML document may be + active at any point in time. As such, there MUST only be one + document transmitted for a given RTP Timestamp. Furthermore, as + stated in Section 4.1, the Marker Bit MUST be set for a packet + containing the last fragment of a document. A packet following one + where the Marker Bit is set contains the first fragment of a new + document. The first fragment might also be the last. 9. Protection Against Loss of Data Consideration must be devoted to keeping loss of documents due to packet loss within acceptable limits. What is deemed acceptable limits is dependant on the TTML profile(s) used and use case among other things. As such, specific limits are outside the scope of this document. Documents MAY be sent without additional protection if end-to-end @@ -472,23 +479,23 @@ The default clock rate for TTML over RTP is 1000Hz. The clock rate SHOULD be included in any advertisements of the RTP stream where possible. This parameter has not been added to the media type definition as it is not applicable to TTML usage other than within RTP streams. In other contexts, timing is defined within the TTML document. When choosing a clock rate, implementers should consider what other media their TTML streams may be used in conjunction with (e.g. video or audio). In these situations, it is RECOMMENDED that streams use - the same Synchronization Source and Clock Rate as the related media. - As TTML streams may be aperiodic, implementers should also consider - the frequency range over which they expect packets to be sent and the + the same clock source and Clock Rate as the related media. As TTML + streams may be aperiodic, implementers should also consider the + frequency range over which they expect packets to be sent and the temporal resolution required. 11.2. Mapping to SDP The mapping of the application/ttml+xml media type and its parameters [TTML-MTPR] SHALL be done according to Section 3 of [RFC4855]. * The type name "application" goes in SDP "m=" as the media name. * The media subtype "ttml+xml" goes in SDP "a=rtpmap" as the