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

["Jose Rey" <Jose.Rey at eu.panasonic.com>]

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
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt