Subject: [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: Thu, 13 Jan 2005 19:53:05 +0100

Hi Magnus,

As always thanks for your detailed comments. I sent already a new version out to the ID manager.  Meanwhile can be downloaded here:
http://www.prdcg.panasonic.de/ietf/docs/draft-ietf-avt-rtp-3gpp-timed-text-09.txt

I have accepted most of your proposals. The ones below should be checked once again. In particualer, please tell me if the SIDX algo is OK now and whether it would be acceptable to mandate monotically increasing SIDXs.

I have also done some small changes:

- section relation to RFC3640. The last figure was not quite correct, as Jan pointed me.  Deleted it.
- some nits in figures 
- changed in MIME Type from :
	"If no "sver" value is available, for example, when streaming out of a 3GP file, the default value "60", which 	corresponds to this RFCXXXX, SHALL be used. "

	to

	"If no "sver" value is available, for example, when streaming out of a 3GP file, the default value "60", 	corresponding to the 3GPP Release 6 version of 3GPP TS 26.245, SHALL be used."

- Changed tx,ty,layer to OPTIONAL under MIME Reg., since the criteria is "If you are allowed to not provide a hint for the declarative parameters in Offer for the sendonly case, then these parameters are not even required." 
- added a comment for possible future extensions to use TYPE 0,6,7. 
- I added the comment that non-compatible sver timed text versions SHALL be offered using different payload types, 9.2.1 and 9.2.2"...Note that, if alternative non-compatible versions are offered, then this SHALL be done using different payload types."

-1), 2), 4), 5), 9), 10), 12), 14), 16-20) cut-

> 3) Section 4.1.1: Type field:
> "The receiver SHALL ignore packets with unrecognized TYPE value."
> 
> I think the word "packet" shall be replaced with "unit". If we ignore 
> the unit, the rest of the packet can be used. Thus allowing extensions 
> like the one the MPEG people asked for.
> However it might be necessary to add something in the processing of TS 
> about ignoring these.
> 

If the units are defined so that they can be ignored, this means that they will not affect the timestamp duration. In that regard, they transparent , not causing any alteration to the operation if ignored.

I've added this:

"- TYPE 0, 6 and 7 are reserved for future extensions.  Note that future extensions are possible, e.g., a unit that explicitly signals the number of characters present in a fragment.  In order to guarantee backwards-compatibility, it SHALL be possible that older clients ignore (newer) units they do not understand, without invalidating the timestamp calculation mechanisms or otherwise preventing from decoding the other units.

Thus, the receiver SHALL ignore units with unrecognized TYPE value.  The RTP header fields and the rest of the units (if any) are still useful, as guaranteed by the requirement for future extensions above.  "

> 
> 6) Section 4.1.3, LEN definition:
> "Hence, as a minimum, a text fragment MUST contain one
>       character in either UTF-8 or UTF-16."
> 
> I think the construction with the minimum is not 100% clear. 
> I think this can be improved by adding a "at least" into the sentence:
> 
> Hence, as a minimum, a text fragment MUST contain at least one
>       character in either UTF-8 or UTF-16."
> 

This is a tautology, 2x the same, "at least one= minimum one", this maybe better : " Hence, a text fragment MUST contain at least one character in either UTF-8 or UTF-16."??

> 7) Section 4.1.3, Page 19, the example:
> "Several constraints may come in this scenario into place, 
> for example:"
> 
> Something is wrong in this sentence.

A bit ackward:"In this scenario, several constraints may apply, for example" is better. Thanks.
> 
> 8) Section 4.1.6.1, the algorithm on page 24:
> 
> I think this algorithm is wrong, because you can move the 
> active box backwards by sending a pattern like: 1, 2, 4, 3 
> which would inactive 4 after 3 has been received. I think the 
> algorithm should be redefined so that it first check if any 
> received SIDX is within the active range, independently if it 
> has been received before or is new and becomes active.
> 
That is in fact what 4.a does. THe window does not move back.

After receiving 4, the invalid range is 5<->68 and the valid 69<->127+0<->5. When 3 is received, 3 is already active so nothing is done.

I have rephrased a bit, and also include the below suggestion.

"Let X be the SIDX of the last received sample description. Let Y be a value within the allowed range for dynamic SIDX: [0,127], and different from X. 	
1.	Initialize all dynamic SIDX values as inactive. For stored content, read the sample description index in the Sample to Chunk box ("stsc") for that sample. For live streaming, the first value MAY be zero or any other value in the interval above. Go to step 2.
2.	First in-band sample description with SIDX=X is received. Go to step 3.
3.	Set Y inactive if inside the (inclusive) interval [X+1 modulo(128), X+64 modulo(128)]. The Y values outside of this interval are set as active. Go to step 4 (wait state).
4.	Wait for next sample description. Once the client is initialized, the interval of active SIDX values MUST change whenever a sample description with an inactive SIDX value is received. I. e., upon reception of a sample description with SIDX=X do: 
a.	If X is currently active, then wait for next SIDX (do nothing). Go to beginning step 4 (wait state). 
b.	Else go to step 3."

