Subject: [AVT] Re: Update (-08) Timed Text draft

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Jan 2005 17:16:31 +0100

Hi Jose,

Lets see if I can provide some response to the question and comments. 
See below.

Rey Jose wrote:
> Hi Magnus, Colin, All,
> 
> I've just sent an update to the ID manager.  You can get it here until
> is published
> http://www.prdcg.panasonic.de/ietf/docs/draft-ietf-avt-rtp-3gpp-timed-te
> xt-08.txt
> 
> Below are the comments and actions taken in the draft -08. The first
> part is the issues pending (until the "Non-issues" mark); the second one
> is the the non-issues; this part is just there for quick checking of
> each comment. Not necessarily to be read, if one reads the draft anyway.
> 
> 
> I have introduced many figures, 2 new sections on relation to RFC2793
> and RFC3640. Also re-arranged into introduction, motivation, basics of
> the format, requirements and limitations at the beginning.  I hope it is
> easier to read now.
> 
> 
> ------
> [CP]
> In Section 3.1.2, SDUR has 3 bytes, since two bytes gives limited
> maximum duration. This will be true no matter what: is it appropriate to
> place a fixed maximum? Or to define a way in which event duration can be
> extended by a following packet to allow unlimited duration events?
> [JR]
> "o	SDUR (24 bits) "Text Sample Duration": indicates the sample
> duration in RTP timestamp units of the text sample.  For this field, a
> length of 3 bytes is preferred to 2 bytes.  This is because, for a
> typical clockrate of 1000 Hz, 16 bits would allow for a maximum duration
> of just 65 seconds, which might be too short for some streams.  On the
> other hand, 24 bits at 1000 Hz allow for a maximum duration of about 4.6
> hours, while for 90 KHz, this value is about 3 minutes.  These values
> should be enough for streaming applications.  However, if a larger
> duration is needed, the extension mechanism specified in Section 4.2
> SHALL be used."
> 
> An extension mechanism has been defined. Thereby a copy of the sample
> with adjusted timestamp and duration is sent:
> "I.e., a sample with timestamp TS and duration SDUR can be sent as two
> samples having timestamps TS1 and TS2 and durations SDUR1 and SDUR2,
> such that TS1=TS, TS2=TS1+SDUR1 and SDUR= SDUR1+SDUR2."
> 
> Comments?

Seems okay for me.

> --
> [JR]
> Also the draft states now explicitly that a limitation is not being able
> to convey packet sizes larger than a 16 bits integer.  This is a design
> choice and it is considered enough for streaming apps. There is no
> extension mechanism defined for this reason. Comments?

Okay for me.

> --
> [MW]
> 
>>14. Section 8.2.2: Last bullet: The usage of "sver" in multicast? Is
> 
> it really possible to offer more 
> 
>>than one version that all uses? Especially if the version result in
> 
> that different parsing of the samples  > must be used, then one can 
> 
>>really only offer one. Otherwise one needs to agree on the version
> 
> used.
> 
> [JR]
> I think so: as "sver" is defined currently if a newer extension to the
> 3GPP TS26245 is done which is not backwards-compatible with previous
> versions or cannot be discarded, then this version will not be listed in
> the "sver" param list (per definition). So this case cannot happen in
> the first place. 
> 
> Thus, if alternative non-compatible versions are offered, then this
> should be done using different payload types. Is this acceptable?
> 
Yes

> On the other hand, it is the question whether the "sver" may be
> obviated. We say that parameters that are not understood by the SDP
> consumer are ignored and the timed text format itself is
> backwards-compatible.  then there's no need, correct? 
> 

It might be beneficial to indicate which version the stream is actually 
for. Also if non-backwards compatible changes are introduced, then the 
SVER becomes a necessity for allowing the payload format to be used.

> --
> [JR]
> 
> I've been asked by some MPEG people whether it would be possible to
> introduce a header that uses char counter to allow the number of chars
> lost to be known. Obviously I have no time to do this.  But, could a new
> header be added later? There are three types remaining "TYPE 0, 6 and 7
> are reserved." Could the number be used in a later complementary draft?

Yes, if it is defined that these can be ignored and simple the LEN field 
is used to skip them.

> ---
> [JR]
> 
> I've done some more emphasis on packet repetition as a means for
> resilient transport, in particular on carousel data transmission in
> section about resilient transport.  Since one of the main applications
> will be for multicast and timed text has low bitrates, I think RTP
> carousel should be a good trade-off, instead of choosing more complex
> redundancy methods such as rfc2733 or reliable multicast.  Comments?

I think repetition is a good always available and interoperable way of 
achieving more resilient. However in certain cases it is wise to 
consider other methods, thus I think the new text has a decent trade off.

I do however object to the SHOULD in the last sentence of Section 5. I 
would suggest to replace it with a more informative "could". The point 
is that there exist other methods to be used if necessary by that 
application context.

