Joint Collaborative Team on Video Coding (jct-vc) of itu-t sg16 wp3 and iso/iec jtc1/SC29/WG11



Yüklə 1,12 Mb.
səhifə19/33
tarix10.08.2018
ölçüsü1,12 Mb.
#68645
1   ...   15   16   17   18   19   20   21   22   ...   33

5.12.7Slices


JCTVC-I0313 Restricting Slice Boundaries to LCU Granularity [T. Hellman, W. Wan (Broadcom)]

PThis contribution proposes to remove the support of finer-than-CTB spatial granularity of slices (E024) from the specification. This feature is not in a currently-specified profile. It was agreed that this document would be re-reviewed if and when we consider specifying support for this feature in a profile.

It was remarked that the specification of support for this feature may not be complete and correct in the current draft text. The feature is (at least basically) supported in the software.

Our plan is to consider the correctness of the specification of this feature to be a relatively low priority, and, if the feature is still not planned for inclusion in a profile in another meeting cycle or two, we will remove it from the specification (along with removing other unused features, unless they are at least planned for use in some future profile).



JCTVC-I0394 AHG11: Copy Slice Type [S. Deshpande, A. Segall (Sharp)]

Currently, we have a skip flag at the CTB level, and copying would use approximately two coded bins per LCU.

This contribution requests adding a new slice type to copy an area from another picture. The number of LCUs to be copied would be inferred from the slice address of the next slice.

Some concern was expressed about the dependency of the slice size on the content of data in some other slice.

It was also commented that this seems like duplicate functionality, since it is possible to use the current syntax to produce the same effect reasonably efficiently.

No action taken.



JCTVC-I0500 AHG11: Definition of slice types [K. Suehring (HHI)] [late]

The cCurrent text uses ue(v) coding of slice_type with the ordering 0=P, 1=B, 2=I (save as AVC).

The software has 0=I, 1=P, 2=B. It was remarked that the CABAC initialization in the text corresponds to this.

The pProposal suggests 0=B, 1=P, 2=I (the first two switched from AVC).



Decision: Adopted (also fixing the CABAC initialization in the text to correspond with this). [Notes cleanup: Here we should just refer to the related action regarding entropy slice type indication.]Note that the value 3 is also defined for entropy/dependent slices as described in the notes relating to I0330.

5.12.8High-level syntax cleanup


JCTVC-I0266 Modifications on signalling collocated picture [Y. Yu, J. Lou, L. Wang (Motorola Mobility)]

Reviewed in Track B.

In the current HEVC committee draft, collocated_from_l0_flag and collocated_ref_idx at the slice header level are used to specify the collocated picture. Another flag enable_temporal_mvp_flag at PPS is used to control whether the temporal motion vector is used or not. This document proposes some modifications on signalling the collocated picture. When enable_temporal_mvp_flag is 0, both collocated_from_l0_flag and collocated_ref_idx are no longer necessary.

The contribution pProposes to not send syntax in the slice header to identify the collocated picture for temporal MVP when the temporal MVP is disabled at the PPS level. The text impact is miniscule – just a small change in the syntax table.



Decision: Adopted (editorially it would seem preferable to nest the existing "if" statements within a new "if( enable_temporal_mvp_flag )" check).

JCTVC-I0037 Removal of Syntax Redundancies [Y. Morigami, K. Sato (Sony)]

Reviewed in HLS BoG (chaired by Y.-K. Wang).

Abstract: In the HEVC CD text specification draft text, the SPS (sequence parameter set) contains the syntax element “chroma_format_idc”. The value cChroma_format_idc = 0 means that the input video is in monochrome format. At the 8th JCT-VC meeting in San Jose, it was proposed by JCTVC-H0457 to remove monochrome format support from HEVC specification, and meeting notes sayssaid: “We will have some profile that does not support monochrome, and an indicator flag in VUI”. The Main profile currently does not support monochrome input, but the HEVC syntax itself still supports monochrome. There would be profiles that support monochrome format either in version 1 or 2 of HEVC.

If the input is monochrome, the syntax elements related to Cb/Cr are redundantunnecessary. In fact such redundancy is excluded on weighted prediction in the current HEVC specification, but not on other syntax elements such as:



  • chroma_pred_from_luma_flag

  • bit_depth_chroma

  • cb_qp_offset and cr_qp_offset

  • sao_cb_enable_flag and sao_cr_enable_flag

  • alf_cb_enable_flag and alf_cr_enable_flag

  • intra_chroma_pred_mode

  • pcm_sample_chroma

  • scaling list

This document proposes to remove such redundancies from HEVC syntax so long as there exists profile(s) that support monochrome either in version 1 or 2 of HEVC. Otherwise, syntax redundancy removal on weighted prediction would not be necessary.


Comments:

