3Project development, status, and guidance (24)
3.1Communication to and by parent bodies (0)
See section 8.1.
3.2Conformance test set development (1)
JCTVC-Q0219 Editor's proposed draft text of HEVC conformance testing [T. Suzuki, W. Wan, G. Sullivan] [late]
This document is a proposed draft 7 of conformance test of HEVC.
JCTVC-Q0249 Proposal of the RExt conformance test development plan [T. Suzuki, O. Nakagami (Sony)]
HEVC RExt is due for finalization. It is necessary to ensure the interoperability of the standard and conformance testing is one tool for accomplishing that. It is an urgent issue to confirm the spec by bitstream exchange, etc for product development. Therefore this contribution proposes to start RExt conformance activity at the Valencia meeting. This contribution provides an initial idea on conformance testing as a starting point of the discussion.
3.3Version 1 bug reports and cleanup (1)
The previously planned handling of MinCR for version 1 defect purposes, in particular, was supported by Japan NB input and was confirmed Wed p.m. (GJS).
JCTVC-Q0111 Errata report: Parsing issue for picture timing SEI message [Y. Wu, L. Zhu, G. J. Sullivan, F. Kyslov, S. Sadhwani (Microsoft)]
Discussed Wed. (MMH). Further discussed Thu. (YKW)
This contribution asserts that there can be a parsing problem for the picture timing (PT) SEI message under certain circumstances, and suggests corrective actions to provide additional information in the standard and to prohibit a particular pathological combination. One discussed case is when CpbDpbDelaysPresentFlag is equal to 1 (and thus PT SEI messages are present) but NalHrdBpPresentFlag and VclHrdBpPresentFlag are both equal to 0 (and thus buffering period SEI message are not present). It is proposed to disallow this combination, as it is suggested that this combination does not seem particularly sensible or to represent any real application scenario and was not fully considered in the development of the standard. The second discussed case is when frame_field_info_present_flag is equal to 1 and CpbDpbDelaysPresentFlag is equal to 0, and it is proposed to add information to the standard to assist decoders in parsing PT SEI messages and to discourage encoders from generating bitstreams that could cause parsing problems.
Decision: Disallow CpbDpbDelaysPresentFlag being equal to 1 when NalHrdBpPresentFlag and VclHrdBpPresentFlag are both equal to 0.
It was remarked that this modification may not require sequential ordering of APS SEI preceding BP SEI preceding PT SEI. Further study of the potential remaining parsing issues for BP and PT SEI was encouraged. It was also remarked that these SEI messages and possibly some others also may require delayed parsing.]
Editorial action item: Editors are also requested to review and add clarification as necessary regarding concept of POC being increasing in output order within each CVS.
3.4HEVC coding performance, implementation demonstrations and design analysis (5) 3.4.1Version 1 verification test (1)
JCTVC-Q0204 HEVC verification test results [T. K. Tan (NTT Docomo), M. Mrak (BBC), V. Baroncini (FUB), N. Ramzan (UWS)]
This document reports on the results for the HEVC video verification test.
The purpose of the HEVC verification test is to confirm that the objective of achieving a substantially greater bit-rate reduction over the AVC High Profile has been met by the HEVC standard.
A subjective evaluation was conducted comparing the HEVC Main profile to the AVC High profile. Twenty video sequences with resolutions ranging from 480p to UHD were tested (at 4 different bit-rates / quality levels).
Analysis of the subjective test results reportedly show that in 86% of the test points, HEVC and AVC have the same quality, even though the bit-rates of AVC are greater than or equal to approximately double the HEVC bit-rates.
The bit-rate savings are similar for the different resolutions tested, with slightly more savings for sequences with higher resolutions. The average bit-rate savings for test sequences with UHD, 1080p, 720p and 480p resolutions are estimated at approximately 64%, 62%, 56% and 52%, respectively.
The results confirmed that the HEVC Main profile achieves the same subjective quality as AVC High profile while requiring on average approximately 59% less bit-rate. A summary of measured bit rate savings is illustrated below.
It was agreed to issue a final report of the verification test effort as an output document, based on this document.
3.4.2Still picture coding (1)
JCTVC-Q0229 HEVC still picture coding performance evaluation [D. Nicholson, C. Larabi, A. Descampe] [late]
Discussed Thu a.m. (GJS).
This document presents a coding performance evaluation of HEVC for coding still pictures. JPEG reference test image set, available in 4:2:0, in 4:4:4 as well as in RGB 4:4:4 were used for the evaluation. All Intra configuration was used and for 4:4:4 and RGB 4:4:4 content, HEVC Rext was used (HM13.0 + RExt 6.0), and results compared to JPEG 2000 (using OpenJPEG v2.1 release candidate).
The objective of this document was reported to be to present coding performance of HEVC for coding still pictures, done in cooperation with some JPEG experts with the objective of verifying the performance of HEVC for coding still pictures.
In the tables below, values indicate the bit rate of JPEG 2000 relative to HEVC, such that positive numbers indicate a benefit for HEVC and negative numbers indicate a benefit for JPEG 2000.
Results generally
RGB 4:4:4
YCC 4:4:4
YCC 4:2:0
The results reportedly validated the performance of HEVC for coding still pictures, both for 4:2:0 and 4:4:4 8bit images. The following actions were recommended by the contributors:
-
To propose a 4:4:4 Still image profile based upon one of the 4:4:4 RExt profiles. (See notes elsewhere.)
-
To set-up subjective tests to complete these verification tests (see below)
-
To continue tests with more than 8bit material
-
To continue tests with video material (including more than 8bits, using HEVC verification test material as well as RExt video sequences) instead of still pictures.
-
To create HEVC still picture compliance (V1 and RExt) test set, potentially by using the JPEG Still picture test set, as for HEVC Still Picture profile, as included in HEVC V1, compliance material is not available.
The contributors indicated that subjective testing was planned and would be reported in the future.
The contributors volunteered to contribute to the development of the HEVC conformance test set with contribution of still pictures.
3.4.3SHVC performance and design aspects (2)
JCTVC-Q0046 Complexity analysis of an optimized SHVC decoder [W. Hamidouche, M. Raulet, O. Deforges (INSA)]
Discussed Tues p.m. (A. Duenas).
This contribution provides a complexity assessment of an optimized SHVC decoder. The SHVC decoder is based on a real time and parallel HEVC decoder developed under the open source "OpenHEVC" project. This contribution reported that the main time-consuming operations introduced in the SHVC standard include the up-sampling of the lower layer picture and the up-scaling of its motion vectors (MVs), which are optimized in single instruction multiple data (SIMD) operations.
The optimized SHVC decoder reportedly archives a real time decoding of 1080p50 enhancement layer on single core of an Intel i7 processor running at 2.6 GHz. The SHVC decoder decoding two layers reportedly introduces an average 50%–80% extra complexity relative to a single layer HEVC decoder.
The up-sampling and up-scaling operations, in the case of spatial scalability and inter coding configuration, reportedly represent around 16% of the total decoding time. The low level optimizations, together with a hybrid parallelism approach, reportedly enable the decoding of a 1600p enhancement layer at 88 frames per second on a 4-core i7 processor.
It was reported that the parallelism was achieved by a combination of picture-level parallelism and wavefront parallel processing. Results were also presented by using only frame level or wavefront parallel processing or both at the same time, as shown in the following table, wherein n is the number of threads allocated for the wavefront parallelism and m is the number of frames decoded in parallel for frame based parallelism.
Configurations
|
Decoding configurations (n, m)
|
(1, 1)
|
(4, 1)
|
(1, 4)
|
(2, 2)
|
Class B
|
Speedup
|
x2
|
1
|
2.99
|
2.02
|
3.24
|
x1.5
|
1
|
3.13
|
2.21
|
3.36
|
SNR
|
1
|
2.90
|
2.50
|
3.34
|
HEVC
|
1
|
3.10
|
2.64
|
3.05
|
Decoding frame rate (fps)
|
x2
|
52
|
156
|
107
|
169
|
x1.5
|
44
|
138
|
99
|
149
|
SNR
|
41
|
124
|
108
|
138
|
HEVC
|
72
|
226
|
195
|
224
|
Decoding time per frame (ms)
|
x2
|
20.54
|
6.88
|
24.04
|
16.08
|
x1.5
|
24.11
|
7.76
|
27.82
|
19.27
|
SNR
|
29.47
|
10.28
|
33.36
|
24.81
|
HEVC
|
16.07
|
5.20
|
24.05
|
10.66
|
Class A
|
Speedup
|
x2
|
1
|
3.6
|
2.07
|
3.81
|
SNR
|
1
|
3.49
|
2.47
|
3.67
|
HEVC
|
1
|
3.49
|
2.83
|
3.22
|
Decoding frame rate (fps)
|
x2
|
23
|
84
|
47
|
88
|
SNR
|
17
|
62
|
43
|
65
|
HEVC
|
33
|
120
|
96
|
110
|
Decoding time per frame (ms)
|
x2
|
47.85
|
13.65
|
55.00
|
32.65
|
SNR
|
63.92
|
18.76
|
73.67
|
50.95
|
HEVC
|
34.56
|
10.25
|
48.65
|
21.90
|
It was reported that it was difficult to achieve more than 3x speed up when using 4 cores.
It was reported that the usage of WPP allowed a simpler combination of picture level parallelism with other types of parallelism and that this was the reason this decoder implementation was selected. Of course, if the encoder does not use WPP encoding, the reported benefits of WPP would not be available.
It was reported that the decoder is capable of correctly decoding all of the HEVC version one conformance bitstreams.
A demonstration of this decoder decoding several scalable bitstreams was presented, with a demonstration of switching between displaying the base-layer decoded information or the combination of the multiple layers.
JCTVC-Q0050 4K real time streaming with SHVC decoder and GPAC player [W. Hamidouche, M. Raulet, J. Le Feuvre (INSA)]
Discussed Tues p.m. (A. Duenas).
This contribution reported a 4K end-to-end video streaming demonstration using an optimized SHVC decoder under the "OpenHEVC/FFmpeg" library and the "GPAC" player. The SHVC decoder was integrated in the OpenHEVC/FFmpeg library, enabling this open source library to support the decoding of a conforming SHVC bitstream. The GPAC player reportedly implements tools to encapsulate conforming SHVC bitstreams into the mp4 file format.
At the server side, the GPAC player reportedly broadcasts the mp4 content in MPEG2-TS. At the receiver side, the GPAC player feeds the openHEVC/FFmpeg SHVC decoder with the received video packets. The FFmpeg library with the SHVC decoder decodes the requested SHVC video layers and outputs YUV pictures corresponding to the highest decoded layer for rendering by the GPAC layer. This demonstration also included, at the receiver side, an interactive interface to switch between the decoded SHVC layers: HD and 4K for x2 spatial scalability.
A demonstration of this streaming system switch in real time between the base layer for HD resolution and the enhancement layer for 4K resolution was performed, and additional information about how to replicate this system was presented in the contribution.
3.4.4Interlace (1)
JCTVC-Q0118 Interlace coding in HEVC v.1 [A. Tourapis, D. Singer (Apple)]
This contribution was provided as information for further study. It was not requested for detailed presentation.
Dostları ilə paylaş: |