International organisation for standardisation organisation internationale de normalisation
Yüklə 8,24 Mb.
|
- Bu səhifədəki naviqasiya:
- Target/Achieved Target/Achieved
- Configuration Sequence Number of Viewers
- Total 92 23 41
Subjective evaluation results:
Compared to the objective results, the visual quality difference between AVC and HEVC appears to be larger (in favor of HEVC). 5.4Profile/level definitionsSome key issues were noted in discussions to include the following:
5.4.1.1.1.1.1.1.1Joint meeting discussion 1600-1700 Tuesday VCEG/MPEG/JCT A joint meeting discussion was held from 1600–1700 on Tuesday 7 Feb 2012. A focus of the discussion was the contribution JCTVC-H0734 "Straw man for profiles and levels". It had been submitted during the meeting by a number of participants. It proposed an initial profile by starting the discussion from the prior LC configuration plus SAO. In terms of "tools", LMChroma, AMP, ALF and NSQT were not included in its proposed profile. It was asserted that there does not seem to be a major difference in coding efficiency depending on whether these "tools" are enabled or not. There was also discussion of the "flexible" (negotiable) profiles as described from H0637. Regarding the so-called "fixed" & "flexible" approaches – e.g. as discussed in H0637, some skepticism was expressed, although it was noted that such systems have existed previously and are supported in standard protocols. This approach was already supported in some ITU-T protocols, e.g. for H.263+, but it is not generally known to what extent such additional flexibility has been used in practice (particularly with cross-vendor interoperability). This type of approach was considered not applicable for broadcast applications. There was some discussion of how to test conformance with such flexibility. Two approaches were considered possible: adding tools or subtracting tools. We did not have a concrete proposal regarding specifically what coding tools should be optional and whether they are beneficial to use in such a flexible-negotiation scenario. The conclusion reached at this point was to adopt one draft profile, and to adopt levels with numbering somewhat aligned with AVC – not pursuing the so-called flexible approach for the time being. A BoG coordinated by K. McCann was requested to further discuss and refine the profile/level definition based on the above. The report of that BoG was produced as document H0738, which was later reviewed as noted below. 5.4.1.1.1.1.1.1.2JCTVC-H0738 JCT-VC BoG report on profiles & levels [K. McCann, T. K. Tan (BoG coordinators)] The BoG recommended to establish a "Main" profile. The proposal was discussed, revised as follows, and agreed, with the following characteristics:
Decision: Adopted per above (consult BoG report for clarification or missing details). 5.4.1.1.1.1.1.1.3JCTVC-H0116 AHG8: Objective and subjective evaluation of HM5.0 [T. K. Tan, A Fujibayashi, J. Takiue (NTT Docomo)] This contribution reported objective and subjective performance measures for the HM5.0 compared to JM18. In addition to the high efficiency (HE) and low complexity (LC) common conditions as specified in JCTVC-G1200, combinations of LC with one or more tools enabled in HE but not in LC were also investigated. The contribution provided an assessment of the performance of HM5.0 and its tools combinations starting from objective measurements and followed by informal subjective assessments. Graphs of the average BD bit rate vs. encoding / decoding time reportedly showed that the objective gains of HE compared to LC were mainly contributed by RDOQ, ALF and SAO. It was also reported that RDOQ does not incur any additional decoding time for the decoder, while SAO and ALF contribute most if not all of the additional decoding time needed by HE compared to LC. Between SAO and ALF, ALF contributes the larger portion of the decoding time. This contribution also asserted that visual comparison showed that all the tools in the HE configuration beyond those in the LC configuration, except for SAO, did not give any significant subjective quality improvement. Based on these results, a clustering of coding tools was made and LC with RDOQ and SAO enabled (LC+RDOQ+SAO) was suggested as the subset of tools combination that gave the best tradeoff in terms of coding gains and decoding time. Subjectively, RDOQ did not seem to help measurably in subjective quality although it did in PSNR. It was reported that RDOQ can sometimes cause noisiness. However, SAO seemed to have substantial effectiveness in subjective quality improvement – perhaps more than would be expected by PSNR. The reported subjective testing results used only the Class B and Class C CTC sequences. It was reported that ALF gives good SNR improvement but no apparent measurable visual benefit. Subjective viewing was conducted in two rounds: Pre-investigation with expert viewers, and then a test with non-expert viewers Reported subjective performances of different combination of tools for random access coding structure were as follows:
Reported subjective performances of different combination of tools for low delay B coding structure:
The contribution suggested the following commented clustering of HM tools:
Reported informal test comparing HM5.0 high efficiency to JM18.2* (where " JM18.2*" indicates the JM-based encoding described in JCTVC-H0360) under random access conditions:
Thus, in 83% of the tested cases, the quality of the HM (HE RA) was rated as comparable or better than the double-bit-rate encoding using JM 18.2* (i.e. the JM encoding described in JCTVC-H0360). The following were suggested as conclusions in this contribution.
5.4.1.1.1.1.1.1.4JCTVC-H0168 Proposal of HEVC profile/level definitions [T. Suzuki (Sony), H. Sasai, T. Nishi (Panasonic)] This contribution proposed some aspects of HEVC profile / level definition. It requested to avoid too much flexibility (and AVC was suggested to be somewhat confusing). It proposed 8 levels, and restrictions on bitstreams such as max/min LCU sizes and max number of SPS/PPS/APS. The proposed level definition was as follows:
Proposed "Main" profile constraints were suggested as: LCU size:
Slice constraints:
Max number of reference frames:
Number of PS:
CABAC constraints:
Parallel processing tool:
Potential candidate constraint:
The following was proposed for level-specific constraints: Memory bandwidth restrictions:
For 4K and larger, more constraints were suggested to be necessary. Further study was suggested. JCTVC-H0221 proposes such constraints – e.g.:
In discussion of the proposal, it was agreed that a maximum decoder frame buffering capacity somewhere between 4 and 8 would be our plan. It was remarked that our current RA CTC uses 5 (4 plus the current picture). 5.4.1.1.1.1.1.1.5JCTVC-H0353 AHG8: Comments on HEVC version 1 Profile and Level definition [M. Zhou, V. Sze, H. Tamama (TI)] For HEVC version 1 Profile and Level definition, it was proposed to define two profiles, namely a "Baseline" Profile (BP) and a "High" Profile (HP). It was proposed that BP should support the low-latency applications, while HP supports high-efficiency applications. "Bi-directional B-frames" were proposed not to be allowed in BP, while it was suggested that other "tools" can be the same for BP and HP. It was proposed to impose constraints on parallel processing tools (tiles, wavefront parallel processing, entropy slices and slices) for BP and HP. It was proposed that tiles should be required in bitstreams when the pixel rate exceeds 1080p@60 (125 Mpixels/sec), and should be prohibited when pixel rate is below 1080p@60. Tiles, when used, were proposed to be required to be independent and evenly-divided in terms of pixel rate. Slices, entropy slices and wavefront parallel processing (WPP) were proposed to be prohibited across tile boundaries. Constraints were also proposed to be imposed on entropy slices to limit the CABAC initialization overhead. Although the proposal suggested to define two profiles, one profile would be desirable from TI’s viewpoint. For parallel processing capability, the contribution suggests that tiles should be independent, and that tiles should be used for balancing pixel numbers between the cores, with other approaches (entropy slices, wavefront) for bit rate/entropy decoding load balancing. 5.4.1.1.1.1.1.1.6JCTVC-H0668 Profiles and Level considerations [A. Wells, C. Fogg (Harmonic)] It was proposed that profile and level definitions for HEVC should permit bitstreams that use a single tile and single slice per frame encoding at coded frame sizes up to 4K (3840x2160 for consumer applications, with 4096x2304 for capture). It was asserted that this extends a common practice of coding a single slice per frame in AVC at 1080p levels. Additionally, it was proposed to restrict the frequency of regular (non-lightweight / entropy) slices should be limited to no more than 4 per coded frame. It was also proposed that limits should be imposed on the number of motion vectors per window of coded blocks in a similar manner as they were for AVC. In discussion, it was suggested that the proposed restriction of number of slices could be removed or relaxed if certain parameters would be kept fixed over multiple slices in the picture. 5.4.1.1.1.1.1.1.7JCTVC-H0637 Profiles and Levels for HEVC [A. Luthra (Motorola)] [late] This contribution suggested that, in addition to defining "fixed" profiles and levels, a mechanism should also be developed such that clients and servers can negotiate attributes at a finer level of granularity. It was suggested that this mechanism could be based on two-way negotiation, in which a client would send an XML document describing its capabilities at a particular time. This was suggested to involve the standardization of:
The proposal also suggested to consider going outside of the "onion structure" for profiles and levels (if necessary). It was commented that having some common baseline/core of a guaranteed interoperability mode of operation may be beneficial. It was remarked that such concepts have been common practice and previously standardized for real-time multimedia communication systems (e.g., for H.323 and H.320). Also, it was suggested to use "neutral" sounding naming such as A, B, C, etc., or Venus, Tango, Cairo, etc., for the names of profiles, rather than names that may appear to have implicit meanings. Moreover, it was suggested that only one profile, called Profile A, should be defined at this stage, with a focus on high coding efficiency. The proposal suggested to keep the same "major numbers" for the levels as found in AVC. In discussion, it was commented that giving up an onion structure should only be done for good reasons. Some concern is raised that the flexibility is advantageous for encoders, but may be a burden for decoder implementation (mainly for hardware-based decoders). 5.4.1.1.1.1.1.1.8JCTVC-H0382 Inclusion of adaptive loop filtering in the HEVC standard [T. Yamakage (Toshiba), I. S. Chong (Qualcomm), Y.-W. Huang (MediaTek)] This contribution proposed to include ALF in the HEVC standard, and provided information on how the HM 5 decoder is implemented. In a revision of the contribution, some subjective test results were provided to support the assertion that ALF provides measurable objective and subjective quality improvement. 11 test sequences were chosen for this testing, either from the common test set or other test sets (i.e., sequences from VCEG activity) with QP=32, 37 for random access and low delay B coding structures. It was reported that the ALF cases mostly have lower bitrate and higher PSNR than the non-ALF encodings. It was reported that out of the 11 sequences, 4 sequences showed a clear visual gain for still images and a slight gain for moving pictures. It was reported that in some particular cases, ALF shows visual gain even though its BD bit rate gain is less than it is for some other test cases. 5.4.1.1.1.1.1.1.9JCTVC-H0734 Straw man for Profiles and levels [M. Horowitz (eBrisk Video), A. Ichigaya (NHK), K. McCann (Samsung/ZetaCast), T. Nishi (Panasonic), S. Sekiguchi (Mitsubishi), T. Suzuki (Sony Corporation), T. K. Tan (NTT Docomo), W. Wan (Broadcom), M. Zhou (TI)] [late 02-06] This multi-company contribution was discussed in joint meeting with MPEG Requirements, MPEG Video and VCEG. (See additional notes above.) 9 levels were proposed, three of which have an extension "H" that would allow higher (typically double) bit rate. It was proposed to start with definition of a "Main Profile" only for 4:2:0 and 8 bit applications The proposed Main profile would be the current LC configuration (from common test conditions) plus SAO. Coding efficiency features from the HE configuration that were proposed not to be included in the profile were: LM chroma, AMP, NSQT, ALF. Yüklə 8,24 Mb. Dostları ilə paylaş:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||