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

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

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