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

From: "Rey Jose" <[email-masked]>
Date: Thu, 3 Feb 2005 17:40:44 +0100

[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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sun, 6 Feb 2005 11:36:54 +0000

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

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

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

---

From: Dave Singer <[email-masked]>
Date: Mon, 7 Feb 2005 09:55:22 -0800

At 11:36 AM +0000 2/6/05, Colin Perkins wrote:
>>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.
>
>         played out, but instead the instant at which they become available
>         for use. A sample description conveyed in a TYPE 5 packet MUST NOT

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

---

From: [email-masked]
Date: Mon, 7 Feb 2005 22:05:20 +0100

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 <[email-masked]>
07-02-2005 18:55
 
        To:     Colin Perkins <[email-masked]>
Rey Jose <[email-masked]>
        cc:     Jan vanderMeer/EHV/IPS/PHILIPS@PHILIPS
IETF AVT WG <[email-masked]>
Magnus Westerlund <[email-masked]>
        Subject:        Re: [AVT] Update (-09) of Timed Tex draft (WAS: 
RE: Comments on  draft-ietf-avt-rtp-3gpp-timed-text-08.txt)
        Classification: 

available
NOT

-- 
David Singer
Apple Computer/QuickTime