Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)

James Sandford <james.sandford@bbc.co.uk> Fri, 25 October 2019 10:12 UTC

Return-Path: <james.sandford@bbc.co.uk>
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 59B1C120818; Fri, 25 Oct 2019 03:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 owH0c8YcDzhW; Fri, 25 Oct 2019 03:12:14 -0700 (PDT)
Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (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 47171120814; Fri, 25 Oct 2019 03:12:14 -0700 (PDT)
Received: from BGB01XI1007.national.core.bbc.co.uk (bgb01xi1007.national.core.bbc.co.uk [10.161.14.21]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id x9PACBQm019211; Fri, 25 Oct 2019 11:12:11 +0100 (BST)
Received: from BGB01XUD1001.national.core.bbc.co.uk ([10.184.52.80]) by BGB01XI1007.national.core.bbc.co.uk ([10.161.14.21]) with mapi id 14.03.0408.000; Fri, 25 Oct 2019 11:12:11 +0100
From: James Sandford <james.sandford@bbc.co.uk>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "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: AQHViBgrJ4118AkyjU2M3/XX8adccadmZ54AgAS5sDI=
Date: Fri, 25 Oct 2019 10:12:10 +0000
Message-ID: <734752AF0E88364D983373FE5CEFED5771C9787B@bgb01xud1001>
References: <157166654391.31879.7510825796211658153.idtracker@ietfa.amsl.com>, <5b2c2983f307529dbca5feebfb75c120a4ab5ef5.camel@ericsson.com>
In-Reply-To: <5b2c2983f307529dbca5feebfb75c120a4ab5ef5.camel@ericsson.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [132.185.132.12]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-12.5.0.1300-8.2.1013-24054.007
x-tm-as-result: No-29.407600-8.000000-10
x-tmase-matchedrid: IeZYkn8zfFq7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p1Swaqf8l1iZL+F fqkgLJRhZ4oHG8WaiVuabxa5lK3CzBdr6zI6nTrtaTkE+8TT7payiNuZzgQ4vOOxOq7LQlGL/FN OfJWhX+MbQTo2pcsodSlwOHe2NNTvv2Nf75q6+/57wVopF8zagxxCcOlDoVfTXwDLkmwDcf0mXj 13JycOOf4kTju5lxTAB3abVxRTBO8/UOKwpH97lPvADvTnCf5vGbJMFqqIm9xHXHN8xfQ9rq+O3 p9xFzgDTiQecD9aKoQLrB+Bba+cAvDPsOf70zK93tJaKJZJX/WMs7LXcKBvj6q9wgXVNwtgE7or XnCF9AyI7qXZddSBHa0Pj/9cOH4sCAKizYVJv3+prpImTnz4tiIBy2vbJcliuqWf6Nh7tmGzP/m FbCCOqL1QqFpoRKPXJDSW1TEpRmfau9iF5mAFe+0/o+/4D7Dz1Ga2L87qPQJq4coTktrGXxEagY lxo94P5euzzS5MWLkGmMYPaGOC9XxyKV09P74pMIiU395I8H00AKed0u9fB26T9TFyBLKGABzto wY3cUCkgYMXP5V9ynN2blhkILLzZfdKl0bT6VZ1e7Xbb6Im2pWr6iSXWtgP+5+93dPb6/cygvvk 2n2DkV/IG+YeHNQ12WzL08HogaOFy36mQhwQgewSNio74PJovpIiqFsHmVYhvFjBsLEZNKHZ5Nt LmicGjqLgNuFnv9oWIaNxgnxVBwmQZcmlOSaBFp8tduyF+iBd7K6NvtpeBNWeXAweUHB1crjyp8 uvLFV2fYW7cXp62Q3Pu1JZ6TRWneTDMjnpUR2eAiCmPx4NwFkMvWAuahr80AUPEgVMzF/e3/9uS SiAvgtuKBGekqUpPjKoPgsq7cA=
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--29.407600-8.000000
x-tmase-version: SMEX-12.5.0.1300-8.2.1013-24054.007
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/LyLe5vDyJTtAKiesuobcLqWSb9c>
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: Fri, 25 Oct 2019 10:12:17 -0000

Hello,
Apologies for only replying to the one thread. I have uploaded a new I-D (-04) which I believe addresses the Discuss items and Comments raised.

Changes include:
* Improvements to typesetting
* Improvements to the clarity of various sentences/terms
* A new section of fragmentation
* A note on the RTCP jitter calculation being unusable with this payload format
* A new section on protection against data loss
* A new section on offer/answer considerations

I would like to highlight that the new section on protection against data loss does not define usage of RFC 2198 redundancy. This is intentional and the reasoning is two fold. I have referenced SMPTE ST2022-7 which defines a means of sending duplicate streams over diverse paths. This provides similar functionality and is the most common method of sending duplicate streams in the broadcast industry, one of the more common users of TTML. Secondly, I could not convince myself that RFC 2198 with usage similar to RFC 4103 Section 4 would work effectively for fragmented payloads in a lossy environment. For this reason, I opted to stick with a reference to ST2022-7 as an example of a redundant transmission mechanism rather than re-inventing the wheel in this spec. This is alongside the usual references for FEC and re-transmission.

https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/

Regards,
James

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

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

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

________________________________________
From: Magnus Westerlund [magnus.westerlund@ericsson.com]
Sent: 22 October 2019 11:34
To: iesg@ietf.org
Cc: avtcore-chairs@ietf.org; draft-ietf-payload-rtp-ttml@ietf.org; avt@ietf.org
Subject: Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)

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
----------------------------------------------------------------------