Subject: Re: [AVT] Update (-09) of Timed Tex draft (WAS: RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)

From: Colin Perkins <[email-masked]>
Date: Sun, 1 May 2005 19:31:01 +0100

Jose,

On 21 Apr 2005, at 10:45, Jose Rey wrote:
...
>>> On this regard, this discussion in the intro of section 4 was moved 
>>> to
>>> 4.5, where the following was added:
>>>
>>>      Regarding sample descriptions in aggregate payloads: since TYPE 
>>> 5
>>>      units may potentially apply to several units in the stream, a
>>>      sender shall ensure that a copy of the sample description is
>>>      received before the affected text sample is due.  Therefore, a
>>>      copy of the sample description SHOULD be placed in the payload
>>>      before the text sample it applies to.  Of course, if several 
>>> text
>>>      samples in a payload use the same sample description, once per
>>>      payload is enough.  A sender MAY choose to omit the sample
>>>      description if it knows by some other means, such as payload
>>>      specific feedback messages [21], that the sample description has
>>>      arrived at the receiver or if it employs additional transport
>>>      resiliency measures (Section 5), for example.
>>
>> I would suggest changing this to:
>>
>> 	Correct reception of TYPE 5 units is important since their contents
>> 	may be referenced by several other units in the stream. Accordingly,
>> 	they MUST be given at timestamp not later than that given to those
>> 	other units. It may be desirable to resend the sample descriptions
>> 	periodically, or to use other transport resiliency mechanisms.
>>
>> since the text in the draft implies that a copy of the sample
>> description is sent in every packet, rather than allowing it
>> to be sent once and referenced by later packets.
>>
>
> Since it is the codec that shall buffer the SDs, then it is possible 
> in some cases to 'skip' putting SDs in every single payload and be (or 
> just relatively) confident that the units will be correctly displayed: 
> for cases such as reliable channels or when the server knows the SD 
> was received by other means; hence, I thought of a SHOULD and not a 
> MUST. Would this text be fine?
>
> --
> Correct reception of TYPE 5 units is important since their contents 
> may be referenced by several other units in the stream.  Sample 
> descriptions MUST be placed in the aggregate payload before the 
> occurrence of any non-TYPE 5 units and MUST receive the RTP timestamp 
> of that packet.

This is fine.

> Additionally, it is RECOMMENDED to include a copy of the sample 
> description if referencing text samples are present.  This is because 
> the decoder is, in general, not able of using the text sample if the 
> sample description is missing.  Of course, if several text samples in 
> a payload use the same sample description, once per payload is enough.

> Nevertheless, a sender MAY choose to omit the sample description if it 
> knows by some other means, such as payload specific feedback messages 
> [21], that the sample description has arrived at the receiver or if it 
> employs additional transport resiliency measures (Section 5), for 
> example.

These are okay, but not particularly clearly written. I suggest 
rewording them as:

	Receivers are unable to use text samples until their corresponding
	sample description is received.  Accordingly, a sender should send
	multiple copies of a sample description to ensure reliability (see
	section 5). Receivers can use payload specific feedback messages
	[21] to tell a sender that they have received a particular sample
	description.

> Note that sending a sample description together with every text sample 
> (or set of samples) may result in a situation where the same sample 
> description is present in the receiver buffer many times, but with 
> different timestamp values.  This is a desing choice to ensure correct 
> reception of sample descriptions and may cause moderate overhead.

I'm not sure this part's appropriate, since it assumes a particular 
receiver buffer implementation strategy.

Colin

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