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

[Magnus Westerlund <[e-mail]>]

Hi,

RTP is way to much a framework, that the different usages normally have to
specify what mechanisms is actually to be used. That is true both for security
as well as for repair / redundancy mechanisms. I don't see this payload format
having that specific requirement that it actually makes sense to lock down to a
single solution for all usages. 

Cheers

Magnus

On Tue, 2019-10-29 at 14:57 +0000, Christer Holmberg wrote:
> Hi,
> 
> I see that you have now added text on protection of packet loss. But, you just
> list a number of different mechanisms, without mandating (or even
> recommending) one of them - you just say that implementations must support *A*
> mechanism. But, that is most likely going to cause interoperability problems,
> if different implementations support different mechanisms.
> 
> 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]
----------------------------------------------------------------------