Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 22 October 2019 10:34 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ECF2120169; Tue, 22 Oct 2019 03:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 LD0LXPuzT9HN; Tue, 22 Oct 2019 03:34:33 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30052.outbound.protection.outlook.com [40.107.3.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E084A120111; Tue, 22 Oct 2019 03:34:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g5fHAt6zZxKBb5aE2lhVJlajE6veKLrdw+ewWljNusG1jyFrm8maw+bXUc+H4LpRbf7tWIuADztYf5Sr38tcP9DPhURNSOU5izpJRhTHLEIAT0zDuFJbeLY9rrEB1gDxly8jxp4k9TSDBptwH2JllOYkuVAuFV7JJ330TofscMw+Su/YicxqPQ3zAEMwN//Z0gEqlXQYjTcG1JR0KABf0XQH01jRHd7xFIJlE2qtWcIDQTeYYg7PF/jmwOvWGC8o14YgVkCH/82J1SCwtxB0bS5Bzi/lIQxV+Ghva/e/7ToDW+j7SoG/YqOtwynDvZXT7Zj0eGYuXuP2X9KdrPxE/g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fS09OFXOlcO5FJtZZpn2AulKRZYCqBwviSZaAS1Arys=; b=WZxWN42rBBYJ7IH2IALT1TiDP1rvpaWiqLl5cNmOGK8w3bH4nXrJd6LCr16Hip5a3faCvK+LIUNR5f+oR8fPfhQAG3N6VAbnFfUn3m+WLWMOpI6IS4vfijHm9k3WZ7duNqmVIF4PQXUuxqLebJD4YUhMr61g/zdRw4YoBi3+UmHInvVsv6fQaSJF9gguSf35gPJcGIFdjg2+vibC+uwM1OZiPjZiFslogu5gKHWGmxwdPNmJyZSSFk2T95/8xWBBCBJNTplsr2eXnnu3hwyVLPXt0NfkCh1ppyMI3Uk69iuz0swifNEhTgsDb9eqSCZpFh0HZBZEub5SJBM4pNbF6g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fS09OFXOlcO5FJtZZpn2AulKRZYCqBwviSZaAS1Arys=; b=cSq5BJ5EzxqIlQaoGSOaYufBeZ7j1rI6QvqZOqUKlBXBuXepGy4HkupZ6nPbgAsnesOuNzW6BDMMShEhKvLbr5N/S1ycqHA5+S+/4JkJhNqeuT1eAJhwfXPbnmk3BHu7dr6leM765Ti5wnaY/07NoPqLl6pFqyMbaY0otHW9LUA=
Received: from HE1PR0701MB2697.eurprd07.prod.outlook.com (10.168.188.16) by HE1PR0701MB2234.eurprd07.prod.outlook.com (10.168.36.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.14; Tue, 22 Oct 2019 10:34:30 +0000
Received: from HE1PR0701MB2697.eurprd07.prod.outlook.com ([fe80::1d5c:4814:3c1e:b769]) by HE1PR0701MB2697.eurprd07.prod.outlook.com ([fe80::1d5c:4814:3c1e:b769%10]) with mapi id 15.20.2387.016; Tue, 22 Oct 2019 10:34:30 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "iesg@ietf.org" <iesg@ietf.org>
CC: "avtcore-chairs@ietf.org" <avtcore-chairs@ietf.org>, "draft-ietf-payload-rtp-ttml@ietf.org" <draft-ietf-payload-rtp-ttml@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Thread-Topic: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
Thread-Index: AQHViBg098PKMu0mGUinEkYSbhMDKKdmeGCA
Date: Tue, 22 Oct 2019 10:34:30 +0000
Message-ID: <5b2c2983f307529dbca5feebfb75c120a4ab5ef5.camel@ericsson.com>
References: <157166654391.31879.7510825796211658153.idtracker@ietfa.amsl.com>
In-Reply-To: <157166654391.31879.7510825796211658153.idtracker@ietfa.amsl.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [192.176.1.82]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 803d6383-85ac-456d-f47d-08d756db6beb
x-ms-traffictypediagnostic: HE1PR0701MB2234:
x-microsoft-antispam-prvs: <HE1PR0701MB2234751F24D46669C0216B3C95680@HE1PR0701MB2234.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7219;
x-forefront-prvs: 01986AE76B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(376002)(346002)(39860400002)(396003)(51444003)(199004)(189003)(6246003)(450100002)(11346002)(3846002)(2616005)(6116002)(6916009)(86362001)(26005)(4326008)(2501003)(99936001)(186003)(446003)(476003)(486006)(2906002)(44832011)(4001150100001)(66556008)(64756008)(6506007)(102836004)(14444005)(2351001)(966005)(256004)(5660300002)(66446008)(118296001)(25786009)(6306002)(66066001)(36756003)(6512007)(76176011)(76116006)(14454004)(6486002)(478600001)(316002)(71190400001)(54906003)(71200400001)(8936002)(7736002)(305945005)(5640700003)(6436002)(66476007)(66616009)(66946007)(229853002)(8676002)(81166006)(81156014)(1730700003)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2234; H:HE1PR0701MB2697.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zsziczuAr+lTAdCU3oz1TqKoR3Nt7p6QouO6MhmQa+nXnxDeJ3EgXB3zUM0+tV0sRmDdYYuTWLp4tcOFukdrOmyAHP9Oq5KuBkMqPGWt5lZFEkSWfZ7s1CHHSnD2ZarALGXrGdaLF0UI8YQ5NlKblip9/sdY9kre8QeyNYOA67Wqa/t8IdIk2CCW3PrZ5l9myJgFRWk913Em0NTSp6jGNQzGCdPxWqyHW+apPa/3tbHgV4MJ6R8/NO8qKTgdxB/YUXPp4IPCs3PfDO0OUCIXTXd83JuhgS/06Eb8Nw5zh+hSQDqpZ2ijXya2ZR2MZJVc77ifarQVYSZXCNho3whyHnWC0+oMmXBFrnMnbu2sI5I+g1g2gJOfmp9AT/YftwUmi0b4k1IYPMATe6qs2+94BI78UYxSSaLdimSbokc7B19NcJp66IHUxM1qeX74UIVM
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-h1bfqBn4DusqfpWQ5C+5"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 803d6383-85ac-456d-f47d-08d756db6beb
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2019 10:34:30.2947 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3ReZb4PsOIB1mrjcNpMdqPqVL/4f9AFE+G7Ik5NcbbCSBhptqGuc4z+NdaYlkeskqlOeMw5XxbgSAPVDwkr1fd5TlItTlH4kVWO2FQ5GsAo=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2234
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/rf8OEa0rUEShX8hfDR1g9WvzGlI>
Subject: Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Oct 2019 10:34:35 -0000
Hi, This is an updated Discuss with the issue of missing SDP O/A parts that Christer Holmberg did notice. I put this on discuss level as it really need to be fixed. I think we all missed it due to the fact that the media type definition is elsewhere. Cheers Magnus On Mon, 2019-10-21 at 07:02 -0700, Magnus Westerlund via Datatracker wrote: > Magnus Westerlund has entered the following ballot position for > draft-ietf-payload-rtp-ttml-03: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > James and WG, > > I do have a couple of issues I want to have your feedback on if they should be > corrected or not before proceeding to publication. Note they are for > discussion > and in cases where things have been discussed and there is consensus please > reference that so that I can take that into consideration when we resolve > these. > > 1. Section 4.1: > Timestamp: > The RTP Timestamp encodes the time of the text in the packet. > > As timed text is a media that has duration, from a start time to an > end > time, and the RTP timestmap is a single time tick in the chose clock > resolution the above text is not clear. I would think the start time > of > the document would be the most useful to include? > > I think the text in 4.2.1.2 combined with the above attempts to imply > that the RTP timestamp will be the 0 reference for the time- > expression? > > I think this needs a bit more clarification. Not having detailed > studied TTML2/1 I might be missing important details. But some more > information how the document timebase:media time line connects to the > RTP timestamp appears necessary. > > 2. A Discuss Discuss: As Timed Text is directly associated with one or more > video and audio streams and requires synchronization with these other media > streams to function correct. This leads to two questions. > > First of all is application/ttml+xml actually the right top-level > media > type? If using SDP that forces one unless one have BUNDLE to use a > different RTP session. Many media types having this type of properties > of being associated with some other media types have registered media > types in all relevant top-level media types. > > Secondly, this payload format may need some references to mechanisms > in > RTP and signalling that has the purpose of associating media streams? > I > also assume that we have the interesting cases with localization that > different languages have different time lines for the text and how > long > it shows as there are different tranditions in different countries and > languages for how one makes subtitles. > > This may also point to the need for discussing the pick one out of n > mechanism that a manifest may need. > > 3. Section 7.1: > > It may be appropriate to use the same Synchronization > Source and Clock Rate as the related media. > > Using the same SSRC as another media stream in the same RTP Session is > no-no. If you meant to use multiple RTP sessions and associate them > using the same SSRC in diffiernt, yes it works but is not recommended. > This points to the need for a clearer discussion of how to achieve > linkage and the reasons for why same RTP timestamp may be useful or > not. > > 4. Fragmentation: > I think the fragmentation of an TTML document across multiple RTP > payloads are a bit insufficiently described. I have the impression > that > it is hard to do something more clever than to fill each RTP payload > to > MTU limtiation, and send them out insequence. However, I think a firm > requirement to apply RTP sequence number for a single document in > consecutive numbers. Also the re-assebly process appear to have to > parts for detecting what belongs together, same timestamp and last > packet of document should have marker bit set. As a receiver can loose > the last packet in the previous document, still know that it has > received everything for the following document. However, if the losses > are multiple, inspection of the re-assemblied document will be > necessary to determine if the correct beginning is present. I have the > impression that a proper section discussing these matter of > fragmentation and re-assembly are necessary for good interoperability > and function. > > 5. Lack of definition of parameter types in the media type when using SDP > Offer/answer. > > As the application/ttml media type do contain parameters (charset and profile) > there is a need to define what SDP O/A interpretations they need to have. See > section 3.4.2.1 of RFC 8088 for discussion of these different types. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A. Section 6. > To my understanding the TTML document is basically not possible to > encode better. A poor generator can create unnecessary verbose XML > which could be shorter, but there are no possibility here to trade-off > media quality for lower bit-rate. I think that should be made more > explicit in Section 6. > > B. Section 7. > Wouldn't using 90kHz be the better default? 1kHz is the minimal from > RTCP report that will work decently. However, if the timed text is > primarily going to be synchronized with video 90k do ensure that > (sub-)frame precise timing is possible to express. I don't see any > need > raster line specific for time text so the SMPTE 27 MHz clock is not > needed. And using non default for subtitling radio etc appears fine. > > C. Repair operations and relation to documents. Based on basic properties of > TTML documents, I do think the repair operations should be highly targeting > single documents as there is likely seconds between documents, while the > fragments of a document will be sent in a rather short interval. That > recommendation would be good to include. > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt -- Cheers Magnus Westerlund ---------------------------------------------------------------------- Network Architecture & Protocols, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [AVTCORE] Magnus Westerlund's Discuss on draft-ie… Magnus Westerlund via Datatracker
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Magnus Westerlund
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… James Sandford
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Magnus Westerlund
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… James Sandford
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Magnus Westerlund
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… James Sandford
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Christer Holmberg
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Christer Holmberg
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Magnus Westerlund
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Magnus Westerlund
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… James Sandford
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Christer Holmberg
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Christer Holmberg
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… James Sandford
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… Christer Holmberg
- Re: [AVTCORE] Magnus Westerlund's Discuss on draf… James Sandford