Subject: RE: [AVT] Comments on draft-rey-avt-3gpp-timed-text-02.txtU

From: "Jose Rey" <[email-masked]>
Date: Mon, 1 Mar 2004 10:10:34 +0100

Hi Magnus,

as usual, thanks a lot for the comments ;)

See inline,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
Magnus
> Westerlund
> Sent: Wednesday, February 25, 2004 6:31 PM
> To: IETF AVT WG
> Subject: [AVT] Comments on draft-rey-avt-3gpp-timed-text-02.txtU
>
>
> Hi Jose,
>
> Here is a number of comments on your draft. I like this much more than
> the previous proposal.
>
> 1. In the next update don't forget to update all the boilerplate for
IPR
> and copyright according to RFC 3667 and 3668.
>
OK

> 2. Abstract: "3GPP timed
>     text is time-lined decorated text media format whose defined
storage
>     format is the ISO (International Standardisation Organisation)
Base
>     Media File Format."
>
> This is not correct. the 3GPP Timed text is stored in the 3GP file
> format, which is based on the ISO Base Media File Format.
>
> 3. section 2, second paragraph: "3GPP timed text is a 3GP file format
> for time-lined decorated text specified in [1]." I would say that
"3GPP
> Timed Text is a media format for time-lined decorated text, with a
> defined storage in the 3GP file format."
>
Yes to both above.

> 4. Section 2.1, bullet 3: "This is especially useful for live
streaming
> (where the contents are not known a priori) or to protect this
> information through other mechanisms like FEC [4] or retransmission
> [13]." The second part of the sentence is not correct. The possibility
> to protect the important sample descriptions are not a reason for
having
> in-band sample descriptions. So please split it out, as FEC and
> retransmission is means to make it work.
>
Wording is not clear. Will change it.

> 5. Section 3, first bullet. "A text sample contains a text length
> indication, a text string, and zero or several modifier boxes (the
> decoration of the text)." Is not "zero or more" a better term, or is
it
> impossible to have only one modifier box?
>
"zero or more" is more precise.

> 6. Section 3, bullet list. Please adjust the formatting, having the
> lines after the first be adjusted further in so the "-" mark i alone
at
> the left makes it more clear that it is a bullet list.
>
OK.

> 7. Section 3, second bullet: "A fragment may either text strings and
> modifiers or just one of these." This sentence is very strange.

actually this sentence is incorrect since we don't allow text strings
and modifiers
to be in the same fragment.
It should say:

"A fragment may consist of either text strings or modifier box
contents."

>
> 8. Section 4, Marker bit: The current definition is unclear if one
only
> has a single complete text sample, should one have the marker bit set
or
> not.
Yes, as usual, it MUST be set. Will clarify.

>
> 9. Section 4, Timestamp: By putting the word "earliest" in the first
> sentence of the timestamp paragraph, you will not have to redefine the
> initial meaning a few lines down and it fits both single and multi
> sample cases. I would also think about using normative SHALL or MUST
in
> the definition to make readers aware of that this is something
important
> to follow.
OK.

> 10. Section 4, Timestamp: "The value timestamp clockrate is copied
> directly from the 3GP file: the value of "timescale" in the Media
Header
> Box is to be used." Is this a SHALL or SHOULD?

MUST/SHALL.

> With the RTP payload it
> will be possible to create 3GPP Timed text without ever storing it
> first. Therefore I think that some general guidance on timestamp rates
> should be written.

Right, for live content streaming...I'll write something on that

> Also, is the clock rate in the 3GP file fixed or can
> it be different between different files.

Every track (audio/video (includes timed text)) in a 3GP file has a
exactly one media header box. The 'timescale' value included there is
for that media and that's the one we use as clockrate.
The duration field refers to the number of cycles the text sample
'uses', so that sdur/timescale = duration[s]

Apart from that, the 3GP file includes a 'presentation' timescale value.
This is not consider in the draft.

In general, between files of them can be different.

>
> 11. Section 4.1: "It appears more appropriate to encode text samples
> without taking the path MTU into account." I think that it most
> applications is will be rather easy to ensure that created samples are
> not to big.

Right, this sentence addresses those cases. This sentence cannot be read
as stand-alone, though. It is the conclusion of the previous sentences.
>
> 12. section 4.1, Third bullet: "- it is RECOMMENDED to include as
fewer
> text sample fragments as possible in an RTP packet." First the
language
> is wrong "few" instead of "fewer".
OK

> Secondly, should one really include
> multiple fragments in a RTP packet. Isn't it much better to ensure
that
> one does not fragment.
The sentence is implicitly saying that one should not interleave
fragments, it is not reasonable to do so, since the lost of such a
packet might affect several samples.

On the other hand it is not possible to avoid fragmentation in every
situation as the draft explains in section 4.1.

> 13. Section 4.2: It is not clear if the payload are formed: header
> header data data, or header data header data. could you please
clarify.

Yes.

>
> 14. Section 4.2, the payload header? Is there a reason why the
reserved
> bits are left most in the first byte?

Not really.

> Otherwise I would recommend them
> to be placed between UL and TYPE. That way the bits could in the
future
> either be used to extend the TYPE field or for more indication bits.
>

Good idea, I'll take that in.

> 15. Section 4.2, L definition. "By default this flag is reset." I
guess
> that reset is having the bit take the value of 0. Please define reset
if
> you are going to use it.
OK

