[BUG] Weird "bug" with vpx

[TheJ]

Version: 2021.07.30.1


A bit hard to explain but here we go, adaptive quantization is greyed out and you cant set the tile rows/columns in VP9





But if you switch the codec to VP8, then switch to VP9 again. The aq-mode dropdown is opened and the tile options are visible


However, i cannot set the cpu-used count above 2, it just wouldn't let me


full gif if you're not getting what i am saying:

[shijan]

On macOS version things are different.
VP9 use adaptive quantization (no any problem)
VP8 don't have adaptive quantization always disabled.

[Selur]

A bit hard to explain but here we go, adaptive quantization is greyed out and you cant set the tile rows/columns in VP9

Seems to be an issue with the intialization. (happend when I changed that VP9 is the default codec when it exists)
-> fixed in dev version

However, i cannot set the cpu-used count above 2, it just wouldn't let me

This a bit tricky.

The minimal 'CPU utilization modifier' is just restricted by the codec choice:
For VP9 it's -9 (this was -8 at the beginning, also fixed this in the dev version) and for VP8 it's -16.

The maximal 'CPU utilization modifier' depend on:
a. the codec choice (VP8/VP9)
b. the basic speed control (--best/--good/--realtime)
at least according to the code I wrote xy years ago, sadly I forgot to put a reference for it .

if one uses VP8 with 'CPU utilization modifier':

• best: cpu-used is fixed to 0
  
• good: cpu-used max = 5
  
• realtime: cpu-used max = 15
  

and with VP9 those valued get halved, so:

• best: cpu-used is fixed to zero
  
• good: cpu-used max = 2
  
• realtime: cpu-used max = 7
  

best:
This usually gives the best quality output but is extremely slow.
In general this is not a recommended setting unless you have a lot of time on your hands.

good:
This will probably be what most users use most of the time. Within the scope of "good" quality there are 6 further speed steps that are set through the --cpu-used parameter (values from 0 to 5). Setting --good quality and --cpu-used=0 will give quality that is usually very close to and even sometimes better than that obtained with --best but the encoder will typically run about twice as fast. Setting --cpu-used=1 or --cpu-used=2 will give further significant boosts to encode speed, but will start to have a more noticeable impact on quality and may also start to effect the accuracy of the data rate control. Setting a value of 4 or 5 will turn off "rate distortion optimisation" which has a big impact on quality, but also greatly speeds up the encoder.

real time:
Real-time mode allows the encoder to auto adjust the speed vs. quality trade-off in order to try and hit a particular cpu utilisation target. In this mode the --cpu-used parameter controls the %cpu target as follows:
target cpu utilisation = (100*(16-cpu-used)/16)%
Legal values for -cpu-used when combined with --rt mode are (0-15). It is worth nothing that in --rt mode the encode quality will depend on how hard a particular clip or section of a clip is and how fast the encoding machine is. In this mode the results will thus vary from machine to machine and even from run to run depending on what else you are doing.

source: https://www.webmproject.org/docs/encoder-parameters/

So from that, it's correct that Hybrid resticts the cpu-used value to 2.

-> if someone finds some better documentation about it from the vpx developers/team or the exact source code that shows the impact of the basic speed control I'll be happy to adjust the code.

Cu Selur

Ps.: will send you a link to a dev version which should fix the gui glitches in ~30min.

[TheJ]

A bit hard to explain but here we go, adaptive quantization is greyed out and you cant set the tile rows/columns in VP9

Seems to be an issue with the intialization. (happend when I changed that VP9 is the default codec when it exists)
-> fixed in dev version

However, i cannot set the cpu-used count above 2, it just wouldn't let me

This a bit tricky.

The minimal 'CPU utilization modifier' is just restricted by the codec choice:
For VP9 it's -9 (this was -8 at the beginning, also fixed this in the dev version) and for VP8 it's -16.

The maximal 'CPU utilization modifier' depend on:
a. the codec choice (VP8/VP9)
b. the basic speed control (--best/--good/--realtime)
at least according to the code I wrote xy years ago, sadly I forgot to put a reference for it .

if one uses VP8 with 'CPU utilization modifier':

• best: cpu-used is fixed to 0
  
• good: cpu-used max =  5
  
• realtime: cpu-used max =  15
  

and with VP9 those valued get halved, so:

• best: cpu-used is fixed to zero
  
• good: cpu-used max =  2
  
• realtime: cpu-used max =  7
  

best:
This usually gives the best quality output but is extremely slow.
In general this is not a recommended setting unless you have a lot of time on your hands.

good:
This will probably be what most users use most of the time. Within the scope of "good" quality there are 6 further speed steps that are set through the --cpu-used parameter (values from 0 to 5). Setting --good quality and --cpu-used=0 will give quality that is usually very close to and even sometimes better than that obtained with --best but the encoder will typically run about twice as fast. Setting --cpu-used=1 or --cpu-used=2 will give further significant boosts to encode speed, but will start to have a more noticeable impact on quality and may also start to effect the accuracy of the data rate control. Setting a value of 4 or 5 will turn off "rate distortion optimisation" which has a big impact on quality, but also greatly speeds up the encoder.

real time:
Real-time mode allows the encoder to auto adjust the speed vs. quality trade-off in order to try and hit a particular cpu utilisation target. In this mode the --cpu-used parameter controls the %cpu target as follows:
target cpu utilisation = (100*(16-cpu-used)/16)%
Legal values for -cpu-used when combined with --rt mode are (0-15). It is worth nothing that in --rt mode the encode quality will depend on how hard a particular clip or section of a clip is and how fast the encoding machine is. In this mode the results will thus vary from machine to machine and even from run to run depending on what else you are doing.

source: https://www.webmproject.org/docs/encoder-parameters/

So from that, it's correct that Hybrid resticts the cpu-used value to 2.

-> if someone finds some better documentation about it from the vpx developers/team or the exact source code that shows the impact of the basic speed control I'll be happy to adjust the code.

Cu Selur

Ps.: will send you a link to a dev version which should fix the gui glitches in ~30min.

This will probably be what most users use most of the time. Within the scope of "good" quality there are 6 further speed steps that are set through the --cpu-used parameter (values from 0 to 5).

Based on this, why not increase it to 5?

[Selur]

Range of VP9 was half that of vp8 and that was the documentation of vp8 only.