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

Hi Mike,

I just added it to the agenda for tomorrow, to discuss if the right folk are present. We can also consider it for next week's face to face meeting.

Kind regards,

Nigel


From: Michael Dolan <mike@dolan.tv<mailto:mike@dolan.tv>>
Date: Friday, 18 January 2019 at 14:05
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,

Let’s put this on an upcoming TTWG agenda.

Thanks,
               Mike

From: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>
Sent: Friday, January 18, 2019 6:01 AM
To: Michael Dolan <mike@dolan.tv<mailto:mike@dolan.tv>>; 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 Michael,

I don’t understand your point about EBU-TT: that subsection of the document is specifically about considerations that apply if the documents are EBU-TT Live documents. I’d be happy to add sections on any other live contribution profiles of TTML if there is an impact on them, but I’m simply not aware of their existence.

I am not proposing to IANA that we change the controlling document from W3C TTML to this document. If the document were to say that, it would needs to be changed: I completely agree with you on that point. I think the wording you mean is in section 8; that text is not intended to state that this document should be considered the new media type registration, but that the existing media type registration should be updated to reference it. In other words, add something into the TTML Profiles Registry pointing to it. Does that help?

I actually wasn’t proposing collating comments from the TTWG but we certainly could do that. I’d be happy to do so, noting that the submitter is from BBC and so am I, so I’d have to establish that I am submitting as TTWG Chair.

Kind regards,

Nigel



From: Michael Dolan <mike@dolan.tv<mailto:mike@dolan.tv>>
Date: Friday, 18 January 2019 at 12:52
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,

I would prefer to see the EBU-TT text made generic about TTML document properties that require special handling such that other documents that have those properties would apply equally.  EBU-TT could be cited as an example.

I don’t understand your reply to the second point.  Let me be clearer.  I would strongly object to a proposal to IANA to change the controlling document from W3C TTML to this IETF ID/RFC. They would not do it anyway without W3C’s approval (the owner of the registration).  Why do you want to do this?

It’s unclear how that helps the issues in SMPTE 2110, that’s just my curiosity upon which we can opine separately.

Do you want to collect comments from this WG and submit them in aggregate to IETF from the WG, or should we all weigh in individually in IETF? Maybe the former would be more productive and coherent?

               Mike

From: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>
Sent: Friday, January 18, 2019 3:48 AM
To: Michael Dolan <mike@dolan.tv<mailto:mike@dolan.tv>>; 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 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.

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



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

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.

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