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=1). Additionally, auto-alt-ref is (“currently”) only available in 2 pass mode, so it’s a catch-22.
The arnr-* parameters are an alternative reference frame construction kit (alternative for auto-alt-ref + lag-in-frames), but 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 arnr-maxframes=7, arnr-strength=5 and arnr-type=centered.
The deadline parameter’s options best, good and 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.
For 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.