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

James Sandford <james.sandford@bbc.co.uk> Tue, 29 October 2019 14:24 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 08C2E120867; Tue, 29 Oct 2019 07:24:22 -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 H2CNDj4ml93o; Tue, 29 Oct 2019 07:24:17 -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 18EFD120934; Tue, 29 Oct 2019 07:24:16 -0700 (PDT)
Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id x9TEOEIc005295; Tue, 29 Oct 2019 14:24:14 GMT
Received: from BGB01XUD1001.national.core.bbc.co.uk ([10.184.52.80]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0408.000; Tue, 29 Oct 2019 14:24:14 +0000
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/XX8adccadmZ54AgAS5sDKABmuygIAAH3gXgAAJdwCAAALCgA==
Date: Tue, 29 Oct 2019 14:24:13 +0000
Message-ID: <734752AF0E88364D983373FE5CEFED5771C9BC29@bgb01xud1001>
References: <157166654391.31879.7510825796211658153.idtracker@ietfa.amsl.com> , <5b2c2983f307529dbca5feebfb75c120a4ab5ef5.camel@ericsson.com> <734752AF0E88364D983373FE5CEFED5771C9787B@bgb01xud1001> , <HE1PR0701MB269744B579C01D0EC09C424E95610@HE1PR0701MB2697.eurprd07.prod.outlook.com> <734752AF0E88364D983373FE5CEFED5771C9BBEA@bgb01xud1001>, <85eb369a2eb610f6c881595fab9ff249fb68ddcc.camel@ericsson.com>
In-Reply-To: <85eb369a2eb610f6c881595fab9ff249fb68ddcc.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-18.692700-8.000000-10
x-tmase-matchedrid: gjZGo2H/wj+7lpQUW6Uvz7iMC5wdwKqdwZLXS0hN8p1pHA4vzDv2iojA +sAfyIsyuiIcdMkoZb8DZCldP9AFvrQ/gWi/bNdVyPPRU9ScEDVr9+Kgn2XgeNrbWin3863fZGa XPLvxUHQmYuoq7bKp2R8oHph1yfXaDsB+KQ9eA7Dx5KZMlKYS/WWuy5Lm0L4/cBu9rPc/2X9ReD 6gNYbuko404Xse9RB3wJov9v3WFTQmcsJib2IjaaOONuzwygtGviRliDV2nyxh2lxkfcGsFAC4p NWGg4USH8v35IbNkM6tgInUmFisf6oxnLP9FwYuBu2zRCSrLjbj5lyuq8IOQS8ggN9+4AxXHgnX JRCHTfYSGWNwWBcXMuLFd6bFLDSFHg2oWr6TWXszw5Ejs3g1lsnlJe2gk8vIlRDMdYEo4UDJmv4 8L9hg3mcbEqwaptfOFgb6tBfAVIctg1fUv6/cnhMxKDqgAFSzUAjrAJWsTe/AyhGgBjmG1ihKmg X0fl89WAoBU104ild5OPD8XJFfpL9ZdlL8eonaa9+JVKonO7f6APa9i04WGCq2rl3dzGQ1DBbGv tcMofzkL+oznPnpNrURW7CrcG+EwKHEcu1nPJmgAwhCyNiMDfPxtcg/+sh0
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--18.692700-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/R_t0Dg5gXWJGBcK9ntcWBqZgGhk>
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, 29 Oct 2019 14:24:22 -0000

Changes have been submitted in -05. 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: 29 October 2019 14:13
To: James Sandford; 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 James,

Looks good to me.

Thanks,

Magnus


On Tue, 2019-10-29 at 13:52 +0000, James Sandford wrote:
> Thank you for your further comments.
>
> I will make the suggested changes to Section 8 and Section 11.1.
>
> With regards to further clarifying the fragmentation of documents, I propose
> the following:
>
> Section 6 OLD:
>   If a TTML document is assessed to be invalid then it MUST be discarded. When
> processing a valid document, the following requirements apply.
>
> Section 6 NEW:
>   If a TTML document is assessed to be invalid then it MUST be discarded. This
> includes empty documents, i.e. those of zero length. When processing a valid
> document, the following requirements apply.
>
> Section 8 ADDITIONAL PARAGRAPH:
>   As described in Section 6, only zero or one TTML document may be active at
> any point in time.  As such, there MUST only be one document transmitted for a
> given RTP Timestamp.  Furthermore, as stated in Section 4.1, the Marker Bit
> MUST be set for a packet containing the last fragment of a document.  A packet
> following one where the Marker Bit is set contains the first fragment of a new
> document.  The first fragment might also be the last.
>
>
> 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: 29 October 2019 11:47
> To: James Sandford; 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 James,
>
> Thanks for the  many updates in -04. However, I think there are a couple of
> adjustments still needed.
>
> Section 8:
>
> When a document spans more than one RTP packet, the entire document
> is obtained by concatenating User Data Words from each contributing
> packet in ascending order of Sequence Number.
>
> I think this can be further clarified by adding "consecutive"
>
> When a document spans more than one RTP packet, the entire document
> is obtained by concatenating User Data Words from each consecutive
> contributing
> packet in ascending order of Sequence Number.
>
> What I think is unclear is what is considered contributing packets. It is
> quite common that one determine fragments based on timestamp and that may be
> assumed by some. I don't know if that is a dangerous assumption here. To my
> understanding one can determine the set of fragments by looking at the
> marker bit for the packets. From first 0 after a 1, until and including the
> packet with a m=1. If that is your intention for how one should do it, so
> that it works for multiple documents to share epoch and thus RTP timestamp
> documents I think this needs to be made explicit.
>
> In section 11.1 it says:
>
> In these situations, it is RECOMMENDED that streams use
> the same Synchronization Source and Clock Rate as the related media.
>
> You do need to insert "Time" before Synchronization source to not be
> misinterpret to mean SSRC. Or maybe better is to say "clock source".
>
> Cheers
>
> Magnus Westerlund
--
Cheers

Magnus Westerlund


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------