Re: draft submission to IETF for carriage of live TTML in RTP

Hi Mike,

Thanks for the speedy response, comments inline below:

From: Michael Dolan <mike@dolan.tv<mailto:mike@dolan.tv>>
Date: Friday, 18 January 2019 at 10:14
To: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>, Timed Text Working Group <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: RE: draft submission to IETF for carriage of live TTML in RTP

Hi Nigel,

Thanks for calling attention to this.

A bit EBU-TT centric.

[NM] I’m not sure why you think so. It’s generically about TTML, and there’s one small section specific to EBU-TT Live, which as far as I know is the only current specification that introduces live contribution semantics to TTML. The goal is certainly to make something that will work broadly for any profile of TTML that meets the profile requirements; those profile requirements are listed in the document, and the set is very small.

Regarding:  “The media types registry should be updated to make reference to this  document for the application/ttml+xml media type.” And to your comment below: “adopted as a first class media type in SMPTE 2110”.

Can someone elaborate on this thinking and/or what the perceived problem is?  W3C is an IANA-approved registration org for media types, hence its definition in TTML. There is no need for an RFC (except of course to document RTP carriage).  And, what does “first class” mean?  There are no classes of media types that are registered through RFC’s or approved orgs like W3C.

[NM] “First class media type” is not a technical term per se – it’s really a hint about moving away from the “catch-all” idea of using SMPTE 2110-40 which allows for provision of ancillary data; in this case subtitles and captions are media not ancillary data, and I would certainly like to avoid any dependency on 2110-40 for that use case, where possible. Even if one were to insert TTML into that ancillary data, questions about the timing semantics would need to be resolved.

In terms of the perceived problem, I think you’re asking about the use cases. The primary one is the contribution of live subtitle streams from the subtitle author or authoring system to an encoder, i.e. the same use case as the contribution of audio and video streams, but for subtitles and captions. Secondarily there may be infrastructures that play out pre-recorded media to a distribution encoder using the same technology, and that would need to be supported too.

In a broadcast world today, typically live subtitles are provided using a binary data format like CEA608 or Nufor into something that inserts them into the video stream as CEA608 or Teletext. Looking ahead to an IP-based contribution world, we should be able to move away from the constraints that such an architecture imposes.

As I mentioned, this is the first submission, and I expect there will be a good level of scrutiny and some adjustments needed to the document. It’s a start!

Kind regards,

Nigel


Regards,
               Mike

From: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>
Sent: Friday, January 18, 2019 2:02 AM
To: Timed Text Working Group <public-tt@w3.org<mailto:public-tt@w3.org>>
Subject: draft submission to IETF for carriage of live TTML in RTP

All,

this may be of interest: https://datatracker.ietf.org/doc/draft-sandford-payload-rtp-ttml/


This is a draft specification for carriage of live TTML over RTP, intended in the fullness of time to be something that can be adopted as a first class media type in SMPTE 2110.

It has just been submitted by a colleague of mine at BBC R&D and no doubt needs some improvements, but worth reviewing now.

kind regards,

Nigel





----------------------------

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.

---------------------



----------------------------

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.

---------------------