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

[[e-mail]]

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