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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Oct 2003 12:53:40 +0200

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:

> 
>>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...
> 
Yes, I think so.

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

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.

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

So you are saying that you will have a different payload type for 
payloads with SPLDESC compared to the ones without. 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.

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

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.

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

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.

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

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.

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

Yes, at least I think so. There has been a while since I wrote these 
comments.

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

I don't now about the answer to your question.

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

I think that sounds more reasonable.

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

Good, I hope it can be implemented without a lot of complexity.

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

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.

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

Then please clarify that.

> 
> 
>>Also I don't like this 
>>variable as 
>>it results in duplication of a rather long "a=fmtp" line.
> 
> 
> what do you propose instead?

As I have written previous I would suggest that you drop the whole PT 
multiplexing for presence or not of FHDR, etc.

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

Looks good

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

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

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