5.13.3.1.1.1.1.1.1JCTVC-H0288 Syntax on picture size signalling [Y. Park, C. Kim, J. H. Kim, J. H. Park (Samsung)]
This contribution proposes a design for picture size signalling in the SPS. The proposal was to send, as ue(v), an indication of the number of bits used to code the width and height. This was motivated by a desire to save bits on the picture size expression syntax. No action was taken on this.
See also the AHG15 report discussion notes.
5.13.3.1.1.1.1.1.2JCTVC-H0485 Picture size signalling and cropping operation [K. Suehring, B. Bross (Fraunhofer HHI)]
This contribution proposed a modified picture size coding scheme based on coding units and a cropping operation. Bit rate savings were reported for typical picture sizes. The contribution also analysed memory requirements for cropping operations inside and outside the coding loop.
The contribution proposed to perform the cropping outside the coding loop (which is agreed as documented above). No further action was taken.
5.13.3.1.1.1.1.1.3JCTVC-H0654 High level syntax [J. Lou, Y. Yu, L. Wang (Motorola Mobility)] [late]
This document proposed some modifications of the sequence parameter set, picture parameter set and slice header syntax. It proposed to remove some syntax elements when max_num_ref_frames is equal to 0.
It was noted that the proposed PPS modifications would introduce a parsing dependency on the SPS content. Also, there was a parsing problem with the first modification proposed for the slice header level. The last modification proposed in the slice level would be a no-op. The remaining modification would save 1 bit in the case of max_num_ref_frames = 0.
It was acknowledged that we have a bit of recognizable redundancy in some of these syntax areas. However, it seemed that the issue addressed by this proposal was a relatively low importance matter – such low-level cleanups can be deferred.
5.13.3.1.1.1.1.1.4JCTVC-H0380 AHG15: SPS and PPS syntax modifications [V. Drugeon, T. Wedi, M. Narroschke, V. Wahadaniah (Panasonic)]
This contribution proposed several modifications of the SPS and PPS syntax. In particular, modifications were proposed by noting some constraints in place for:
-
block size signalling (MinTr <= MinCU <= MaxCU, MinTr <= MaxTr <= MaxCU)
-
PCM related syntax (MinCU <= MinPCMCU <= MaxPCMCU <= MaxCU)
-
slice granularity (currently 2 bits in PPS, proposed to move this SPS and change its coding)
It was commented that it seems desirable to keep the ability to change slice granularity flexibility at the PPS level (e.g. to use a coarser granularity for higher temporal layers).
However, it seemed that the issue addressed by this proposal was a relatively low importance matter – such low-level cleanups can be deferred.
5.13.3.1.1.1.1.1.5JCTVC-H0313 AHG15: On Signalling of Several Syntax Elements in SPS [X. Li, J. An, X. Guo, S. Lei (MediaTek)]
In this proposal, the signalling of the maximum coding unit (CU) size, minimum transform unit (TU) size and maximum RQT depth information in the sequence parameter set (SPS) were discussed. Considering the constraints of CU and TU sizes in current HEVC, somewhat different signalling methods were proposed. It was asserted that the proposed methods can not only save bits in SPS, but also avoid potential incorrect settings of encoding parameters.
The contribution discussed log2_diff_max_min_coding_block_size, log2_min_transform_block_size_minus2, log2_diff_max_min_transform_block_size, max_transform_hierarchy_depth_inter and max_transform_hierarchy_depth_intra.
It was commented that the proposed FLC approach may limit future extensibility.
However, it seemed that the issue addressed by this proposal was a relatively low importance matter – such low-level cleanups can be deferred.
5.13.3.1.1.1.1.1.6JCTVC-H0343 Redundancy removal of syntax [T. Lee, J. Park (Samsung)]
The value of log2MinCUDQPSize is required to be less than or equal to the CU size specified by the value of slice granularity. It was suggested to modify max_cu_qp_delta_depth syntax to make this implicit in the encoding.
It was suggested that ticket #310 resolves this issue (differently but adequately).
Placing the slice address at the beginning of the slice header had been adopted. By using a first_slice_in_pic_flag, it was proposed to remove some redundancy of coding the entropy_slice_flag. This would probably save one bit per picture.
It was proposed to condition a syntax element (5_minus_max_num_merge_cand) on not being an entropy slice. It seemed apparent that this is a justifiable cleanup.
However, it seemed that the issue addressed by this proposal was a relatively low importance matter – such low-level cleanups can be deferred.
Dostları ilə paylaş: |