> 16. Section 4.2, The L bit. Is is really worth having the length field
> as a variable field. It will be needed in all cases except when only a
> single data unit is in a packet. Thus I don't think the overhead from
> these two bytes are in anyway excessive. The number of RTP packets
from
> timed text are rather few. In a subtitling usage, their is only a
single
> new sample every few seconds. I think simplicity is an advantage here.
>

It is certainly easier that way.

> 17. Section 4.2, SIDX: "To allow SIDX wrap-up, clients SHALL keep as
> valid only those values of SIDX outside of the interval (X+128) modulo
> 255, where X is the last SIDX value received." I think you need to
> specify it as an interval not a single value which (X+128) modulo 255
> are. I think you should define this as a client shall only use the
> sample entries that are (X-127)..(X) modulo 255.
>

This mechanism is faulty. The actual way it should work has been
discussed in the last days.  We decided to split it into two different
SIDX spaces: for dynamic and static types. It should work this way:

- Dynamic in-band SIDXs get values between 1 and 127, both inclusive.
- Static out-of-band SIDXs allowed are betwen 128 and 254 both
inclusive.
- 0,255 reserved

The wrap-up mechanism for dynamic SIDXs is as follows:  a sliding window
of a maximum 64 values is allowed per session.  This window may move
during the session:i.e. everytime a new undefined value comes the
algorithm redefines the interval of active values that fall in the
interval and keeps these SIDXs as active.  Typical sessions shouldn't
need more than 64 SIDXs. E.g.

if SIDXs received were 63,64,65, then SIDX belonging 2<->65 are
considered valid. The other values 66-128 + 1 invalid.

Dynamic values may be updated in-band. Static values not. Static values
have no wrap-up mechanism since they should be much less in number (no
need for that).

What do you think?

> 18. Section 4.2, SDUR: "However, samples of unknown duration MAY
precede
> sample descriptions, as they have no duration." I think duration is
the
> wrong word here. Sample descriptions is lacking timing information.
They
> are simply sent out and exist.
>
OK

> 19. Section 4.2: I think that making each type format its own
> sub-chapter and giving the name would increase the readability.
>
OK

> 20. section 4.2: Type=2: If you make the Len field permanent I think
the
> SDUR field should be shifted left one byte, the SLEN moved to the end
> and the TOTAL|This byte precede the SDUR field, that way one allows
for
> easier processing of the fields on a 32 bit machine.

OK,

from here:

*TYPE2*
|R|U|L|TYPE|LEN|SIDX|SLEN|SDUR|TOTL|THIS|
<---1-----><-2-><-1><--2><--3><---1----->

to:
*TYPE2*
|R|U|L|TYPE|LEN|SIDX|SDUR|TOTL|THIS|SLEN|
<---1-----><-2-><--1><--3><----1---><-2->
<-------32bit-------><---32bit----->

The others would be:

*TYPE1*
|R|U|L|TYPE|LEN|SIDX|SDUR|
<--1-------><2-><-1-><--3>
<-------32bit------->
which also fulfils your comment.

*TYPE 3&4* would be 4 bytes, thus also complying.

>
> 21. Section 4. type 2, TOTAL and THIS. I think the rules for how one
can
> send fragments in relation to other packets needs to be clarified.
OK.

> In
> general I think the fragmentation concept could be explained on a more
> general level. The concept of having different types for splitting
text
> and modifiers and that different rules apply could be explained prior
to
> defining the boxes.
I'll include an introductory explanation at the end of section 4.1
before the actual definition.

> 22. section 8. Please add an statement that unknown parameters SHALL
be
> ignored. That way there is some chance of extending the format in a
> predictable way in the future.
>
OK

> 23. Section 8. The reference to the timed text specification. Are you
> referring to the release 5 or release 6. As the release 6 is not yet
> frozen, how is the intended timing between the payload format and the
> timed text specification for release 6?
>
Both docs contain (except for editorials) the same thing.

The target is still to have this payload format for Release 6, which is
not due to March'04 anymore. In March a decision will be taken as to
when to freeze Release 6, probably September '04

> 24. Section 9. You have two definitions of how the parameters intended
> for the "a=fmtp" line shall be mapped. Ether you keep the two line
> stating "the REQUIRED .." and "The OPTIONAL", or you use only the
> following line.
>

OK

> 25. Section 9.1, the mapping of the clockrate is unclear. It does not
> state exactly to what the 3GP file formats "timescale" value shall be
> copied to.

This is already explained in the Annex.  I think I'll add some comments
and refer to the Annex also including the explanation above.

>Also must this really be done, one could translate all times
> if desired.

Sorry, I don't understand this sentence. What do you mean?

> 26. Section 9. Missing Offer Answer section.

OK

>
> 27. Section 11. Please write the IANA section as a statement what IANA
> must do. In this case it seems appropriate to write. "IANA is request
to
> register one MIME type (3GPP-tt) as defined by section 8."
>
OK

> 28. Section 12. Are there any data in the 3GPP timed text media format
> that can be introduced that would result in significant higher
> processing requirements for a receiver, thus enabling DOS attacks?
>

I think not.

Cheers ,

José

>
> Cheers
>
> Magnus
>
>
>
>
>
> --
>
> 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]
>
>
>
> This communication is confidential and intended solely for the
> addressee(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you believe this message has been
> sent to you in error, please notify the sender by replying to
> this transmission and delete the message without disclosing it. Thank
you.
>
> E-mail including attachments is susceptible to data corruption,
> interruption, unauthorized amendment, tampering and viruses, and
> we only send and receive e-mails on the basis that we are not
> liable for any such corruption, interception, amendment,
> tampering or viruses or any consequences thereof.
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>

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