vp8enc: better defaults, more presets/profiles

Submitted by Tim Müller @tpm

Link to original bug (#670108)

Description

Just some quick comments on our default values from an e-mail exchange with Ronald:

mode : Mode
Enum "GstVP8EncMode" Default: 0, "vbr"
(0): vbr - Variable Bit Rate (VBR) mode
(1): cbr - Constant Bit Rate (CBR) mode

You may want to look into CQ mode (2) also.

max-keyframe-distance: Maximum distance between key frames
Integer. Range: 0 - 9999 Default: 60

60 is quite low (for high-quality encodes), any particular reason for that?

I think in our tests and on webmproject.org, we recommend 120 frames
as kf interval.

multipass-mode : Multipass encode mode
Enum "GstVP8EncMultipassMode" Default: 0, "one-pass"
(0): one-pass - One pass encoding (default)
(1): first-pass - First pass of multipass encoding
(2): last-pass - Last pass of multipass encoding

Can the default be changes to 2pass? We really do all our internal
testing for high-quality encodes on 2pass, it'll generate much better
output (in the range of >1dB difference).

(tpm: can't ever default to 2-pass, since that requires co-operation by the application. 2-pass can only ever be opt-in)

auto-alt-ref-frames : Automatically create alternative
reference frames
Boolean. Default: false

This isn't a good idea, alt-refs by themselves will also cause several
tenths of dB difference (in a positive way), I'd highly recommend you
turn them on for high-quality (2pass) encodes.

(tpm: only for high-quality 2-pass encodes? BBB: yes)

lag-in-frames : If set, this value allows the encoder to consume
a number of input frames before producing output frames.
Unsigned Integer. Range: 0 - 64 Default: 0

Probably want to up this to e.g. 25 for high-quality encodes (unless 0
means 'don't touch').

(tpm: I think 0 means whatever the library default is, someone needs to check this)

tune : Tune
Enum "GstVP8EncTune" Default: 0, "psnr"
(0): psnr - Tune for PSNR
(1): ssim - Tune for SSIM

Minor nit, most people would claim ssim is a better default here, but
it's not that relevant.

I see you haven't mapped the ARNR options, which provide a quality
boost for noisy input (without affecting noiseless input much), are
you guys interested in exposing these options also? They affect the
way the alt-ref frame is used.

(tpm: might be good for input from webcams - though what would be even better if we could detect that kind of input and switch to that mode automatically)

Other possibly interesting pages:
http://www.webmproject.org/tools/encoder-parameters/