| Age | Commit message (Collapse) | Author |
|---|
|
Added a new flag in rate control which turns off gf interval constrain
on key frame frequency for external RC.
It remains on for libvpx.
Change-Id: I18bb0d8247a421193f023619f906d0362b873b31
|
|
Change-Id: I3d2565572c2b905966d60bcaa6e5e6f057b1bd51
|
|
This reduces some regression when external RC
is used, for which avg_frame_low_motion is not
set/updated (=0).
Change-Id: I2408e62bd97592e892cefa0f183357c641aa5eea
|
|
Change-Id: I5c42013a08677cdef8d47f348458118338ff0138
|
|
This refactoring is needed to allow the
RC_rtc library to support VBR.
Change-Id: I863a4a65096fed06b02307098febf7976360e0f3
|
|
Bug: webm:1731
Change-Id: I1db777c0c3a8784fb3dcf7cd39f78ebf833ab915
|
|
Two pass rc parameters are only initialized in the second pass
in vp9 normal two pass encoding.
However, the simple_encode API queries the keyframe group, arf group,
and number of coding frames without going throught the two pass
route.
Since recent libvpx rc changes, parameters in the TWO_PASS
struct have a great influence on the determination of the above
information.
We therefore need to properly init two pass rc parameters in
the simple_encode related environment.
Change-Id: Ie14b86d6e7ebf171b638d2da24a7fdcf5a15c3d9
|
|
Properly init and delete cpi struct in simple encode functions.
Change-Id: I6e66bcac852cbb3dec9b754ba3fb01a348ac98b8
|
|
this reduces the number of instructions to compute the sum
Change-Id: Icae4d4fb3e343d5b6e5a095c60ac6d171b3e7d54
|
|
Change clamp to an assert so we are warned if changes to input
ranges or defaults in the future lead to an invalid value.
Change-Id: Idb4e0729f477a519bfff3083cdce3891e2fc6faa
|
|
Imposed provisional upper and lower limits to each parameter
that can be adjusted in the Vizier ML experiment.
Also in some cases applied secondary limits on on the
range of the final "used" values.
Defaults and limits may well require further tuning after
subsequent rounds of experimentation.
Re-factor get_sr_decay_rate().
Change-Id: I28e804ce3d3710f30cd51a203348e4ab23ef06c0
|
|
Further changes to normalize the Vizier command line parameters.
The intent is that the default behavior for any given parameter
is signaled by the value 1.0 (expressed on the command line as a
rational).
The final values used in the two pass code are obtained by multiplying
the passed in factors by a default values if use_vizier_rc_params is 1.
Where use_vizier_rc_params is 0 the values are explicitly set to
the defaults.
This patch also changes the default value of each parameter to 1.0
even if not set explicitly. This should ensure safe /default behavior
if the user sets use_vizier_rc_params to 1 but does not set all the
the individual parameters.
Change-Id: Ied08b3c22df18f42f446a4cc9363473cad097f69
|
|
Add command line options for three rd parameters.
They are controlled by --use_vizier_rc_params, together with
other rc parameters.
If not set from command line, current default values will be used.
Change-Id: Ie1b9a98a50326551cc1d5940c4b637cb01a61aa0
|
|
|
|
If pass --use-vizier-rc-params=1, the rc parameters are overwittern
by pass in values. It --use-vizier-rc-params=0, the rc parameters
remain the default values.
Change-Id: I7a3e806e0918f49e8970997379a6e99af6bb7cac
|
|
|
|
Deleted #define that is no longer referenced.
Change-Id: If0b132c5a40dd8910f535fffdee7d2d1c7df4748
|
|
|
|
|
|
Recently, some function signatures have been changed.
This change fixes compilation error if --enable-rate-ctrl is used.
Change-Id: Ib8e9cb5e181ba1d4a6969883e377f3dd93e9289a
|
|
Changes the exposed zm_factor parameter.
This patch alters the meaning of the zm_factor
parameter that will be exposed for the Vizier project.
The previous power factor was hard to interpret in terms
of its meaning and effect and has been replaced by a linear factor.
Given that the initial Vizier results suggested a lower zero motion
effect for all formats, the default impact has been reduced.
The patch as it stands gives a modest improvement for PSNR
but is slightly down on some sets for SSIM
(overall psnr, ssim % bdrate change: -ve is better)
lowres -0.111, 0.001
ugc360p -0.282, -0.068
midres2 -0.183, 0.059
hdres2 -0.042, 0.172
Change-Id: Id6566433ceed8470d5fad1f30282daed56de385d
|
|
Delete some #defines that are no longer needed.
Change-Id: I9e4e4df10716598b0d62b0c70f538d4b78a32296
|
|
This is similar to the change:
https://chromium-review.googlesource.com/c/webm/libvpx/+/2771081
Which fails libvpx nightly test.
Here we add range check to get rid of the warning of
"divided by zero".
BUG=webm:1723
Change-Id: I7712efe7abd4b11cdb725643d51fd1c0a300d924
|
|
This reverts commit f32829a2e5db3cd1624e8a7a530af84c382762ef.
BUG=webm:1723
Change-Id: I866cdf288f9873c350b32091515a6d5f4df362a3
|
|
|
|
|
|
Change the way the rd multiplier is adjusted for Q and frame type.
Previously in VP9 the rd multiplier was adjusted based on crude Q bins
and whether the frame was a key frame or inter frame.
The Q bins create some problems as they potentially introduce
discontinuities in the RD curve. For example, rate rising with a
stepwise increase in Q instead of falling. As such, in AV1 they
have been removed.
A further issue was identified when examining the first round of
results from from the Vizier project. Here the multiplier for each Q bin
and each frame type was optimized for a training set, for various video
formats, using single point encodes at the appropriate YT rates.
These initial results appeared to show a trend for increased rd
multiplier at higher Q for key frames. This fits with intuition as in
this encoding context a higher Q indicates that a clip is harder to
encode and frames less well predicted. However, the situation
appeared to reverse for inter frames with higher rd multipliers
chosen at low Q.
My initial suspicion was that this was a result of over fitting, but on
closer analysis I realized that this may be more related to frame type
within the broader inter frame classification. Specifically frames coded
at low Q are predominantly ARF frames, for the mid Q bin there will
likely be a mix of ARF and normal inter frames, and for the high Q bin
the frames will almost exclusively be normal inter frames from difficult
content.
ARF frames are inherently less well predicted than other inter frames
being further apart and not having access to as many prediction modes.
We also know from previous work that ARF frames have a higher
incidence of INTRA coding and may well behave more like key frames
in this context.
This patch replaces the bin based approach with a linear function
that applies a small but smooth Q based adjustment. It also splits
ARF frames and normal inter frames into separate categories.
With this done number of parameters that will be exposed for the
next round of Vizier training is reduced from 7 to 3 (one adjustment
factor each for inter, ARF and key frames)
This patch gives net BDATE gains for our test sets even with the
baseline / default factors as follows: (% BDRATE change in overall
PSNR and SSIM, -ve is better)
LowRes -0.231, -0.050
ugc360p 0.160, -0.315
midres2 -0.348, -1.170
hdres2 -0.407, -0.691
Change-Id: I46dd2fea77b1c2849c122f10fd0df74bbd3fcc7f
|
|
Change-Id: I02eabeccf2fe4604875820d38e23c2586a63e290
|
|
These rate control parameters are for the Vizier experiment.
They are defined as rational numbers.
Change-Id: I23f382dd49158db463b75b5ad8a82d8e0d536308
|
|
This patch converts the Vizier custom RD multipliers, to factors
that adjust each RD multiplier either side of its default value, where
a factor of 1.0 will give the previous default behavior.
Ultimately I would like to replace the multiple RD multipliers
triggered at different Q thresholds (eg, low, medium, high q)
with a function that adjusts the rd behavior smoothly as Q
changes.
Vizier could then be presented with a single adjustment control
for each of key frame and inter frame rd.
The current behavior is problematic.
Firstly having hard threshold Q values at which rd behavior changes
may cause anomalies in the rate distortion curve, where in some
situations, raising Q, for example, may not cause the expected drop
in rate and rise in distortion, because we have crossed a threshold
where the rate distortion multiplier changes sharply and this alters
the balance of bits spent in the prediction and residual parts of the
signal.
Having a single value that is used for a range of Q index values
(eg 0-64), (65-128) may also cause problems and over-fitting in
the context of the Vizier ML project. This project tries to optimize
the values for each Q range, for various YT formats, but does so
by analyzing the results of single point encodes on a set of clips.
For a given format all the clips are encoded with the same parameters
(target rate etc) so there is likely to be clustering in regards to the
Q values used. For example the training set may give a new value
for the Q range 0-64 but most of the data points used may have Q
close 64.
It will likely require several iterations working with the Vizier team
to get this right. This patch just gives an initial framework for
testing.
Change-Id: Iaa4cd5561b95a202bcae7a1d876c4f40ef444fa2
|
|
This patch changes the way prediction decay is calculated.
We expect that frames that are further from an ALT-REF frame (or Golden
Frame) will be less well predicted by that ALT-REF frame. As such it is
desirable that they should contribute less to the boost calculation used
to assign bits to the ALT_REF.
This code looks at the reduction in prediction quality between the last
frame and the second reference frame (usually two frames old). We make
the assumption that we can accumulate this to get a proxy for the likely
loss of prediction quality over multiple frames.
Previously the calculation looked at the absolute difference in the
coded errors. The issue here is that the meaning of a unit difference
is not the same for very complex frames as it is for easy frames.
In this patch we scale the decay value based on how the error difference
compares to the overall frame complexity as represented by the intra
coding error.
This was tuned experimentally to give test results that
were approximately neutral for our various test sets. There was
a slight drop in Overall PSNR but a consistent improvement in
SSIM. This balance may be improved with tuning further as it is
noteworthy that it was much better on the hd_res set.
Results (Overall PSNR, SSIM -ve better) for low_res, ugc360, midres2,
ugc480P and hd_res are as follows:
0.173 -0.688
0.118 -0.153
0.132 -0.239
0.261 -0.405
-0.305 -1.109
As part of this adjustment the contribution of motion amplitude was
removed.
This patch also changes the control mechanism that will be exposed
on the command line for use by the Vizier project. The control is now
a linear factor which defaults to 1.0, where values < 1.0 mean a lower
decay rate and values > 1.0 mean an increased decay rate.
This presents a more easily understandable interface for use in
optimizing the decay behavior for various formats, where it is clear
what a passed in value means relative to the default.
With the new decay mechanism the current values for various formats
are almost certainly wrong and we still need to define sensible upper
and lower bounds for use during future training.
Change-Id: Ib1074bbea97c725cdbf25772ee8ed66831461ce3
|
|
Added the experimental max per frame KF boost values derived from
the Vizier experiments.
These are still all off by default.
When enabled I expect these to cause significant regression as they
fluctuate wildly and in a way that makes no sense from format to format.
I suspect these values reflect over fitting perhaps from a subset of
training clips with more frequent mid chunk key frames and or short key
frame groups.
Also fixed incorrect value for gf boost for one format.
Experiment to moderate these values and use different values for first
and subsequent KF groups to follow.
Change-Id: Ibeb4268957f2edacdb4549d74930255a22a2fcc5
|
|
Added kf_frame_min_boost field to hold the minimum per frame
boost in key frame boost calculations. Replaces hard wired value.
To be used in conjunction with and tied to the maximum value.
Change-Id: I67a39ecb3f21b5918512a5ccd9a1b214d7971e45
|
|
|
|
|
|
Previous code did not have sensible defaults for larger image formats.
Added defaults for Vizier RD parameters for sizes > 1080P and changed
the first pass parameters for large formats to use the 1080P values.
No supplied value for rd_mult_q_sq_key_high_qp case yet so set to
old hard wired default value.
If the Vizier parameters were enabled the lack of sensible defaults
caused a large regression for 2K clips in one of our test sets.
Change-Id: I306c0cd76eab00d50880c91fadb5842faf6661ff
|
|
Change-Id: Ib926e694d4bc4675af1435a32f6316a587756380
|
|
Further integration of Vizier adjustable parameters,
This patch connects up additional configurable two pass rate control
parameters for the Vizier project. This still needs to be connected up
to a command line interface and at the moment should still be using
default values that match previous behavior.
Do not submit until verified that defaults are all working correctly.
Change-Id: If1241c2dba6759395e6efa349c4659a0c345361d
|
|
This patch adds fields into the RC data structure for the Vizier.
The added fields allow control of some extra rate control parameters
and rate distortion.
This patch also adds functions to initialize the various parameters
though many are not yet used / wired in and for now all are set to
default values. Ultimately many will be set through new command
line options.
Change-Id: I41591bb627d3837d2104fb363845adedbddf2e02
|
|
Change-Id: I8635f6121e13089c25e201df033d5bc68e2862b4
|
|
The flag update_pattern_ was being set to 0
(because it was set before reset) instead of 1.
And the example flexible mode pattern was not setting
non-reference frame on top temporal top spatial.
Change-Id: I8aee56ce13cc4e0d614126592f9d0f691fe527b0
|
|
And allow the frame to recode when the frame size is larger
than the input max frame size.
If the max frame size is not specified, let vp9 decide whether
to recode. The recode follows the vp9's current recoding mechanism.
The rate control api will return the new qindex back to the
external model.
Change-Id: I796fbf713ad50a5b413b0e2501583b565ed2343f
|
|
|
|
Change-Id: I4a9402f468e54c58081c882ed37f59ee0269c0fc
|
|
|
|
Bug: b/154890543
Change-Id: Iad5791912f781d225e610a61bc13f3dbaef81bb9
|
|
Bug: webm:1716
Change-Id: Ic60c367aabfc03d94816e85476895b988aced5f1
|
|
Bug: webm:1716
Change-Id: I204cd3ab35b493759808500b799da3b9e55686d4
|
|
Bug: webm:1716
Change-Id: Ib016ab5a49c765971366cc8d2b75bcca3ed5bd0f
|
|
Bug: webm:1716
Change-Id: Ie6d63a68539369c51fefefa528e299b00a967e29
|
