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

[José Rey <[e-mail]>]

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