Subject: RE: [AVT] Update (-09) of Timed Tex draft (WAS: RE: Comments on draft-ietf-avt-rtp-3gpp-timed-text-08.txt)

From: "Rey Jose" <[email-masked]>
Date: Tue, 18 Jan 2005 15:53:02 +0100

Hi Colin, 

Thanks for the comments. Some quick answers, issues first, nits after the "======" line.

...
> text-09.txt
> 
> I have some technical comments on this version:
> 
>   - Why are type 5 units untimed, rather than being timed 
> with their sending
>     time?
Because the sample description is strictly NOT a part of the text sample.  The timestamp is used for identifying the units that belong to the same text sample.  

> It would fit the RTP model better if they were 
> given a timestamp
>     indicating the time at which they become active 

Sample descriptions may be needed by several text samples, cannot have two timestamps.  Also with duration is difficult since it is not set in neither files or live streaming.  Further, when decoding a text sample it should be looked for the needed sample descriptions.  If not available, the application decides how to display, if at all.  Most times will be possible, since sample descriptions only relate to formatting and position. Therefore a default formatting could be used for that.  This is also explained in the draft.  

> (and 
> arrange the stream
>     such that they cannot apply to packets with earlier timestamps).
> 
This can never happen. I mean the server takes care that, the SIDX are correctly synchronised, c.f. section on the dynamic SIDX.  Or maybe I don't get your question?
 
>   - 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.

> 
>   - It's not clear why type 1 packets are permitted to 
> contain modifiers? Why
>     not enforce that they contain only text, and aggregate 
> that text with a
>     type 3 packets as appropriate? 

It seems simpler to give it all in one go to the app instead of forcing to paste the parts together for every sample.  TYPE 2 & 3 are for large text samples.  Normal case should be to use type 1 for most samples. Anyway, a decoder can just ignore the modifiers it doesn't understand. TYPE 1 headers tells it where the text string ends.

> There is slightly more 
> overhead, but having
>     two different ways of sending modifier boxes is ugly (and 
> it's not until
>     you get to the examples that it becomes clear how 
> modifier boxes are sent
>     as part of type 1 packets).

I can add an example there to clarify early, if that's necessary.

>   - 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.

Actually it doesn't mandate, but recommend. If your comment is valid anyway for SHOULD, I can decrease it to MAY

>   - Section 2.5 part 1 bullets a and b use slightly different 
> terms ("text
>     sample" versus "text string"). Is it intended that these 
> mean the same
>     thing?
> 
Actually no.  These terms are defined differently in the Terminology section.

========

> 
>   - 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.
> 

Not sure, I'll check with Jan.  

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

Yes, this is a mistake overseen when changed from REQUIRED to OPTIONAL.

> 
> Some also have editorial comments:
> 
>   - Section 2 uses RFC 2119 terms, but these are not defined 
> until section
>     3. The easiest fix is to change the uppercase terms to lowercase,
> non-
>     normative terms in section 2 (this also avoids the issue 
> that the RFC
>     2119 terms are not entirely appropriate for requirements 
> specification).
> 

OK. I'll do.

>   - Figure 1 is drawn in a way that makes it look like the 
> header and sample
>     contents are 32 bit aligned. Since they're not, it might 
> be better to
>     draw the diagram showing an example of this (to avoid 
> possible confusion).

Done.

> 
>   - For clarity, I suggest indenting the several paragraphs 
> of text that
>     explain how the timestamp is interpreted in section 4 
> (last paragraph
>     of page 11 and first 6 paragraphs of page 12). The third 
> paragraph of
>     page 12 is somewhat redundant with the previous text - 
> suggest removing
>     it?
Will check.

> 
>   - The example on page 17 starts "Let us revisit the 
> previous example..."
>     but it's not clear what previous example is meant?
> 
Will check.

>   - I don't think the use of MAY in section 4.4 (2.b.i, 2.b.ii and
> 2.b.iv)
>     is appropriate. This is not a normative requirement, so 
> the lowercase
>     "may" is better.
> 
You are right, it is expressing an option rather than a rule.

>   - Penultimate bullet point on page 31: "inline" -> "in line"
> 

Thanks.

>   - 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?
> 

Yes, the language is bad. It is actually meant that can artificially make this fill-in.

> Otherwise, very much improved from the previous version I read!
> 

Nice to hear that! 

Cheers,

José

> Cheers,
> Colin

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 30 Jan 2005 14:39:08 +0000

Jose,

On 18 Jan 2005, at 14:53, Rey Jose wrote:
...
>> with their sending time?
> Because the sample description is strictly NOT a part of the text 
> sample.  The timestamp is used for identifying the units that belong 
> to the same text sample.

Okay - but you give them a timestamp now.

>> It would fit the RTP model better if they were given a timestamp
> Sample descriptions may be needed by several text samples, cannot have 
> two timestamps.  Also with duration is difficult since it is not set 
> in neither files or live streaming.  Further, when decoding a text 
> sample it should be looked for the needed sample descriptions.  If not 
> available, the application decides how to display, if at all.  Most 
> times will be possible, since sample descriptions only relate to 
> formatting and position. Therefore a default formatting could be used 
> for that.  This is also explained in the draft.

I understand this. However, the payload format gives sample 
descriptions a timestamp now, setting it equal to "the current value of 
the RTP timestamp plus one" but ignoring it on reception and assuming 
the sample descriptions become available for use immediately the packet 
is received.

I am suggesting is that this is less than ideal, since a receiver has 
to handle some RTP packets in the stream according to the usual RTP 
timing model, but to ignore that model for some other packets and 
decode them as soon as they arrive. This makes an implicit assumption 
that the sample description is to be used after the time it arrives - 
why not make that explicit, with the RTP timestamp being the time at 
which the sample description becomes available for use?

>> (and arrange the stream such that they cannot apply to packets with 
>> earlier timestamps).
>>
> This can never happen. I mean the server takes care that, the SIDX are 
> correctly synchronised, c.f. section on the dynamic SIDX.  Or maybe I 
> don't get your question?

I understand that it can never happen. Why not make that explicit in 
the use of the RTP timestamp?

>> contain modifiers? Why not enforce that they contain only text, and 
>> aggregate that text with a type 3 packets as appropriate?
>
> It seems simpler to give it all in one go to the app instead of 
> forcing to paste the parts together for every sample.

This would only be simpler if modifier boxes were never sent separately 
from the text. As it stands, a receiver must support two different ways 
of getting the modifier. If we remove support for type 1 packets, and 
always send either text or modifiers, then a receiver has only one way 
of getting the data. That would reduce the amount of code in the 
receiver.

The other changes in -11 look okay to me.

Colin