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

From: José Rey <[email-masked]>
Date: Fri, 24 Oct 2003 11:54:34 +0200

Hi Magnus,all

First of all, thanks to you and Per for the comments.  Please see inline:

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 1:54 PM
> To: Jose Rey; IETF AVT WG
> Cc: Dave Singer
> Subject: Comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt
> 
> 
> 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.

OK

> 
> 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.
> 
OK

> 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
> 
OK

> 5. How do you plan to handle the Release 6 update and definitions?
> 
Could you be more specific in your question?

> 6. Section 2, last paragraph, stray ".".
> 
> 7. Section 4. Marker bit definition. Needs normative MUST. 
> Some note on 
> multi sample packets.

OK.
> 
> 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.
> 

This is described in the text as you say above, as no negative SDUR values are defined.  It seems this needs further clarification...

> 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.

This is a mistake. It should read: "Payload Type (PT): the payload type is set dynamically by out-of-band means. "

> 
> 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.

Right, this is not specified. I think the best solution here is to add (reuse) a new (the fragment) header field carrying some type of fragment numbering for those having the same TS. This is much easier.  

> 
> 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."

OK.

> 
> 12. Figure 1, 2, 3, 4. I think there is not clear how a 
> receiver will be 
> able to distinguish between the cases. 

This is the same observation as in item 10 above.

> 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. 

The presence of SPLDESC is signalled using SDP. The SPLDESC is always at least one byte long = the entry count byte.  A value of zero is allowed for the entry count field.

As for the presence of the rest: FHDR is indicated in SDP and for THDR in the FHDR itself (T=1)

> 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.

Correct. To avoid this, is it not possible to associate the sample descriptions and just write the contents in one line? I think this should be possible through some new SDP attribute and defining the behaviour of the receiver. This way the PT-multiplexing still works fine.

> 
> 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?

The motivation for SLEN is for packets containing several whole text samples, to allow the receiver to jump from one sample to another, as a kind of indexing. In the case the RTP packet only contains one text sample, SLEN is theoretically not needed; however we thought making an exception here would make it all too confusing. 

> In my opinion 
> knowing the total length of the fragmented sample allows one 
> to allocate 
> the correct buffer for that sample.
> 
I think this is an implementation issue.  In general packet sizes are not included in RTP and buffering works anyway. I don't see why the sizes should be used in this particular case to reserve buffer in advance, specially given the low bitrates.

> 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.

I think you mean the same as in 10 and 12 with the reassembly. 

> 
> 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.

We developed the fragmentation headers because 3GPP timed text allows in principle for bigger packets (until 2048 bytes) and didn't want to leave that out. We also didn't assume the use of FEC, for simplicity.

We realize that the FHDR increments the complexity of the draft. If fragmentation happens seldom, we agree it is convenient to reduce the complexity of the headers, i.e. to a mere counter of the fragments. Therefore we would agree to simplify them if no one else has an application/use case for that. Does anyone feel the advanced fragmentation headers as they are in the draft now are needed?

> 
> 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.

I think this is the same we mean in the text. Each entry starts with a field "highlight-end-time" which is I guess what you call highlight-offset.

> 
> 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.

Of course, we'll add some wording.
> 
> 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. 

This is not what is meant; descriptions are only present once. What we meant to be present in both SPLDESC and text samples is the SIDX value to be able to pair them. This has two reasons: 1) in principle, SPLDESC was thought for live streaming and 2) feedback might not always be available, so that the sender doesn't know the received descriptions. But it might be used for other things, as you point out. So we can abolish the restriction and make a note saying that the sender shall provide the means for the receiver to have all descriptions available for the received text samples whether there's feedback or not: using retransmissions, include the descriptions again or protect them with FEC appropriately.

> 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.
> 
I like the idea of using sample-description-only packets. A bit of the initial entry count field could be used to indicate there are any (SIDX,SPLATTR) pairs following or is just a sample-description-only packet.

> 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.

Yes, this is more simple. We'll take that in the next draft.

> 
> 20. Section 5.1: Why is not FEC with RFC 2733 mentioned?
> 
is an option...can be included in next revision.

> 21. section 6, second paragraph, last sentence: "Such a rule would 
> translate in practice into the following actions: " I think 
> "would" is 
> rather "can".

OK

> 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.
> 
OK

> 22. Section 8.1: Fragment variable: The values allow to be given are 
> they "one" and "zero" or "1" or "0"? 
> 
"fragment=0" and "fragment=1" are possible values.

