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

From: jan.vandermeer at philips.com [mailto:jan.vandermeer at philips.com]
Sent: Thursday, February 10, 2005 12:16 AM
To: Rey Jose
Cc: IETF AVT WG; avt-bounces at ietf.org; Magnus Westerlund
Subject: RE: [AVT] Update (-09) of Timed Tex draft (WAS: RE: Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)

Hello Jose,

Pulling TYPE 5 units out in TS order is fine, but for TYPE 5 units itself TSs are meaningless, and therefore no relationship between a time stamp and a TYPE 5 unit should be defined. I may be wrong, but in my view the current problem is caused by assiging a meaning to TSs for SDs (indicating the instant in time when the TYPE 5 unit becomes available for use). SDs just arrive in TYPE 5 units, and they should in principle be present prior to their use. The exact time at which they become available does not matter at all, as long as the SD is present prior to its use. So my suggestion to move forward is to leave the TYPE 5 unit as is, but to change your suggested text below into something along the following lines:

"TYPE 5 units are an exception: though time stamps are meaningless for TYPE 5 units, TYPE 5 units receive their time stamp from the RTP packet carrying the most recent text sample data received prior to the sample description. The TYPE 5 unit conveys a sample description that may be used by many samples, and is removed from the play-out buffer upon reception in time stamp order. Typically, a sample description conveyed in a TYPE 5 packet should not be referenced by a unit with an earlier timestamp, unless the sample description is currently in use and included for random access purposes."

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. 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. 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