[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Re: Request for WG Last-Call for draft-ietf-avt-rtp-3gpp-timed-text-07.txt
Hi Jose,
I have reviewed the draft, and found some things that needs to be
correct. However I think it is getting close.
1. Section 2.3.4: bullet 3:
"
3. for PAYLOAD 3:
ts(#6)= ts(#7)= rtpsts2= rtpts3
In this case rtpts3 must be equal to rtpts2 in order to be
able to assign this fragment to the correct sample (TS4).
Additionally, note that units 6 and 7 have the same timestamp
since they belong to the same text sample (also TS4)."
I think this paragraph is hard to understand, and maybe even misleading.
ts(#6) is equal to ts(#7) due to the rule that if type 2 and 3 are
present in the same payload they must all have the same timestamp. The
current second sentence gives the impression that due to that the TS are
the same, they belong to the same sample, while the reason is the rule.
I also think one should clarify that the values of SDUR are ignored in
this case. I would recommend that the comment is totally rewritten.
2. Section 3:
" Note that TYPE 5 units do not make use of the timestamp and therefore
the above does not apply for this particular case."
I have two comments around this. First, there should be a clarification
on how to set the RTP timestamp if one makes packets with only Type 5
packets. I would recommend to set it according to the current TS value.
Secondly, I think some clarification on when Type 5 packets shall be
assumed to become active. From the point they are received, when they
are unpacked, i.e. order in the RTP packet may have some meaning, or
when other packets type the type 5 was attached to is utilized. I think
this has some impact, although the guard band for dynamic types normally
would prevent it.
3. Section 3.1.1: Bullet about LEN:
o Finally, the LEN (16 bits) "Length Field": indicates the size (in
bytes) of this header field and all the fields following, i.e. the
LEN field followed by the unit payload (text strings and
modifiers, if any).
It might be beneficial to be clear to add a comment, that the only thing
excluded from the LEN field is the U|R|Type byte first in the payload
header.
4. Section 3.1.6:
" The SIDX value is in the (inclusive) interval [0,127], as this unit
contains a dynamic sample description."
It is not written explicitly that the SIDX value in a TYPE 5 payload is
the SIDX value for that content. I would propose something like this:
"The SIDX value that is assigned to the sample description carried as
sample content of this unit. As any sample description carried is a
dynamic one, the possible SIDX values are in the (inclusive)
interval[0,127]."
5. Section 12.1, I think should be moved into 3.1.6 as it contains
normative language about the handling of dynamic sample descriptions.
6. Section 6.1, last paragraph: I think the SHALL is very unnecessary, I
think a informative sentence is sufficient. What interoperability effect
would occur, and what does help with the definition that appropriate
values needs to be used.
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.
8. Section 7.1: I think there should be an appropriate reference to
figure 5.1 in [1] for how the tx, ty, width, height parameters work.
9. Section 7.1: Author/Change controller section in the template. As the
mime type belongs to IETF, the following split between author and change
controller is appropriate:
"
Author:
Jose Rey
Yoshinori Matsui
Change Controller:
IETF Audio/Video Transport working group delegated from the
IESG.
"
The Change controller section is provided by Allison and originates from
one of the APPS ADs.
10. Section 8.2, third paragraph:
"As stated in the O/A model, some "fmtp" (payload-format-specific)
parameters have a clear meaning and shall be included in the answer
as present in the offer. Other parameters may need to be set among
parties, because it is not clear that offerer and answerer shall use
the same values. A third type of parameters may take different
values for offerers and answerers."
This paragraph has several sentences of unclear wording:
First sentence, was is meant with "clear meaning". I think we usually
call them symmetric, and that is due to that both end-point needs to use
the same value for some reason.
Second sentence, what is meant with "set among parties"? It doesn't seem
to be declarative (which is the third alternative), so what is special
with these and what is the difference in relation to symmetric and
declarative parameters?
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?
12. Section 8.2.1, bullet 2:
"2. Parameters describing the display capabilities, ..."
Which parameters are included in this category? Please be explicit about
this.
13. Section 8.2.1, bullet 3, b: Please clarify that the tx3g applies in
the offerers or answerers transmission direction.
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.
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.
16. Section 8.4, second paragraph:
"In this case, the receiver of a session description MUST support the
parameters and given values for the streams or else it MUST reject
the session."
I think one can without changing the sentence meaning replace the first
MUST with "requires to"
17. Another "sver" related question, which i thought of in relation to
the example of a Sendonly offer: What happens if the sample description
format is version dependent? In that case you can't include the tx3g
parameter until you have agreed on the version you are going to use. The
resolution would to offer different versions using different payload types.
18. Section 12.1: The algorithm description. I have some problem with
the current description. Bullet 3, has an IF without an clear argument.
Also I think it fails to properly describe if the new X must be the next
value or values above the current active set. Or if one is allowed to
send an X=127 in a session that had the inactive set to be [64..127]?
Thus resulting in that the currently active set is completely inactivated.
19. Section 12.3:
o the Decoding Time to Sample Box (stts): the 24 least
significant bits of the "sample_delta" are mapped to the
field SDUR (Text Sample Duration),
I think this is incorrectly stated, I think one should use as many bits
as existing in the mapping to the SDUR value. Please consider that if
one strictly takes the lower 24, values one can't scale in the mapping,
or do ceiling value with the bits one have. Lets assume that one can
only represent number with 3 digits, and SDUR would be 1023, then one
could send this sample as one with SDUR=999 and another with
TS=TS_org+999 and SDUR=24.
Editorial comments
E1. Where has all the page break markers gone?
E2. Section 2.3.4, Bullet 1, the note:
"Note that no sdur value is assigned to TYPE 5
units, and they are taken into account in the timestamp
calculation."
Is there a missing "not" ".. and they are taken into .."?
E3. Section 6.1, second paragraph: "O/A" do not abbreviate here.
E4. Section 7.1, tx3g: Please include a reference after the first
reference to BASE64 encoding.
E5. Section 7.1, Additional information: The first sentence has lower
case "the" in the first sentence.
E6. Section 8.2, third paragraph:
"<directionality> may take the values sendrecv, sendonly andrecvonly."
missing space between "and" and "recvonly".
E7. Section 8.2.1, bullet 1, second sentence: Unclear what "they" refer
to, please write out "The offerer or answerer".
E8. Section 8.3: "Note also that the answerer's text box dimensions fit
.." Shouldn't text box be text track in this sentence?
E9. Section 11: Ref [1] exist in 6.0.0 version. Also [16] is available
in rel 6 if that is desired to be used as ref instead of the REL5 version.
If there is any unclarities about my comments, simply ask about it.
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: magnus.westerlund at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt