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

[Dave Singer <[e-mail]>]

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.
>
>In particular, it was suggested that the draft sticks too much to the
>3gp file format itself and does not look at the particularities of the
>RTP transport (Colin please correct me if the language is wrong).
>Currently the draft just reads the text samples from the 3gp file and
>puts them into RTP packets. If a packet is too big for one RTP packet
>then it is cut and a fragment header is used to be able to interpret the
>information in that fragment. As long as fragmentation happens rarely
>then this could be the best option.
>
>On the other side, there's the option (which I call 'pure ALF approach'
>in the slides) to preprocess the data read from the 3gp file before
>packetising. This preprocessing would not only cut the text samples to
>fix the RTP packet size but also re-arrange the packets so that the
>fragments are not only self-contained but contain all the decorations.
>This approach requires to define extra headers for the cases in which
>the modifier boxes would have to be split into several RTP packets.
>
>You can download some clarifying slides at
>http://www.pel.panasonic.de/ietf/docs/tt-design.pdf in pdf format or
>from http://www.pel.panasonic.de/ietf/docs/tt-design.ppt in MSPowerPoint
>format.
>
>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.

>
>
>We appreciate your feedback,
>
>cheers,
>
>
>Jose
>
>
>
>
>
>>  -----Ursprüngliche Nachricht-----
>>  Von: [e-mail] [mailto:[e-mail]]Im Auftrag von José
>>  Rey
>>  Gesendet: Montag, 10. November 2003 21:02
>>  An: [e-mail]; 'IETF AVT WG'
>>  Cc: Colin Perkins; Magnus Westerlund; 'Dave Singer'; Yoshinori Matsui
>>  Betreff: AW: [AVT] More comments on
>>  draft-rey-avt-rtp-3gpp-timed-text-01.txt
>>
>>
>>
>>  Jan, all,
>>
>>
>>  > -----Ursprüngliche Nachricht-----
>>  > Von: José Rey [mailto:[e-mail]]
>>  > Gesendet: Montag, 10. November 2003 18:11
>>  > An: Jose Rey
>>  > Betreff:
>>  >
>>  >
>>  > Dear Jose, all,
>>  >
>>  > I will not be in Minneapolis either but would like to provide
>>  > some input
>>  > on the issue of transport of 3GPP timed text. I know this
>>  > input is very
>>  > late; my appologies for that.
>>  >
>>  > As you know also MPEG is working on timed text; currently
>>  the Committe
>>  > Draft (CD) is ballotted, and MPEG schedules to enter the
>>  next phase in
>>  > about one month and to finish the work in July 2004. The
>>  > end-result will
>>  > be part 17 of MPEG-4, defining MPEG-4 text streams. Through
>>  liaisons,
>>  > MPEG tries to harmonize its work with the work that is
>>  already carried
>>  > out in 3GPP and also with ongoing work in W3C. Most
>>  important in this
>>  > respect is that MPEG focusses at maximum commonality with the
>>  > timed text
>>  > format defined by 3GPP for download. In summary, the current CD of
>>  > MPEG-4 part 17 specifies streaming of the 3GPP timed text format by
>>  > defining a very straightforward way to transcode the 3GPP
>>  format into
>>  > the MPEG-4 structure of a decoder configuration and text
>  > access units.
>>  > Please find the Committee Draft (a public document) attached to this
>>  > email. So far, 3GPP expressed through liaison statements to be very
>  > > pleased with the work done by MPEG.
>>  >
>>  > Once the work is finished, the timed text format can be
>>  streamed using
>>  > "RFC#simple", draft-ietf-avt-mpeg4-simple-08.txt, that is
>>  scheduled to
>>  > be published as RFC very soon. In summary this approach
>>  would work as
>>  > follows:
>>  > - media type: "video",
>>  > - MIME subtype name: mpeg4-generic,
>>  > - streamType (required parameter in RFC#simple): indicates
>>  MPEG-4 text
>>  > stream as defined in ISO 14496-17,
>>  > - profile-level-id (required parameter in RFC#simple): specifies the
>>  > functional subset as defined in the current 3GPP timed text
>>  > specification,
>>  > - config (required parameter in RFC#simple): carries the decoder
>>  > configuration specified for text streams in ISO 14496-17,
>>  > - the RTP payload contains either (a) one fragment of a text
>>  > access unit
>>  > or (b) one or more complete text access units,
>>  > - the RTP payload carries one AU-header for each carried text access
>>  > unit,
>>  > - in the RTP payload the concatenated AU-headers preceed
>>  concatenated
>>  > data of text access units, as defined in RFC#simple,
>>  > - each AU-header contains (at least) the following
>>  information on the
>>  > associated text access unit: (a) the size of the text
>>  access unit, (b)
>>  > the time stamp of the text access unit,
>>  > - if deemed necessary, the AU-header may also carry the index
>>  > of a text
>>  > access unit (fragment) and/or an indication whether the
>>  > associated text
>>  > access unit is a random access point.
>>  > In RFC#simple the fields in the AU-header are configurable, but if
>>  > desired one or two new modes for RFC#simple could be defined
>>  > with fixed
>>  > length fields, for example one using an 8 bit AU-size field
>>  (for most
>>  > common applications) and another using 16 bits AU-size field for
>>  > applications using (very) large text access units.
>>  >
>>  > The above "RFC#simple approach" has a high level of commonality with
>>  > draft-rey-avt-rtp-3gpp-timed-text-01.txt. There are some small
>>  > differences that can be fixed either way, but roughly the
>>  "RFC#simple
>>  > approach" is a simplified version of
>>  > draft-rey-avt-rtp-3gpp-timed-text-01.txt. In particular, the
>>  > "RFC#simple" approach does not have the advanced error resiliency
>>  > measures that are in draft-rey-avt-rtp-3gpp-timed-text-01.txt.
>>  >
>>  > In my view not only in IETF, but also in 3GPP and in MPEG a
>>  number of
>>  > basic issues should be discussed, such as:
>>  > - are the error resiliency features of
>>  > draft-rey-avt-rtp-3gpp-timed-text-01.txt sufficiently valuable to
>>  > justify their complexity (note that a partly corrupted
>>  > subtitle may not
>>  > have much more value to the user than a missing one);
>>
>>  This is a good question which I will also ask during my
>>  presentation on
>>  Monday.  This is a question which certainly needs feedback of
>>  the group.
>>  The complexity can be reduced, we have to agree where to cut
>>  down: do we
>>  need the MTSF headers? or do we want to just keep resiliency for plain
>>  text fragments?, for example.  PT multiplexing will probably be
>>  abandoned for a simpler scheme.
>>
>>  > - is it desirable to define a 3GPP timed text transport
>>  solution based
>>  > on draft-rey-avt-rtp-3gpp-timed-text-01.txt next to the one
>>  > that will be
>>  > available based on RFC#simple;
>>
>>  Allowing both would mean that one does not have to implement
>>  RFC#simple
>>  in order to transport timed text, which I think is desireable.
>>
>>  > - is it desirable that draft-rey-avt-rtp-3gpp-timed-text-01.txt
>>  > specifies a mode or an extension of RFC#simple;
>>
>>  Would this mean that the RFC#simple has to be implemented to use the
>>  draft? I think this is not a good idea.
>>
>>  > - how can a timing conflict (if any) between release 6 of
>>  > 3GPP and part
>>  > 17 of MPEG-4 be resolved (note that such conflict will only exist if
>>  > 3GPP adopts streaming of timed text as a work item and if
>>  3GPP decides
>>  > that this functionality has to be in release 6).
>  > >
>>
>>  We are targetting to include this in Release 6 (03/04). According to
>>  your information above MPEG4 timed text will be ready in
>  > July'04, which
>>  is out of the deadline. Apart from that, current Release 6
>>  does not use
>>  the RFC#simple for streaming... so one would not be able to use timed
>>  text in Release 6.
>>
>>  Assuming timed text comes into the Release 6 agenda, what I would like
>>  to know is what should, in your opinion, the current draft include in
>>  order to consider the MPEG work and the possible extensions it may
>>  incorporate ?. It is now the time to talk about these issues if the
>>  draft shall consider the MPEG work.
>>
>>
>>  > I hope you will have a fruitful discussion on this subject in
>>  > Mineapolis.
>>
>>  You can dowload the session slides and take  a look at the
>>  presentation
>>  which is related to this email.
>>
>>  cheers,
>>
>>  Jose
>>
>>  >But, this is not just an IETF issue. Therefore,
>>  > as both 3GPP
>>  > and MPEG are main "customers" of a timed text streaming solution, I
>>  > suggest that IETF requests 3GPP and MPEG to advice IETF as
>>  to the most
>>  > desirable direction for resolving this issue. Note that
>>  both 3GPP and
>>  > MPEG will have meetings where this issue can be discussed
>>  well before
>>  > the end of this year.
>>  >
>>  > Best regards,
>>  >
>>  > Jan van der Meer
>>  >
>>  >
>>
>>
>>  _______________________________________________
>>  Audio/Video Transport Working Group
>>  [e-mail]
>>  https://www1.ietf.org/mailman/listinfo/avt


-- 
David Singer
Apple Computer/QuickTime

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