Of itu-t sg16 wp3 and iso/iec jtc1/SC29/WG11

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]
JCTVC-Q0249 Proposal of the RExt conformance test development plan [T. Suzuki, O. Nakagami (Sony)]

3.3Version 1 bug reports and cleanup (1)

JCTVC-Q0111 Errata report: Parsing issue for picture timing SEI message [Y. Wu, L. Zhu, G. J. Sullivan, F. Kyslov, S. Sadhwani (Microsoft)]

3.4HEVC coding performance, implementation demonstrations and design analysis (56)

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)]

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 bit rat of JPEG 2000 relative to HEVC, such that positive numbers indicate a benefit for HEVC and negative number 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 performances 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 contributor indicated that subjective testing was planned and would be reported in the future.

The contributor 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 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 (12)

JCTVC-Q0117 Extension of the pic_struct element in HEVC [A. Tourapis, D. Singer (Apple), A. Duenas (NGCodec), G. Martin-Cocher (BlackBerry)] [late]

Discussed Thu 3 April (GJS).

This contribution updates to a previous contribution in JCTVC-P0261 of extending the pic_struct element that is present in the picture timing SEI message of HEVC to handle some interlace content applications. In particular, this extension enables a proposed method of carriage of interlaced video material using a “progressive”-like carriage mechanism.

A previous document P0082 discusses the same topic.

The contributor indicated that the document was essentially provided as information about how this could be done, without necessarily saying that the contributor themselves planned to do this or was aware that any significant community would be likely to want to be able to indicate such usage.

It was remarked that also the same indication could be provided by other means (e.g. a user data SEI message or system-level signal), and noted that only a few reserved values of pic_struct exist. Only one value would remain reserved for future use if this would be adopted.

Another participant indicated that some previous system had used a similar indication.

Another participant indicated that this could be used for "PSF" applications to avoid a one-field delay when sending PSF video.

It was suggested that a new SEI message may be a more appropriate way to indicate this than extending the capability of an existing SEI message.

The functionality was agreed to be desirable.

A single bit would appear to suffice for the indicator.

The value of field_seq_flag would be required to be zero.

Decision: Adopt as new 1-bit SEI message with field_seq_flag required to be zero (in SHVC, editor delegated to produce the exact text for the syntax consisting of a one-bit flag with the meaning proposed).
JCTVC-Q0118 Interlace coding in HEVC v.1 [A. Tourapis, D. Singer (Apple)]

Information for further study. Not requested for detailed presentation.

3.4.5Implementation demonstrations (0)