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

Hello,
Apologies for only replying to the one thread. I have uploaded a new I-D (-04) which I believe addresses the Discuss items and Comments raised.

Changes include:
* Improvements to typesetting
* Improvements to the clarity of various sentences/terms
* A new section of fragmentation
* A note on the RTCP jitter calculation being unusable with this payload format
* A new section on protection against data loss
* A new section on offer/answer considerations

I would like to highlight that the new section on protection against data loss does not define usage of RFC 2198 redundancy. This is intentional and the reasoning is two fold. I have referenced SMPTE ST2022-7 which defines a means of sending duplicate streams over diverse paths. This provides similar functionality and is the most common method of sending duplicate streams in the broadcast industry, one of the more common users of TTML. Secondly, I could not convince myself that RFC 2198 with usage similar to RFC 4103 Section 4 would work effectively for fragmented payloads in a lossy environment. For this reason, I opted to stick with a reference to ST2022-7 as an example of a redundant transmission mechanism rather than re-inventing the wheel in this spec. This is alongside the usual refe
 rences for FEC and re-transmission.

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 [[email protected]]
Sent: 22 October 2019 11:34
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: [AVTCORE] Magnus Westerlund's Discuss on draft-ietf-payload-rtp-ttml-03: (with DISCUSS and COMMENT)

Hi,

This is an updated Discuss with the issue of missing SDP O/A parts that Christer
Holmberg did notice. I put this on discuss level as it really need to be fixed.
I think we all missed it due to the fact that the media type definition is
elsewhere.

Cheers

Magnus

On Mon, 2019-10-21 at 07:02 -0700, Magnus Westerlund via Datatracker wrote:
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-payload-rtp-ttml-03: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ttml/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> James and WG,
>
> I do have a couple of issues I want to have your feedback on if they should be
> corrected or not before proceeding to publication. Note they are for
> discussion
> and in cases where things have been discussed and there is consensus please
> reference that so that I can take that into consideration when we resolve
> these.
>
> 1. Section 4.1:
>         Timestamp:
>         The RTP Timestamp encodes the time of the text in the packet.
>
>         As timed text is a media that has duration, from a start time to an
> end
>         time, and the RTP timestmap is a single time tick in the chose clock
>         resolution the above text is not clear. I would think the start time
> of
>         the document would be the most useful to include?
>
>         I think the text in 4.2.1.2 combined with the above attempts to imply
>         that the RTP timestamp will be the 0 reference for the time-
> expression?
>
>         I think this needs a bit more clarification. Not having detailed
>         studied TTML2/1 I might be missing important details. But some more
>         information how the document timebase:media time line connects to the
>         RTP timestamp appears necessary.
>
> 2. A Discuss Discuss: As Timed Text is directly associated with one or more
> video and audio streams and requires synchronization with these other media
> streams to function correct. This leads to two questions.
>
>         First of all is application/ttml+xml actually the right top-level
> media
>         type? If using SDP that forces one unless one have BUNDLE to use a
>         different RTP session. Many media types having this type of properties
>         of being associated with some other media types have registered media
>         types in all relevant top-level media types.
>
>         Secondly, this payload format may need some references to mechanisms
> in
>         RTP and signalling that has the purpose of associating media streams?
> I
>         also assume that we have the interesting cases with localization that
>         different languages have different time lines for the text and how
> long
>         it shows as there are different tranditions in different countries and
>         languages for how one makes subtitles.
>
>         This may also point to the need for discussing the pick one out of n
>         mechanism that a manifest may need.
>
> 3. Section 7.1:
>
>         It may be appropriate to use the same Synchronization
>    Source and Clock Rate as the related media.
>
>         Using the same SSRC as another media stream in the same RTP Session is
>         no-no. If you meant to use multiple RTP sessions and associate them
>         using the same SSRC in diffiernt, yes it works but is not recommended.
>         This points to the need for a clearer discussion of how to achieve
>         linkage and the reasons for why same RTP timestamp may be useful or
> not.
>
> 4. Fragmentation:
>         I think the fragmentation of an TTML document across multiple RTP
>         payloads are a bit insufficiently described. I have the impression
> that
>         it is hard to do something more clever than to fill each RTP payload
> to
>         MTU limtiation, and send them out insequence. However, I think a firm
>         requirement to apply RTP sequence number for a single document in
>         consecutive numbers. Also the re-assebly process appear to have to
>         parts for detecting what belongs together, same timestamp and last
>         packet of document should have marker bit set. As a receiver can loose
>         the last packet in the previous document, still know that it has
>         received everything for the following document. However, if the losses
>         are multiple, inspection of the re-assemblied document will be
>         necessary to determine if the correct beginning is present. I have the
>         impression that a proper section discussing these matter of
>         fragmentation and re-assembly are necessary for good interoperability
>         and function.
>
> 5. Lack of definition of parameter types in the media type when using SDP
> Offer/answer.
>
> As the application/ttml media type do contain parameters (charset and profile)
> there is a need to define what SDP O/A interpretations they need to have. See
> section 3.4.2.1 of RFC 8088 for discussion of these different types.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> A. Section 6.
>         To my understanding the TTML document is basically not possible to
>         encode better. A poor generator can create unnecessary verbose XML
>         which could be shorter, but there are no possibility here to trade-off
>         media quality for lower bit-rate. I think that should be made more
>         explicit in Section 6.
>
> B. Section 7.
>         Wouldn't using 90kHz be the better default? 1kHz is the minimal from
>         RTCP report that will work decently. However, if the timed text is
>         primarily going to be synchronized with video 90k do ensure that
>         (sub-)frame precise timing is possible to express. I don't see any
> need
>         raster line specific for time text so the SMPTE 27 MHz clock is not
>         needed. And using non default for subtitling radio etc appears fine.
>
> C. Repair operations and relation to documents. Based on basic properties of
> TTML documents, I do think the repair operations should be highly targeting
> single documents as there is likely seconds between documents, while the
> fragments of a document will be sent in a rather short interval. That
> recommendation would be good to include.
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email protected]
> https://www.ietf.org/mailman/listinfo/avt
--
Cheers

Magnus Westerlund


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email protected]
----------------------------------------------------------------------



_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt