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

[jan.vandermeer at philips.com]

Magnus, Jose

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

I have problems with this time stamp
interpretation for TYPE 5 units, which, if I understand correctly, results
from the current notion that the time stamp of a TYPE 5 unit indicates
when the TYPE 5 unit becomes available for use.

In my view, there should be no relationship
at all between the TYPE 5 units and time stamps, not even an indication
when they become available for use. A packet that contains data from a
"timed text access unit" carries the time stamp associated to
that  "timed text access unit", but for a contained TYPE
5 unit that time stamp has no meaning. The SD contained in a TYPE 5 unit
will be used in future, but when may be unknown at reception. A notion
of "when it becomes available for use" has very little meaning
in my view. I suggest the time stamp model fully ignores TYPE 5 units;
assigning "time" to TYPE 5 units complicates the problem, while
I think there is no need for that.

Best regards,

Jan

Magnus Westerlund <magnus.westerlund at ericsson.com> Sent by: avt-bounces at ietf.org 08-02-2005 09:48

To:        Rey Jose <Rey at panasonic.de>         cc:        IETF AVT WG <avt at ietf.org> (bcc: Jan vanderMeer/EHV/IPS/PHILIPS)         Subject:        Re: [AVT] Update (-09) of Timed Tex draft (WAS: RE: Comments        ondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)         Classification:

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

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