International organisation for standardisation

6.10.3Parameter sets and slice header

6.10.3.1.1.1.1.1.1JCTVC-F131 Modifications to slice header termination for low delay encoding [V. Sze, M. Budagavi, A. Osamoto (TI)]

SAO and ALF are performed in the last stage of video coding; however, SAO and ALF parameters are inserted in the slice header which is before the slice data (generated from earlier stages of video coding). This inconsistency between order of processing and order of data transmission under the current that slice header format implies that at the encoder CABAC and EPB insertion must be performed after SAO and ALF, which can be an issue for low delay encoders. This contributions proposes that 1) CABAC should be terminated after slice header to enable CABAC encoding as syntax elements are produced; 2) the slice header should be byte aligned to enable EPB insertion as bits are being produced; 3) we should ensure that last byte in slice header is non-zero, as this allows slice header and slice data to be easily stitched together without changing slice data. This modification was implemented in HM-3.2 and its coding efficiency was evaluated with ALF on for both HE and LC: 0.0% AI-HE, 0.1% RA-HE, 0.1%, LD-HE, 0.0% AI-LC(ALF on), 0.0% RA-LC (ALF on), 0.0% LD-LC(ALF on); and ALF off for both HE and LC: 0.0% AI-HE (ALF off), 0.1% RA-HE(ALF off), 0.1% LD-HE(ALF off), 0.0% AI-LC, 0.0% RA-LC, 0.0% LD-LC.

Byte alignment issues:

• 
  Proposes byte alignment after slice header (with CABAC termination and also for CAVLC).
  
• 
  Add RBSP trailing bits (or equivalent without the minimum single bit found using that) for achieving the byte alignment:
  

Decision: Agreed.

These decisions were pending review of JCTVC-F377.

See notes under JCTVC-F377.

6.10.3.1.1.1.1.1.2JCTVC-F393 Cross-check report on TI's slice header termination for low delay encoding (JCTVC-F131) [I.-K. Kim (Samsung)]

6.10.3.1.1.1.1.1.3JCTVC-F187 Comments on Slice Common Information Sharing [M. Li, P. Wu (ZTE)]

Prior related contribution JCTVC-E281.

Relates to discussion for JCTVC-F321 and JCTVC-F384.

See also notes relating to JCTVC-F747.

6.10.3.1.1.1.1.1.4JCTVC-F377 Arithmetic coding in high level syntax [T. Suzuki (Sony)] [late upload 07-07]

In WD3, some syntax elements, ALF and SAO parameters, are encoded in the slice header layer by arithmetic coding. However, it was asserted that the slice header layer is often handled by firmware, not hardware, in many HW implementations. Since the resources of firmware are limited, CABAC arithmetic coding was asserted to be too difficult for processing in firmware. The contribution proposed the following:

• 
  Not to use arithmetic coding in high level syntax (slice header and higher layers);
  
• 
  To move ALF and SAO parameters to the top of the slice data;
  
• 
  Or move SAO parameters to the end of slice header;
  
• 
  And/or move the syntax to initialize CABAC (slice_type and slice_qp_delta) to the beginning of the slice header.
  

It was suggested to add RBSP trailing bits (or equivalent) for achieving the byte alignment also before the ALF switch flags (when present): Decision: Yes.

A potential slice syntax structure was discussed to be as follows:

• 
  Header stuff (all non-CABAC header syntax here, includes PPS index and slice parameter set index)
  
• 
  ALF when present:
  
  • 
    RBSP trailing
    
  • 
    CABAC ALF switch flags (ending with CABAC flush)
    
• 
  RBSP trailing bits
  
• 
  Slice data
  
• 
  RBSP trailing
  
• 
  CABAC zero word (when present)
  

Decision: Yes (neglecting any superseding impact relating to the adaptation parameter set usage per JCTVC-F747).

See additional notes under JCTVC-F131.

The slice parameter set syntax was documented in a revision of JCTVC-F747.

See also the section discussing JCTVC-F747.

6.10.3.1.1.1.1.1.5JCTVC-F399 Restart of CABAC after coding of ALF and SAO slice header data [M. Narroschke, T. Wedi, S. Esenlik (Panasonic)]

Typically, ALF and SAO control parameters are estimated after the determination of the syntax elements to code the blocks of a slice. In order to allow decoders a convenient block-by-block decoding including the application of ALF and SAO, the control parameters of ALF and SAO are coded before the slice block data within the slice header. In HM3.2, the slice block data is coded dependently on the ALF/SAO control parameters in one arithmetic codestream. Thus, the encoder needs to buffer all syntax elements of the slice block data until the ALF and SAO control parameters are estimated and coded. Afterwards, the buffered syntax elements are coded. Thus, the encoding is associated with the two problems: Large buffer and delay. In order to overcome these two problems, it is proposed to restart CABAC after the coding of the ALF/SAO control parameters by the use of a cabac_restart_flag, which is coded in the terminating mode within the slice header. By a restart of CABAC, all block data of a slice is coded independently from the ALF/SAO control parameters. As a consequence, the syntax elements of slice block data can be coded without delay and without being buffered until the ALF/SAO control parameters are estimated and coded. The influences on the coding efficiency and on the encoder and decoder run times are negligible. It is proposed to adopt the proposed technique into the next version of the HM.

