[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Update (-09) of Timed Tex draft (WAS: RE:Commentsondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
Jose,
On 13 Apr 2005, at 11:32, Jose Rey wrote:
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.
Yes, I know.
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.
You missed some of the complexity. The full quote is:
o Regarding timestamp calculation: in general, the rules for
calculating the timestamp of units in an aggregate payload depend
on the type of unit. Based on the possible constellations for
aggregate payloads as above we have:
o For the first case: the first step is to calculate the
timestamp of the TYPE 1 units as if there were no TYPE 5
units present. Since units MUST be placed in play-out
order, i.e., earliest first in the payload, the timestamp
of any unit different from the first one MUST be obtained
by adding the sample duration and timestamp (both) of the
preceding TYPE 1 unit.
o For the second and third case, all units, TYPE 2, 3 and 4,
MUST receive the timestamp from the RTP header.
Once the timestamp of the non-TYPE 5 units has been
calculated the next step is to calculate the TYPE 5 units'
timestamps. This procedure depends on the composition of the
payload:
o In general, TYPE 5 units MUST receive their timestamp from
the first non-TYPE 5 unit following them in the payload.
o 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.
o Finally, if there are no non-TYPE 5 units that follow, but
only non-TYPE 5 units before the sample description (e.g.,
the sample description is piggy-backed), then the
timestamp of the sample description MUST be calculated in
the usual way, i.e. by adding sample duration and
timestamp value of the last unit encountered. In practice
this is the timestamp value that the subsequent non-TYPE 5
unit would have (if present) and so the procedure is the
same as in the first case above (see case a in Figure 10
for an example).
Refer to detailed examples on the timestamp calculation in
Section 4.5
Note that for TYPE 5 units, the timestamp actually does not
represent the instant when they are played out, but instead
the instant at which they become available for use.
I'm struggling to understand why the timestamp definition has to be so
complex. The additional rules regarding Type 5 units don't seem to be
necessary, and will likely lead to confusion and implementation errors.
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.
I don't understand your comment - the statement that a "sample
description conveyed in a TYPE 5 packet MUST NOT be referenced by a
unit with earlier timestamp" is simply that type 5 units are sent
before they are used. You seem to be suggested that they can be used
before they're transmitted?
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.
I would suggest changing this to:
Correct reception of TYPE 5 units is important since their contents
may be referenced by several other units in the stream. Accordingly,
they MUST be given at timestamp not later than that given to those
other units. It may be desirable to resend the sample descriptions
periodically, or to use other transport resiliency mechanisms.
since the text in the draft implies that a copy of the sample
description is sent in every packet, rather than allowing it to be sent
once and referenced by later packets.
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?
See my other message, to which Magnus replied.
Colin
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt