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: Tue, 12 Apr 2005 19:36:59 +0100

Jose,

On 11 Feb 2005, at 14:31, Rey Jose wrote:
> Jan and I have discussed this offline and came with the following 
> proposal, which is much simple and requires almost no changes. It 
> doesn't mess up the timestamp while still associating a TS to SDs (in 
> some way). As follows:
>
> 1.- if a text sample needs an SD SHOULD include it always *before* the 
> text samples it applies to.
> 2.- SD become available for use as indicated by the TS in the packet 
> so even if more than one (SD,TextSample) pair is present in the packet 
> this is valid since they are timely ordered. If some SDs are available 
> 'too early', so what?
> 3.- if you send spare SDs nothing changes, only there are no text 
> samples
> 4.- The SHOULD in 1) is not a MUST because there may be cases you can 
> relax this, e.g., SDs can be omitted if the server knows that these 
> are available at the client. This allows applications that can 'live' 
> with some SD losses and still display something useful

This, and the text that is in -13, seem to be unnecessarily complex. We 
talked about changing:

         TYPE 5 units are exception: TYPE 5 units do not make use of the
         timestamp, but instead become active upon reception and not at
         the time instant indicated by the timestamp.  Therefore, if RTP
         packets contain only one TYPE 5 unit or only (several) TYPE 5
         unit(s), the RTP timestamp SHALL be set to the current value of
         RTP timestamp plus one.  Adding one (1) unit, as opposed to just
         using the current timestamp, further allows the use of the
         timestamp for identifying RTP packets that carry fragments of
         the same text sample.

into something like:

         TYPE 5 units are exception: TYPE 5 units can be used to convey
         sample descriptions that are used by many samples. Accordingly,
         their timestamp does not represent the instant when they are
         played out, but instead the instant at which they become 
available
         for use. A sample description conveyed in a TYPE 5 packet MUST 
NOT
         be referenced by a unit with earlier timestamp.

which to me seems much clearer than the text in section 4.5 of draft 
-13. I don't understand the objections raised about sending duplicate 
type 5 data: surely if you give such duplicate data the timestamp of 
the packet in which it's sent, you get exactly the same semantics as in 
the earlier draft, while retaining the RTP timing model and accurate 
jitter calculations?

Colin

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

---

From: "Jose Rey" <[email-masked]>
Date: Fri, 15 Apr 2005 15:53:50 +0200

Jan,

	Jose, 
	
	Sorry, I meant the SD buffer, not the SDIX buffer. 
	
	In my view, an SD is an element of the timed text stream, and the SD buffer an internal attribute of the timed text decoder. Within the SD buffer, each SD with a dynamic SDIX is stored until it is invalidated. The SD buffer is transport independent. 
	This is what I meant :) Only it seems a bit unusual to me to define how the codec should behave wrt dynamic SDs in a payload format?? I wanted to check if this is OK.
	 
	Cheers,

	José 
	 
	I hope that answers your question.
	 
	Best regards,
	
	Jan

"Jose Rey" <[email-masked]> 

15-04-2005 12:54 

        To:        Jan vanderMeer/EHV/IPS/PHILIPS@PHILIPS
"Jose Rey" <[email-masked]> 
        cc:        <[email-masked]>
"Colin Perkins" <[email-masked]>
"Magnus Westerlund" <[email-masked]>
"Dave Singer" <[email-masked]> 
        Subject:        RE: [AVT] Update (-09) of Timed Tex draft (WAS: RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt) 

        Classification:         

	Jan, 

	Jose, 
	
	> I.e., it cannot be that SDs be just discarded once they are used.
	
	Right, but in my view they are stored in an SIDX buffer until they are invalidated; when that is is not relevant. Or do I miss something ?   
	And where is the SD (not SIDX) buffer? What I want to say is (cf. answer to Dave) that dynamic SDs (and SIDX) are first introduced by this payload format and therefore codecs that use them have to implement the dynamic SIDX wrap-up algo to know how long to buffer SDs (at codec level).  This sounds a bit strange: a payload format setting requirement on a codec and that's why I am a bit doubtful this be OK(?) or am I missing something ?? 
	  
	Cheers, 
	José 

	Best regards,
	
	Jan
	
	[]

---

From: "Jose Rey" <[email-masked]>
Date: Fri, 15 Apr 2005 20:27:40 +0200

> >Such observation would go in a section titled something like 
> >"Requirements on decoders for supporting dynamic SDs" Does this make 
> >sense?
> >(BTW, I assume static SDs are always stored anyway for the 
> duration of 
> >the session, would be good to clarify, though)
> 
> yes, agreed.  But this is not unusual (that the decoder has 
> to handle new situations because of streaming).
> 

OK, perfect.

> Provided the sample descriptions have a 'suitable timestamp 
> for (a) their position in the stream and (b) before the 
> timestamp of the first AU that uses them, I don't see that 
> there is much of a problem.

Yes, this is clear. 

Cheers,

José

---

From: "Jose Rey" <[email-masked]>
Date: Thu, 21 Apr 2005 11:45:09 +0200

Colin,

once it is agreed (?) to change the timestamp rules to the easier option: where all sample descriptions are placed at the beginning before ocurrence of any non-TYPE5 units, the answer to the 2nd part of the email follows:

> You seem to be 
> suggested that they can be used before they're transmitted?
> 
> > 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.  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.  
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.  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.
--

If OK, I will submit a new draft asap,

Cheers,

José