Moving the ALF and SAO data to the slice parameter set fixes this for the parameters, but not the CU level control data for ALF.

Remark: Consider the delay implications of the positioning of the ALF control data.

Question: Where are the on/off flags and filter selection indicators sent? The on/off flags are in the slice header. Filter selection is implicit (for luma).

Suggestion: Do not use the single initial flag found in the WD – always restart CABAC and flush to byte align. Finalization of flag status to reflect the intent.

Question: Is there a way to code filter control data using CAVLC? Yes.

Essentially adopted; see above discussion under JCTVC-F131 and JCTVC-F377.

6.10.3.1.1.1.1.1.6JCTVC-F469 Syntax improvement for fine granularity slices [C. Kim, Y. Park (Samsung)]

The fine granularity slices was adopted at the last meeting through the BoG report of JCTVC-E483. The adopted syntax structure reportedly looks somewhat unsuitable for recursive coding_tree() representation. In this proposal a modified fine granularity slice syntax and process is proposed to make the syntax fit for quadtree structure.

Currently we send slice_granularity (16x16, 32x32, 64x64) in PPS, and slice_address in slice header.

The proponent proposed a different syntax.

The benefit of the proposal did not seem clear to the group. It was commented that this seems to be sending some additional bits and syntax elements in the slice header.

For further study.

6.10.3.1.1.1.1.1.7JCTVC-F503 Results on slice header modifications [N. Ouedraogo, P. Onno (Canon)]

This contribution presents results of some experiments conducted by implementing the modifications around the slice header introduced in JCTVC-E222 at the Geneva JCT-VC meeting. This technical proposal introduces two main modifications. A first modification consists of gathering some coding parameters of slice headers in a dedicated NAL unit. A second modification adds some additional parameters within this new NAL unit. Some coding efficiency results targeting a streaming scenario are reported (under certain assumptions).

Proposes to move almost all slice header syntax into a different NAL unit shared by all slices of a picture, including picture-specific parameters such as frame_num.

This proposed additional NAL unit is basically a repeatable picture header (as tested).

Benefit reported approximately 1% on average (more in some classes, less in others).

For further study (esp. in relation to new slice parameter set).

6.10.3.1.1.1.1.1.8JCTVC-F523 Improvements of SPS syntax [V. Drugeon (Panasonic), T. Wedi (Panasonic)]

The current high-level syntax in the working draft (JCTVC-E607) is different from the one in the software (HM3.2). In a first step, this contribution analyzes discrepancies between working draft and software as well as shortcomings in the SPS (Sequence Parameter Set) syntax. In a second step, an implementation and text is provided that synchronizes the SPS syntax in the software and the working draft and that is asserted to solve problems related to the signalling of the picture size.

The current SPS syntax of WD sends width and height in luma samples as u(16).

We agree that the current syntax does not does not necessarily represent what we ultimately want to have, but at the moment it is not clear what exactly we would want – and the current WD seems adequate for our experiments.

For further study.

6.10.3.1.1.1.1.1.9JCTVC-F747 Adaptive slice parameter set (APS) [S. Wenger, J. Boyce] [late reg. 07-16, upload 07-17]

This document was submitted at the request of the JCT-VC (submitted as a proposal document, although also somewhat of a BoG report) after discussions at the meeting prompted consideration of the previously-proposed concept of a slice-layer-activated adaptation parameter set (APS). Provided in the document were syntax and semantics, as well as pointers to documents providing more information on the utility of slice parameter sets – the predecessor proposal in the spirit of the APS. Syntax, semantics and decoding process are based on JCTVC-E603-d8. (The authors also took the liberty to comment on and/or remove leftover text from AVC that doesn’t seem to apply to HEVC, nor is likely in their subjective opinion to apply in the future.)

It was noted that the ALF and SAO parameters don't (at least currently) change within a picture.

It was noted that JCTVC-F542 (Cisco) may be relevant.

In further discussion, the following points were initially agreed:

• 
  To define such a new NAL unit.
  
• 
  For the draft to say that the index must stay the same for the picture.
  
• 
  For the index to the APS to go in the slice header.
  
• 
  For the index to the PPS to go in the APS.
  

However, after further discussion, it was decided that we would use two indices in the slice header, and a new version of JCTVC-F747 was provided to reflect this.

The new version of JCTVC-F747 was reviewed on Wednesday.

Decision: Adopted (the revised version).