draft-ietf-payload-rtp-ttml-04.txt   draft-ietf-payload-rtp-ttml-05.txt 
A/V Transport Payloads Workgroup J. Sandford A/V Transport Payloads Workgroup J. Sandford
Internet-Draft British Broadcasting Corporation Internet-Draft British Broadcasting Corporation
Intended status: Standards Track 25 October 2019 Intended status: Standards Track 29 October 2019
Expires: 27 April 2020 Expires: 1 May 2020
RTP Payload for TTML Timed Text RTP Payload for TTML Timed Text
draft-ietf-payload-rtp-ttml-04 draft-ietf-payload-rtp-ttml-05
Abstract Abstract
This memo describes a Real-time Transport Protocol (RTP) payload This memo describes a Real-time Transport Protocol (RTP) payload
format for TTML, an XML based timed text format for live and file format for TTML, an XML based timed text format for live and file
based workflows from W3C. This payload format is specifically based workflows from W3C. This payload format is specifically
targeted at live workflows using TTML. targeted at live workflows using TTML.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 24 skipping to change at page 2, line 24
4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . 5
5. Payload content restrictions . . . . . . . . . . . . . . . . 5 5. Payload content restrictions . . . . . . . . . . . . . . . . 5
6. Payload processing requirements . . . . . . . . . . . . . . . 6 6. Payload processing requirements . . . . . . . . . . . . . . . 6
6.1. TTML Processor profile . . . . . . . . . . . . . . . . . 7 6.1. TTML Processor profile . . . . . . . . . . . . . . . . . 7
6.1.1. Feature extension designation . . . . . . . . . . . . 7 6.1.1. Feature extension designation . . . . . . . . . . . . 7
6.1.2. Processor profile document . . . . . . . . . . . . . 7 6.1.2. Processor profile document . . . . . . . . . . . . . 7
6.1.3. Processor profile signalling . . . . . . . . . . . . 8 6.1.3. Processor profile signalling . . . . . . . . . . . . 8
7. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 9 7. Payload Examples . . . . . . . . . . . . . . . . . . . . . . 9
8. Fragmentation of TTML Documents . . . . . . . . . . . . . . . 11 8. Fragmentation of TTML Documents . . . . . . . . . . . . . . . 11
9. Protection Against Loss of Data . . . . . . . . . . . . . . . 11 9. Protection Against Loss of Data . . . . . . . . . . . . . . . 11
10. Congestion Control Considerations . . . . . . . . . . . . . . 11 10. Congestion Control Considerations . . . . . . . . . . . . . . 12
11. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12 11. Payload Format Parameters . . . . . . . . . . . . . . . . . . 12
11.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 12
11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 12 11.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 12
11.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 13 11.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 13
11.3. Offer/Answer Considerations . . . . . . . . . . . . . . 13 11.3. Offer/Answer Considerations . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Security Considerations . . . . . . . . . . . . . . . . . . . 13 13. Security Considerations . . . . . . . . . . . . . . . . . . . 13
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
15. Normative References . . . . . . . . . . . . . . . . . . . . 14 15. Normative References . . . . . . . . . . . . . . . . . . . . 15
16. Informative References . . . . . . . . . . . . . . . . . . . 16 16. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 17 Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
TTML (Timed Text Markup Language)[TTML2] is a media type for TTML (Timed Text Markup Language)[TTML2] is a media type for
describing timed text such as closed captions and subtitles in describing timed text such as closed captions and subtitles in
television workflows or broadcasts as XML. This document specifies television workflows or broadcasts as XML. This document specifies
how TTML should be mapped into an RTP stream in live workflows how TTML should be mapped into an RTP stream in live workflows
skipping to change at page 6, line 36 skipping to change at page 6, line 36
Figure 2: TTML2 Content Profile Definition for Documents Carried Figure 2: TTML2 Content Profile Definition for Documents Carried
Over RTP Over RTP
6. Payload processing requirements 6. Payload processing requirements
This section defines constraints on the processing of the TTML This section defines constraints on the processing of the TTML
documents carried over RTP. documents carried over RTP.
If a TTML document is assessed to be invalid then it MUST be If a TTML document is assessed to be invalid then it MUST be
discarded. When processing a valid document, the following discarded. This includes empty documents, i.e. those of zero length.
requirements apply. When processing a valid document, the following requirements apply.
Each TTML document becomes active at its epoch E. E MUST be set to 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 the RTP Timestamp in the header of the RTP packet carrying the TTML
document. Computed TTML media times are offset relative to E in document. Computed TTML media times are offset relative to E in
accordance with Section I.2 of [TTML2]. accordance with Section I.2 of [TTML2].
When processing a sequence of TTML documents each delivered in the When processing a sequence of TTML documents each delivered in the
same RTP stream, exactly zero or one document SHALL be considered 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 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 document D_(n-1) with E_(n-1) is active, and document D_(n) is
skipping to change at page 11, line 26 skipping to change at page 11, line 26
* Text strings MUST split at character boundaries. This enables * Text strings MUST split at character boundaries. This enables
decoding of partial documents. As a consequence, document decoding of partial documents. As a consequence, document
fragmentation requires knowledge of the UTF-8/UTF-16 encoding fragmentation requires knowledge of the UTF-8/UTF-16 encoding
formats to determine character boundaries. formats to determine character boundaries.
* Document fragments SHOULD be protected against packet losses. * Document fragments SHOULD be protected against packet losses.
More information can be found in Section 9 More information can be found in Section 9
When a document spans more than one RTP packet, the entire document When a document spans more than one RTP packet, the entire document
is obtained by concatenating User Data Words from each contributing is obtained by concatenating User Data Words from each consecutive
packet in ascending order of Sequence Number. 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 9. Protection Against Loss of Data
Consideration must be devoted to keeping loss of documents due to Consideration must be devoted to keeping loss of documents due to
packet loss within acceptable limits. What is deemed acceptable packet loss within acceptable limits. What is deemed acceptable
limits is dependant on the TTML profile(s) used and use case among 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 other things. As such, specific limits are outside the scope of this
document. document.
Documents MAY be sent without additional protection if end-to-end Documents MAY be sent without additional protection if end-to-end
skipping to change at page 12, line 26 skipping to change at page 12, line 34
The default clock rate for TTML over RTP is 1000Hz. The clock rate The default clock rate for TTML over RTP is 1000Hz. The clock rate
SHOULD be included in any advertisements of the RTP stream where SHOULD be included in any advertisements of the RTP stream where
possible. This parameter has not been added to the media type possible. This parameter has not been added to the media type
definition as it is not applicable to TTML usage other than within definition as it is not applicable to TTML usage other than within
RTP streams. In other contexts, timing is defined within the TTML RTP streams. In other contexts, timing is defined within the TTML
document. document.
When choosing a clock rate, implementers should consider what other When choosing a clock rate, implementers should consider what other
media their TTML streams may be used in conjunction with (e.g. video media their TTML streams may be used in conjunction with (e.g. video
or audio). In these situations, it is RECOMMENDED that streams use or audio). In these situations, it is RECOMMENDED that streams use
the same Synchronization Source and Clock Rate as the related media. the same clock source and Clock Rate as the related media. As TTML
As TTML streams may be aperiodic, implementers should also consider streams may be aperiodic, implementers should also consider the
the frequency range over which they expect packets to be sent and the frequency range over which they expect packets to be sent and the
temporal resolution required. temporal resolution required.
11.2. Mapping to SDP 11.2. Mapping to SDP
The mapping of the application/ttml+xml media type and its parameters The mapping of the application/ttml+xml media type and its parameters
[TTML-MTPR] SHALL be done according to Section 3 of [RFC4855]. [TTML-MTPR] SHALL be done according to Section 3 of [RFC4855].
* The type name "application" goes in SDP "m=" as the media name. * The type name "application" goes in SDP "m=" as the media name.
* The media subtype "ttml+xml" goes in SDP "a=rtpmap" as the * The media subtype "ttml+xml" goes in SDP "a=rtpmap" as the
 End of changes. 8 change blocks. 
13 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/