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

From: "Jose Rey" <[email-masked]>
Date: Wed, 13 Apr 2005 12:32:22 +0200

Colin, 

Thanks for the comments. Please see inline:

> Jose,
> 
> On 11 Feb 2005, at 14:31, Rey Jose wrote:
> > Jan and I have discussed this offline and came with the following 
> > proposal, which is much simple and requires almost no changes. It 
> > doesn't mess up the timestamp while still associating a TS 
> to SDs (in 
> > some way). As follows:
> >
> > 1.- if a text sample needs an SD SHOULD include it always 
> *before* the 
> > text samples it applies to.
> > 2.- SD become available for use as indicated by the TS in 
> the packet 
> > so even if more than one (SD,TextSample) pair is present in 
> the packet 
> > this is valid since they are timely ordered. If some SDs 
> are available 
> > 'too early', so what?
> > 3.- if you send spare SDs nothing changes, only there are no text 
> > samples
> > 4.- The SHOULD in 1) is not a MUST because there may be 
> cases you can 
> > relax this, e.g., SDs can be omitted if the server knows that these 
> > are available at the client. This allows applications that 
> can 'live'
> > with some SD losses and still display something useful
> 
> This, and the text that is in -13, seem to be unnecessarily 
> complex. We talked about changing:
> 
>          TYPE 5 units are exception: TYPE 5 units do not make 
> use of the
>          timestamp, but instead become active upon reception 
> and not at
>          the time instant indicated by the timestamp.  
> Therefore, if RTP
>          packets contain only one TYPE 5 unit or only (several) TYPE 5
>          unit(s), the RTP timestamp SHALL be set to the 
> current value of
>          RTP timestamp plus one.  Adding one (1) unit, as 
> opposed to just
>          using the current timestamp, further allows the use of the
>          timestamp for identifying RTP packets that carry fragments of
>          the same text sample.
> 

This text is not in -13 anymore.  It was removed in -12.

Currently, TYPE 5 units receive the timestamp as per s. 4.5 in http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed-text-13.txt, I quote:

	In general, TYPE 5 units MUST receive their timestamp from the first non-TYPE 5 unit following them in the payload.
	However, if: 
	o	the payload only contains (one or several) TYPE 5 units or,
	o	if one or several TYPE 5 units follow a sample of unknown duration (see Section 4.1.2, SDUR definition),

	then (all) TYPE 5 units MUST use the RTP timestamp.  

> into something like:
> 
>          TYPE 5 units are exception: TYPE 5 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.

Prohibiting that a particular SIDX value is used by a previous unit is not OK, since the same sample description may be used by different text samples which have different timestamps.  On this regard, this discussion in the intro of section 4 was moved to 4.5, where the following was added:

     Regarding sample descriptions in aggregate payloads: since TYPE 5 
     units may potentially apply to several units in the stream, a 
     sender shall ensure that a copy of the sample description is 
     received before the affected text sample is due.  Therefore, a 
     copy of the sample description SHOULD be placed in the payload 
     before the text sample it applies to.  Of course, if several text 
     samples in a payload use the same sample description, once per 
     payload is enough.  A sender MAY choose to omit the sample 
     description if it knows by some other means, such as payload 
     specific feedback messages [21], that the sample description has 
     arrived at the receiver or if it employs additional transport 
     resiliency measures (Section 5), for example.

> 
> which to me seems much clearer than the text in section 4.5 
> of draft -13. I don't understand the objections raised about 
> sending duplicate type 5 data: surely if you give such 
> duplicate data the timestamp of the packet in which it's 
> sent, you get exactly the same semantics as in the earlier 
> draft, while retaining the RTP timing model and accurate 
> jitter calculations?
> 
Sorry, exactly, which comments do you mean? In -13? 

Cheers,

José

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Wed, 13 Apr 2005 13:15:24 +0100

Jose,

> This text is not in -13 anymore.  It was removed in -12.

Yes, I know.

> Currently, TYPE 5 units receive the timestamp as per s. 4.5 in  
> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-3gpp-timed- 
> text-13.txt, I quote:
>
> 	In general, TYPE 5 units MUST receive their timestamp from the first  
> non-TYPE 5 unit following them in the payload.
> 	However, if:

You missed some of the complexity. The full quote is:

    o Regarding timestamp calculation: in general, the rules for
      calculating the timestamp of units in an aggregate payload depend
      on the type of unit.  Based on the possible constellations for
      aggregate payloads as above we have:

           o For the first case: the first step is to calculate the
              timestamp of the TYPE 1 units as if there were no TYPE 5
              units present.  Since units MUST be placed in play-out
              order, i.e., earliest first in the payload, the timestamp
              of any unit different from the first one MUST be obtained
              by adding the sample duration and timestamp (both) of the
              preceding TYPE 1 unit.

           o For the second and third case, all units, TYPE 2, 3 and 4,
              MUST receive the timestamp from the RTP header.

           Once the timestamp of the non-TYPE 5 units has been
           calculated the next step is to calculate the TYPE 5 units'
           timestamps.  This procedure depends on the composition of the
           payload:

            o In general, TYPE 5 units MUST receive their timestamp from
              the first non-TYPE 5 unit following them in the payload.
            o However, if:

                o the payload only contains (one or several) TYPE 5
                   units or,
                o if one or several TYPE 5 units follow a sample of
                   unknown duration (see Section 4.1.2, SDUR definition),

            o Finally, if there are no non-TYPE 5 units that follow, but
              only non-TYPE 5 units before the sample description (e.g.,
              the sample description is piggy-backed), then the
              timestamp of the sample description MUST be calculated in
              the usual way, i.e. by adding sample duration and
              timestamp value of the last unit encountered.  In practice
              this is the timestamp value that the subsequent non-TYPE 5
              unit would have (if present) and so the procedure is the
              same as in the first case above (see case a in Figure 10
              for an example).

            Refer to detailed examples on the timestamp calculation in
            Section 4.5

            Note that for TYPE 5 units, the timestamp actually does not
            represent the instant when they are played out, but instead
            the instant at which they become available for use.

I'm struggling to understand why the timestamp definition has to be so  
complex.  The additional rules regarding Type 5 units don't seem to be  
necessary, and will likely lead to confusion and implementation errors.

> Prohibiting that a particular SIDX value is used by a previous unit is  
> not OK, since the same sample description may be used by different  
> text samples which have different timestamps.

I don't understand your comment - the statement that a "sample  
description conveyed in a TYPE 5 packet MUST NOT be referenced by a  
unit with earlier timestamp" is simply that type 5 units are sent  
before they are used. You seem to be suggested that they can be used  
before they're transmitted?

> On this regard, this discussion in the intro of section 4 was moved to  
> 4.5, where the following was added:
>

I would suggest changing this to:

	Correct reception of TYPE 5 units is important since their contents
	may be referenced by several other units in the stream. Accordingly,
	they MUST be given at timestamp not later than that given to those
	other units. It may be desirable to resend the sample descriptions
	periodically, or to use other transport resiliency mechanisms.

since the text in the draft implies that a copy of the sample  
description is sent in every packet, rather than allowing it to be sent  
once and referenced by later packets.

> Sorry, exactly, which comments do you mean? In -13?

See my other message, to which Magnus replied.

Colin