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

From: "Rey Jose" <[email-masked]>
Date: Tue, 8 Feb 2005 00:44:30 +0100

Jan,
 
this would simply translate into requiring that the SD is assigned the timestamp of the RTP packet in which is contained. That is:

"TYPE 5 units are an exception: TYPE 5 units receive their timestamp from the RTP packet in which they are contained.  These 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."

José

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Monday, February 07, 2005 10:05 PM
	To: Dave Singer; Rey Jose; Colin Perkins
	Cc: Magnus Westerlund; IETF AVT WG
	Subject: Re: [AVT] Update (-09) of Timed Tex draft (WAS: RE: Comments ondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)

	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:         

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

---

From: Dave Singer <[email-masked]>
Date: Mon, 7 Feb 2005 15:50:27 -0800

At 12:44 AM +0100 2/8/05, Rey Jose wrote:
>Jan,
>
>this would simply translate into requiring that 
>the SD is assigned the timestamp of the RTP 
>packet in which is contained. That is:
>
>
>"TYPE 5 units are an exception: TYPE 5 units 
>receive their timestamp from the RTP packet in 
>which they are contained.  These 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."
>
>
>José

This is fine.  Only allow TYPE5's to be first in 
the packet, then, or the only one (or else you 
might get a surprise after you've already 
processed some TTUs).

>	From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>[email-masked]
>	Subject: Re: [AVT] Update (-09) of Timed 
>Tex draft (WAS: RE: Comments 
>ondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
>
>
>
>	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
>
>
>
>
>
>
>
>
>
>	        Subject:        Re: [AVT] Update 
>(-09) of Timed Tex draft (WAS: RE: Comments on 
>draft-ietf-avt-rtp-3gpp-timed-text-08.txt)
>
>	        Classification:        
>
>
>
>
>
>

-- 
David Singer
Apple Computer/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 08 Feb 2005 09:48:57 +0100

Hi,

I am in support of this change, however as outline below I don't think 
we have thought yet of all the issues.

> "TYPE 5 units are an exception: TYPE 5 units receive their timestamp from the RTP packet in which they are contained.  These units can be used to convey sample descriptions that are used by many sa…
I don't think it will be this simple. We must consider how we assign 
timestamps to SDs and when packet losses occurs. Let me give an example:

Packet 0: Type 1: SIDX=1

Packet 1: Type 5: SIDX=2
           Type 1: SIDX=2

Packet 2: Type 1: SIDX=2

Packet 3: Type 5: SIDX=2 (Repetition)
           Type 1: SIDX=2

IF you in the above case would loose packet 1, you can only utilize 
packet 2 if you get packet 3 and its SD. With the proposed timestamp 
model, the timestamp of the TYPE 5 unit in packet 3 should have a TS 
equal to the TS of packet 1, rather than the TS of packet 3 to indicate 
that it is useful from the TS time of packet 1. To make this work we 
need to possibility to provide the type 5 with a TS even if it is sent 
very long after the first usage of that sample description.

As I can see it we can get this TS in two ways. First proposal would be 
to use the existing model, which would mean equipping the TYPE 5 with a 
SDUR field to provide duration until the next unit. However the 
semantics is not clear, as the SD has a usage duration, however it may 
not be known or be infinite, and in this case if would simply be a TS 
offset field for the next unit.

Alternative 2 would be to provide the TYPE 5 with an explicit TS 
indication (4 bytes) and maintain the current model for the other types, 
however that would mean that the RTP TS would reflect the other types 
timestamp and not the SD at all. This would not follow the usual 
behavior of RTP TS according to the first content, however it may be 
advantageous. The reason is that if you have a periodic repeat of any 
dynamic SD during a long lived multicast session, your timestamp will 
otherwise make big backwards jump for each packet that contain a 
repetition.

Opinions on this?

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: [email-masked]
Date: Wed, 9 Feb 2005 20:12:19 +0100

Magnus, Jose

Magnus wrote:

"With the proposed timestamp 
model, the timestamp of the TYPE 5 unit in packet 3 should have a TS 
equal to the TS of packet 1, rather than the TS of packet 3 to indicate 
that it is useful from the TS time of packet 1."

I have problems with this time stamp interpretation for TYPE 5 units, 
which, if I understand correctly, results from the current notion that the 
time stamp of a TYPE 5 unit indicates when the TYPE 5 unit becomes 
available for use.

In my view, there should be no relationship at all between the TYPE 5 
units and time stamps, not even an indication when they become available 
for use. A packet that contains data from a "timed text access unit" 
carries the time stamp associated to that  "timed text access unit", but 
for a contained TYPE 5 unit that time stamp has no meaning. The SD 
contained in a TYPE 5 unit will be used in future, but when may be unknown 
at reception. A notion of "when it becomes available for use" has very 
little meaning in my view. I suggest the time stamp model fully ignores 
TYPE 5 units; assigning "time" to TYPE 5 units complicates the problem, 
while I think there is no need for that.

Best regards,

Jan

Sent by: 
[email-masked]
08-02-2005 09:48
 
        To:     Rey Jose <[email-masked]>
        cc:     IETF AVT WG <[email-masked]>
(bcc: Jan vanderMeer/EHV/IPS/PHILIPS)
        Subject:        Re: [AVT] Update (-09) of Timed Tex draft (WAS: 
RE: Comments    ondraft-ietf-avt-rtp-3gpp-timed-text-08.txt)
        Classification: 

Hi,

Rey Jose wrote:
> Jan,
> 
> this would simply translate into requiring that the SD is assigned the 
timestamp of the RTP packet in which is contained. That is:
> 
> 
> "TYPE 5 units are an exception: TYPE 5 units receive their timestamp 
from the RTP packet in which they are contained.  These 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."

Packet 0: Type 1: SIDX=1

Packet 1: Type 5: SIDX=2
           Type 1: SIDX=2

Packet 2: Type 1: SIDX=2

Opinions on this?

Cheers

Magnus Westerlund