Hi Brion,

I think that 1080p HD OGV transcodes would be a big improvement for both Safari and Edge. I'd love to see that happen, preferably before 2Q 2016-2017.

Pine

On May 24, 2016 11:09, "Brion Vibber" <bvibber@wikimedia.org> wrote:

On Tue, May 24, 2016 at 10:21 AM, Pine W <wiki.pine@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-performance/ & 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

_______________________________________________
Multimedia mailing list
Multimedia@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia

_______________________________________________
Multimedia mailing list
Multimedia@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia