Large amount of padding

[jacob]

In some instances, VTM-2.0.1 and BMS-2.0.1 generates a lot of padding data for some configurations.

An example is BQTerrace low delay configuration at qp 22, where every fourth frame includes around 30000 bytes of padding data (see part of log file at the end of this description).

This affects the results; according to Frank Bossen, around 0.15% for AI, 0.07% for RA, 0.06% for LB and LP.

Also according to Frank, It is possible to disable the padding by setting CabacZeroWordPaddingEnabled to 0 in the configuration file, but currently the CTC configuration files do not do this.

It is a question whether we should ever have so much padding data even if CabacZeroWordPaddingEnabled is set to 1.

Below the last few lines of the log file for BQTerrace.

Adding 27561 bytes of padding
POC 588 TId: 0 ( B-SLICE, QP 23 ) 2155512 bits [Y 41.1733 dB U 41.9457 dB V 43.6371 dB] [ET 268 ] [L0 587 584 580 576 ] [L1 587 584 580 576 ]
POC 589 TId: 0 ( B-SLICE, QP 27 ) 572960 bits [Y 36.8749 dB U 41.7335 dB V 43.5809 dB] [ET 260 ] [L0 588 584 580 576 ] [L1 588 584 580 576 ]
POC 590 TId: 0 ( B-SLICE, QP 26 ) 844160 bits [Y 37.7695 dB U 41.6953 dB V 43.5811 dB] [ET 281 ] [L0 589 588 584 580 ] [L1 589 588 584 580 ]
POC 591 TId: 0 ( B-SLICE, QP 27 ) 519160 bits [Y 36.8410 dB U 41.6747 dB V 43.5527 dB] [ET 222 ] [L0 590 588 584 580 ] [L1 590 588 584 580 ]
Adding 26727 bytes of padding
POC 592 TId: 0 ( B-SLICE, QP 23 ) 2134320 bits [Y 41.1670 dB U 41.9557 dB V 43.6365 dB] [ET 272 ] [L0 591 588 584 580 ] [L1 591 588 584 580 ]
POC 593 TId: 0 ( B-SLICE, QP 27 ) 560920 bits [Y 36.8926 dB U 41.7106 dB V 43.5776 dB] [ET 251 ] [L0 592 588 584 580 ] [L1 592 588 584 580 ]
POC 594 TId: 0 ( B-SLICE, QP 26 ) 829496 bits [Y 37.7516 dB U 41.6732 dB V 43.5641 dB] [ET 280 ] [L0 593 592 588 584 ] [L1 593 592 588 584 ]
POC 595 TId: 0 ( B-SLICE, QP 27 ) 536264 bits [Y 36.8417 dB U 41.6547 dB V 43.5258 dB] [ET 232 ] [L0 594 592 588 584 ] [L1 594 592 588 584 ]
Adding 27699 bytes of padding
POC 596 TId: 0 ( B-SLICE, QP 23 ) 2156920 bits [Y 41.1654 dB U 41.9464 dB V 43.6186 dB] [ET 271 ] [L0 595 592 588 584 ] [L1 595 592 588 584 ]
POC 597 TId: 0 ( B-SLICE, QP 27 ) 559880 bits [Y 36.8879 dB U 41.7076 dB V 43.5802 dB] [ET 253 ] [L0 596 592 588 584 ] [L1 596 592 588 584 ]
POC 598 TId: 0 ( B-SLICE, QP 26 ) 833256 bits [Y 37.7584 dB U 41.6862 dB V 43.5492 dB] [ET 284 ] [L0 597 596 592 588 ] [L1 597 596 592 588 ]
POC 599 TId: 0 ( B-SLICE, QP 27 ) 536216 bits [Y 36.8383 dB U 41.6510 dB V 43.5308 dB] [ET 224 ] [L0 598 596 592 588 ] [L1 598 596 592 588 ]

Total Frames | Bitrate Y-PSNR U-PSNR V-PSNR YUV-PSNR

600 a 51949.1944 38.4215 42.2273 44.2937 39.2556

finished @ Sun Aug 26 23:50:27 2018
Total Time: 153809.600 sec. [user] 174340.057 sec. [elapsed]

-Jacob

[fbossen]

Thanks for the report.

The average BD rate differences somewhat hide the fact that the differences are concentrated around a few test points. Under CTC, padding occurs only for certain sequences, and mostly at QP=22.

In general I don't expect this issue to influence results of experiments or new proposals.

The padding constraint is a carry over from AVC and HEVC. It should be discussed at the next meeting (if not before).

[fbossen]

Should be resolved with integration of JVET-L0274