International organisation for standardisation

6.10.4Tiles

6.10.4.1.1.1.1.1.1JCTVC-F335 Tiles [A. Fuldseth (Cisco), M. Horowitz, S. Xu (eBrisk Video), A. Segall (Sharp), M. Zhou (TI)]

This contribution proposes a coding technique called tiles, similarly to what was previously presented in JCTVC-E408. The use of such tiles partitions a picture into rectangular segments. Tile partitioning comprises establishing vertical and horizontal boundaries that partition a picture into columns and rows respectively. Column and row boundaries break prediction mechanisms (e.g., intra prediction and motion vector prediction) in the same way as slice boundaries unless indicated otherwise. Intersecting column and row boundaries delineate rectangular regions called tiles, each containing an integer number of LCUs. LCUs are processed in raster scan order within tiles and tiles are processed in raster scan within a picture. Results from three experiments are presented comparing coding efficiency for tiles against an identically configured encoder using slices with LCUs processed in raster scan-order within a picture. It was reported that the use of such tiles provide 1.7%, 3.1%, and 4.8% coding gains for Intra, Random Access, and Low Delay, respectively, relative to some example configurations of the HM using slices that were asserted to be relevant (not the common conditions).

One difference from JCTVC-E408 is in regard to what happens for "equal" divisions into tiles, for which QP and cabac_init_idc are initialized from the slice header of the slice containing the first CU in the tile.

Draft text was provided.

Note that tiles are not analogous to slice groups and are not analogous to slices. Slices can cross tile boundaries and tiles can cross slice boundaries.

A proposed flag determines whether the entropy coding (and basically all other dependencies) is reset at the start of each tile boundary. CABAC gest flushed and padded to a byte boundary when the flag indicates independence.

A basic intent is to enable encoder-side parallelism.

Loop filtering crosses the tile boundaries. Is there a flag proposed for that? Currently, no (just applied always across tile boundaries).

It was noted that we also have slices and entropy slices, so there is a concern that we may end up with too many multi-CU packing and dependency structures in a way that would make support for all of them impractical.

The reported bit rate savings was suggested to be primarily due to avoiding the need to send more slice headers.

6.10.4.1.1.1.1.1.2JCTVC-F547 Cross-check of Tiles (JCTVC-F335), experiment #1 [R. Sjöberg, P. Wennersten (Ericsson)] [late upload 07-08]

Cross-checker reported consistent results for the experiment that was checked (#1). The software was reportedly studied and determined to match the technical proposal design.

6.10.4.1.1.1.1.1.3JCTVC-F589 Cross check report of JCTVC-F335 Tiles [M. Coban (Qualcomm)] [late upload 07-06]

Cross-checker reported consistent results for the experiment that was checked (#2).

6.10.4.1.1.1.1.1.4JCTVC-F140 Support of very low delay coding in tile [K. Kazui, S. Shimada, J. Koyama, A. Nakagawa (Fujitsu)]

Past contributions JCTVC-B031, JCTVC-C021 and JCTVC-D054 proposed the high-level syntax and semantics based on vertical intra MB line refresh scheme. JCTVC-E061 asserted that the proposed high-level syntax and semantics are needed to satisfy the requirement for real-time video transmission applications with minimal loss of coding efficiency.

This contribution proposes a modification of "tiles" similar to the tile proposal at the 5th JCT-VC meeting, modified for support of very low delay video coding.

It was proposed to allow the LCU scan within a slice to be in raster scan order within the picture rather than in raster scan order within each tiles.

A form of special handling of tile boundaries – e.g. for independence of deblocking and intra prediction, was discussed.

Some other ideas for flexibility of the use of tiles and scanning were presented.

In addition to very low delay, the proponent suggested that there might be parallel processing benefits to be developed from these ideas.

The ideas presented here seemed somewhat preliminary, and in need of further development and testing.

Further study, including experimental design and statistical analysis of test cases, was encouraged.

6.10.4.1.1.1.1.1.5JCTVC-F594 New results for parallel decoding for tiles [K. Misra, A. Segall (Sharp)]

This contribution presents results for JCTVC-E412, which extended “Tiles” (JCTVC-E408) to support decoder parallelization. Decoder parallelization is realized by signalling tile entry points in the bitstream. A decoder is then able to enter the bitstream at the beginning of a tile. The signalling is used as tiles does not use a header and thus cannot be located in the bitstream by a decoder (without completely parsing the bitstream). The approach supports sending tile entry points explicitly in the slice header or using markers in the bitstream. The bit rate overhead for signalling locations explicitly in slice headers is reportedly AI_HE: 0.0%, AI_LC: 0.0%, RA_HE: 0.1%, RA_LC: 0.2%, LD_HE: 0.5%, LD_LC: 0.5% (not based on common conditions, but according to a described experiment design is adjusted for relevance to the technology). The bit rate overhead for signalling using markers is AI_HE: 0.1%, I_LC: 0.1%, RA_HE: 0.6%, RA_LC: 0.7%, LD_HE: 1.8%, LD_LC: 1.7%.

Scheme 1: send location information in the slice header.

Scheme 2: send entry marker patterns (e.g., 0x000002) in the bitstream.

The SEI approach discussed at the preceding meeting was further discussed, and the possibility of something like an SEI message that could fall between slices in NAL unit order. This would be a somewhat higher overhead approach.

The scheme proposed was the same as that of the previous meeting.

6.10.4.1.1.1.1.1.6JCTVC-F749 Cross-check of new results for parallel decoding for tiles (JCTVC-F594) [M. Horowitz, S. Xu (eBrisk)] [late reg. 07-16, upload 07-16]

The software was studied and generally considered clearly written. The results (so far, with at least 2/3 complete) matched.