International organisation for standardisation organisation internationale de normalisation


HEVC Scalable and Multi-view Extension Profiles



Yüklə 8,63 Mb.
səhifə41/117
tarix25.10.2017
ölçüsü8,63 Mb.
#13029
1   ...   37   38   39   40   41   42   43   44   ...   117

HEVC Scalable and Multi-view Extension Profiles


4.2.0.1.1.1.1.1.84m28274 Unification of HEVC scalable and multi-view extensions with HLS only changes [Kemal Ugur, Miska M. Hannuksela, Jani Lainema, Dmytro Rusanovskyy, Justin Ridge]

This contribution was discussed in MPEG Requirements and only shortly summarized in the joint meeting on Monday.

The HLS-only approach of m28067 was noted.

The compression gain for use of "fancy" coding tools seems limited.

The contributors suggested that MHVC can be naturally combined with SHVC.

It was agreed that we certainly don't want two profiles that are minimally different in capability.

In regard to the concept of desirability of an "HLS-only" approach – it was notedt hat sometimes "HLS-only" doesn't mean there is no substantial added complexity.

It was asked whether MHVC should have one profile or two? (stereo and general multiview). It was agreed that stereo has priority and the PDAM should be stereo.


4.2.0.1.1.1.1.1.85m28067 Requirement for HLS-only profile in scalable extensions of HEVC [Y. Ye (InterDigital), A. Vetro (MERL), P. Yin (Dolby), J. W. Kang (ETRI), E. Piccinelli (STMicroelectronics)]

This contribution was discussed in MPEG Requirements and only shortly summarized in the joint meeting session on Monday. Some related remarks are recorded above in the section discussing m28274.

4.2.0.1.1.1.1.1.86m27818 On disparity vector constraints [O. Nakagami, T. Suzuki (Sony)]

Beyond technical issues that were discussed in JCT-3V, this document made a specific suggestion on defining both a stereo-only profile and a more generic multiview profile in the context of the multiview extensions. During the joint meeting, it was concluded that only the stereo profile, which is most urgently needed by short-time market demands, should be included in the beginning.


    1. HEVC for Interlaced-Scan Content


In the joint meeting session with Requirements SG on Monday, the status of evidence gathering on this topic was assessed and discussed.

It was reported that people have been working in AHG activity, getting clips and analyzing them.

It was noted that both visual and PSNR should be measured to reach the best conclusion. Some key things had not yet been tested, including.


  • Sequence-level AFF

  • Subjective quality

  • Deinterlace-first operation

1.5 second intra refresh was tested. It was reported the JM does not work so well for MBAFF.

Relevant elements in AVC that are not in HEVC were noted as follows:



  • PicAFF

  • MBAFF

  • Chroma motion vertical adjustment

  • Scan pattern adjustment for field mode

  • Other entropy coding adjustment for field mode

  • Deblocking customized for field mode

Among these, only chroma motion vector adjustment had been tested for HEVC.

Multigeneration loss can be a concern.

The reported average results were on either frame-only or field-only coding for HEVC. Sequence-adaptive frame/field coding is to be investigated with GOP-specific switching, such that the best of each results could be combined. A desire was also expressed to test versus "deinterlace first" processing.

Issuing a "call for evidence" was suggested. However, we generally try to get some amount of evidence before taking such a step, and so far no evidence has been shown in individual contributions that a signficant benefit exists.

It was agreed to wait one more meeting cycle to see if the situation gets clarified.
4.2.0.1.1.1.1.1.87m28133 Interlaced compression performance comparison of HEVC with AVC for Low delay cfg [Nicolas Dhollande, Xavier Ducloux]
4.2.0.1.1.1.1.1.88m28178 Description of experiments for AhG for the study of interlace coding in HEVC [J.M. Thiesse, Y.Syed, A.T. Hinds]
4.2.0.1.1.1.1.1.89m27523 HEVC Software modifications for field based coding [Zineb AGYO, Jean-Marc Thiesse, Jérôme Viéron]
4.2.0.1.1.1.1.1.90m28312 Crosscheck of JCTVC-L0187 on HEVC software modifications for field based coding [Gordon Clare, Félix Henry] [late]
4.2.0.1.1.1.1.1.91m27755 Performance evaluation of HEVC on YUV4:2:2 interlace video sources [A. Minezawa, K. Sugimoto, S. Sekiguchi (Mitsubishi)] [late]
4.2.0.1.1.1.1.1.92m28119 Information on forthcoming 4Ever project subjective HEVC evaluation [Jean-Charles Gicquel, Jerome Fournier, Jean-Marc Thiesse on Behalf of the 4Ever Project]

    1. HEVC for Still Pictures


4.2.0.1.1.1.1.1.93m27367 Performance evaluation of HEVC on still picture coding [K. Ugur, J. Lainema]
4.2.0.1.1.1.1.1.94m27758 Subjective evaluation of HEVC intra coding for still image compression [Philippe Hanhart, Martin Rerabek, Pavel Korsunov, Touradj Ebrahimi (EPFL)]

  1. MFC


The contributions in this area were presented and discussed in a joint meeting of MPEG Video and JCT-3V (Tuesday 9:00). It was agreed that the MFC specification work should progress in the JCT-3V henceforth.

4.2.0.1.1.1.1.1.95m27760 Unification of Upsampling Filters in MFC [P. Yin, H. Ganapathy, T. Lu, T. Chen, W. Husak (Dolby)]

In the MFC CfP submission, two upsampling filters (one 6-tap and one 4-tap) were initially supported in the RPU process, and the 6-tap upsampling filter was used in the full-resolution reconstruction process. Later in a simplification contribution, the upsampling filter used in the RPU process was fixed to the 4-tap and the upsampling filter in the reconstruction process remained unchanged. This might cause confusion and extra effort in filter implementation. In this contribution, it is proposed to unify the upsampling filters in both RPU process and full resolution reconstruction. Simulation results suggest that the use of the 6-tap upsampling filter has better performance, which is very close to the results in the MFC CfP submission. It was proposed to adopt the 6-tap upsampling filter in the MFC specification.

In the WD, the simplified set of filters (from M27249) had been integrated: 5-tap downsampling, 4-tap upsampling, 6-tap reconstruction. In JCT3V-C0037, it is suggested to use the 6-tap reconstruction filter also for the upsampling step. It is reported that the 4-tap filter (when used for upsampling and reconstruction) produces additional loss (BD bit rate 2.2% on average) and may produce some artefacts –particularly for interlaced sequences.

In terms of BD bit rate, there was no reported difference between the old (4-/6-tap) and the new (6-tap unified) design.

In a DSP design, the unification would rather be a disadvantage (due to longer upsampling filters), whereas in a dedicated hardware design it might be an advantage (usage of same circuits, gate number reduction).

Decision: Adopted.
4.2.0.1.1.1.1.1.96m27769 Cross-check of JCT3V-C0037: Unification of Upsampling Filters in MFC [Y. He, Y. Ye (InterDigital)]

Results confirmed.

4.2.0.1.1.1.1.1.97m27761 Editorial Improvements on WD for MVC extensions for inclusion of MFC (multi-resolution frame compatible) [P. Yin, H. Ganapathy, T. Lu, T. Chen, W. Husak (Dolby)]

This document provides editorial improvements of the working draft of the new amendment to ITU-T Rec. H.264 | ISO/IEC 14496-10 adding MFC (multi-resolution frame compatible) technologies.

Purely editorial changes (naming etc.) relative to previous WD.

A short overview about MFC (based on a deck of slides from the Shanghai MPEG meeting) was also provided. This deck of slides shall be uploaded in a new version.

Plan for approvals on ISO side: PDAM 13/01, DAM 13/04, FDAM 13/10

Editors: P. Yin, Y.-K. Wang, G. J. Sullivan.

It is necessary to keep this amendment aligned with the other ongoing amendments (Amd.2, Amd.3). Before submitting for PDAM ballot, consult with M. Hannuksela, A. Vetro and Y. Chen for consistency.


  1. Yüklə 8,63 Mb.

    Dostları ilə paylaş:
1   ...   37   38   39   40   41   42   43   44   ...   117




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin