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

["Rey Jose" <Rey at panasonic.de>]

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: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of jan.vandermeer at philips.com
	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 <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