Luca Barbato authored Jun 11, 2019 and Thomas Daede committed Jun 13, 2019

In preparation to the pub cleanup.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

"kb/s" in communication always means 1000 b/s.

We now properly track Show Existing Frame frames, and only add rate
 back to the rate control buffer on TU boundaries.

This logic was buried deep inside
 FrameInvariants::new_inter_frame(), but we will need it elsewhere
 to make guess_frame_subtypes() work.
Separate out the static configuration into InterConfig, and pass in
 the variable state as function parameters.
This patch makes new functions to
- Determine the index of an output frame in its reorder group
- Get the order hint for a given output frame
- Get the pyramid level of an output frame
- Get the reference frame slot where a decoded frame will be stored
- Get whether or not a given output frame will be shown
- Get whether or not a given output frame is a Show Existing Frame
Not yet converted:
- Logic to select the references used by an inter frame

This patch introduces no functional changes.

Instead of using generic terms like "idx" and "number", explicitly
 describe every variable involving frame indices in terms of
 whether it is counting input frames or output frames.
This removes an output-centric bias that may not be obvious in some
 places (group_len vs. group_src_len), and immediately makes
 several bugs in guess_frame_subtypes() obvious.

This patch introduces no functional changes.
It is just renaming.

PUBLIC API CHANGE:
-Packet::number gets renamed

Despite the name, we were passing FrameInvariants to encode_frame()
 as &mut.
There were two places that it actually mutated the contents.
1) In write_sequence_header_obu(), several fields were set to
    constants.
   Given that we write the sequence header multiple times, but its
    contents should never change, the initialization does not
    belong in this function, as that is just asking to violate this
    constraint if we ever make them non-constant.
   Instead just initialize the fields when the rest of the
    FrameInvariant struct is initialized, since the values are
    currently constant anyway.
   We can find a better place than write_sequence_header_obu()
    (one that really is called once per sequence) if we ever want
    to make them non-constant.
2) The ref_frame_sign_bias[] fields are initialized at the very
    start of encode_frame().
   These can instead be initialized in new_inter_frame() as soon as
    ref_frames[i] is set.

With the above two changes we can drop the &mut and ensure that
 FrameInvariants really is invariant.

The remaning field was not updated

Prepares for publishing to crates.io

Fixes #1330

`Muxer` is a trait, and passing dynamic traits without the `dyn` keyword is now deprecated.

Vladimir Kazakov authored Jun 01, 2019 and Thomas Daede committed Jun 03, 2019

https://rust-lang.github.io/rust-clippy/master/index.html#type_complexity

There's no reason to explicitly bind this to the max keyframe interval.
It's useful to, for example, set it larger than 1.5x the keyframe
interval for short intervals (1-3s) to prevent bitrate starvation after
larger than expected (complex) keyframes.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

The build target in `build.rs` is available as environment variable at
runtime, not compile time.

While at it refactor the code to support the future ARM assembly
contributions.

It wasn't supposed to be enabled, and we don't handle it correctly.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

So the cli can exit cleanly on sigterm.

This is a bug fix and aligns to rate-control in Theora and Daala.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

These were derived by analyzing the data collected for the first
iteration and applying a 3-segment piecewise-linear fit.
The boundaries were aligned to integer values of pixels-per-bit,
while optimizing for similarity to a cubic interpolation of the
control points (log-quantizer as a function of log-bitrate.)

Testing against objective-1-fast, these values appear unbiased
within a fifth of a standard deviation prior to trial encodes.
After adjusting scale by trial encode, there is no significant
bias and the standard deviation of initial frame sizes is on the
order of 3%, for all frame types except P-frames.

Ewout ter Hoeven authored May 28, 2019 and Thomas Daede committed May 28, 2019

Updates to the Visual Studio 2019 AppVeyor image, which contains Visual Studio 16.1.

We don't use msbuild so it shouldn't matter that much.

Monty authored May 28, 2019 and Monty Montgomery committed May 28, 2019

Move to unsigend arithmetic in LRF box accumulations, and simply guard
the one subtraction that can underflow (that was the reason we were
using signed ints to begin with).  Fixes an overflow in 12-bit encodes.