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

[James Sandford <[e-mail]>]

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