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 protected]] *Sent:* Friday, April 08, 2016 2:15 PM *To:* Minhua Zhou *Cc:* [email protected] *Subject:* Re: [video-codec] Proposed changes to IETF draft on NETVC video codec requirements 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 protected]> wrote: 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. 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). · 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. 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. " · 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. 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.* Best Regards, Minhua *From:* video-codec [mailto:[email protected]] *On Behalf Of *Andrey Norkin *Sent:* Tuesday, April 05, 2016 9:19 PM *To:* [email protected] *Subject:* [video-codec] Proposed changes to IETF draft on NETVC video codec requirements 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
_______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
