[video-codec] AD Review: draft-ietf-netvc-requirements-09 & draft-ietf-netvc-testing-08

[Adam Roach <[e-mail]>]

This is my AD review for both draft-ietf-netvc-requirements-09 and
draft-ietf-netvc-testing-08. Neither document contains any issues
that need addressing prior to IETF last call, which I plan to request
shortly. Please treat the comments below the same as you would any other
IETF last call comments.

Thanks to the authors of and contributors to both of these documents.

===========================================================================
draft-ietf-netvc-requirements-09
===========================================================================

Please either move the table in Appendix A to the beginning of Section 
1, or add
a forward citation to it from the introduction. Also, consider adding 
"SIMD" to
the table.

---------------------------------------------------------------------------

§2.1:

 >  o  Middle QP values are normally used in streaming, this is also the
 >     range where compression efficiency is important for this
 >     scenario.

Nit: "...in streaming. This is also..."

---------------------------------------------------------------------------


§2.6:

 >  There are many
 >  companies such as Twitch, YY in China enable game broadcasting

Nit: this sentence is missing a preposition. I suggest fixing it as: 
"...such
as Twitch and the China-focused YY that enable game broadcasting."

---------------------------------------------------------------------------

§3.1.4:

 >  3.1.4. A bitstream should have a model that allows easy parsing and
 >  identification of the sample components (such as ISO/IEC14496-10,
 >  Annex B or ISO/IEC 14496-15).

Please add references (in the "Informative References" section) to these
ISO/IEC documents.

---------------------------------------------------------------------------

§3.2.2:

 >  o  Resolution and quality (SNR) scalability that provide low
 >     compression efficiency penalty (up to 5% of BD-rate [12] increase
 >     per layer with reasonable increase of both computational and
 >     hardware complexity) can be supported in the main profile of the
 >     codec being developed by the NETVC WG.

Because working groups are generally not visible to consumers of RFCs,
we don't typically include information like this in final versions of
our documents. Consider removing everything after "codec".

---------------------------------------------------------------------------

§4.1:

 >  Initially, for the codec selected as a reference one (e.g., HEVC or
 >  VP9), a set of 10 QP (quantization parameter) values should be
 >  specified (in a separate document on Internet video codec testing)

...

 >  A list of video sequences that should be
 >  used for testing as well as the 10 QP values for the reference codec
 >  are defined in a separate document

Please cite draft-ietf-netvc-testing rather than indicating a "separate
document."

---------------------------------------------------------------------------

§4.1:

 >  According to the coding efficiency requirement described in Section
 >  3.1.1, BD-rate savings calculated for each color plane and averaged
 >  for all the video sequences used to test the NETVC codec

"...to test the candidate codec..."

 >  In addition to the objective quality measures defined above,
 >  subjective evaluation must also be performed for the final NETVC
 >  codec adoption

"...for the final codec adoption..."

 >  For
 >  perception-oriented tools that primarily impact subjective quality,
 >  additional tests may also be individually assigned even for
 >  intermediate evaluation, subject to a decision of the NETVC WG.

Omit the final clause (i.e., end the sentence after "evaluation").

---------------------------------------------------------------------------

§4.2:

 >  Reference software provided to the NETVC WG for candidate codecs
 >  should comprise a fully operational encoder supporting necessary

Omit "provided to the NETVC WG".

---------------------------------------------------------------------------

Consider removing section 6; conclusions sections are not common in
RFCs.



===========================================================================
draft-ietf-netvc-testing-08
===========================================================================

As a general question -- the requirements document calls out a couple of
chroma subsampling schemes that aren't mentioned in the testing document
(notably, YCbCr  4:2:2 and monochrome). If this omission is intentional, can
we add a sentence or two to the testing document that explains why running
tests with these schemes isn't necessary?

---------------------------------------------------------------------------

§2.2:

 >  The still image pair comparison method can be modified to also
 >  compare vidoes.

Nit: "videos"

---------------------------------------------------------------------------

§3.1:

 >  PSNR is a traditional signal quality metric, measured in decibels.
 >  It is directly drived

Nit: "derived"

---------------------------------------------------------------------------

§3.3:

 >  The PSNR-HVS metric performs a DCT transform of 8x8 blocks of the

Please expand "DCT"; e.g: "...performs a DCT (Discrete Cosine Transform)
of..."

---------------------------------------------------------------------------

§4.3:

 >  For individual feature changes in libaom or libvpx, the overlap BD-

Would it be possible to add citations for libaom and libvpx?

---------------------------------------------------------------------------

§5.3:

 >  Four operating modes are defined.  High latency is intended for on
 >  demand...

Nit: "...on-demand..."

 >  Both of
 >  these modes come in CQP and unconstrained variants

Please expand "CQP".

---------------------------------------------------------------------------

§5.3:

Where possible, please indicate where the tools being discussed can be
located:

  - av1
  - daala
  - vp9
  - x264