On Tue, May 24, 2016 at 10:21 AM, Pine W <wiki.pine(a)gmail.com> wrote:
In addition to automated bitrate adjustments, can
there be a way for users
to manually adjust their bitrates or quality settings on the fly without
changing resolutions or file formats?
Probably not; if I understand you correctly you would like to be able, as
an end-user watching a video, to switch from "480p Ogg Theora at 2 Mbps" to
"480p Ogg Theora at 3 Mbps" etc? That would require pre-generating, and
storing, some arbitrarily large number of copies of the file at different
bitrates/quality settings for very little expected benefit.
It makes a lot more sense to me to encode at a bitrate/quality setting that
results in reasonable quality for each resolution; then if you need to
change bitrates due to network limitations, you bump up or down a notch on
the resolution list. This also avoids extra blocky artifacts from having a
too-low-bitrate at a high resolution, etc.
Not meaning to be ungrateful, but I think that
improving HD video playback
in IE and Safari should take precedence as a priority. I tried watching one
of Victor's HD WEBM fundraising videos on a 4K display in Safari, and my
user experience went from amazing to awful as soon as playback started in
low-def OGV.
There are several questions kind of stuck together there, let me tease them
apart and answer them each:
* The source file's format is not related to resolution or quality of the
source -- we have beautiful 1080p HD videos with high bitrate OGV sources,
and 240p quarter-SD videos with crappy, artifact-laden low-bitrate WebM VP9
sources.
* Visual quality is not determined by format alone, but by a combination of
format, bitrate, quality settings, and the particular input data. When
rendered at the same resolution at *appropriate* bitrates/quality settings,
WebM and OGV will look about the same... OGV will tend to degrade a bit
more in high-motion scenes, but if the base quality is good that's usually
a modest effect.
* WebM is not currently used for the ogv.js fallback player in
Safari/IE/Edge because it's several times slower to decode than OGV at the
same resolution, and still a lot buggier (though you'll be happy to hear
I've fixed several major bugs recently!) If we switched to using WebM for
ogv.js, you *would not* get HD because it's too slow to decode HD WebM in
ogv.js.
* OGV transcodes are currently only made up to 480p (standard def); we do
not currently produce 720p or 1080p high-def transcodes in OGV. This means
in Safari you won't get high-def playback even if your computer could
handle it (and if it's a current-ish Mac or a recent model iPad, it can
probably handle OGV at 720p or 1080p at a modest 24fps or 30fps).
* Bitrate & quality settings -- many of our OGV transcodes at 480p and 360p
are still older versions from when a too-low bitrate was used, leading to
*very* poor appearance. You can determine this by going to the File: page
on Commons and checking the transcode list at the bottom; if it says
something around 1 Mbits for 480p or 500 kbits for 360p, it's an old file
and not representative of current settings. It should say around 2 Mbits
for 480p, 1 Mbit for 360p, 500 kbits for 240p.
* Sometimes the automatic resolution downgrade for slow computers in the
ogv.js/TimedMediaHandler integration picks a super-low 160p resolution
version when it should not have, which looks pretty bad.
So -- what am I doing to improve it, you ask? :)
Here's what: the general disk space / bandwidth savings from using variable
bitrate encodings make it less scary-sounding to enable 720p (and _maybe_
1080p) HD OGV transcodes, which will enable high-def playback in Safari and
Edge. (And maybe IE 11 on a fast machine, but IE is less than half the
speed of Edge or Safari at decoding.) These will still be bigger than the
WebM versions because Theora needs a higher data rate than VP8 to maintain
quality, but the WebMs and the other OGVs will be smaller than they used to
be at fixed bitrates, so it's less of a burden.
I know you really want HD WebM in Safari, but that's not possible until
*huge* performance gains can be realized in the decoder... or Apple gives
in and adds WebM support to their operating system. Don't hold your breath
on waiting for Apple; their ways are mysterious.
Don't hold your breath on huge performance gains either; I'm investigating
avenues for improvement (see
https://brionv.com/log/2016/05/19/peeking-into-vp8-video-decoding-performan…
&
https://brionv.com/log/2016/05/20/vp8-parallelization-continued/ for
details) but overlapping macroblocks on CPU threads will probably give less
than a 50% improvement, and I have literally no idea what kind of
performance to expect from pushing more work to the GPU (and it sounds like
a LOT of work, could take months/years of poking at it).
-- brion