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

From: "Rey Jose" <[email-masked]>
Date: Tue, 8 Feb 2005 23:08:00 +0100

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Tuesday, February 08, 2005 9:49 AM
> To: Rey Jose
> Cc: IETF AVT WG
> Subject: Re: [AVT] Update (-09) of Timed Tex draft (WAS: RE: 
> Comments ondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
> 
> Hi,
> 
> 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. 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. To make this work we need to 
> possibility to provide the type 5 with a TS even if it is 
> sent very long after the first usage of that sample description.
> 
> As I can see it we can get this TS in two ways. First 
> proposal would be to use the existing model, which would mean 
> equipping the TYPE 5 with a SDUR field to provide duration 
> until the next unit. However the semantics is not clear, as 
> the SD has a usage duration, however it may not be known or 
> be infinite, and in this case if would simply be a TS offset 
> field for the next unit.
Seems easier than below..

> 
> Alternative 2 would be to provide the TYPE 5 with an explicit 
> TS indication (4 bytes) and maintain the current model for 
> the other types, however that would mean that the RTP TS 
> would reflect the other types timestamp and not the SD at 
> all. This would not follow the usual behavior of RTP TS 
> according to the first content, however it may be 
> advantageous. The reason is that if you have a periodic 
> repeat of any dynamic SD during a long lived multicast 
> session, your timestamp will otherwise make big backwards 
> jump for each packet that contain a repetition.
> 

Option two is not addressing the concerns of Colin, namely non-standard RTP handling, because the TYPE 5 TS would not be visible until you extract the packet from buffer, sometimes too late, so that is not a solution.  If we are going for this line, easier would be to keep the solution as is now.  

Got to think more about it...

José

> Opinions on this?
> 
> 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: Magnus Westerlund <[email-masked]>
Date: Wed, 09 Feb 2005 09:29:05 +0100

> Option two is not addressing the concerns of Colin, namely non-standard RTP handling, because the TYPE 5 TS would not be visible until you extract the packet from buffer, sometimes too late, so tha…

Yes, not putting the earliest timestamp in the RTP header will prevent 
any entity pre-depacketization to determine from when the SDs can be 
used. Assuming that we avoid this and go with a TYPE 5 packet that has a 
TS offset field (32 bits). Then we need to add text that the jitter 
calculation becomes basically useless if one sends dynamic SDs that are 
repeated. This due to the periodically jump in the TS backwards when one 
includes the repeated SDs. I would also recommend that the TS offset 
field is not called SDUR, because this is not the sample duration, it is 
only a TS offset to the next unit.

Cheers

Magnus Westerlund