> Also I don't like this 
> variable as 
> it results in duplication of a rather long "a=fmtp" line.

what do you propose instead?

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

We'll work that out.

> 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.
> 
OK

> 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.

Agree,  how about :

"spldesc=in"
"spldesc=out"
"spldesc=both"

as possible values for in-band, out-of-band and both in- and out-of-band tx of sample descriptions?

> 
> 26. Section 8.1 width and height parameters: What is the unit 
> of these 
> parameter?
Pixels, will be indicated.

> 
> 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.

OK. Basically it is expected that 3GP files, also including timed text, will be extended while still keeping backwards compatibility, so old terminals can ignore attributes they don't understand. 

> 
> 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.

could you reword your question? I am not sure I understand what you mean. Base64 encoding was proposed in the last meeting in Vienna for h264 to reduce overhead in the transport of parameter sets instead of the usual base16 encoding which has an expansion factor of two.

> 
> 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.

OK, seems we forgot that.

> 
> 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.

Indeed. Cut&paste error.
> 
> 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.
> 
> 
OK

> 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.
> 

OK

> 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.

Yes, after re-reading the text I think references to the payload format itself should be removed and so reduce the scope to the merely informative.
 
thanks again, 

José

> 
> 
> 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

---

From: José Rey <[email-masked]>
Date: Fri, 24 Oct 2003 15:03:26 +0200

Hi,

please see inline.

> Sent: Friday, October 24, 2003 12:54 PM
> To: Rey Jose
> Cc: 'IETF AVT WG'; 'Dave Singer'; Jan van der Meer (E-mail); Yoshinori
> Matsui (E-mail)
> Subject: Re: Comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt
> 
> 
> Hi José,
> 
> See comments and clarifications below. I hope that you will 
> be able to 
> speed up the process for this, if you want to meet the deadlines you 
> have targeted.
> 
> José Rey wrote:
> 
> > 
> > This is described in the text as you say above, as no 
> negative SDUR values are defined.  It seems this needs 
> further clarification...
> > 
> Yes, I think so.
> 
> > 
> > Right, this is not specified. I think the best solution 
> here is to add (reuse) a new (the fragment) header field 
> carrying some type of fragment numbering for those having the 
> same TS. This is much easier.  
> > 
> 
> Yes that will of course work. However it also gives one more 
> insecurity, 
> as you will not know when you should have received all fragments. The 
> potential problem as I see it if not all fragments are required to be 
> sent in RTP sequence number order is that the receiver having 
> lost some 
> packets from the start can't determine if the lost packets contained 
> fragments or not. However there might be some other advantage 
> of doing 
> as you propose it.
> 
> > 
> > The presence of SPLDESC is signalled using SDP. The SPLDESC 
> is always at least one byte long = the entry count byte.  A 
> value of zero is allowed for the entry count field.
> > 
> So you are saying that you will have a different payload type for 
> payloads with SPLDESC compared to the ones without. 

No. This is a remainder from the initial purpose for SPLDESC: live streaming. In live streaming there is no need to use the  4 PTs simultaneously. 

After all, with all these complications and changes/additions of fucntionality it seems reasonable to include the flags for this and the fragmentation headers in the fixed header bytes.

> Then you 
> will have a 
> different payload for presence of the FHDR or not. That makes it 
> necessary to have four payload types to allow for all four 
> combinations.
> 
> I think you should strongly reconsider the usage of payload type 
> multiplexing for this functionality. Problems I see with payload type 
> multiplexing:
> 
> - The eventual exhaustion of the payload format space. If the payload 
> formats starts using multiple payload formats for normal cases the 
> choice of using PT in the RTP retransmission format is probably a bad 
> one, as it doubles the number of used payload formats.
> - The need for having MIME parameter declaration for each and 
> everyone 
> of the payload format configurations.
> 
> Due to this and the mitigating factor that this payload format is not 
> extremely high packet rate to begin with, the inclusion of 1 byte per 
> header will not cause a massive increase in overhead.
> 
> I would propose that you actually spend a byte for indicating the 
> necessary header types, allowing for the use of a single 
> payload format 
> in the normal cases.
> 

OK, the SDP fix is not a good idea. Some bits for flags in the fixed header seem necessary.

> > Correct. To avoid this, is it not possible to associate the 
> sample descriptions and just write the contents in one line? 
> I think this should be possible through some new SDP 
> attribute and defining the behaviour of the receiver. This 
> way the PT-multiplexing still works fine.
> > 
> 
> As I point out above I don't think the usage PT multiplexing is the 
> correct choice for this format. I would also like to avoid having to 
> create a copy operation for the fmtp fields in SDP. We don't 
> need more 
> functionality in SDP, we need a better session description format.
> 

