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