The changes introduced to support SCC in the transform unit syntax table have modified the condition for chroma QP offset coding compared to Rext.

In Rext the condition for coding cu_chroma_qp_offset_flag and cu_chroma_qp_offset_idx include the cbfChroma and !cu_transquant_bypass_flag values. In SCC the coding of these syntax elements was moved to chroma_qp_offset() to share with palette coding. However, since the aforementioned variables are no longer present in chroma_qp_offset() these conditions should be added in transform unit before calling chroma_qp_offset().

The current wording in JCTVC-W1005-v3.doc is that chroma QP offset gets coded inside transform unit even when cbfChroma is 0 or cu_transquant_bypass_flag is 1. This mismatches with the HM model and Rext behavior.

Rext transform unit syntax:

if( cu_chroma_qp_offset_enabled_flag  &&  cbfChroma  &&
    !cu_transquant_bypass_flag  &&  !IsCuChromaQpOffsetCoded ) {
    cu_chroma_qp_offset_flag
    if( cu_chroma_qp_offset_flag  &&  chroma_qp_offset_list_len_minus1 > 0 )
        cu_chroma_qp_offset_idx
}

SCC transform unit syntax table:

if( cbfLuma  | |  cbfChroma ) {
    <removed for brevity>
    delta_qp( )
    chroma_qp_offset( )

SCC chroma QP offset syntax:

chroma_qp_offset( ) {
    if( cu_chroma_qp_offset_enabled_flag  &&  !IsCuChromaQpOffsetCoded ) {
        cu_chroma_qp_offset_flag
        if( cu_chroma_qp_offset_flag  &&  chroma_qp_offset_list_len_minus1 > 0 )
            cu_chroma_qp_offset_idx
    }
}

In the spec, there is:

pcm_enabled_flag equal to 0 specifies that PCM data are not present in the CVS. NOTE 4 – When MinCbLog2SizeY is equal to 6, PCM data are not present in the CVS even when pcm_enabled_flag is equal to 1. The maximum size of coding block with pcm_enabled_flag equal to 1 is restricted to be less than or equal to Min( CtbLog2SizeY, 5 ). Encoders are encouraged to use an appropriate combination of log2_min_luma_coding_block_size_minus3, log2_min_pcm_luma_coding_block_size_minus3, and log2_diff_max_min_pcm_luma_coding_block_size values when sending PCM data in the CVS.

It is not clear what PCM data are assumed not to be in the stream: only PCM samples, or related syntax like pcm_sample_bit_depth_luma_minus1 etc.

The HM Encoder takes excessive memory, especially when considering increasing picture sizes and GOP structures.

For example, when encoding Traffic (2560x1600), with the 16-frame GOP structure used by JVET, memory requirements are 2482 MiB.

For 4K sequences, memory requirements are approximately 2.1 times higher; i.e. ~ 5361 MiB.

For derived branches, such as JEM, memory utilization is even higher.

The reason is because all memory is allocated for all the processing at the outset. This means that for a 16 frame GOP simulation, up to 32 TComPic objects will be present, all of which have memory allocated for encoding decisions.

15 of the frames will only actually contain source image data

• these are frames that have been buffered up prior to the complete GOP encoding.

1 of the frames will be being processed, and will therefore need

source data and encoding decision data.

Up to 16 frames will be kept as part of the reference picture

list structure. These technically only require the reconstructed picture data and other information present in the DPB.

The attached patch reduced the memory usage by ~60% for the above example, reducing Traffic, GOP-16 from 2482 MiB to just 1020 MiB.

It achieves this by allocating memory only when it is needed. It also introduces a DPB structure into which side information is placed for reference frame usage.

Note that there is not such a significant problem in the decoder, as it only allocates data for pictures when they are decoded, and destroys the data afterwards (as it also has to cope with video format changes).

The patch does not affect run-time or coding efficiency.

I have uploaded it as a ticket so that other branches may examine and comment.