Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements

[Filippov Alexey <[e-mail]>]

Dear Mr. Zhou,

Thank you so much for your analysis of draft-ietf-netvc-requirements and your valuable comments!
I'd like to put my 2 cents in:


1)      Table 6.

It seems that the parameters there only constrain the maximum pixel rate, which is not sufficient for containing decoder implementation cost. We need to have additional parameters to restrict decoder on/off chip memory footprint and entropy decoding throughput. At least the following parameters are missing:

*         Maximum horizontal picture size  => impacts line buffer size

*         Memory size for buffering bitstream and decoded reference pictures  => impacts off-chip memory size

*         Maximum bit-rate and minimum compression ratio => impacts entropy decoding throughput requirement for real-time decoding


[AF]: Yes, I fully agree that it should be included into table 6. However, it's hard to do it right now as we currently don't have the detailed information on final codec architecture (e.g., we can't say how many pictures should be kept in the buffer) and its compression performance (maximum bit-rate and minimum compression ratios will evidently depend on the codec's actual compression performance). I guess we should keep this comment in mind and add the mentioned information into table 6 when available. In other words, I guess profiles and levels can be more clearly defined when the final codec architecture is better defined.


2)      Section 3.1

if YUV 4:4:4 is a basic requirement, there should be no problem for a same codec to support RGB 4:4:4 color sample format. Therefore, YUV/RGB 4:4:4 should be put in a same place (either in section 3.1 or in  3.2)

[AF]: Yes, there should be no problem for a same codec to support RGB 4:4:4 color sample format like it is done in the HEVC RExt profile. But direct coding of RGB source material can adversely affect the coding gain in comparison with YUV case. So, RGB 4:4:4  support was considered as an optional requirement.


3)      HDR (high dynamic range) should belong to section 3.1.

4)      WCG (Wide Color Gamut) support is missing, e.g. color space BT.2020, DCI-P3, BT.709 and OETF (ST.2084, HLG, BT.1886)

[AF]: In my opinion, these two comments are a very good point. I guess they should be discussed together with levels and profiles to avoid encumbered implementations.


5)      Section 4.1

since H.265 is taken as reference codec for compression efficiency comparison,  why not taking JCTVC approach to do subjective quality evaluation, i.e. using 4 fixed QPs (could be sequence dependent to match the target bit-rates) and computing BD-rate difference at the end?

[AF]: You probably meant objective (not subjective) quality evaluation. Now, it is proposed to evaluate objective performance in 3 ranges (for low, middle and high bit-rates). In the current version of the draft, the ranges are non-overlapped and each of them include 4 bit-rates that should be specified in the test draft. Hence, the simulation should be performed for 12 bit-rates. Is the high amount of calculations your concern? If so, it is possible to keep 3 ranges but they can be overlapped as it was done in draft-filippov-netvc-requirements-01 (page 10). Anyway, I guess it's reasonable to separately evaluate the coding gain for low, middle and high bit-rates to know in what bit-rate range a codec as a whole or its separate coding tools are more efficient.
In addition, I'd like to emphasize that both Daala and Thor have different QP ranges and we cannot simply map Daala's QP range into Thor's QP range and vice versa as this mapping is content dependent as you mentioned in your comment. I performed such experiments and tried to carry out such a mapping for Daala and HEVC but this attempt failed because the correspondence between Daala and HEVC QPs differs for different sequences. I assume that a similar situation will be observed if we compare Daala and Thor. If your concern is that different codecs will use different rate-control mechanisms that can impact the overall performance of candidate codecs, I agree that only QP adjustment (but not rate-control) should be used to match the target bit-rates.

--
Best regards,
Alexey Filippov