An explanation for vvenc output

[birdie-github]

It's not a bug but it would be nice to get an explanation for the terms used in vvenc output (1/2/3).

1. First of all its header:

vvencapp: Fraunhofer VVC Encoder ver. 1.6.1 [Linux][GCC 12.2.1][64 bit][SIMD=AVX2]
CODING TOOL CFG: CTU128 QT44BTT3333332 IBD:1 SAO:1 ALF:1 (NonLinLuma:1 NonLinChr:1) CCALF:1 Tiles:1x1 Slices:1 WPP:0 WPP-Substreams:1 TMVP:1 DQ:1 SDH:0 CST:1 BDOF:1 DMVR:1 MTSImplicit:0 SBT:1 JCbCr:1 CabacInitPresent:0 AMVR:1 SMVD:1 LMCS:2 (Signal:SDR Opt:0) CIIP:1 MIP:1 AFFINE:1 (PROF:1, Type:1) MMVD:1 DisFracMMVD:1 SbTMVP:1 GPM:1 LFNST:1 MTS:1 (IntraCand:3) ISP:1 TS:2 TSLog2MaxSize:5 useChromaTS:0 BDPCM:2 IBC:2 BCW:2 
ENC. ALG. CFG: QPA:1 HAD:1 RDQ:1 RDQTS:1 ASR:1 MinSearchWindow:96 EDO:2 MCTF:2 
PRE-ANALYSIS CFG: STA:1 LeadFrames:0 TrailFrames:0 
FAST TOOL CFG: ECU:0 FEN:3 FDM:1 FastSearch:1 (SCC:2) LCTUFast:1 FastMrg:1 PBIntraFast:1 AMaxBT:0 FastQtBtEnc:1 ContentBasedFastQtbt:0 FastMIP:0 FastIntraTools:0 IntraEstDecBit:1 FastLocalDualTree:1 IntegerET:0 FastSubPel:0 ReduceFilterME:0 QtbttExtraFast:1 FastTTSplit:1 IBCFastMethod:1 FIM:0 ALFSpeed:0 QuantThr: 4 
RATE CONTROL CFG: RateControl:0 LookAhead:0 
PARALLEL PROCESSING CFG: NumThreads:8 MaxParallelFrames:4 WppBitEqual:1 WF:0

Some items are pretty self-explanatory, e.g. PARALLEL PROCESSING CFG: NumThreads:8 MaxParallelFrames:4 but others are pretty cryptic.

2. Then encoding output:

POC     0 TId: 0 (  IDR_N_LP, I-SLICE, QP 11, TF 3)    2575840 bits [Y 49.2438 dB    U 56.5677 dB    V 58.4297 dB] [ET    52 ] [L0 ] [L1 ]
POC    32 TId: 0 (     TRAIL, B-SLICE, QP 14, TF 3)    2181336 bits [Y 47.3346 dB    U 54.8549 dB    V 55.7641 dB] [ET   134 ] [L0 0 ] [L1 0 ]
POC    16 TId: 1 (      STSA, B-SLICE, QP 15, TF 2)    1366152 bits [Y 46.3344 dB    U 54.0853 dB    V 55.1923 dB] [ET   118 ] [L0 0 32 ] [L1 32 0 ]
POC    64 TId: 0 (       CRA, I-SLICE, QP 12, TF 3)    2639304 bits [Y 48.3808 dB    U 55.6834 dB    V 56.8192 dB] [ET   101 ] [L0 ] [L1 ]
POC    39 TId: 5 (      RASL, B-SLICE, QP 22)            21048 bits [Y 44.0537 dB    U 53.7304 dB    V 54.5433 dB] [ET    17 ] [L0 38 36 ] [L1 40 48 ]

3. Lastly, everything in the header seems to be configurable but is it or I need to use vvencFFapp? I know it's all work in progress, so if it makes no sense, don't bother.

[adamjw24]

So... this is a complicated question. First of all, a disclaimer. We inherited the output from VTM, so some of the things might not make sense for VVenC.

1st line:
Its the name of the exacutable, version (but beware that we only adapte a version before tagging it, so 1.6.1 might mean the exact 1.6.1 tag or any untagged changes after it), and some compile info. Lastly, the used SIMD extension is specified.

2nd line:
Describes the used coding tools, i.e. the usage/non-usage and parametrization of various parts of the VVC standard. If you have speicifc questions about the tools feel free to ask, I can point you to some resources.

3rd line:
It is about encoder-only algorithm parametrization, i.e. the usage of QPA (adaptive quantization), RDOQ (rate-distrortion optimized quantization) or pre-filtering (MCTF). If you do a vvencFFapp --fullhelp most of those options are somehow described.

4th line:
Here the applied preanalysis is described. Most imporant here is STA, which says if B-to-I slice type adaptation is allowed.

5th line is about the used speedups. Again, try looking up an option in vvencFFapp --fullhelp or ask here for more carification.

6th line:
Here the settings of the rate-control or described, when used, i.e. target rate, used number of passes etc.

In the last line the threading configuration is described, while actually the only important info here is the number of threads (NumThreads).

From user perspective, the most important infos are contained in lines 1, 3, 4, 6 and 7. Within those the settings to lookout for are:

• QPA: it basically says is the encoding is tuned for psnr or human visual system.
• MCTF: a pre-filtering step, will change the input data the encoder gets
• STA: is a kind of scene-cut detection that (for now) doesn't insert key-frames
• TargetBitrate (visible when RateControl is enabled) and NumPasses spacify your rate control settings
• NumThreads tells you how many threads are allocated in the thread pool of workers

About the per frame outputs:

• POC describes picture number in display order (as opposed to coding order, in which the lines are output).
• TId is the temporal ID, which is imporant to achieve temporal scalability
• In the parenthases you see the NAL unit type used for a frame, the slice type to encode it, the used QP and if the picture is temporally fitered (the number describes which strenght)
• Than you have the resulting number of bits per frame and per-component PSNR
• ET is elapsed time (seconds)
• L0 and L1 shows which frames are available for a frame as references

You can configure most of the settings either with the FF-app or using the additional option of the simple app (it's implemented through a key-value interface).

Hope this helps.

Best, Adam

[birdie-github]

Thanks a ton!

---

1. It looks like POCs correspond to frames, why there are far fewer POCs than frames?
2. Why POCs are shown out of order?
3. The bits being consumed by POCs - to how many frames those bits belong? It's hard to say.

---

4. IDR_N_LP, TRAIL, STSA, CRA, RASL - what are these?

---

5. There are no P frames for this encoding mode. Will the resulting video be playable using HW decoders? AFAIK B frames playback requires a lot more processing power.

[adamjw24]

1. POCs do correspond to frames. If there are less POCs than frames, you are seeing a bug and it should be reported. There should be exactly one POC entry for every encoded frame.
2. The frames are not coded in the order (coding order) they are shown (display order), to increase efficiency (e.g. temporal prediction from the future).
3. The bits belong to exactly the POC they are shown for. Its actually very easy to say.
4. NAL unit types. Its high level packaging of VVC and indicates a specific semantics, i.e. IDR_*, CRA indicate a random access point, RASL frames need to be dropped when seeking, TRAIL frames only reference past etc.
5. HW decoders need to be able to decode every VVC compliant bitstreams which holds the level constraints. There are no constraints on the B/P ratio, i.e. all HW decoders will be able to deal with our bitstreams just fine. There is no real advantage to P frames really.