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

[Magnus Westerlund <[e-mail]>]

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