According to the residual quadtree concept, for the given CU, various TU size is evaluated in the quadtree style. In the configuration file, two parameters are given:

QuadtreeTULog2MaxSize QuadtreeTULog2MinSize

where they specify the maximum and minimum possible transform sizes, respectively. It is a good feature, however, it can be improved further. For example, for 64x64 PU, all transform sizes of 4x4, 8x8, 16x16, 32x32 and 64x64 are evaluated when RQT=1. It slows encoder a lot.

We suggest to add one another way to configure residual quadtree: maximum allowed depth of residual quadtree such as:

QuadtreeTUMaxDepth

If we set QuadtreeTUMaxDepth=3, 64x64, 32x32 and 16x16 are used for 64x64 CU while 16x16, 8x8 and 4x4 are used for 16x16 CU. It is helpful to reduce the encoder complexity.

It should be noted that it does not change RQT itself, but just encoder behaviour. And if we set QuadtreeTUMaxDepth sufficiently large value, it should have the same results in the previous version.

This feature is also useful in TE9 to check variable aspects of the TU structure.

If we configure the framework structure not having 8x8 CU with RQT=1, the encoder seems to be crashed. For example,

-s 16 -h 2 (ok) -s 16 -h 1 (crash) -s 32 -h 3 (ok) -s 32 -h 2 (crash) -s 64 -h 4 (ok) -s 64 -h 3 (crash)

Turning off RQT seems to be ok.

When --GPB=0 (or in configuration file), tool status shows GPB is turned off, but actually still B-slice is used instead of P-slice. (both in high-delay of GOP 8 and low-delay of GOP 1).

Maybe due to the new configuration processing system?

P.S. with LowDelayCoding=1, GPB option works. It's strange.