5.6.4.1.1.1.1.1.1JCTVC-H0394 Coding in 4:4:4: Preferred Conversions in Colour and Sampling [P. Topiwala (FastVDO)]
It was asserted that, for the most part, cameras capture, and displays render, RGB 4:4:4, whereas the HEVC draft design works in YUV 4:2:0. Two key components are needed to make the connection between what is captured/rendered, and the codec – colour transforms and resampling filters. The contribution proposed integer colour transforms and resampling filters. The resampling filters are targeted for dynamic resolution conversion, and correspond to the prior proposal G264.
It was asked whether the proposed filters had been tested for screen content.
5.6.4.1.1.1.1.1.2JCTVC-H0065 Mixed Chroma Sampling-rate coding: combining the merits of 4:4:4 and 4:2:0 and increasing the value of past 4:2:0 investment [Tao Lin, Shuhui Wang (Tongji Univ.)]
For compound image compression, this contribution proposes a "mixed chroma sampling-rate" (MCS) coding technique that combines and mixes one chroma sampling rate (such as full-chroma YUV 4:4:4) coding with another chroma sampling rate (such as chroma-subsampled YUV 4:2:0) coding at the coding unit (CU) boundary, the coding chain component (such as prediction, transform, quantization, entropy coding etc.) boundary, or other properly selected boundary. Typically, the full-chroma coder is discontinuous-tone content oriented to code mostly computer-generated discontinuous-tone content such as text, chart, graphics, and icon in a compound image like screen content, while the chroma-subsampled coder is continuous-tone content oriented to code mostly camera-captured continuous-tone content such as photograph, movie/TV clips, and natural picture video sequences in a compound image.
5.6.4.1.1.1.1.1.3JCTVC-H0073 4:4:4 screen content coding using Macroblock-Adaptive Mixed Chroma-Sampling-Rate [Shuhui Wang, Tao Lin (Tongji Univ.)]
This contribution presents a "macroblock- (or CU)-adaptive mixed chroma-sampling-rate" (MAMC) technique for 4:4:4 screen content coding. MAMC coding consists of two coders – one is a traditional "continuous-tone content oriented" (CCO) chroma-subsampled (4:2:0 or 4:2:2) coder such as the existing HEVC/ AVC coder with 4:2:0 or 4:2:2 chroma format. The other is a "discontinuous-tone content oriented" (DCO) 4:4:4 full-chroma coder such as a dictionary-entropy coder. One of the two coders is selected to code each macroblock (or CU), based on the rate-distortion performance.
Another aspect of the contribution is to propose a modification to the existing 4:2:0 or 4:2:2 chroma format HEVC/AVC coder to be used in MAMC coding. Since the full-chroma pixels are available in MAMC coding, the prediction can be done in full-chroma format without any change to the existing syntax and semantics including prediction modes of the 4:2:0 or 4:2:2 chroma format HEVC/AVC standard specifications except adding a "MAMC flag" bit in the SPS.
The main point of MAMC is to enable 4:4:4 chroma format content coding in HEVC and AVC, 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 4:2:0/4:2:2 chroma format HEVC/AVC coder design.
Coding experimental results reportedly indicate that MAMC coding consisting of a gzip-based dictionary-entropy coder and an AVC High profile coder can get much higher PSNR than ordinary AVC High profile coding. Using full-chroma prediction AVC coder instead of traditional AVC High profile coder in MAMC coding can reportedly get further PSNR improvement in two pictures which have a lot of discontinuous-tone content.
The contribution provided examples and experiment results relating to the coding scheme proposed in H0065.
The emphasis was on screen content coding, for which alternative coding mechanisms were reported to provide very substantial coding improvements relative to conventional waveform-oriented coding.
The group is certainly interested in having good capability of representing 4:4:4 video.
It was suggested that this is somewhat similar, in the chroma domain, to RRU or perhaps ARC on the coding unit level.
The proposal had not been tested in the HEVC context.
Further study would be needed to study the complexity and coding performance of the proposed techniques and to develop the full details of an HEVC specification for this capability.
5.6.4.1.1.1.1.1.4JCTVC-H0457 Removal of Monochrome Chroma Format Support [T. Hellman, W. Wan (Broadcom)]
This submission proposes a claimed simplification to the standard by the removal of monochrome chroma format. It contends that the gain from adding specific monochrome support versus coding monochrome material in 4:2:0 is likely quite small, and in any case only applies only to a small fraction of video source material. The proposal recommends removing support for the monochrome format, or performing further study to measure the actual gain for a future decision.
It was remarked that alpha has been supported using auxiliary coded pictures in AVC, and the separate colour plane scheme in AVC is also built on the monochrome concept.
Monochrome could be left out of a profile if that is desirable. If it is left out of a profile, there should be some (e.g. VUI) indicator that the decoded video is actually monochrome. Consideration of true monochrome may be best left to some later phase of work when the same parts of the design are being modified to also support 4:4:4.
Decision: We will have some profile that does not support monochrome, and an indicator flag in VUI. If feasible, we would like the flag to indicate that the chroma will be exactly 128 (i.e., 1 << (bitDepth − 1)) if decoded.
5.6.4.1.1.1.1.1.5JCTVC-H0650 AHG20: 4:2:2 support in HEVC [K. Sugimoto, A. Minezawa, S. Sekiguchi (Mitsubishi)] [late]
This contribution proposes support of 4:2:2 format in the HEVC standard, which it was asserted could expand opportunities of its market adoption especially in digital broadcasting area. The main point of this proposal is to introduce modifications as small as possible in order to accommodate 4:2:2 format. Modifications of the current specification to support 4:2:2 format were described (at the concept level, without draft text). The proposal requested no change of syntax other than the sending of additional transform coefficients.
It was commented that 4:4:4 is conceptually simpler to support – basically applying luma-like processing for all components.
For the residual coding there are basically two possible approaches, which would be to use more blocks or to use vertically larger blocks. This proposal is to use larger blocks. Both approaches seem desirable to investigate.
To be studied in an AHG.
Dostları ilə paylaş: |