> 11) Section 4.2, The SIDX algorithm. I can't understand how 
> it would be required to use the algorithm you suggest. As 
> long as a sender ensures that the receiver will have all 
> sample descriptions when he has them, there is no need for a 
> normative algorithm that I am not convinced will work. If you 
> have a usage of sample descriptions that goes back and forth 
> in the value field. Lets for example say that you have series 
> that according to your algorithm contains the following usage 
> of SIDXs: 4, 97, 4, 98, 97, 4, 97. To avoid emptying and 
> needing to retransmit the sample descriptions you could 
> instead do intelligent renumbering.

Certainly the algo will be used rarely. The thing is that if the session is very long and the SIDXs change frequently, a static one-time mapping may be exhausted. To avoid this, a window is done and the receiver just ensures that all the SIDXs that the receiver needs are within that window. So the usage of values that goes back and forth over intervals >64 in sessions where the SIDX space may be exhausted is certainly not reasonable, but nevertheless someone could come to the idea of doing that.  A solution is to mandate that dynamic SDIXs be icnremented by one to make full (and reasonable) use of the algo.  This is simpler than renumbering or checking what the receiver has or does not have.  It is assumed that 64 simultaneous active SIDXs will be enough.  Tell me if the re-phased algo is OK and if it should be mandated that dynamic SIDXs increase monotically.

> 13) Section 4.5: I am missing a note that explain how to 
> achieve a aggregated type 1 packet that contains samples that 
> are not consecutive, i.e. TS1+SDUR1 < TS2. Although it is 
> quite simple to include an extra Type 1 unit with no sample, 
> but a SDUR2 field that are equal to TS2-(TS1+SDUR1).

I'll include this.
"o	Finally, note that aggregate payloads containing non-consecutive samples are feasible.  Two units, 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."

> 15) Section 6. Sentence 2 and 3 are in error. The current 
> profiles are not mandating congestion control due to it 
> considered to be used also on tightly managed networks where 
> congestion is addressed in other ways then monitoring. Also 
> it do not define a method that is deemed TCP friendly by the 
> larger IETF community. I would avoid this type of statement 
> and instead discuss how one can regulate the bandwidth when 
> using the payload format. The important factors should be the 
> improvement possible with aggregation and the dangers with 
> the resilient mechanism, especially repetition that increases 
> bandwidth and thus need to be included in any bit-rate budget 
> to not cause congestion.
> 
Replaced by:
"When using this payload format, mainly two factors may affect the congestion control:

o	The use of (unit) aggregation may make the payload format more bandwidth efficient, by avoiding header overhead and thus reducing the used bitrate.  

o	The use of resilient transport mechanisms: although timed text applications typically operate at low bitrates, the increase due to resilient transport shall be considered for congestion control mechanisms.  This applies to all mechanisms but especially to less efficient ones like repetition."

Cheers,
---------------------------------------------
Jose Rey              mailto:[email-masked]
P R D C G - Panasonic R&D Center Germany GmbH
Phone/Fax: +49(0)6103766-134/166
--------------------------------------------- 

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

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jan 2005 17:06:55 +0100

Hi Jose,

See inline. Down to 2 issues.

> - I added the comment that non-compatible sver timed text versions SHALL be offered using different payload types, 9.2.1 and 9.2.2"...Note that, if alternative non-compatible versions are offered,…

These changes looks very reasonable. I also have removed the issues 3, 
6, 7, 13, 15 as the resolution looks fine.

> a.	If X is currently active, then wait for next SIDX (do nothing). Go to beginning step 4 (wait state). 

Okay, now I do understand what the issues between my and your 
interpretation was. I assumed that active only meant SIDX that was 
actually received. I had a separation between invalid, valid and active. 
The updated clarified what was considered to be active. However I think 
the algorithm can be updated even further to be clearer. My proposal is 
to change the algorithm to actual clarify what is to be done with the 
sample descriptions themselves.

So here is my take on it:

Let X be the SIDX last received that updated the range of valid sample 
descriptions.  Let Y  be a value within the allowed range for dynamic 
SIDX: [0,127], and different from X. Let Z be the SIDX of the last 
received sample description.

