Subject: [AVT] Comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Sep 2003 13:54:11 +0200

Hi Jose,

Here is a number of comment on your draft from me and my colleague Per 
Fröjdh. I think there are a couple of fundamental design issues here. 
Most however is details.

1. A General comment is about the language which is rather fuzzy and 
unprecise. I would strongly recommend a much greater level of use of 
normative language to describe how things work.

2. In the abstract there is a sentence saying: "3GPP timed text is 
time-lined decorated text media format based on the ISO (International 
Standardisation Organisation) Base Media File Format."

In my opinion the text format is not BASED ON ISO, it is rather defined 
within the framework for ISO files.

3. Abstract, " As of today, 3GPP timed text contents can be downloaded 
via HTTP and synchronised with audio/video contents." I think one should 
consider the formulation. The 3GPP timed text content can be download as 
  a 3GP file using HTTP.

4. Section 2, second paragraph, first sentence: "3GPP timed text is a 
3GP file format for time-lined decorated text specified in Annex D.8.a 
of [1]." Again 3GPP timed text is a format with defined storage in a 3GP 
file according to Annex D.8.a

5. How do you plan to handle the Release 6 update and definitions?

6. Section 2, last paragraph, stray ".".

7. Section 4. Marker bit definition. Needs normative MUST. Some note on 
multi sample packets.

8. Section 4. Timestamp definition: In the case of multiple samples in a 
packet, I think that the timestamp SHALL be set for the earliest, rather 
than first sample. Otherwise the duration rule will have problem. I 
think one should also point out that all samples have unique timestamps 
that is why one can use the TS as a identifier of which packet the 
fragments belong to.

9. Section 4. Payload type definition. "Payload Type (PT): the payload 
type is set dynamically and sent by out-of-band means. " I think the 
sentence is slightly wrongly formulated. The payload type is dynamically 
assigned per RTP session and the assignment is done by out-of-bands 
mechanisms, for example SDP.

10. Section 4. Sequence number handling. I think there are need to 
consider sequence number in the case of FU packets to get the right 
assembly order. In general I think there is a lack of definition or 
explanation of how a receiver determines what is the first and last 
packet of fragment.

11. Section 4. Page 5, Last partial sentence: "This payload format is 
used to convey both fragmented and non-fragmented text samples." In the 
case for more normative language the sentence should be probably be 
reformulated as "This payload format MAY be used to convey both 
fragmented and non-fragmented text samples."

12. Figure 1, 2, 3, 4. I think there is not clear how a receiver will be 
able to distinguish between the cases. The only one that has an 
explanation at all is the case with FHDR first. How a receiver detects 
the presence or not of a SPLDESC I have no idea. When I have this 
complains I would also like to point out that using the payload types is 
not a good solution, at least not as the current parameter mapping is 
done. When one has fragments one in fact duplicates all the track header 
information and sample descriptions sent in the SDP. As the fmtp line 
can become rather big for this format I don't see this as an acceptable 
solution.

13. Section 4.1, page 8:
"  The composition of the THDR depends on whether the text sample is
    fragmented or not.  In particular:

    - SLEN MUST NOT be present if the RTP packet contains a text sample
    fragment.  If the RTP packet carries one or several non-fragmented
    samples SLEN MUST be present for every text sample, as in Figure 1."

Why should one not have a SLEN field for a fragment? In my opinion 
knowing the total length of the fragmented sample allows one to allocate 
the correct buffer for that sample.

14. Section 4.2.2 I am not convinced that the fragmentation rules allow 
for all cases to have the sample reconstructed. For example is seems 
that multiple fragments of boxes will not be guaranteed to be 
reconstructed in the correct order unless some other information is 
provided.

In general I would like to have a discussion of the need for the 
advanced fragmentation formats that is defined. Could not a simple 
fragmentation requiring all parts be sufficient. Are really there enough 
advantage of using the fragments when some are missing enough. Will it 
also not in some cases result in something that is more confusing the 
not presenting it at all would.

If one keeps this advance fragmentation then it is really need for a 
introduction part that talks about why and how this works.

15. Section 4.2 There is need for having guidelines on how to fragment. 
I think there are some fragmentation points that are advantageous.

