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

["Jose Rey" <[e-mail]>]

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?


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


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