The proposed syntax introduces a parsing dependency of PPS on SPS.

If we don't anything nowdo not take any action now, in a potential new profile in the future that supports 4:0:0, we can still add a condition in a way that is backwards compatible. In such a potential new profile, it should be useful to do this.

The BoG recommended no action.



JCTVC-I0127 Syntax cleanup [T. Lee, J. Park (Samsung)]

Reviewed in HLS BoG (chaired by Y.-K. Wang).

Document abstract: There are syntax elements having dependencyies each other. To clarify the dependency and reduce redundant bits, the a conditional coding or differential coding of the information related temporal motion predictor, dQP signalling unit and entropy slice are proposed.

Elements of the proposal included the following:

1) The proposal mMakes the current signalling of collocated_from_l0_flag and collocated_ref_idx further conditioned on enable_temporal_mvp_flag

This was rResolved by the decision of for I0266.

2) To The proposal suggests to fix a bug in the semantics of max_cu_qp_delta_depth, and further proposes a syntax cleanup for bits saving.

The BoG rRecommended adoption. (also rememberinding to put establish a value range when integrating). Decision:  Adopted.

3) The proposal mMakes entropy_slice_flag conditional on !first_slice_in_pic_flag, and also makes all SH syntax elements and syntax structures from five_minus_max_num_merge_cand conditional on !entropy_slice_flag.

The BoG recommended adoption. Decision: Adopted.



JCTVC-I0165 On Signalling of Several Syntax Elements in Slice Header [J. An, X. Guo, C.-W. Hsu, Y.-W. Huang, S. Lei (MediaTek)]

Reviewed in HLS BoG (chaired by Y.-K. Wang).

In this contribution, some conditions and constraints were proposed to be added on the signalling of two syntax elements in slice header, aps_id and inherit_dbl_params_from_aps_flag. It is reported that the proposed method can save some redundant bits, as well as avoid the potential contradictory between related syntax elements.

This was no longer relevant due to APS- related decisions at this meeting.



JCTVC-I0144 Removal of input picture size constraint and picture cropping offset parameters in sequence parameter set [I.-K Kim, Y. Park, J. H. Kim, J. H. Park (Samsung)]

Reviewed in HLS BoG (chaired by Y.-K. Wang).

In this contribution, removal of a constraint on picture width and height (picture width and height shall be integer multiple of minimum CU size) is proposed. Based on the proposal, it is also suggested to move the position of picture cropping offset parameters from sequence parameter set (SPS) to supplemental enhancement information (SEI). By this modification, general cropping functionality is kept as optional and only the mandatory cropping process is kept in the decoding process.

The BoG recommended no action.



JCTVC-I0420 High-level Syntax: Proposed fix on signalling of TMVP disabling flag [C. S. Lim, S. Mon Thet Naing (Panasonic), J. Xu (Microsoft), B. Li(USTC)]

Reviewed in HLS BoG (chaired by Y.-K. Wang).

IThis contribution proposes to explicitly signal the enable_temporal_mvp_flag at every P and B slice header. It is purported asserted that the benefit includes cleaner design for TMVP disabling process.

Elements of the proposal included the following:

1) To remove the marking process and normatively constrain the bitstream such that any pictures that follow the current picture in both decoding order and output order shall not use temporal motion vector prediction from any picture that precedes the current picture either in decoding order or output order.

The BoG recommended to adopt this aspect. Decision: Adopt.

2) Explicitly signalling the flag in the slice header

Suggestion: To have a flag in the SPS, if that flag is equal to 1, then no flag in the slice header, otherwise the slice header flag is sent.

Suggestion: The enable_temporal_mvp_flag in the slice header shall be the same for all slices in a picture.

The BoG recommended to adopt the above suggestions. Decision: Adopt.

3) An eEncoder constraint to enable establish the refresh point (no functionality change)

The BoG recommended no action.



JCTVC-I0170 Parsing robustness issue for deblocking filter syntax [S. Esenlik, M. Narroschke, T. Wedi (Panasonic)]

Was reviewed in Track B.

According to the current HM6.0 the deblocking control parameters can be signalled either in the Adaptation Parameter Set (APS) syntax structure or in the slice header. It is noted in the proposal that when the deblocking control parameters are sent in the APS, the parsing of the syntax element slice_loop_filter_across_slices_enabled_flag in the slice header depends on the DB control parameters that are sent in the APS. This results in a parsing issue for the slice data, since the APS is expected to be subject to packet losses in the communication network. The contribution provides a solution for the parsing problem with a small change in the slice header syntax. With the help of the proposal the slice data can be parsed independently from the APS.

NThis was no longer relevant due to APS- related decisions at this meeting.



Yüklə 1,12 Mb.

Dostları ilə paylaş:
1   ...   15   16   17   18   19   20   21   22   ...   33




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