> --
> [MW]
> 11. Section 8.2.1, bullet 1, a, i: Should it also be added, that unless
> special 
> preference exist the offered value should be used?
> 
> [JR]
> 
> Hhmmm... a) if not used then the answerer MUST ensure that the
> preference of the offerer are compatible with the values offered, how
> makes this sense?? and b) what should be done if this is not so?? A
> behaviour for error case shall be defined...no?
> 
> Accordingly, in the second bullet the second MUST changed to SHOULD.
> 
> This is what I wrote:
> 
> "
> a.	"tx", "ty" and "layer": these are parameters describing where
> the received text track is placed.  Depending on the directionality:
> i.	MUST appear in all sendrecv offers and answers and in all
> recvonly offers and answers(thus applying to the incoming stream).  In
> the case of sendrecv offers and answers and in recvonly offers, these
> values SHOULD be used by the sender of the stream unless it has a
> particular preference, in which case, it MUST make sure that these
> different values do not corrupt the presentation.  For recvonly answers,
> the answerer MAY accept the proposed values for the incoming stream (in
> a sendonly offer, see bullet below) or respond with different ones.  The
> offerer MUST use the returned values.  
> 
> ii.	MAY appear in sendonly offers and MUST appear in sendonly
> answers.  In sendonly offers they specify the values that the offerer
> proposes for sending (see example in Section 9.3).  In sendonly answers
> these values SHOULD be copied from the corresponding recvonly offer upon
> accepting the stream, unless a particular preference by the receiver if
> the stream exists, as explained in the previous bullet "

This looks good to me.

> ---
> 
> [MW]
> 7. Section 7.1: I think that a number of parameters are misclassified.
> Any 
> parameter that do not need to be included in all messages belongs under
> Optional 
> parameters. I think that include: max-w, max-h, width, and height. This
> also has 
> effect in 8.1.
> [JR]
> What means are "all" messages? Sendrecv or recvonly O & A? I thought
> about all possibilities and created a new table:
> 
> +..---------------------------+----------+----------+----------+
> |   ``--..__  Directionality/ | sendrecv | recvonly | sendonly |
> + Type of   ``--..__   O or A +----------+----------+----------+
> |    Parameter      ``--..__  |   O/A    |   O/A    |   O/A    |
> +--------------+------------``+----------+----------+----------+
> | Declarative  |tx, ty, layer |   M/M    |   M/M    |   m/M    |
> |              |              |          |          |          |
> +--------------+--------------+----------+----------+----------+
> | Display      |max-h, max-w  |   M/M    |   M/M    |   -/-    |
> | Capabilities |              |          |          |          |
> +--------------+--------------+----------+----------+----------+
> | Stream       |height, width |   M/M    |   -/(M)  |   M/M    |
> | properties   |tx3g          |   m/m    |   -/-    |   m/m    |
> |              |              |          |          |          |
> +--------------+--------------+----------+----------+----------+
> |  Negotiable  |sver          |   M/M    |   M/M    |   M/M    |
> |              |              |          |          |          |
> +--------------+--------------+----------+----------+----------+
> |  Symmetric   |rate          |   M/M    |   M/M    |   M/M    |
> +--------------+--------------+----------+----------+----------+
> Table 1. Parameter usage in Unicast Offer /Answer.
> 
> Key:
> o M means MUST be present
> o m means MAY be present (such as proposed values)
> o (m) or (M) means MUST or MAY, when applicable
> o means MUST NOT be present.

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. Sure, there usage rules says that they needs to be present 
almost always, but there is still cases where you can skip sending them, 
thus optional.

The question is if these parameter are really required parameter and 
also is required to be hinted in a Offer, or it they should simply be 
moved to the Optional part of the MIME registration.

> ---
> 
> [MW]
> 15. Section 8.3:
> "In this case the answerer's "max-h" and
>    "max-w" are compatible with the offerer's "height" and "width".
>    Otherwise, the answerer would have to remove this stream and the
>    answerer issue a new offer taking the answerer's capabilities into
>    account."
> 
> I would like to make you aware that the offerer will not receive a
> payload type 
> at all if the answerer has to refuse the stream due to that height and
> width are 
> larger then the supported max-w and max-h. The only way to ensure that
> this 
> would happened would be do define multiple payload types, with at least
> one that 
> is guaranteed to be acceptable, thus allowing the answerer to give his
> max-w and 
> max-h parameters. Then the offerer can re-issue the offerer with the
> knowledge 
> about the answerers capability.
> 
> [JR]
> I added the following: 
> "In this case the answerer's "max-h" and "max-w" are compatible with the
> offerer's "height" and "width".  Otherwise, the answerer would have to
> remove this stream and the offerer would have to issue a new offer
> taking the answerer's capabilities into account.  This is possible only
> if multiple payload types are present in the initial offer so that at
> least one of them matches the answerer's capabilities as expressed by
> "max-h" and "max-w" in the negative answer.  Note also that the
> answerer's text box dimensions fit within the within the maximum values
> signalled in the offer.  Finally, the answerer chooses to use version 60
> of the timed text format."

Looks okay.

-- 

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]

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