16. Section 4.2.5, The use of this MSF field requires that the 
fragmentation of a "krok" is done at a boundaries of the 
highligth-offset entry.

17. Section 4.2.6: Last sentence in section: "Fragmentation MUST be done 
between the URL and the altLength fields." I guess this is conditionally 
if fragmentation is done.

18. Section 4.3: "   - All SIDX values present in the SPLDESC field of 
an RTP packet MUST be present in at least one of the text samples in the 
payload." I interpret this rule saying that within a RTP packet which 
carries the Sample descriptions the sample description must be included 
in the sample part. However I don't see a reason for this. All sample 
descriptions MUST be cached and can at any time be used. Therefore I see 
some advantage of allowing sample description only packets for example. 
  They can be given high protection with FEC. They can be given highest 
priority for retransmission. They can be sent in advance and verified as 
arrived if explicit packet loss vectors are used. So what is the reason.

19. Section 4.3.1: The SPLATTR field. I don't see why the fields are 
conditionally on the bit field to be present. In the sample description 
in the 3GP file all fields must always be present. Therefore I see a 
great simplification by removing the whole first 16 bits which contains 
flags if fields are present or not. Also if the fields would be 
conditionally present default values or derivation rules must be 
defined. As the number of sample descriptions are limited I don't see a 
reason for making this field minimal in bandwidth, I think simplicity is 
an advantage here.

20. Section 5.1: Why is not FEC with RFC 2733 mentioned?

21. section 6, second paragraph, last sentence: "Such a rule would 
translate in practice into the following actions: " I think "would" is 
rather "can". I also think one should be clearer that if one have a 
congestion control system being fair, then one may use as much bandwidth 
as the system allows for if deemed necessary. So in these cases the 
sender can use retransmission or FEC at a higher bit-rate then before. 
So the SHOULD NOT (next paragraph) is conditional if one knows that 
there is available bandwidth.

22. Section 8.1: Fragment variable: The values allow to be given are 
they "one" and "zero" or "1" or "0"? Also I don't like this variable as 
it results in duplication of a rather long "a=fmtp" line.

23. Section 8.1: brand: How does one handle the Release 6 brands that 
are several and the usage of brand compatible list?

24. Section 8.1: Version: pointing at the SDP section in the MIME 
registration is not acceptable as the MIME registration may be separated 
into another database.

25. Section 8.1: spldesc-inband: I think there are interesting cases 
where one would like to initially define some sample descriptions which 
is carried out-of-band, e.g. in SDP, and where one later may want to add 
more. I think there should be a "both" value for this parameter. Also 
the acceptable value should be clearly defined.

26. Section 8.1 width and height parameters: What is the unit of these 
parameter?

27. Section 8.1 Interoperability consideration: I think there are some 
to mention. As this format will support 3GPP timed text from different 
3GPP releases and some extension may be done in the future this should 
be discussed.

28. Section 9, The encoding of the sample descriptions: You mention that 
they are compressed why base64 only provides expansion to allow for 8 
bit binary in a set of characters acceptable for text protocol. Base 64 
has an expansion factor that 4 8-bit bytes becomes 5 base64 8 bit chars.

29. Section 10.1  The "a=control" header in SDP should point to the 
track of a 3GP file, e.g. "a=control:rtsp://server/example.3gp/trackID=2".
The meaning of "...example.3gp/text" is not defined.

30. Section 10.2 Example figures 1 and 2: I think there is something 
really wrong with the first figure: First it has SLEN which is SHALL NOT 
have. Secondly the FHDR header is not first. A receiver would not have 
any possibilities to decode these payloads as I see it.

31. section 11: The payload format shall be registering one MIME type, 
nothing more. There is no special action for IANA regarding the 
mentioned parameters.

32. Section 13: Reference list comments
- There is an updated version of reference 1 (V5.5.0).

- Reference 2 should point to "14496-12 | 15444-12".

- In my eyes reference 7, 8, 11 are normative.

33. Appendix B. I don't see how an informative Annex can have normative 
language. This is nothing this specification can determine. Any 
requirements are already part of the 3GPP specs.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt