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

James Sandford <james.sandford@bbc.co.uk> Wed, 13 February 2019 09:25 UTC

Return-Path: <james.sandford@bbc.co.uk>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C44130E74 for <payload@ietfa.amsl.com>; Wed, 13 Feb 2019 01:25:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbdS0BNMfN5V for <payload@ietfa.amsl.com>; Wed, 13 Feb 2019 01:25:08 -0800 (PST)
Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2903C130E6E for <payload@ietf.org>; Wed, 13 Feb 2019 01:25:07 -0800 (PST)
Received: from BGB01XI1001.national.core.bbc.co.uk ([10.184.50.51]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id x1D9Oams001544; Wed, 13 Feb 2019 09:24:36 GMT
Received: from BGB01XUD1001.national.core.bbc.co.uk ([10.184.52.80]) by BGB01XI1001.national.core.bbc.co.uk ([10.184.50.51]) with mapi id 14.03.0408.000; Wed, 13 Feb 2019 09:24:35 +0000
From: James Sandford <james.sandford@bbc.co.uk>
To: "Roni Even (A)" <roni.even@huawei.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] new draft - RTP Payload for TTML Timed Text
Thread-Index: AQHUww3IJnvrFU1bhEuuuCEhNcSFAKXddXxV
Date: Wed, 13 Feb 2019 09:24:35 +0000
Message-ID: <734752AF0E88364D983373FE5CEFED57594B9E61@bgb01xud1001>
References: <D88741E9.3CBE0%nigel.megitt@bbc.co.uk>, <6E58094ECC8D8344914996DAD28F1CCD18CB3E04@dggemm526-mbx.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18CB3E04@dggemm526-mbx.china.huawei.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.212]
x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769
x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-24052.007
x-tm-as-result: No-22.202200-8.000000-10
x-tmase-matchedrid: TxtdI7DxMqo7iuZ/mdYYtndysr7mPnqL6kOL/MSUCvdfz3eqPsVF7tKD F5sBjuJXqb8bt5iwUztYKMMlFh4BnYWdLRedvR18Hp6T0pXs+wOY2spSGP3t2KduVYQZj4GSDzu eAsqJuiuUocUWkvA59bqQyAveNtg60zEP/d7xPF1G2qlFbyxbItLQxtZ8WmAA36LcfL2m62CSU8 48M/hs6Me4Woyb+kVF5gCHftmwEMIhmbYg1ZcOngn8pPiKHhdcTB9nGWYnqHDYeFKVTYYRXWYV7 WxujJyNtD+BaL9s11XI89FT1JwQNWv34qCfZeB42ttaKffzrd90KOaTEWsYklAUX4q2G9UzDosE HPCMGzX2OsNd4n97EovptQwz5tsibv16+gil4jeNTnqOMBIJ4VOLNIaYmKl84y6qlouf80Qd6Ad 6u6QQsH7iereGMC/oTQh9A4m9EtEhHWssEmb8zlpbYq2f4jz+YeGP4tValiD5afVp5Xd6vL9bkQ jKyYV4+zElR7y0HDO2FK5J1KhC+xSRa9qpSosf55TSoW/nwH4LNJrF7IQmLtC6gmjZSvByFd1+H yX1T/7aOWCt37RI5nuTVkeYosXtRdLx1X9BVkAwU67HqISZEZdVTfpERP4jJaLwSDpC4WejNBeQ QGOzHQm1Ffg4ixTDsy5zTeFbONugD0t7xcmlup0Koq3EzpuHoXrT0auYLu1QpPXCHADw34nr9T9 XLgXisK4O5i/VzFo1zTm7Qr1KLcnlJe2gk8vIVPDUPUfDU5K2ii62uH2gIOjjhzbBFx3WrFwIge lSuPCmvYCWHmG8zJmug812qIbzQHMudKcSZKpHQgtCTJ1arKPFjJEFr+olSlnU38LCY8tEjLkWa 8TVpR9kw80dd4buXLpt0q9zrizUUE+34L12YpUNU9pHlUi2othhzDV1qmLbhtjaBq2KLw==
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--22.202200-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.2.1013-24052.007
Content-Type: multipart/alternative; boundary="_000_734752AF0E88364D983373FE5CEFED57594B9E61bgb01xud1001_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/wXAKXRggoCwfSAl4xtYd16nypmQ>
Subject: Re: [payload] new draft - RTP Payload for TTML Timed Text
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2019 09:25:11 -0000

Thanks, Roni. Should I make these changes now or wait until the call for the WG to adopt v02 has lapsed?

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: Roni Even (A) [roni.even@huawei.com]
Sent: 12 February 2019 07:52
To: Nigel Megitt; payload@ietf.org
Subject: Re: [payload] new draft - RTP Payload for TTML Timed Text

Hi,
Thanks for the information.
The way I see it is that this document only wants to specify how to send TTM time text using RTP which is not specified by W3C

I think that the text explains it but maybe we need better clarification, any input is welcome. I think that at least it should say that this document only define how to carry TTML time text over RTP using the media subtype defined by W3C and reference the relevant W3C document.

I agree that we do not need the registration template since the document suggest using the current registration in the IANA media  type, so the IANA consideration should only ask for adding the reference to this document in the current registration. This assumes that there are no changes in the registration required.   Another direction is to have a different media subtype name for the RTP usage but In see no real reason if the document only specify how to use this payload over RTP and change nothing in the current registration.

The only other comment I noticed is “A request to make sure that the language about profile signalling does not imply that the codecs parameter can denote all profiles, especially in the case that the payload document contains an embedded profile.“  This should be addressed by the authors

Let the WG know if this sounds reasonable
Roni Even
Payload WG co-chair




From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Nigel Megitt
Sent: Monday, February 11, 2019 5:16 PM
To: payload@ietf.org
Subject: Re: [payload] new draft - RTP Payload for TTML Timed Text

Dear IETF Payload group,

This draft was discussed by the W3C Timed Text Working Group (TTWG) on 2019-02-07 [1].

[1] Minutes of W3C TTWG meeting 2019-02-07: https://www.w3.org/2019/02/07-tt-minutes.html#item03

During the meeting concern was raised about the approach to the IANA registered media type, specifically the meaning of section 8. IANA Considerations.

There was consensus amongst the group that the text specifying that this text:

“The media types registry SHOULD be updated to make reference to this document for the application/ttml+xml media type.”

is incorrect and needs to be changed. The media type registration for TTML is owned by W3C and should not be changed by IETF – we note that the change control is clearly marked as being owned by W3C so in that sense this text is inconsistent.

The IANA media type registration itself defers to the TTWG document “TTML Media Type Definition and Profile Registry” [2] which is already referenced by the RTP Payload draft. An improvement would therefore be to update the text in section 8 to suggest that [2] can be updated to include the profiles defined within the payload document. Indeed doing so would result in the creation of a short code for the profile processor mentioned in section 4.2.1.2.1.3 Processor profile signalling.

[2] TTML Media Type Definition and Profile Registry https://www.w3.org/TR/ttml-profile-registry/


The TTWG also discussed two additional concerns without closing on a position at this time:

  1.  A query whether the media type registration information really needs to be copied in at all here or if it can be referenced;
  2.  A request to make sure that the language about profile signalling does not imply that the codecs parameter can denote all profiles, especially in the case that the payload document contains an embedded profile.
TTWG may provide further input on those two points but would welcome further input especially on the first.

Kind regards,

Nigel Megitt as Chair of W3C TTWG




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

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.

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