Organisation internationale de normalisation
HM Settings and Common Test Conditions
Yüklə 7,54 Mb.
|
17.2HM Settings and Common Test Conditions17.2.1.1.1.1.1.1.1JCTVC-D040 PSNR computation on R'G'B' color system [D. Hoang (Zenverge)] The R′G′B′ color system is commonly used in the specification of digital video capture and display devices. Digital video transmission and compression systems, on the other hand, commonly use the Y′CBCR component color system. Digital video compression systems (generally) code the residuals of the Y′, CB, and CR components separately. Objective distortion in video compression is commonly measured using the Y′, CB, and CR components, with MSE being the most commonly used measure. In the evaluation of a digital video compression system, it can be difficult to juggle three different distortion measurements, especially when trying to balance the coding of the Y′, CB, and CR components. In this document, it was proposed to compute a single distortion measure based upon a combined MSE of R′, G′, and B′ components. To illustrate the proposed R′G′B′ distortion measure, an analysis of the simulation results from JCTVC-D035 was provided. A participant suggested the following combined measure: ( 6 * AVPSNRY + AVPSNRCb + AVPSNRCr ) / 8. Another suggestion in the proposal was to compute MSE across all frames and then perform the log conversion (resulting in a arithmetic-mean-MSE-based PSNR rather than a geometric averaging). A participant suggested to consider a frame with infinite PSNR. Averaging in the log domain results in an infinite average. A participant suggested that averaging in the log domain seems closer to an averaging in the MOS domain. A participant recalled the suggestion to measure coding performance by adding up total bits across both the "easy" and "difficult" sequences, and then producing BD measures from that. Further study on finding improved fidelity measurement practices was encouraged, although using R'G'B' rather than Y′CBCR was not supported. 17.2.1.1.1.1.1.1.2JCTVC-D181 Report on the evaluation of HM versus JM [Seungwook Park, Joonyoung Park, Byeongmoon Jeon] This document reported an evaluation of HM compared with JM in respect of both coding efficiency and complexity. Modified anchors (for the Alpha/HE and Beta/HE anchor coding tool configurations) were used, to (approximately) match the QP settings used in the current HM common conditions. "Gamma"/LC anchors were not tested. Intra-only behavior was additionally tested. Six common configurations for TMuC 0.9 and Alpha and Beta configurations for JM 16.2 were used. As a result, 17.1% BR for I HE, 36.2% BR for RA HE and 31.2% BR for LD HE were achieved from an objective coding efficiency perspective. And in the decoder side, 75% for I HE, 22% for RA HE and 49% for LD HE complexity increase were observed. At the encoder side, 110% for I HE, 112% for RA HE and 193% for LD HE runtime increases were observed. And the low complexity configuration provides less gain and lower complexity than the HE configuration (as should presumably be the case). It was remarked that we should not pay too much attention to the speed of reference software, since it depends heavily on code optimization issues. It was remarked that, to the extent that it is relevant, the JM has been getting faster since the version used here. It was remarked that the Beta anchor used hierarchical P rather than forward-predictive B coding, and could have benefitted from such usage. It was remarked that it is important to keep in mind that our actual goal is to measure perceptual quality differences, not PSNR behavior. The contributor did not try any subjective viewing to see to what extent the perceptual quality matched the PSNR behavior. It was remarked that chroma was not improving as much as luma in these tests. This may simply be a matter of the default relationship established in the designs between luma and chroma quantization fidelities, or could indicate some other issues as well. Another possible explanation was the RDOQ operation in chroma. Another possible explanation was unusual behavior of the chroma R-D points to which the BD curve interpolation and cross-curve averaging was applied. The proponent suggested that:
Contributions to achieve these goals would certainly be welcomed. 17.2.1.1.1.1.1.1.3JCTVC-D234 Random access support for HEVC [A. Fujibayashi, TK Tan (NTT DOCOMO)] This contribution reported that random access is not actually properly supported in the HM0.9 software and therefore the common test conditions currently do not simulate true random access capabilities, as the bitstreams that are created cannot be decoded from the middle of the bitstream without causing error propagation. Two different methods that output random accessible bitstreams were added to the HM0.9 software and simulation results were reported. The first method implements the "closed GOP" instantaneous decoding refresh (IDR) which is useful when simple bitstream editing and splicing are needed. The second method implements an "open GOP" which gives better coding efficiency than the first method. An average coding gain of 4.4% in BD BR for both high efficiency and low complexity test was obtained with the open GOP refresh method compared to the IDR method. Both random access enabling methods show merit and it was proposed that both these methods should be added to the HEVC description and future HM software releases. When performing core experiments under the random access coding conditions, it was recommended that the open GOP refresh method be used. Finally, the ability to skip frames and random access into the middle of a bitstream had also been implemented in the HM0.9 software decoder. It was proposed that this feature be added to the future releases of the HM software as well. The coding efficiency loss of the open GOP method, relative to the current buggy behavior, was reported as 1.9% and 1.1% for HE RA and LC RA, respectively. Decision: Adopted (although not necessarily using the suggested "deferred decoding refresh" term). 17.2.1.1.1.1.1.1.4JCTVC-D265 Cross-check results of JCTVC-D234: random access support for HEVC [W.-J. Han (Samsung)] Cross-check for JCTVC-D234. The cross-checker confirmed the presence of the problem, as well as the impact of the fix. 17.2.1.1.1.1.1.1.5JCTVC-D356 Three digits to speed up the reference encoder [F. Bossen (DOCOMO USA Labs)] Track A In this proposal, some relatively minor modifications to the software were suggested. The proposed modifications reportedly result in little coding performance loss (<0.5%) while significantly speeding up the encoder (by up to 37%).
The above changes were motivated for (reference encoder) complexity reduction. A further modification was provided for obtaining coding efficiency improvement.
Decision: Adopted all of these changes into the HM reference configurations. It was remarked that we would likely benefit from having improved (fast) motion search for the HM, and such work was encouraged. It was also noted that a description of the algorithm used for the search should be put into the HM document. A corresponding software branch was released as branch 1.0-D356 on the server. 17.2.1.1.1.1.1.1.6JCTVC-D093 Reference Lists For B Pictures Under Low Delay Constraints [C.S. Lim, S. M. Thet Naing, V. Wahadaniah, X. Jing (Panasonic)] This contribution provided an investigation report on the different reference picture lists settings when QP fluctuation is used for low delay constraints. The best coding performance can reportedly be achieved when the reference picture list 0 for B pictures is ordered based on quality while reference picture list 1 is ordered based on POC. The proposed technique reportedly provides an average gain of 11.0% for HE and 11.5% for LC settings under LD constraints. It was remarked that the current software does not match the draft in regard to reference picture list construction, and that this should be fixed. It was remarked that the planned modified common conditions use more reference pictures in the lists, and the proposal does not (directly) describe/study what to do in this case. It was noted that the AVC (Beta) anchors used for the CfP used hierarchical QP for LD in the HE case. It was suggested to use QP scaling in the LD configuration, but not modify the list construction at this time (other than to use more pictures, as proposed in JCTVC-D356). Decision: It was agreed to use this technique. QP settings used in the contribution were as follows:
This discussion was later revisited for QP value refinement; after integrating the changes due to JCTVC-D356, the results of that were as follows:
The encoder and decoder actually ran somewhat faster – due to effectively running at a lower bit rate. It was noted that the above configuration differs from what we do for RA:
Results of that were as follows:
It was suggested to use the second case above, to minimize the chance of bit rate effect, for greater consistency with RA case, and for reduced potential for artifacts in the top layers. Decision: This was agreed. The results for these experiments described above were to be uploaded as a revision of JCTVC-D356. It was suggested to study the effect on the overall bit rate operating points. This will be for further study. Further study of the reference list contruction was also recommended. 17.2.1.1.1.1.1.1.7JCTVC-D416 LCEC RDOQ speedup [V. Seregin, J. Chen (Samsung)] (late registration Monday 17th, uploaded Monday 17th, before meeting) This contribution proposed complexity reduction for LCEC RDOQ, reportedly with a minor software modification in a similar manner that already existed in RDOQ for CABAC. The proposed method reportedly provides 0.0%, 0.1% and 0.0% performance loss and with the 81%, 93% and 93% running encoder time in low complexity intra-only, random access, and low-delay configurations, respectively. The revision reportedly adds only one (relatively brief) line of code. Cross-verification was provided in (late) document JCTVC-D437. JCTVC-D374 also relates to this. Decision: Adopted. 17.2.1.1.1.1.1.1.8JCTVC-D437 Cross-check of JCTVC-D416 LCEC RDOQ speedup [Jing Wang, Dake He (RIM)] (late registration Sunday 23rd after start of meeting, uploaded Sunday 23rd, fourth day of meeting) Cross-verification of JCTVC-D416. The software was studied as well as tested. Results matched in all but one case, where there was not a major difference.
Yüklə 7,54 Mb. Dostları ilə paylaş:
|