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

[Magnus Westerlund <[e-mail]>]

Hi Christer,

Actually, if they are all declarative it is actually sufficient. That results in
all parameters behaving as defined in RFC 3264 and you actually don't have to go
into details. 

Or do you disagree with that assessment? 

Cheers

Magnus


On Tue, 2019-10-29 at 14:52 +0000, Christer Holmberg wrote:
> 
> 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
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------