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

[Christer Holmberg <[e-mail]>]

Fair enough.

Regards,

Christer

On 29/10/2019, 17.32, "James Sandford" <[e-mail]> wrote:

    Hi,
    
    I am hesitant to mandate a specific mechanism for the reason Magnus has noted. The most likely use case for TTML over RTP, in my view, is in the broadcast industry. The industry standard for protection in this case is SMPTE ST2022-7 or the provision of an appropriately robust network. But that is a broadcast-oriented solution that may not be appropriate for other use cases. I'm hesitant to mandate support for mechanisms that may never be use by many/any implementations.
    
    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 15:20
    To: James Sandford; Christer Holmberg; [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,
    
    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]
    ----------------------------------------------------------------------