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

From: [email-masked]
Date: Mon, 10 Nov 2003 14:57:05 +0100

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);
- 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;
- is it desirable that draft-rey-avt-rtp-3gpp-timed-text-01.txt specifies 
a mode or an extension of RFC#simple;
- 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).

I hope you will have a fruitful discussion on this subject in Mineapolis. 
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

---

From: [email-masked]
Date: Tue, 11 Nov 2003 10:19:15 +0100

Hello José,

> Allowing both would mean that one does not have to implement RFC#simple
> in order to transport timed text, which I think is desireable.

Could you please clarify the above statement. It is possible to have a 
straightforward solution for transport of time text based on RFC#simple 
and your draft is a second and more complex solution that is more 
desirable because then there is no need to implement the simpler one ??

Best regards,

Jan

José Rey <[email-masked]>
Sent by: 
[email-masked]
2003-11-10 09:02 PM

        To:     Jan vanderMeer/EHV/CE/PHILIPS@PHILIPS
"'IETF AVT WG'" <[email-masked]>
        cc:     "Colin Perkins" <[email-masked]>
"Magnus Westerlund" <[email-masked]>
"'Dave Singer'" <[email-masked]>
"Yoshinori Matsui" <[email-masked]>
        Subject:        AW: [AVT] More comments on draft-rey-avt-rtp-3gpp-timed-text-01.txt
        Classification: 

Jan, all,

> -----Ursprüngliche Nachricht-----
> Von: José Rey [mailto:[email-masked]]
> Gesendet: Montag, 10. November 2003 18:11
> An: Jose Rey
> Betreff:
>
>
> Dear Jose, all,
>
> 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.
>
> "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",
> - in the RTP payload the concatenated AU-headers preceed concatenated
> data of text access units, as defined in RFC#simple,
> associated text access unit: (a) the size of the text access unit, (b)
> the time stamp of the text access unit,
> 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.
>
> 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.
>
> 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

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

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt