In section 8.8.3.2 (Deblocking filter process for one direction) of JVET-T2001-v2, the following is present.

–Otherwise, if edgeType is equal to EDGE_HOR and one or more of the following conditions are true, the variable filterEdgeFlag is set equal to 0:
    –The top boundary of the current luma coding block is the top boundary of the picture.
    –The top boundary of the current coding block coincides with the top boundary of the current subpicture and sps_loop_filter_across_subpic_enabled_flag[ CurrSubpicIdx ] or sps_loop_filter_across_subpic_enabled_flag[ subpicIdx ] is equal to 0, where subpicIdx is the subpicture index of the subpicture for which the top boundary of the current coding block coincides with the bottom subpicture boundary of that subpicture.
    –The top boundary of the current coding block is the top boundary of the tile and pps_loop_filter_across_tiles_enabled_flag is equal to 0.
    –The top boundary of the current coding block is the top boundary of the slice and pps_loop_filter_across_slices_enabled_flag is equal to 0.

"The top boundary of the current luma coding block is the top boundary of the picture" should be "The top boundary of the current coding block is the top boundary of the picture".

Broadcom discovered that the deblocking do not work properly when max transform size is smaller than 64 since the code assumes it always is 64.

A fix to this was sent in as a merge request 220.

Difference between encoder PSNR and decoder PSNR for POC 17 to 31 for VTM-4.0rc1 for SlideShow for random access at QP 32 when running parallel simulations. A quick test on sequential simulation for 33 frames did not get any mismatch. Perhaps some dependency between intra pictures?

PSNR for POCs for reconstruction after encoder and decoder respectively: Decoder 17 43.5273 49.2218 50.5996

18 43.5267 49.2012 50.5805 19 43.5247 49.1793 50.5617 20 43.5270 49.1409 50.5410 21 43.5195 49.0282 50.4877 22 43.5152 48.8892 50.4280 23 43.5166 48.9966 50.4542 24 43.5230 48.9968 50.4522 25 43.5212 48.9968 50.4522 26 43.5230 48.9968 50.4522 27 49.9128 50.0493 50.8160 28 49.9067 50.0468 50.8160 29 49.8930 50.0375 50.8154 30 49.8262 50.0034 50.8050 31 49.7722 49.9511 50.7881

Encoder:

17 43.5148 49.1673 50.3354 18 43.5151 49.1554 50.3192 19 43.5110 49.1371 50.3022 20 43.5145 49.1130 50.2824 21 43.5067 49.0848 50.2447 22 43.5026 49.0361 50.1972 23 43.5046 49.0323 50.2077 24 43.5114 49.0327 50.2052 25 43.5087 49.0327 50.2052 26 43.5114 49.0327 50.2052 27 49.9128 50.0491 50.8160 28 49.9067 50.0465 50.8160 29 49.8930 50.0373 50.8154 30 49.8262 50.0032 50.8050 31 49.7722 49.9509 50.7881

Looking at the parallel simulations: First parallel gop: POC 0 TId: 0 ( I-SLICE, QP 29 ) 201296 bits [Y 43.3439 dB U 46.4949 dB V 47.6155 dB] [ET 121 ] [L0 ] [L1 ] POC 16 TId: 0 ( I-SLICE, QP 29 ) 76184 bits [Y 43.5284 dB U 49.2273 dB V 50.6035 dB] [ET 66 ] [L0 ] [L1 ] .. But second parallel gop: POC 0 TId: 0 ( I-SLICE, QP 29 ) 75872 bits [Y 43.5171 dB U 49.1724 dB V 50.3382 dB] [ET 71 ] [L0 ] [L1 ] Both bits and PSNR are different for POC 0 in second GOP and POC 16 in first GOP which corresponds to same picture!