Subject: [video-codec] Proposed changes to IETF draft on NETVC video codec requirements

From: Andrey Norkin <[email-masked]>
Date: Tue, 5 Apr 2016 21:19:16 -0700

Dear all,

Please find attached proposed changes to the IETF draft of NETVC
requirements document
https://datatracker.ietf.org/doc/draft-ietf-netvc-requirements/.
The changes include description of the Internet video streaming use case,
which is very relevant for Netflix, and proposed modifications and
suggestions to the general requirements to NETVC. The proposed changes are
also being discussed in the Alliance for Open Media (AOM)
http://aomedia.org/.

The attached MS Word file contains several sections from the IETF
requirements document with proposed modifications in the form of editing
marks and comments. The sections that do not contain modifications were
omitted from the document.

Waiting for your comments.

Best regards,
Andrey Norkin

---

From: Minhua Zhou <[email-masked]>
Date: Thu, 7 Apr 2016 10:31:31 -0700

Dear Andrey,

Thanks for bringing the streaming video requirements into the picture.  I
have few comments:

·         In section 2.1, you stated “High encoder complexity (up to 10x
and more) can be tolerated in case of on-demand streaming since encoding
happens once and in parallel for different segments. (Live streaming
typically requires lower-complexity encoders capable of real-time
operation)”

Would “High *software* encoder complexity” more accurately reflect what you
intended to say? For HW solutions, 10x increase of area and power
consumption is something very scary.

·         While I agree that resolution and quality scalability could be
desirable for some applications, I think that the focus of netvc
standardization should remain on the single layer codec design. The
preliminary designs of net-gen codecs such as JEM, AOM, and netvc are out
there for quite some time, but so far there is no evidence showing that
doing single layer and scalable codec design in parallel would result in a
better scalable codec design. Also, since the implementation cost of
building a single layer and scalable codec is distinctly different,
scalable tools should be in different profiles as we always had in the past.

·         Section 3.1.6, I think the statement of “Encoder should allow
feasible real-time implementations supporting a chosen subset of tools that
can be used by real-time applications” is not sufficient. An real-time
encoder design always has freedom of choosing a subset of coding tools to
meet design budget, but it would not serve the purpose if a codec was
designed so hardware implementation unfriendly that one had to cut some
many corners to meet real-time requirements,  resulting in the video
quality being marginally better or even worse than previously deployed
standards. I think it is important to make clear that for real-time encoder
implementations we expect significant coding efficiency improvements with
reasonable encoder implementation cost increase. Of course, the term of
“reasonable” here  is vague, but I do not expect 10x for hardware
implementations.

>From the document, it is clear to me that you are willing to spend 10x more
run-time for better coding efficiency, but it is not clear what coding
efficiency improvements we can expect for real-time encoder
implementations.  We should be designing a codec which is both hardware and
software implementation friendly, with enough coding efficiency enhancement
tools built-in for off-line encoding in which throughput, memory size,
memory bandwidth and etc. are not a big concern.

Software and hardware complexity have lots in common, but they are
different in lots of aspects. For example, large CTU and TU sizes may not
show up in run-time measures, but have significant impact on hardware cost
because of on-chip memory increase;   Longer motion compensation
filter-taps may show little difference in run-time because everything is
on-chip, but may significantly slow-down hardware implementations due to
memory bandwidth increase. While 10x run-time might be a good number for
run-time measurement guidance, other complexity measures shall also come
into play  when evaluating coding tools.

Best Regards,

Minhua

*From:* video-codec [mailto:[email-masked]] *On Behalf Of *Andrey
Norkin
*Sent:* Tuesday, April 05, 2016 9:19 PM
*To:* [email-masked]
*Subject:* [video-codec] Proposed changes to IETF draft on NETVC video
codec requirements

Dear all,

Best regards,

Andrey Norkin

---

From: Andrey Norkin <[email-masked]>
Date: Fri, 8 Apr 2016 14:15:03 -0700

Dear Minhua,

Thank you for your feedback. Please find my answers to your comments below
in green:

Andrey

On Thu, Apr 7, 2016 at 10:31 AM, Minhua Zhou <[email-masked]>
wrote:

> Would “High *software* encoder complexity” more accurately reflect what
> you intended to say? For HW solutions, 10x increase of area and power
I indeed meant software encoders. Of course, the effect of encoder
complexity increase for real-time hardware implementations would be more
significant (which is somewhat reflected in the note on live streaming).

> scalable tools should be in different profiles as we always had in the past.
I have included the scalability claim in the optional requirements in case
the NETVC codec happens to have a structure that allows "cheap" scalability
in terms of computational complexity and compression efficiency loss. In
this case, it would be beneficial to include it in the first profile. In
case NETVC codec has exactly the same block-based structure as previous
generations of VCEG and MPEG codecs, the scalability would likely come at
high complexity and compression efficiency cost and then it would makes
perfect sense to have profiles without scalability.
Would the following phrasing of the requirement better reflect this intent?

"Resolution and quality (SNR) scalability should be supported in the first
(main) version provided that scalability has low compression penalty (not
higher than 5% of bitrate increase per layer) and does not significantly
increase decoder complexity. "

> From the document, it is clear to me that you are willing to spend 10x
> more run-time for better coding efficiency, but it is not clear what coding
Agree. What about this wording?

Encoder should allow feasible real-time implementations supporting a chosen
subset of tools that can be used by real-time applications. *The real-time
encoder tools subset should provide sufficient improvement in compression
efficiency and take into account complexity of hardware and software
encoder implementations.*

---

From: Minhua Zhou <[email-masked]>
Date: Mon, 11 Apr 2016 07:41:17 -0700

Dear Andrey,

Your changes look good to me, provided that “Resolution and quality (SNR)
scalability should be supported in the first (main) version” does not
necessarily mean having scalable tools in every profile.

Best Regards,

Minhua

*From:* Andrey Norkin [mailto:[email-masked]]
*Sent:* Friday, April 08, 2016 2:15 PM
*To:* Minhua Zhou
*Cc:* [email-masked]
*Subject:* Re: [video-codec] Proposed changes to IETF draft on NETVC video
codec requirements

Dear Minhua,

Andrey

Dear Andrey,

Best Regards,

Minhua

Dear all,

Best regards,

Andrey Norkin