The spec (V1005-v1.doc), in section 7.4.7.1, describes the entry point offsets in relation to tiles_enabled_flag and entropy_coding_sync_enabled_flag.

For the High Throughput profile family, tiles and entropy coding sync can be simultaneously selected. The paragraph describing this particular configuration states:

When tiles_enabled_flag is equal to 1 and entropy_coding_sync_enabled_flag is equal to 1, each subset k with k in the range of 0 to num_entry_point_offsets, inclusive, shall consist of all coded bits of all coding tree units in the slice segment that include luma coding tree blocks that are in the same luma coding tree block row of a tile, and the number of subsets (i.e., the value of num_entry_point_offsets + 1) shall be equal to the number of luma coding tree block rows of a tile that contain coding tree units that are in the coded slice segment.

This implies that only one tile may exist within a slice, which was not the intention.

It is suggested to change "of a tile" to "of tiles".

The spec says (e.g. JVCTV-V1005-v1), in A.3.5,

– In bitstreams conforming to the Main Intra, Main 10 Intra, Main 12 Intra, Main 4:2:2 10 Intra, Main 4:2:2 12 Intra, Main 4:4:4 10 Intra, Main 4:4:4 12 Intra, or Main 4:4:4 16 Intra profiles, all pictures with nuh_layer_id equal to 0 shall be IRAP pictures and the output order indicated in the bitstream among these pictures shall be the same as the decoding order.

However, "Main 4:4:4 Intra" is not listed.

I think this is a typo of the spec text and should be fixed as below.

– In bitstreams conforming to the Main Intra, Main 10 Intra, Main 12 Intra, Main 4:2:2 10 Intra, Main 4:2:2 12 Intra, Main 4:4:4 Intra, Main 4:4:4 10 Intra, Main 4:4:4 12 Intra, or Main 4:4:4 16 Intra profiles, all pictures with nuh_layer_id equal to 0 shall be IRAP pictures and the output order indicated in the bitstream among these pictures shall be the same as the decoding order.

As a background, the issue is found on checking GENERAL_8b_444_RExt_Sony_1 which (not intentionally) includes TRAIL NAL in the Intra profile bitstream. If the text fix is agreed, the bitstream will also be revised.

There is my logs after testing BQSquare as an anchor with a command line -c cfg/encoder_randomaccess_main.cfg -c cfg/per-sequence/BQSquare.cfg

If a refer to HM-15.0 anchor result on ​ftp://ftp.kw.bbc.co.uk/hevc/hm-15.0-anchors/cross-check/; I get the BD-rate loss ~12%.

Is there anything I am doing wrong?