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

["Rey Jose" <Rey at panasonic.de>]

[I included Jan and Dave] 


Inline:


> On 18 Jan 2005, at 14:53, Rey Jose wrote:
> ...
> >>   - Why are type 5 units untimed, rather than being timed 
> with their 
> >> sending time?
> > Because the sample description is strictly NOT a part of the text 
> > sample.  The timestamp is used for identifying the units 
> that belong 
> > to the same text sample.
> 
> Okay - but you give them a timestamp now.
> 
> >> It would fit the RTP model better if they were given a timestamp 
> >> indicating the time at which they become active
> >
> > Sample descriptions may be needed by several text samples, 
> cannot have 
> > two timestamps.  Also with duration is difficult since it 
> is not set 
> > in neither files or live streaming.  Further, when decoding a text 
> > sample it should be looked for the needed sample 
> descriptions.  If not 
> > available, the application decides how to display, if at all.  Most 
> > times will be possible, since sample descriptions only relate to 
> > formatting and position. Therefore a default formatting 
> could be used 
> > for that.  This is also explained in the draft.
> 
> I understand this. However, the payload format gives sample 
> descriptions a timestamp now, setting it equal to "the 
> current value of the RTP timestamp plus one" but ignoring it 
> on reception and assuming the sample descriptions become 
> available for use immediately the packet is received.
> 
> I am suggesting is that this is less than ideal, since a 
> receiver has to handle some RTP packets in the stream 
> according to the usual RTP timing model, but to ignore that 
> model for some other packets and decode them as soon as they 
> arrive. This makes an implicit assumption that the sample 
> description is to be used after the time it arrives - why not 
> make that explicit, with the RTP timestamp being the time at 
> which the sample description becomes available for use?
> 

Yes, the introduction of a timestamp for sample descriptions is artificial; just to distinguish it from the timestamp of a text sample (or fragment).  You really don't need it and that's why the header is small (no SDUR) and it can be put anywhere, even behind samples without duration. 

Changing this would be a major change to the draft, since the TYPE 5 header would have to include SDUR and cannot be piggy-backed anymore.

Is it worth for complying with the requirement above? (static sample descriptions don't include timestamp) 

> >> (and arrange the stream such that they cannot apply to 
> packets with 
> >> earlier timestamps).
> >>
> > This can never happen. I mean the server takes care that, 
> the SIDX are 
> > correctly synchronised, c.f. section on the dynamic SIDX.  
> Or maybe I 
> > don't get your question?
> 
> I understand that it can never happen. Why not make that 
> explicit in the use of the RTP timestamp?
> 
> >>   - It's not clear why type 1 packets are permitted to contain 
> >> modifiers? Why not enforce that they contain only text, 
> and aggregate 
> >> that text with a type 3 packets as appropriate?
> >
> > It seems simpler to give it all in one go to the app instead of 
> > forcing to paste the parts together for every sample.
> 
> This would only be simpler if modifier boxes were never sent 
> separately from the text. As it stands, a receiver must 
> support two different ways of getting the modifier. If we 
> remove support for type 1 packets, and always send either 
> text or modifiers, then a receiver has only one way of 
> getting the data. That would reduce the amount of code in the 
> receiver.
> 
> 
I understand. But, is the additional code such a burden? To outline the options once again: 1) currently you directly read out text samples from (and store into) the file or decoder and transport them on TYPE 1 units as they are.  Most server applications will probably have no need to send type 2 units, TYPE 2 is there for completeness. 2) On the other hand, if you elliminate TYPE 1, you would have to fragment & reassemble always. For small units this is overhead. 

Looking forward to your comments,

José
> The other changes in -11 look okay to me.
> 
> Colin
> 
> 
> 


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