[AVT] Update (-11) of Timed Text draft

["Rey Jose" <Rey at panasonic.de>]

Hi,

I just sent the last update addressing Colin's comments to the ID
manager.  

As usual:

http://www.prdcg.panasonic.de/ietf/docs/draft-ietf-avt-rtp-3gpp-timed-te
xt-11.txt


Jose


====================


Detailed changes follow:

-------
>  
> >   - In section 4.1.1, a flag indicates if the text is UTF-8 
> or UTF-16. 
> > If
> >     UTF-16 is used, is it big or little endian? Doesn't seem to be 
> > specified.
> 
> Big endian, since 0xFEFF is used.
> 

This has been explained in the section on common headers with:

"o	U (1 bit) "UTF Transformation flag": this is used to inform RTP
receivers whether UTF-8 (U=0) or UTF-16 (U=1) was used to encode the
text string.  UTF-16 text strings transported by this payload format
MUST be serialized in big endian order, a.k.a. network byte order.  

Informative note:  timed text clients complying with the 3GPP Timed Text
format [1] are only required to understand the big endian serialization.
Thus, in order to ease interoperability, the reverse serialization
(little endian) is not supported by this payload format."

And noted in the Limitations section

	 5. A further limitation concerns the UTF encodings supported:
only 
        UTF-16 big endian byte order is supported.  See Section 4.1.1 
        for details. 


-------

>   - Section 8 allows empty lists in "tx3g". Why is this? Why not just 
> omit the
>     parameter if there is no data?

Added it SHALL NOT be empty.

-------
Regarding your comments, more in detail

  - Why are type 5 units untimed, rather than being timed with their
sending
    time? It would fit the RTP model better if they were given a
timestamp
    indicating the time at which they become active (and arrange the
stream
    such that they cannot apply to packets with earlier timestamps).

I tried to answer your concerns with the following:

"This header type is used to transport whole text samples.  This unit
should be the most common case, i.e. the text sample should be usually
small enough to be transported in one unit without having to separate
text strings from modifiers.  In an aggregate (RTP packet) payload
containing several text samples, every sample is preceded by its own
TYPE 1 header (see Figure 12).

Informative note: as indicated in the Terminology Section, a text sample
is composed by the text strings followed by the modifiers (if any).
This is also how text samples are stored in 3GP files.  The separation
of a text sample into text strings and modifiers is only needed for
large samples (or small available IP MTU sizes, see Section 4.3) and it
is accomplished with TYPE 2 and TYPE 3 headers, as explained in the
Sections below."


-------

> The third paragraph 
> of
>     page 12 is somewhat redundant with the previous text - suggest 
> removing
>     it?

Removed :

"
However, it is noted that using too low clockrates may turn the RTCP
measurements useless or may not provide enough synchronization accuracy.
If this is the case, then such clockrate values SHALL NOT be used.  On
the other hand, note that the duration of the samples in inversely
proportional to the clockrate so that choosing too high a value may
lower the maximum duration too much.  E.g. 24 bits at 1000 Hz allow for
a maximum duration of about 4.6 hours, while for 90 KHz, this value is
only of about 3 minutes."

-------

>   - The last bullet point on page 31 is not clear. If it's feasible to

> include
>     payloads with non-consecutive samples, why does one need to 
> generate the
>     fill-in?

"
o	Finally, note that the use of empty text samples allows for
aggregating non-consecutive TYPE 1 units in the same payload.  Two text
samples, with timestamps TS1 and TS3 and durations SDUR1 and SDUR3, are
not consecutive if it holds TS1+SDUR1 < TS3.  A solution for this is to
include an empty TYPE 1 unit with duration SDUR2 between them, such that
TS2+SDUR2 = TS1+SDUR1+SDUR2 = TS3.
"
----------
>   - Section 7.2 mandates the use of SMIL. This is not appropriate - 
> the draft
>     can suggest how SMIL can be used if desired, but the payload 
> format should
>     not depend on particular signalling methods.

Changed to MAY.

----------
>   - Section 4.7 notes that MPEG-4 part 17 can convey timed text 
> "Amongst other
>     capabilities". Are these other capabilities incompatible with 3GPP

> timed
>     text when used? If so, the following text in section 4.7 need to 
> be
>     rewritten to make it clear which subset of MPEG4 part 17 is 
> implied.
> 
Deleted "Amongst other capabilities" as explained in previous email.


The rest of the comments have been already addressed in previous emails.

---------------------------------------------
Jose Rey              mailto:rey at panasonic.de
P R D C G - Panasonic R&D Center Germany GmbH
Phone/Fax: +49(0)6103766-134/166
--------------------------------------------- 


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt