Subject: RE: AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt

From: "Rey Jose" <[email-masked]>
Date: Tue, 18 Nov 2003 07:30:45 +0100

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Tuesday, November 18, 2003 1:36 AM
> To: Dave Singer
> Cc: Rey Jose; [email-masked]; 'IETF AVT WG'; Magnus
> Westerlund; Yoshinori Matsui
> Subject: Re: AW: [AVT] More comments on
> draft-rey-avt-rtp-3gpp-timed-text-01.txt
> 
> 
> On Tuesday, Nov 11, 2003, at 18:43 Europe/London, Dave Singer wrote:
> > At 17:27 +0100 11/11/03, Jose Rey wrote:
> >> Hi all,
> >>
> >> for those that did not attend the AVT session on Monday, 
> there was a
> >> number of comments and useful feedback during the timed text
> >> presentation.
> ...
> >> The current approach makes sense if the text samples are regularly 
> >> small
> >> and one or several of them fit into an RTP packet. 
> Fragmentation would
> >> happen seldom. The 'pure alf approach' is, in general, the most 
> >> correct
> >> one, and so also the one that requires more header definitions. If
> >> fragmentation is a rare event, this overhead may be not 
> worth (?).  
> >> The
> >> question to the group is pretty simple: which approach should be
> >> pursued?
> >
> > I think we can find a middle ground.  I think that text 
> samples over 
> > 512 bytes are quite rare, and over 1400 bytes very rare indeed.  I 
> > don't mind going to a format which is less file-format 
> centric, but I 
> > don't think we should spend a lot of time optimizing 
> fragmented text 
> > access units.
> 
> I think my question was more fundamental: do we need to support 
> fragments at all? Or is it possible, assuming the text generator is 
> aware of the network, that timed text samples can always be 
> made it fit 
> within the MTU?
> 
> Are the large samples an innate property of text, or an 
> artefact of the 
> process which can be avoided by careful coding?
> 

for live streaming, on-the-fly MTU adaptation sounds reasonable; however for the normal  streaming scenario should every 3gp text file be available as a streameable file in every possible MTU size? 

Jose

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Y. Matsui" <[email-masked]>
Date: Wed, 19 Nov 2003 03:19:02 +0900

Hi Jose, Colin,

> > >> for those that did not attend the AVT session on Monday, there was a
> > >> The current approach makes sense if the text samples are regularly small
> > >> and one or several of them fit into an RTP packet. Fragmentation would
> > >> happen seldom. The 'pure alf approach' is, in general, the most correct
> > >> fragmentation is a rare event, this overhead may be not worth (?). The
> > >> question to the group is pretty simple: which approach should be pursued?
> > >
> > > I think we can find a middle ground.  I think that text samples over
> > > don't mind going to a format which is less file-format centric, but I
> > > don't think we should spend a lot of time optimizing fragmented text
> > > access units.
> >
> > fragments at all?

I think fragmentation should be supported, though it must be very rare.

> > Or is it possible, assuming the text generator is
> > made it fit within the MTU?

This could be a recommendation or guideline for text sample creators.

I think it may not be needed to define heavy fragment header for only
very rare case.  However, the payload format for timed text should
allow at least the simple fragment of text sample, in order to
support the timed text specification without any restrictions.

> > Are the large samples an innate property of text, or an artefact of the

A possible example of the large sample would be the ending roll of the movie.

> for live streaming, on-the-fly MTU adaptation sounds reasonable; however
> for the normal  streaming scenario should every 3gp text file be
> available as a streameable file in every possible MTU size?

Best regards,
Yoshinori Matsui
Panasonic/Matsushita

---

From: Dave Singer <[email-masked]>
Date: Tue, 18 Nov 2003 10:25:05 -0800

I agree with Matsui-san.  Large samples (e.g. a "ticker tape" which 
scrolls a long time, or the ending credits of a movie, likewise) 
might happen, but are rare.  The most we should do is allow you to 
find the string-length (and hence the beginning of the modifier 
boxes).  This might be as naive as putting the beginning of the 
modifier boxes at a packet boundary -- which also means you might 
send them twice, or whatever (very half-formed thought, you 
understand).

-- 
David Singer
Apple Computer/QuickTime