In the past, we've had a mixture of fixed bitrates and quality-based
settings for producing video transcodes.
Each has its advantages: fixed bitrates are more predictable for watching
while streaming, while fixed quality settings allow for reducing the
bitrate on low-complexity scenes to save bandwidth (and increasing it on
high-complexity scenes to keep quality up!)
Since "download and watch it later" is less of a thing on today's internet
than "stream it right now!", I'd been leaning for a while towards moving
more things to fixed bitrates. However, I'm starting to come down on the
side of a fixed quality setting with a variable bitrate...
Overall variable rate encoding should lead to lower bandwidth usage for
most parts of most files, while still maintaining high quality on scenes
that need it.
The downside is that a high-complexity scene encoded at a higher bitrate
might cause buffering to run out during playback that had been working ok
on earlier scenes at a lower bitrate.
Once we support adaptive streaming (using MPEG-DASH, or something like it)
the system should be able to provide a detailed enough manifest[1] to show
which segments of the file are low-bandwidth and which are high-bandwidth,
so if there's a bandwidth limitation that stops us from viewing one
particular segment at the current resolution, we can bump down and then
bump resolution back up again when the bandwidth usage goes down.
If there's no strong objection, I'm going to tinker with the quality
settings for WebM and Ogg Theora video transcodes to try to find quality
settings I'm happy with that result in reasonable bandwidth averages.
[1] An MPEG-DASH manifest (.mpd) specifies a target bitrate on each
resolution representation, but the actual segments can be different sizes.
When they're specified as byte ranges of a source file, the exact segment
size is conveniently available!
-- brion