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

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Apr 2005 19:36:36 +0100

On 8 Feb 2005, at 08:48, Magnus Westerlund wrote:
> I am in support of this change, however as outline below I don't think 
> we have thought yet of all the issues.
>
> Rey Jose wrote:
>> Jan,
>>  this would simply translate into requiring that the SD is assigned 
>> the timestamp of the RTP packet in which is contained. That is:
>> "TYPE 5 units are an exception: TYPE 5 units receive their timestamp 
>> from the RTP packet in which they are contained.  These 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."
> I don't think it will be this simple. We must consider how we assign 
> timestamps to SDs and when packet losses occurs. Let me give an 
> example:
>
> Packet 0: Type 1: SIDX=1
>
> Packet 1: Type 5: SIDX=2
>           Type 1: SIDX=2
>
> Packet 2: Type 1: SIDX=2
>
> Packet 3: Type 5: SIDX=2 (Repetition)
>           Type 1: SIDX=2
>
> IF you in the above case would loose packet 1, you can only utilize 
> packet 2 if you get packet 3 and its SD.

This is the behaviour in the -09 draft, yes.

> With the proposed timestamp model, the timestamp of the TYPE 5 unit in 
> packet 3 should have a TS equal to the TS of packet 1, rather than the 
> TS of packet 3 to indicate that it is useful from the TS time of 
> packet 1.

Why? If you give the type 5 unit sent in packet 3 the timestamp of 
packet 3, then the behaviour is unchanged from the previous, except 
that the timing model is used to decode the data.

Colin

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Apr 2005 13:40:09 +0200

> packet 3, then the behaviour is unchanged from the previous, except that 
> the timing model is used to decode the data.

The reason is that otherwise, you would not care to depacketize packet 3 
until after you have tried to consume packet 2 and failing that due to 
lack of sample description, and moved on. That assumes the quite common 
buffering strategy of sorting packets in timestamp order. Of course it 
might be the fact that 3GPP timed text, just like AMR works best with a 
post depacketized buffering structure. However as this buffer is sorted 
in timestamp order with samples. It would still make most sense to have 
the sample descriptors having a timestamp equal to there first valid 
point. That way they get sorted into the same time as they are first used.

Cheers

Magnus

-- 

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]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 13 Apr 2005 12:47:56 +0100

Magnus,

On 13 Apr 2005, at 12:40, Magnus Westerlund wrote:
>>> With the proposed timestamp model, the timestamp of the TYPE 5 unit 
>>> in packet 3 should have a TS equal to the TS of packet 1, rather 
>>> than the TS of packet 3 to indicate that it is useful from the TS 
>>> time of packet 1.
> The reason is that otherwise, you would not care to depacketize packet 
> 3 until after you have tried to consume packet 2 and failing that due 
> to lack of sample description, and moved on.

Yes, of course. That's exactly the behaviour that was defined in the 
earlier versions of the draft, which made the Type 5 units available 
for use as soon as they arrived.

The changes in the latest versions of the draft add a lot of complexity 
for very minimal benefit (i.e. they help if you have packet loss in 
between two repetitions of a type 5 unit and a playout buffer long 
enough such that the repeated copy of the unit arrives before the data 
referencing the first has been played out). I just don't think the 
added complexity is worth it for this use case.

Colin