Dear colleagues, Today, version -06 of the requirements draft was published. The only change in the document is in Section 3.1.1. The sentence "3.1.1:The most basic requirement is coding efficiency, i.e. compression performance on both "easy" and "difficult" natural content as well as screen sharing content (both static and dynamic)." was replaced by "3.1.1:The most basic requirement is coding efficiency, i.e. compression performance on both "easy" and "difficult" content for applications and use cases in Section 2." It is done to keep the requirements draft consistent with the testing draft where different content is used for estimating compression performance.
In addition, we (the authors of the requirements draft) would like to comment on the changes appeared in version -05 of the document and discussed at the meeting in Chicago. 3.1.3: Bitstream syntax should allow extensibility and backward compatibility. New features can be supported easily by using metadata (e.g., such as SEI messages, VUI, headers) without affecting the bitstream compatibility with legacy decoders. A newer version of the decoder shall be able to play bitstreams of an older version of the same or lower profile and level. Our comment: In fact, this requirement was contained in the previous versions of the draft (starting from version -02). In particular, SEI messages, VUI and headers were mentioned there. To clarify this point, it is NOT a requirement that a new version of the codec with new coding tools has to support the older versions of that codec. It merely states that extending the current codec with support of new metadata, such as video source information etc, should not break compatibility with older bitstreams of the same codec. That is, the syntax for signaling metadata should be extensible and adding new metadata should not break compatibility with older decoders. The decoders should just ignore metadata they do not understand. Minor changes in Section 3.2.2. "Coding delay": Support of efficient random access point encoding (such as intra coding and resetting of context variables) as well as efficient switching between multiple quality representations. Our comment: This requirement was in the description of the use cases in the document (e.g., in section 2.1 "Internet Video Streaming"), now it is also explicitly mentioned in the requirements 3.2.3. Complexity: Feasible real-time implementation of both an encoder and a decoder supporting a chosen subset of tools for hardware and software implementation on a wide range of state-of-the-art platforms. The real-time encoder tools subset should provide meaningful improvement in compression efficiency at reasonable complexity of hardware and software encoder implementations as compared to current real-time implementations of state-of-the-art video compression technologies such as HEVC/H.265 and VP9. Our comment: This is just a clarification regarding what a feasible real-time implementation means. Your further questions and comments are welcome! -- Best regards, Alexey Filippov _______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
