[AVT] Review draft-ietf-avt-rtp-h264-09.txt

[Joerg Ott <jo at tzi.uni-bremen.de>]

Folks,

please find below my "official review" comments for
draft-ietf-avt-rtp-h264-09.txt.  Comments are largely minor
and I do not see any reason not to proceed quickly with this
draft.

Comments:

Sect. 5.2, NRI, 2nd para:
  The text suggests that "network elements" may look into the
  payload-specific header and use this information for some kind
  of prioritization.  While it may be true that they can, they
  probably should not try to perform payload-specific functions
  as this requires them to first learn about the payload type
  of the stream, will not work with SRTP, will incur significant
  performance penalty, etc.

  It may be that the sender can use this information to map the
  packets to different service classes but I would discourage
  mentioning network elements here.  (Maybe the term is just
  misleading.)

Sect. 5.4, Table 2:
  Disallowing the undefined types means that any future extension
  will require an update to the H.264 draft (rather than a supplement).
  It may be better to just specify what to do with these reserved
  values rather than forbidding them outright.

Sect. 5.7 and 5.8:
  I may have missed it (and it may go without saying) but the draft
  does not appear to specify the use of "network byte order" for
  16 and 24 bit values.

Sect. 6.1, last para:
  The term network element should be avoided here since we are
  talking about transport/application layer functions.

Sect. 7.1, 1st para:
  While only informative and an example, there may be other
  governing local rules (e.g. inter-stream synchronization)
  that would not want to see a packet to be passed to the
  decoder immediately after decapsulation.

Sect. 7.2, 2nd para:
  While again only informative, this part does not consider
  outdated (too long delayed) or duplicate packets.

Sect. 8.1, max-cbp and max-dbp:
  There is likely to be a good reason in H.264, nevertheless the
  units for these parameters appear confusing.  Both refer to
  a size, but while max-cbp is specified in 1000bit units, max-dbp
  uses 1024 byte units.

Sect. 8.2.2, p.49, 2nd-to-last line
  "is going to" -> "is able to"

Sect. 8.2.3, last para
  "or the receiver must reject the session"
  ->
  "or the receiver MUST reject (RTSP) or not participate in (SAP)
  the session"

Sect. 10, last para:
  Again, "network elements" is not a good term here.

Sect. 12.5, p.62, 2nd para:
  The sentence "Although end-to-end solutions are usually not preferable,
  they are unavoidable in some scenarios." probably deserves some further
  explanation.


More of an issue to point out:

Sect. 5.1, last para:
  The informative note on the jitter estimation is surely a good idea.
  But it is a bad thing that the packet format modifies generic
  RTP assumptions and counters the use of general purpose RTP analysis
  tools (or libraries).  It appears it be worthwhile to report how an
  H.264-aware receiver would perform these calculations properly.


Editorial nits:

Sect. 1.1, 2nd para: the second sentence ("Most, if not all...")
  could well be deleted since it does not really add any value.

Sect. 1.1, 2nd para:
  "In-picture" -> "Inter-picture" ???

Sect. 3.:
  "video telephony or video conferencing"

Sect. 5.2, 1st para: "depending on need"

Sect. 5.2, F: 1 bit,
  4th line: "MAY" -> "may"

Sect. 5.3, NRI, 1st para
  "Value above 00" -> "Values greater than"

Sect. 8.2.2, p.52, 6th para:
  "outer limit" -> "upper limit"

Sect. 8.3, last para:
  New para before "Please note that"

Sect. 12.6 and 12.7: "This scheme..."

Finally, there are some general comments:

-- The Informative notes should be somehow indented to improve readability.
-- Double check the use of normative language throughout the document
   (e.g. also in all descriptions of field semantics)

Cheers,
Joerg


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt