Joint Collaborative Team on Video Coding (jct-vc) of itu-t sg16 wp3 and iso/iec jtc1/SC29/WG11
Yüklə 1,12 Mb.
|
- Bu səhifədəki naviqasiya:
- 5.6.1Scalable coding hooks
- 5.6.1.2VUI and SEI related
- 5.6.1.3Motion vector coding related
- 5.6.1.4Slice header
- 5.6.1.5Other
5.5Source video test materialJCTVC-I0513 New 4K test sequence for HEVC standard extension [K. Sugimoto, A. Minezawa (Mitsubishi)] [late] Information on this was provided verbally – there seemed to be no need for detailed presentation. 5.6Functionalities5.6.1Scalable coding hooks5.6.1.1NAL Unit Header and high layer parameter set relatedA summary of contributions in this area was provided as an attachment in a revision of the AHG12 report:
In the discussion, it was noted that start code emulation possibilities need to be considered. The potential parsing dependency between the proposed VPS and SPS was mentioned as a possible issue. It was remarked that, with regard to VPS, we should consider the need for random access at locations other than CRA and IDR. It was remarked that it is generally better to try to avoid using profile_idc values in a way that makes the parsing or decoding process directly dependent on them. It was agreed that, at this time, we will not make changes to the NUH syntax. Immediate questions:
Note that the base specification needs temporal scalability, and this should be designed in anticipation of how it would fit into an extended scheme. It was remarked that an SEI message (or something like it) can be used to carry descriptive metadata. Currently the SPS has a loop on temporal layers for max_dec_pic_buffering, num_reorder_pics, max_latency_increase. Currently we don't have a way to indicate a different profile, level or different HRD parameters, for different temporal layers. A VPS would contain some of that. In principle, the VPS could be metadata-only, from the perspective of the base specification. Regarding wWhere to put a VPS ID – these possibilities were discussed:
Note that JCTVC-I0338 is relevant, and includes an additional "GPS" concept. The potential need for being able to provide an enhancement layer for an already-encoded base layer was requested to be considered. SVC did not support this. "SPS inheritance" is an alternative scheme that could "build up" the information from the bottom up. However, it was suggested that it is probably possible to solve this issue within the VPS concept and that this scenario should not be considered an obstacle to the VPS concept consideration. A suggestion was to put a version number in the VPS. Suggested minimum content for the VPS:
One issue is to consider is whether the VPS is to be an indication of what is actually in the bitstream or is a description of the maximum of what could be in the bitstream. The ability to adapt the bitstream without needing to send an IDR was suggested to be needed. The use of the VPS as a description of maximum possible bitstream content was suggested to be friendly to this scenario. In SVC and MVC we have SEI messages defined to indicate when some information is not present in the bitstream. Something like this can be a way to enable a description of the actual content of the bitstream. A suggestion was to put ue(v) into the SPS after sps_id called something like likely_to_become_vps_id. Another sSuggestion: put 16 bit FLC reserved there. Another sSuggestion: put extra_data_length as ue(v) followed by that number of bits of data. This was further discussed in plenary on Sunday 6 May.
An SEI message is proposed for the base HEVC specification, to optionally indicate sub-bitstream profiles and levels. The proposed SEI message applies to both temporal-sub layers and to scalability or multiview layers. For the future scalable and multiview extensions, a re-definition of the maximum pixel throughput limit level constraint is proposed, such that the constraint applies only to the individual layer, and not the full sub-bitstream corresponding to that target layer_id, enabling the same SPS to be referred to by multiple layers. Further consideration necessary: It was asked whether to put pProfile & level idc indicators in the VPS.? This is a questionProblem to be further investigated: Does layer switching in a higher layer require that an IDR must be present in the base layer? In terms of decodability, this would not be necessary. Perhaps the requirement that an IDR has to be sent when a new VPS is sent should be modified for the case of scalable coding. For further study. JCTVC-I0263 Extension of HEVC VUI Syntax Structure [M. Haque, A. Tabatabai (Sony)] This document presents an extension of the "base" HEVC VUI parameters syntax structure to consider the future HEVC Extensions of Scalability and Multi-view coding. It also has a provision to include VUI parameters combinations for other HEVC extensions like 3DV. Essentially, only one extra 1-bit flag is added to the existing HEVC VUI parameter syntax structure for HEVC VUI parameters extension. Something along these lines may be needed (with temporal aspects in the "base spec"). For further study in AHG.
In the multiview / 3D Video (3DV) extension of HEVC under development, it is possible that there would be a profile wherein only high-level syntax changes are introduced compared to the HEVC base spec, similarly as the existing AVC-based MVC extension compared to AVC Annex A profiles. In HEVC, both temporal motion vector prediction (TMVP) and implicit weighted prediction are designed in a way that POC distances need to be checked. However, in multiview or 3DV, a picture from a different view, i.e., view component in the context of AVC based MVC, may be present in a reference picture list of the current picture (view component). In this case, a picture and one of its reference pictures can have the same POC value. Zero POC distance is a problem for both POC based motion vector scaling (e.g. in TMVP) and POC based implicit prediction weights calculation (in weighted prediction). It is proposed that hooks with slight modifications in HEVC base spec can be provided, in order to avoid the above problem while keeping the benefits of TMVP and weighted prediction in the multiview or 3DV extension of HEVC to be developed soon. It was noted that implicit weighted prediction was agreed to be removed at the current meeting. It was suggested that it could be specified that, for purposes of the base spec, we may not need to do anything, and for the extension spec, we could specify that inter-view reference pictures are processed in the same manner as long-term reference pictures for purposes of TMVP. This seemed adequate to address the issue.
In this contribution, it was proposed to modify the derivation process on motion vector predictor (MVP) and weighted prediction as hooks for future HEVC multi-view extension. With high-level modification on top of the existing text of the HEVC CD specification, denominator or numerator on scaling calculation of MVP could become zero for inter-view prediction. In order to solve this issue, additional conditions were proposed to take care of the case that either denominator or numerator becomes zero. Experimental results reportedly showed no loss for all test conditions relative to HM6.0 with implicit weighted prediction since the denominator and the numerator will never become zero for single-view video coding. This proposal was similar in spirit to I0353. See notes in that section.
An extension field in the slice header is proposed to enable extension of the slice header in future profiles (or extensions) of HEVC. The proposed extension field is preceded by a length parameter in order to provide a legacy decoder with the information needed to find the start of the slice data. The presence of the extension field in the slice header is conditioned on a flag in the SPS in order to not add any bit overhead in the slice headers for the current profile(s) of HEVC. This seemed useful to allow interpretation of the base layer of scalable bitstreams by legacy decoders, making them skip the unknown extension. It was agreed that such a thing could be useful, e.g. to avoid the prefix NAL unit phenomenon. This should be put before the byte alignment bits at the end of the slice header. It was suggested to consider a scheme as in H.263 and MPEG-2 / H.262, where there is a flag, then a byte, then a flag, etc. It was then suggested to just change the proposal to express the length in units of bytes rather than in units of bits. It was suggested to put the flag in the PPS rather than the SPS.
It was remarked that another extension scheme that could be used would be to enable extension of the end of the slice layer RBSP as we do for the SPS and PPS and APS (with a flag to enable/disable at PPS level like the other one). Decision: Adopted. 5.6.1.5OtherJCTVC-I0190 Low Complexity Scalable Extension of HEVC intra pictures based on content statistics [S. Lasserre, F. Le Leannec, E. Nassor (Canon)] Not relevant to version 1. (Was reviewed in MPEG Video.) 5.6.2Colour component sampling and higher bit-depthsJCTVC-I0108 High Bit Depth considerations in HEVC [P. Andrivon, P. Bordes (Technicolor)] This contribution relates a shallow analysis of WD 6 (HEVC Working Draft 6) and HM6.0 (HEVC Test Model v6.0) with respect to high bit depth as well as different bit depth coding experiment results. These latter deal with comparisons of coding efficiency between JM18.3 (H.264/AVC Joint Model v18.3) and HM6.0 for different bit depth coding; namely 8, 10, 12, 14 bits. Proposed test material is six class B (1080p) videos retrieved from SVT sequences and adapted to 8, 10, 12, 14 bits format. This document states that, for the proposed test material, HM6.0 outperforms JM18.3 HP (High Profile) in objective measure (BD-rateBD-BR) of around 18% luma, 29%, Cb, 22% Cr for AI-HE (All Intra High Efficiency) 8, 10, 12 bits configuration and around 33% luma, 50% Cb, 35% Cr for RA-HE (Random Access High Efficiency), 8, 10, 12 bits configuration. AI-HE 14 bits experiments reportedly show performances regression from 18% to 13% luma in favour of HM6.0. It is reported that RA-HE 14 bits experiments could not exploit results due to JM18.3 issues. The contributor remarked that the Beta calculation in the deblocking filter should be checked for proper bit depth scaling. The contributor noted a (very) small difference between the PSNR calculations in HM and JM. This difference not seem significant. The contribution proposes to continue high bit depth HEVC support preparatory work through an Ad Hoc Group (prior AGH14). This was agreed. It was remarked that the test sequences that were used wereas rather noisy. The contributor suggested study of artefacts in the sky area in the Crowd Run sequence.
This contribution proposes support of color format extension for the HEVC standard. The main point of this proposal is towas asserted to limit the modifications from the current specification to be as small as possible to support 4:2:2 and 4:4:4 format. A modified version of the HM6.0 software to support 4:2:2 and 4:4:4 format was provided; however, the implementation hads not been completed. This approach uses rectangular transform blocks. At the previous meeting, it was encouraged to investigate both the approach with rectangular TUs and with square TUs in a rectangular areas.
This contribution presents a dual-coder mixed chroma-sampling-rate (DMC) technique for full-chroma (YUV 4:4:4) screen content coding. The proposed DMC coding adds a full-chroma dictionary-entropy coder to the existing chroma-subsampled (YUV 4:2:0) HEVC coder. The existing YUV 4:2:0 HEVC syntax and semantics can be used as-is. Three new syntax elements (distance, length, literal) are added to enable YUV 4:4:4 dictionary-entropy coding. The main point of DMC coding is was asserted to be to enable full-chroma YUV 4:4:4 content coding in HEVC, which it was asserted could expand their market adoption especially in cloud-mobile computing and wireless display areas, with minimum addition, modification, and complexity increment to the current YUV 4:2:0 HEVC coder design. Coding experimental results are were asserted to show that DMC coding can achieve much higher PSNR than the current 4:2:0 HEVC. It was also asserted that tThere are also obvious subjective visual quality differences between DMC coding and the current HEVC. This seems interesting for future consideration in the context of "FRExt" profile (v2 or beyond). Further study was encouraged. JCTVC-I0336 Subjective Quality Comparison between Mixed Chroma Sampling-Rate Coding and Chroma-subsampled 4:2:0 Coding Using YUV444 Screen Content Test Sequences [T. Lin, S. Wang, K. Zhou (Tongji Univ.)] This contribution presents results of subjective quality comparison between the dual-coder mixed chroma-sampling-rate (DMC) coding described in JCTVC-I0272 and the existing HEVC chroma-subsampled YUV 4:2:0 hybrid coding using the five YUV 4:4:4 screen content test sequences submitted in JCTVC-H0294. It was reported that DMC coding has obvious improvement of subjective quality over YUV 4:2:0 hybrid coding at the same bit rate. See notes above for I0272.
Not relevant to version 1. (Was reviewed in MPEG Video.) Yüklə 1,12 Mb. Dostları ilə paylaş:
|