draft-ietf-payload-rtp-ttml-00.txt   draft-ietf-payload-rtp-ttml-01.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: Informational March 5, 2019 Intended status: Informational April 25, 2019
Expires: September 6, 2019 Expires: October 27, 2019
RTP Payload for TTML Timed Text RTP Payload for TTML Timed Text
draft-ietf-payload-rtp-ttml-00 draft-ietf-payload-rtp-ttml-01
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 September 6, 2019. This Internet-Draft will expire on October 27, 2019.
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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
7.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Clock Rate . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 10 7.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 10
7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11 7.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 14 Appendix A. RFC Editor Considerations . . . . . . . . . . . . . 14
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
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 (also known as describing timed text such as closed captions (also known as
subtitles) in television workflows or broadcasts as XML. This subtitles) in television workflows or broadcasts as XML. This
document specifies how TTML should be mapped into an RTP stream in document specifies how TTML should be mapped into an RTP stream in
live workflows including, but not restricted to, those described in live workflows including, but not restricted to, those described in
the television broadcast oriented EBU-TT Part 3[TECH3370] the television broadcast oriented EBU-TT Part 3[TECH3370]
specification. This document does not define a media type for TTML specification. This document does not define a media type for TTML
skipping to change at page 4, line 31 skipping to change at page 4, line 31
documents MUST NOT use the same timestamp. Because packets do not documents MUST NOT use the same timestamp. Because packets do not
represent any constant duration, the timestamp cannot be used to represent any constant duration, the timestamp cannot be used to
directly infer packet loss. directly infer packet loss.
Reserved: 16 bits Reserved: 16 bits
These bits are reserved for future use and MUST be set to 0x0. These bits are reserved for future use and MUST be set to 0x0.
Length: 16 bits Length: 16 bits
The length of User Data Words in bytes. The length of User Data Words in bytes.
User Data Words: integer number of words whose length is defined by User Data Words: integer number of data words
the character encoding
User Data Words contains the text of the whole document being User Data Words contains the text of the whole document being
transmitted or a part of the document being transmitted. transmitted or a part of the document being transmitted.
Documents using character encodings where characters are not Documents using character encodings where characters are not
represented by a single byte MUST be serialized in big endian represented by a single byte MUST be serialized in big endian
order, a.k.a. network byte order. When the document spans more order, a.k.a. network byte order. When the document spans more
than one RTP packet, the entire document is obtained by than one RTP packet, the entire document is obtained by
concatenating User Data Words from each contributing packet in concatenating User Data Words from each contributing packet in
ascending order of Sequence Number. ascending order of Sequence Number. Note that the length of data
words will depend on the character encoding used (e.g. 8 bit words
for UTF-8, 16 bit words for UTF-16).
4.2. Payload Data 4.2. Payload Data
Documents carried in User Data Words are encoded in accordance with Documents carried in User Data Words are encoded in accordance with
one of the defined TTML profiles specified in its registry one of the defined TTML profiles specified in its registry
[TTML-MTPR]. These profiles specify the document structure used, [TTML-MTPR]. These profiles specify the document structure used,
systems models, timing, and other considerations. systems models, timing, and other considerations.
Additionally, documents carried over RTP MUST conform to the Additionally, documents carried over RTP MUST conform to the
following profile. following profile.
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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. active at each moment in the RTP time line.
Each TTML document becomes active at E. In the event that a document Each TTML document becomes active at E. In the event that a document
D_(n-1) with E_(n-1) is active, and document D_(n) is delivered with 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) where E_(n-1) < E_(n), processing of D_(n-1) MUST be stopped at
E_(n) and processing of D_(n) MUST begin. E_(n) and processing of D_(n) MUST begin.
When all defined content within a document has ended, i.e. the active When all defined content within a document has ended then processing
intermediate synchronic document contains no content, then processing of the document MAY be stopped. This can be tested by constructing
of the document MAY be stopped. 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.
4.2.1.2.1. TTML Processor profile 4.2.1.2.1. TTML Processor profile
4.2.1.2.1.1. Feature extension designation 4.2.1.2.1.1. Feature extension designation
This specification defines the following TTML feature extension This specification defines the following TTML feature extension
designation: designation:
o urn:ietf:rfc:XXXX#rtp-relative-media-time o urn:ietf:rfc:XXXX#rtp-relative-media-time
skipping to change at page 14, line 38 skipping to change at page 14, line 38
(RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February
2008, <https://www.rfc-editor.org/info/rfc5124>. 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP [RFC7202] Perkins, C. and M. Westerlund, "Securing the RTP
Framework: Why RTP Does Not Mandate a Single Media Framework: Why RTP Does Not Mandate a Single Media
Security Solution", RFC 7202, DOI 10.17487/RFC7202, April Security Solution", RFC 7202, DOI 10.17487/RFC7202, April
2014, <https://www.rfc-editor.org/info/rfc7202>. 2014, <https://www.rfc-editor.org/info/rfc7202>.
Appendix A. RFC Editor Considerations Appendix A. RFC Editor Considerations
*TODO* To be filled Note to RFC Editor: This section may be removed after carrying out
all the instructions of this section.
The namespace "urn:ietf:rfc:XXXX" is to be replaced with the
namespace for this document once it has received an RFC number.
Appendix B. Acknowledgements Appendix B. Acknowledgements
*TODO* Thanks to Nigel Megitt, James Gruessing, Robert Wadge, Andrew Bonney,
James Weaver, John Fletcher, Frans De jong, and Villem Vermost for
their valuable feedback throughout the development of this draft.
Thanks to the W3C Timed Text Working Group and EBU Timed Text working
group for their substantial efforts in developing the timed text
formats this payload format is intended to carry.
Author's Address Author's Address
James Sandford James Sandford
British Broadcasting Corporation British Broadcasting Corporation
Dock House, MediaCityUK Dock House, MediaCityUK
Salford Salford
United Kingdom United Kingdom
Phone: +44 30304 09549 Phone: +44 30304 09549
Email: james.sandford@bbc.co.uk Email: james.sandford@bbc.co.uk
 End of changes. 10 change blocks. 
13 lines changed or deleted 27 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/