Last modified: 2014-07-23 18:43:33 UTC
Currently we use a fixed bitrate for webm (and ogg for that matter) transcodes except for webm 720p where we use a variable bit rate( -qmin 18 -qmax 18). I just noticed there are some files, such as [[File:Hindesite_-_Lily_-_Focus_Stacking_(by).ogv]], where the 720p webm transcode is smaller (2733005 bytes) than the 360p webm transcode (2769705 bytes). This seems wrong. (Note, this is probably specific to the lily file which has a lot of still frames) I don't know what original considerations went into using a fixed bitrate, but maybe we should just be specifying a quality level instead. In my test of the lily file, using a quality level of 18 (like the current 720p setting) for the 480p version gave a file size of 1.5mb, compared to the current 480p settings of -qmin 1 -qmax 51 -vb '1024000' which gives a file size of 5.3mb.
I believe the original idea was that 160p, 360p, and 480p transcodes were meant for online streaming viewing and 720p was meant for offline downloading, so the 160/360/480 have fixed nitrates designed around tiers of network speed... while the 720 has a quality setting and so is variable bitrate -- making it indeed potentially a LOT smaller on a video like this that has a low rate of visual change entropy. Can we make the bitrate setting a _maximum_ bitrate on VBR encoding or something, rather than a fixed bitrate?
nitrates -> bitrates *damn you autocorrect*
