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

From: Filippov Alexey <[email-masked]>
Date: Wed, 27 Jan 2016 13:32:50 +0000

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

---

From: "Coppa, Greg" <[email-masked]>
Date: Thu, 28 Jan 2016 17:31:05 +0000

Dear Alexey -

I agree with Andrew that the frame rates referenced in BT.2020 Table 2 are representative of the fractional frame rates in use and should be included into the draft-ietf-netvc-requirements.

Best regards,

greg

From: "Krupiczka, Andrew" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 27, 2016 10:24 AM
To: Filippov Alexey <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, greg coppa <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Adam Roach <[email-masked]<mailto:[email-masked]>>, Zhoujiantong <[email-masked]<mailto:[email-masked]>>, Jose Alvarez <[email-masked]<mailto:[email-masked]>>
Subject: RE: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements

Dear Alexey,

>From our current (but also mid-term future perspective) referring to the Table 2 in BT.2020-2 (see https://www.itu.int/rec/R-REC-BT.2020-2-201510-I/en ) would be more than sufficient.
Certainly due to associated complexity, for now we may want to limit the frame rates requirement above 60fps to be only supported let’s say for up to 1080p resolution, since we’re already listing:

| 2160p (4K),3840x2160 |  24, 25, 30, 48, 50, 60 |       RA       |

and the codec levels in the Table 6 already much higher than that?

Alternatively, any frame-rate higher than 60fps could be placed into the section 3.2.1 as an optional requirement.

Best regards,

Andrew

From: Filippov Alexey [mailto:[email-masked]]
Sent: Wednesday, January 27, 2016 4:30 AM
To: [email-masked]<mailto:[email-masked]>; Krupiczka, Andrew; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Adam Roach; Zhoujiantong; Jose Alvarez
Subject: Re: Re: [video-codec] Call for review comments: draft-ietf-netvc-requirements

Dear Mr. Coppa, dear Mr. Krupiczka,

Thank you for your valuable comments! Is my understanding correct that you want to keep fractional frame-rates just for IPTV/OTT/VoD applications? Could you please specify a set of such fractional frame-rates that you would like to include into draft-ietf-netvc-requirements?

Thank you in advance!

--
Best regards,
Alexey Filippov