[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

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


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