Re: [payload] new draft - RTP Payload for TTML Timed Text

[James Sandford <[e-mail]>]

Hello,
Thank you for your replies.

Kjetil. TTML and its variants (e.g. EBU-TT) do define a number of possible timing methods where absolute times are specified within the document. This has a number of disadvantages in the streaming use case. *There is not necessarily a guarantee that the reference clock used within the document is identical to that in the RTP header. The document could have been originally generated on a different system and a naive implementation could persist the original timestamps/reference clock when packaging the document into an RTP stream.
*The timestamps in the document may end up contradicting that in the RTP header. The replication of data, i.e. timestamps in the RTP header and within the document, feels like poor design that leaves more room for bugs in implementations.
*Unrestricted, timestamps in a document may specify changes in the past. They shouldn't, but there would be nothing to stop them.
*A convention for converting each timing method within the document to each possible reference clock at the RTP level would be required to correctly align closed-captions/subtitles in a TTML stream with other media such as Video. This could potentially increase the complexity of specifications and implementations.
*Where absolute timings are used in the streamed documents, replaying a stream may require re-writing of the timestamps within the payload against the new playout time
*A broadcast center may implement devices such as buffers for aligning, for example, external contributions from different points around the world with vastly differing latencies. Allowing timing to be specified within the document would require TTML specific knowledge to correctly align multiple streams. As the draft currently stands, this alignment/buffering could be done at the RTP level.

Some of these potential issues could of course be solved by senders/receivers "doing the sensible thing". Others cannot. And it would be preferable to reduce the potential for bugs/poor implementations as much as possible. This draft aims to reduce the risk of all of these points by moving the timing to the RTP level while still allowing a level of internal timing that allows, for example, animation of text. We would also like to discourage the implementation of senders which send, for example, an entire program's worth of subtitles in a single document. This would obviously be poor use of RTP.

As the draft is currently written, it will require the sender/reader to have knowledge of the RTP time to correctly calculate the display time of subtitles. Though this would be a requirement wherever TTML is combined with RTP video/audio anyway. Section 4.2.1 specifies a TTML profile that restricts the time base within the TTML document to Media time and defines it as 0-based against the RTP time for each payload. So you are correct, Kjetil, an RTP Timestamp is considered the epoch of its respective TTML document.

I hope this helps.

Regards,
James

==========
James Sandford
R&D Engineer

BBC Research and Development
5th Floor
Dock House
MediaCityUK
Salford
M50 2LH

Tel: 030304 (09549)
Web: http://www.bbc.co.uk/rd

________________________________________
From: Thomas Edwards [[e-mail]]
Sent: 17 January 2019 19:12
To: Kjetil Oftedal; James Sandford
Cc: [e-mail]
Subject: Re: [payload] new draft - RTP Payload for TTML Timed Text

I'm not sure what the author was thinking, but I'd think that in many cases, a TTML RTP flow would be often associated with another RTP media flow (such as RFC 4175/SMPTE ST 2110-20, AES67, etc.) and hopefully the RTP timestamp time would line up...

In RFC 8331 (RTP for SMPTE Ancillary Data), it was suggested they were tightly locked together:
"When an ANC data RTP stream is to be associated with an RTP
         video stream, the RTP timestamp rates SHOULD be the same to
         ensure that ANC data packets can be associated with the
         appropriate frame or field.  Otherwise, a 90 kHz rate SHOULD be
         used."

But that might be less appropriate for TTML which is less directly associated with video fields/frames.

-Thomas

On 1/17/19, 10:53 AM, "payload on behalf of Kjetil Oftedal" <[e-mail] on behalf of [e-mail]> wrote:

    On 17/01/2019, James Sandford <[e-mail]> wrote:
    > I have uploaded a draft specifying an RTP payload format for TTML Timed Text
    > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dsandford-2Dpayload-2Drtp-2Dttml_&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=lcOWqoAOZng6eG5ibGyA-k5wqdyjNwxcOsa251X-eLg&s=eGgyZQYCqKg2ArgO0aFCaNFoX8fZTyL7cOP55goWDY4&e=
    >

    Hi,

    Can you please elaborate a bit on the RTP Timestamping requirements
    outlined here?
    As far as I can see TTML already specifies the timing of the text in
    relation to some epoch.
    Will the processing of the RTP packet require the receiver/sender to
    rewrite the timing data in TTML-information in relation to the RTP
    timestamp? Or written another way: Is the RTP Timestamp considered the
    epoch of the TTML document?

    Best regards,
    Kjetil Oftedal

    _______________________________________________
    payload mailing list
    [e-mail]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_payload&d=DwICAg&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=lcOWqoAOZng6eG5ibGyA-k5wqdyjNwxcOsa251X-eLg&s=tiBjx73Dw6-x1Yj7MlpvB_bNw67I5UVkduJQHa8xwDA&e=




-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------