1. Initialize all dynamic SIDX values as inactive.  For stored 
  content, read the sample description index in the Sample to 
Chunk box ("stsc") for that sample.  For live streaming, the first value 
MAY be zero or any other value in the interval above.  Go to step 2.

2. First in-band sample description with SIDX=Z is received and stored, 
Set X = Z. Go to step 3.

3. Any SIDX within the interval [X+1 modulo(128), X+64 modulo(128)] is 
marked as inactive and any corresponding sample description is deleted. 
Any SIDX within the interval [X+65 modulo(128), X] is set active. Go to 
step 4 (wait state).

4. Wait for next sample description.  Once the client is initialized, 
the interval of active SIDX values MUST change whenever a sample 
description with an SIDX value in the inactive set is received.  I.e., 
upon reception of a sample description with SIDX=Z do:
A. If Z is in the interval (inclusive) [X+1 modulo(128), X+64 
modulo(128)] then set X=Z, store the sample description and go to step 3.
B. If SIDX=Z is not stored, then store the sample description. Go to 
beginning of step 4 (wait state).
C. Else go to the beginning of step 4 (wait state).

--- END of Alg ---

> Certainly the algo will be used rarely. The thing is that if 
 > the session is very long and the SIDXs change frequently,
 > a static one-time mapping may be exhausted. To avoid this,
 > a window is done and the receiver just ensures that all the
 >
> SIDXs that the receiver needs are within that window. So the 
 > usage of values that goes back and forth over intervals >64
 > in sessions where the SIDX space may be exhausted is certainly
 > not reasonable, but nevertheless someone could come to the
 > idea of doing that.  A solution is to mandate that dynamic
 > SDIXs be icnremented by one to make full (and reasonable) use
 > of the algo.  This is simpler than renumbering or checking
 > What the receiver has or does not have.  It is assumed that
 > 64 simultaneous active SIDXs will be enough.  Tell me if the
 > re-phased algo is OK and if it should be mandated that
 > dynamic SIDXs increase monotically.
>   

I have a problem seeing the need for any mandating at all. However my 
big problem was that the it required you to assign SIDXs in such a way 
from the file that it could create the example I listed above. To my 
understanding the tx3G box simple consists of a bunch of sample 
descriptions. There is no requirement to use this list of boxes in 
linear fashion and I can at any point in time return to an lower number. 
Thus doing the strict mapping your algorithm mandated would not have 
worked.

My proposal for this text in the draft it the following:
OLD:
         o SIDX from the Sample to Chunk Box (stsc): the stsc Box is
           used to find samples and their corresponding sample
           descriptions.  These are referenced by the "sample
           description index", a (unsigned) 32-bit integer.  If the
           value of the index for that sample into the 8-bit, then it
           can be mapped directly to the field SIDX.  Otherwise, the
           following wrap-around operation SHALL be performed with this
           value:
                 a) If the value corresponds to a dynamic sample
                 description, the result of ((sample description) modulo
                 127) is mapped to the SIDX field.
                 b) If the value corresponds to a static description,
                 then (129 +((sample description) modulo 126)) is used as
                 the (static) SIDX, which is used to construct the
                 dynamic sample description, see Section 8.

NEW:
         o SIDX from the Sample to Chunk Box (stsc): the stsc Box is
           used to find samples and their corresponding sample
           descriptions.  These are referenced by the "sample
           description index", a (unsigned) 32-bit integer. If possible 
these indicies may be directly mapped to the SIDX. However there are 
several limitations that may prevent this:

    a) The number of used indicies are more than 127 static ones or 64
       dynamic ones.
    b) In usage of SIDX values, the indicies do not match the ranges for
       static (129-254) or the dynamic (0-127) sample descriptions.

If assigning SIDX numbers to the sample descriptions the following 
guidelines are provided:

   Static sample descriptions can simply be assigned consecutive numbers
   within the range 129-254.

   Dynamic sample descriptions with less than 64 ones in the same stream 
is recommended to be assigned consecutive numbers anywhere in the range 
0-127. In streams with more than 64 sample descriptions they must be 
assigned numbers in usage order, and if any sample description is used 
after it has been expired by other sample descriptions will need to be 
re-sent and assigned a new SIDX value.

--- End of proposal ---
I would suggest that you go through the text and fix language errors. 
There is most probably need for better word alignment and usage of 
terms. However I do hope you get the idea of the problem and my suggest 
solution.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 18 Jan 2005 13:45:43 +0000

On 13 Jan 2005, at 18:53, Rey Jose wrote:
> As always thanks for your detailed comments. I sent already a new  
> version out to the ID manager.  Meanwhile can be downloaded here:

I have some technical comments on this version:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,
Colin