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

[Christer Holmberg <[e-mail]>]

Hi,

I see that you have added an SDP Offer/Answer section, but the only statement there is "All parameters are declarative".

I assume (please correct me if I am wrong) it shall be possible for two endpoints to negotiate a TTML RTP flow, in which case you need to describe the procedures for the Offerer and the Answerer.

Regards,

Christer




________________________________
From: avt <[e-mail]> on behalf of James Sandford <[e-mail]>
Sent: Tuesday, October 29, 2019 4:24 PM
To: Magnus Westerlund <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)

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 [[e-mail]]
Sent: 29 October 2019 14:13
To: James Sandford; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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 [[e-mail]]
> Sent: 29 October 2019 11:47
> To: James Sandford; [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------



_______________________________________________
Audio/Video Transport Core Maintenance
[e-mail]
https://www.ietf.org/mailman/listinfo/avt