Hi all! https://datatracker.ietf.org/doc/draft-ietf-netvc-requirements/
The requirements document could do with some reviews. Check out Filippov’s email below re changes to the doc, review the doc (link above) and send comments to the list. Thanks! Natasha On 28 Apr 2017, at 12:24, Filippov Alexey <[email protected]<mailto:[email protected]>> wrote: 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 This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.
_______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
