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 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