Yes. It doesn't seem to be appropriate, the comments above apply.

> > The motivation for SLEN is for packets containing several 
> whole text samples, to allow the receiver to jump from one 
> sample to another, as a kind of indexing. In the case the RTP 
> packet only contains one text sample, SLEN is theoretically 
> not needed; however we thought making an exception here would 
> make it all too confusing. 
> > 
> 
> Yes, I agree with your comments are bad, but you haven't answered why 
> there is a need for having a SLEN exception for the fragmented case.
> > 

see below

> > I think this is an implementation issue.  In general packet 
> sizes are not included in RTP and buffering works anyway. I 
> don't see why the sizes should be used in this particular 
> case to reserve buffer in advance, specially given the low bitrates.
> > 
> 
> Yes, I would agree that if would not be needed in the normal 
> case, but 
> we are in fact talking about fragmented samples that has no 
> given size 
> limit. They could in fact be as large as 100kbytes. 
> Depending on the 
> unlimited sample size
> I think it would be good to allow a receiver to 
> determine how big this sample is before trying to assemble 
> it. That it 
> also helps the implementations in some cases to do this 
> efficiently is 
> just a bonus.

If it is needed, the upper limit is given by SLEN, <=64Kbytes (16bits). Anyway, the headers have to be re-arranged. We shall then take your comments into account. 

> Yes, at least I think so. There has been a while since I wrote these 
> comments.
> 
> > 
> > 
> > We developed the fragmentation headers because 3GPP timed 
> text allows in principle for bigger packets (until 2048 
> bytes) and didn't want to leave that out. We also didn't 
> assume the use of FEC, for simplicity.
> > 
> > We realize that the FHDR increments the complexity of the 
> draft. If fragmentation happens seldom, we agree it is 
> convenient to reduce the complexity of the headers, i.e. to a 
> mere counter of the fragments. Therefore we would agree to 
> simplify them if no one else has an application/use case for 
> that. Does anyone feel the advanced fragmentation headers as 
> they are in the draft now are needed?
> > 
> 
> I don't now about the answer to your question.
> 
> > This is not what is meant; descriptions are only present 
> once. What we meant to be present in both SPLDESC and text 
> samples is the SIDX value to be able to pair them. This has 
> two reasons: 1) in principle, SPLDESC was thought for live 
> streaming and 2) feedback might not always be available, so 
> that the sender doesn't know the received descriptions. But 
> it might be used for other things, as you point out. So we 
> can abolish the restriction and make a note saying that the 
> sender shall provide the means for the receiver to have all 
> descriptions available for the received text samples whether 
> there's feedback or not: using retransmissions, include the 
> descriptions again or protect them with FEC appropriately.
> > 
> 
> I think that sounds more reasonable.
> 
> > 
> > 
> > 
> > I like the idea of using sample-description-only packets. A 
> bit of the initial entry count field could be used to 
> indicate there are any (SIDX,SPLATTR) pairs following or is 
> just a sample-description-only packet.
> > 
> 
> Good, I hope it can be implemented without a lot of complexity.
> 
> > 
> > 
> I think this is one of the formats that may really need to 
> use FEC for 
> at least any SPDLDESCRs, this is especially for multicast 
> distribution 
> cases, but also for unicast.
> 
> Then please clarify that.
> 
> > 
> > 
> >>Also I don't like this 
> >>variable as 
> As I have written previous I would suggest that you drop the whole PT 
> multiplexing for presence or not of FHDR, etc.
> 

Yes, the SDP fix seems too complex, thanks.
> > as possible values for in-band, out-of-band and both in- 
> and out-of-band tx of sample descriptions?
> 
> Looks good
> 
> > 
> > could you reword your question? I am not sure I understand 
> what you mean. Base64 encoding was proposed in the last 
> meeting in Vienna for h264 to reduce overhead in the 
> transport of parameter sets instead of the usual base16 
> encoding which has an expansion factor of two.
> > 
> 
> YEs, this is nit picking. If you compare the binary save sample 
> description, that will have a size of X. Then the BASE64 
> encoded will no 
> t be compressed but rather expanded in regards to the binary. 
> OF course 
> it is better than BASE16, but that what not what I was seeing as the 
> base line.
> 
> 

cheers,

José