Mismatch when using parcat, related to ALF

[jsauer]

I added 360Lib 10.0 to VTM 8.0. Further I applied the attached patch to account for some changes of internal variables.

I get a mismatch when using parcat for BranCastle. It can be reprocuded by encoding:

bin/EncoderAppStatic -c cfg/encoder_randomaccess_vtm.cfg -c cfg-360Lib/encoder_360_HEC.cfg --CodingFaceWidth=1280 --CodingFaceHeight=1280 --IntraPeriod=32 --SEIDecodedPictureHash=1 --OutputBitDepth=10 --SphFile=cfg-360Lib/360Lib/sphere_655362.txt --Level=5.2 --QP=22 --CodingFPStructure="2 3   4  0 0   0 5 0       3 180 1 270 2   0" --FrameRate=30 --SourceHeight=3072 --SourceWidth=6144 --InputFile=BranCastle2_6144x3072_30fps_8bit_420pf_erp.yuv --BitstreamFile=str/BranCastle2_3840x2560_30fps_10bit_420pf_FTBE96to128_QP22.vvc --FramesToBeEncoded=33 --InputBitDepth=8 --InputChromaFormat=420 --FrameSkip=96 --ReconFile=rec/BranCastle2_3840x2560_30fps_10bit_420pf_FTBE96to128_QP22_rec_enc.yuv

and

bin/EncoderAppStatic -c cfg/encoder_randomaccess_vtm.cfg -c cfg-360Lib/encoder_360_HEC.cfg --CodingFaceWidth=1280 --CodingFaceHeight=1280 --IntraPeriod=32 --SEIDecodedPictureHash=1 --OutputBitDepth=10 --SphFile=cfg-360Lib/360Lib/sphere_655362.txt --Level=5.2 --QP=22 --CodingFPStructure="2 3   4  0 0   0 5 0       3 180 1 270 2   0" --FrameRate=30 --SourceHeight=3072 --SourceWidth=6144 --InputFile=BranCastle2_6144x3072_30fps_8bit_420pf_erp.yuv --BitstreamFile=str/BranCastle2_3840x2560_30fps_10bit_420pf_FTBE128to160_QP22.vvc --FramesToBeEncoded=33 --InputBitDepth=8 --InputChromaFormat=420 --FrameSkip=128 --ReconFile=rec/BranCastle2_3840x2560_30fps_10bit_420pf_FTBE128to160_QP22_rec_enc.yuv

then

bin/parcatStatic str/BranCastle2_3840x2560_30fps_10bit_420pf_FTBE96to128_QP22.vvc str/BranCastle2_3840x2560_30fps_10bit_420pf_FTBE128to160_QP22.vvc str/BranCastle2_3840x2560_30fps_10bit_420pf_FTBE96to160_QP22.vvc

Decoding the merged stream results in mismatches.

I found that the frame 32 of the first segment has

POC    0 LId:  0 TId: 0 ( I-SLICE, QP 19 ) [DT 12.813] [L0] [L1] [MD5:ca6f5f0f129263c77c042e1420caeea4,d3d0c5f8173d4f0236f302d2baf94232,b3058800397a4c7d45aa5941ff2b703a,(OK)] 

while frame 0 of the second segment has

POC   32 LId:  0 TId: 0 ( I-SLICE, QP 19 ) [DT 11.916] [L0] [L1] [MD5:bc277468b0fe0d1bb6aa58dd9fc08242,d3d0c5f8173d4f0236f302d2baf94232,b3058800397a4c7d45aa5941ff2b703a,(OK)] 

After some digging I found that the reconstruction matches until ALF is executed.

[jsauer]

patch for vtm 8.0 to be used after adding 360Lib

[tung.nguyen]

The same issue occurs with VTM-8.0 for some of the sequences in the lowQP configuration, and for some 422 sequences of the non-420 test set.

lowQP:
KirstenAndSara QP 7, Johnny QP 7, FourPeople QP 7, RitualDance QP 2 and 7, MarketPlace QP 7
non-420 natural:
EBUKidsSoccer_422 QP 22, Seeking_422 QP 22, Crowdrun_444 QP 22

[ksuehring]

This should have been fixed with MR 1488

​https://vcgit.hhi.fraunhofer.de/jvet/VVCSoftware_VTM/-/merge_requests/1488

The fix was verified for no-420 conditions on low QP.

Can you check, if it fixed the 360Lib use case as well.

[jsauer]

Alright, I started some simulations.

[jsauer]

It is fixed :)