As I wrote at the end of the previous post, the second pass may fail with “Application provided invalid, non monotonically increasing dts to muxer in stream 0″ when
auto-alt-ref=1 is used. The VP8 Parameter Guide now tells me that
lag-in-frames depends on
auto-alt-ref being enabled. Specifying
lag-in-frames when using 2 passes therefore apparently won’t do any good (not as long as avconv chokes on
auto-alt-ref is (“currently”) only available in 2 pass mode, so it’s a catch-22.
arnr-* parameters are an alternative reference frame construction kit (alternative for
auto-alt-ref can, according to the guide, “substantially improve quality in many situations (though there are still a few where it may hurt)” whereas
arnr-* filtering is considered experimental and is disabled by default. Additionally,
arnr-type is unsupported. All libvpx preset files provided with avconv currently have
deadline parameter’s options
realtime apparently translate to quality at the cost of speed, with “best” being “best quality, slowest to encode” and “not a recommended setting unless you have a lot of time on your hands.” The “good” option can be further tweaked with the
cpu-used option: with
cpu-used=0, quality will be “very close to and even sometimes better than” with
deadline=best, but typically twice as fast. Bigger values of
cpu-used (1-5) each translate to more encoding speed than the previous, but with equally noticeable impact on quality.
slices, the ffmpeg wiki recommends “1 for small images, 4 or 8 for HD“. The aforementioned presets have 4 for 720p and 1080p, and no setting (probably meaning
slices=1) for 360p.
For non-zero values of
profile, the encoder increasingly optimizes low powered devices at the expense of quality.