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

[jan.vandermeer at philips.com]

Just my 2 cts on this issue. 

1) I agree that Type 1 units represent
the most common case and should not be removed.

2) Conceptually (at least in my view),
a timed text stream is a concatenation of data from subsequent "timed
text access units", whereby the data from each "timed text access
unit" may also contain one or more sample descriptions (SDs). Though
a time stamp has no relevance for the SD itself, from this conceptual point
of view, the time stamp of a SD should be equal to the time stamp of the
"timed text access unit" in which the SD is included. The text
that Colin suggests seems to be perfectly in line with the above, but perhaps
it would be beneficial to convey some text on the above concept as well.

Best regards,

Jan

Dave Singer <singer at apple.com> 07-02-2005 18:55

To:        Colin Perkins <csp at csperkins.org> Rey Jose <Rey at panasonic.de>         cc:        Jan vanderMeer/EHV/IPS/PHILIPS at PHILIPS IETF AVT WG <avt at ietf.org> Magnus Westerlund <magnus.westerlund at ericsson.com>         Subject:        Re: [AVT] Update (-09) of Timed Tex draft (WAS: RE: Comments on  draft-ietf-avt-rtp-3gpp-timed-text-08.txt)         Classification:

At 11:36 AM +0000 2/6/05, Colin Perkins wrote:
>Jose,
>
>On 3 Feb 2005, at 16:40, Rey Jose wrote:
>...
>>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.
>
>I would think it's a trivial change to the draft. Why the need to 
>include SDUR and prohibit piggy-backing? I'm suggesting 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.
>
>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.

I like this, it's much clearer to implement and understand.

>
>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).
>
>>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.
>
>Colin


-- 
David Singer
Apple Computer/QuickTime

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