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>]

Colin,

> 
>          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.
> 
> The benefit of doing this is that it makes it explicit when a 
> receiver gets access to the sample description data, as it is 
> released to the application in accordance with the RTP timing 
> model. I would also expect this to make a receiver 
> implementation simpler, since it doesn't have to special-case 
> the reception of TYPE 5 units by removing them from the 
> playout buffer early (as is currently required).
> 

Ok, I get it. This is no problem.

> > Is it worth for complying with the requirement above? 
> (static sample 
> > descriptions don't include timestamp)
> 
> Static sample descriptions are assumed to be received before 
> the session starts, so they don't need to include a 
> timestamp. For sample descriptions sent during a session, I 
> would have thought it beneficial to know when the receiver is 
> assumed to have received the data?
> 
> ...
> >> 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.
> 
> That depends on how you build your system, and how tightly 
> integrated the 3GPP timed text decoder is with the payload 
> format decoder. I would argue that it's cleaner from a 
> protocol design viewpoint to have only a single way of 
> transporting the data, rather than forcing both client and 
> server to implement two alternatives which do essentially the 
> same thing. Maybe the benefit from having TYPE 1 units is 
> worthwhile, but I'm a little concerned that the design is 
> being optimised for one particular case - streaming from a 
> pre-created timed text file across a network with known 
> characteristics - at the expense of others.
> 

I'll like to hear from Dave & Jan on this (and of course the WG!) since they are more onto implementation.

Cheers,

José




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