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

["Rey Jose" <Rey at panasonic.de>]

> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund at ericsson.com] 
> 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: magnus.westerlund at ericsson.com
> 
> 


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt