I have several comments, which I discussed with Alexey and some other participants during the Berlin meeting. The version cited above does not address them since it was published before our discussion.
Technical comments: 1. Page 12. Section 3.1.2. It may be useful to explicitly mention that levels definition may change in the future when we know better what complexity the codec has. 2. Page 13. Section 3.2.1. "Support of arbitrary resolution for such applications where a picture can have an arbitrary size (e.g., in screencasting)" --> "Support of arbitrary resolution *according to level constraints* for such applications where a picture can have an arbitrary size (e.g., in screencasting)" It is not practical for the codec to support completely arbitrary resolutions (e.g. a one-macroblock wide and very tall picture does not need to be supported). 3. Page 15. If we move Section 3.3.3 "Complexity" from optional to basic requirements, it would likely address Jonathan's comment. 4. Page 15-16, Section 4.1. Compression performance evaluation. It is proposed to calculate the BD-rate based on 12 bitrates, where three groups of four bitrates correspond to the low, medium, and high bitrate ranges. It would be better to align QP's or quality levels of two codecs rather than bitrates. The BD-rate savings are calculated on overlap in quality (e.g. PSNR or MS-SSIM values) between the rate-distortion curves of two codecs. If we align the bitrates then a big difference in codecs performance (i.e. a big distance between the RD-curves) would translate to poor overlap in quality ranges and less reliable BD-rate values. Another point is that the same bitrate may correspond to a very high quality for an easy sequence and a poor quality for a difficult sequence. Let's use alignment in QPs/quality levels instead as the basis for generating the bitstreams. 5. Same section. We should not require a 20-25% improvement on each quality range and each resolution. We could require instead 20-25% bitrate savings (average of three quality ranges) on high resolutions and somewhat lower (e.g. 15%) on lower resolutions. Finally, the requirements for improvements on each quality range could be half of the requirements for the average of three ranges. For example, we might not want to discard a proposed codec if it gets less than 20% BD-rate reduction at a very high quality range, where the codec is rarely used. 6. Page 16. Section 4.1. "To assess the quality of output (decoded) sequences, two indexes, PSNR [3] and MS-SSIM [3,11], should be separately calculated for each color plane." We should not calculate MS-SSIM for chroma planes since it was developed for luminance signal and will likely not reflect the visual quality (chroma is usually much smoother than luma). We can and probably should calculate the chroma PSNR to ensure it does not get a big drop due to a change in luma/chroma bit allocation. The question is whether we should use it when evaluating the bitrate savings (in my opinion, we do not have to but if we do, we should use some smaller weights for chroma planes, such as 1/8th for each chroma plane and 6/8th for the luma). Editorial comments: 1. Page 6. End of Section 2.1 - Fix the bullet sign. 2. Page 13. Section 3.1.4. Any elementary stream -> An elementary stream. 3. Page 14. Section 3.2.2. "Note 1: end-to-end delay should be up to 320 ms [2] but it's preferable value should be less than 100 ms [7]" Change "it's" to "its". Best regards, Andrey On Wed, Aug 24, 2016 at 9:07 AM, Adam Roach <[email protected]> wrote: > [as chair] > > As a reminder, the WGLC for this document ends tomorrow. If you have any > interest in commenting on the requirements before we freeze them, please > comment now. > > Thanks. > > /a > > > On 8/4/16 16:18, Adam Roach wrote: > >> [as chair] >> >> NETVC participants: >> >> We would like to start a two-week working group last call on the codec >> requirements document: >> >> https://tools.ietf.org/html/draft-ietf-netvc-requirements-02 >> >> All working group participants are encouraged to carefully read the >> document and comment on the mailing list -- even something simple like "I >> have reviewed the document and believe it is in good shape" is helpful. >> >> I'll also note that the question as to whether we request publication of >> this document as an RFC is still open. As part of this last call, please >> indicate whether you believe such publication would be of value. If we do >> not request publication, we will instead announce a document freeze at some >> point after the end of WGLC (roughly, the amount of time typically between >> end of WGLC and publication request). >> >> Thanks! >> >> /a >> >> _______________________________________________ >> video-codec mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/video-codec >> > > > _______________________________________________ > video-codec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/video-codec >
_______________________________________________ video-codec mailing list [email protected] https://www.ietf.org/mailman/listinfo/video-codec
