Switch from libvpx-vp9 to ffvp9?

[Leo Wattenberg]

As you probably know by now, ffvp9 outperforms libvpx-vp9 (which is currently used by Chrome) especially because it has good multi-thread support. (libvpx-vp9 has it as well, though it's still slower) [1][2] 

libvpx-vp9 performing poorly is an issue because, for users, it means that Videos in Chrome stutter (ie drop frames), while it works perfectly fine in other browsers/players. This is especially the case for resolutions beyond FullHD. 

YouTube converting more and more videos from codecs that have very mature decoders (AVC) to VP9 doesn't help with that either (though, to be fair, less buffering is probably a higher priority than some framedrops)

I don't have metrics regarding how many users are affected by this, but since I see at least one thread per week in the help forums, I'd say "quite a few". 

In a discussion almost a year ago, Dale Curtis stated that at at that time, there are no plans to switch. [3]

Since then, ffvp9 has improved; VP9 profiles other than 0 are supported and 32bit is optimized as well [4]. Meanwhile, libvpx did get multi-threading, but it doesn't work in Chrome  and is actually slower than it is without [5]

The question is: Should libvpx-vp9 get ditched in favor of ffvp9? 

The "I-only-watch-YouTube-on-desktop"-me says "definitely yes, asap". The "I-can't-code"-me says "maybe the devs have something to object, better ask them" :)

[1] https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/

[2] crbug.com/541473

[3] https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/2Dz5Q5gCTXQ/K8zospxijPoJ

[4] http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/vp9.c;h=d5bdbc7e6c6eaf2ad9fd291e25d1c08eed39e2b9;hb=HEAD

[5] crbug.com/529409

[Chrome Cunningham]

Hi Leo,

FFvp9's performance is great and we've been eager to use it. Sadly, I've found it adds ~1MB to Chrome's binary size. Chrome is already pretty large, so this blocks us, at least for now. 

We could probably get away with something like 200 - 400kb, but after talking to rbultje (who wrote ffvp9) this would be very difficult and sacrifice a great deal of performance. 

It would also be nice to save some space by removing the existing VP9 decoder from libVPX in favor of ffvp9, but this too is difficult because we still need the encoder from libVPX and this code is somewhat tangled with the decoder. 

I've been focusing on some other priorities recently, but we're still open to shipping FFvp9 in the future... we just have to tackle the above. Also, the libVPX team is making some performance improvements recently, so I need to re-profile and see where things stand. 

Chris

[Leo Wattenberg]

Sadly, I've found it adds ~1MB to Chrome's binary size

Is it that significant? I mean, surely, feature creep is something that should be prevented, but arguing over a single megabyte if you're already on a hundred and sacrificing user experience for it isn't worth it IMHO. 

Also, the libVPX team is making some performance improvements recently, so I need to re-profile and see where things stand. 

Well, I certainly can tell you that as of now, even on high-end hardware, 4K60 drops frames while it doesn't in other browsers. But maybe this is just due to an implementation issue in Chrome (ie crbug.com/529409) rather than libvpx' not being able to go faster.

[Elliott Sprehn]

We should definitely fix whatever is making us slower than other browsers. :)

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Alexandre Elias]

On Thu, Jan 7, 2016 at 2:50 PM, Leo Wattenberg <leoxd...@gmail.com> wrote:

Sadly, I've found it adds ~1MB to Chrome's binary size

Is it that significant? I mean, surely, feature creep is something that should be prevented, but arguing over a single megabyte if you're already on a hundred and sacrificing user experience for it isn't worth it IMHO. 

The problem is that for users on pay-per-megabyte data plans or with limited SD card space, disk usage is also an important part of the user experience.  It's also generally hard to find cutpoints like this one that noticeably save binary size since code size tends to just universally creep upwards every release.

--

[Daniel Bratell]

On Thu, 07 Jan 2016 23:50:03 +0100, Leo Wattenberg <leoxd...@gmail.com> wrote:

Sadly, I've found it adds ~1MB to Chrome's binary size

Is it that significant? I mean, surely, feature creep is something that should be prevented, but arguing over a single megabyte if you're already on a hundred and sacrificing user experience for it isn't worth it IMHO. 

Not all versions are that big, but then you also have to remember that video is only one of a multitude of use cases for a browser. If every use case could optimize for performance without regard for resource usage, the end result would be a product where everything is slow because of massive overuse of computer resources (be it CPU cores, RAM, disk, memory I/O, disk I/O, net I/O, ...).

So a balance has to be found where every feature uses a reasonable amount of resources for itself. Video and codecs is already one of the features that make up a large portion of the browser so it's normal to be reluctant to increase that portion if it's possible to find more intelligent ways to accomplish the same goal.

There is an overshadowing goal to reach more users globally, users that have access to much weaker hardware than you and I (judging from the 4K screen. :-) ). Anything that makes that harder really has to be considered carefully.

/Daniel

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Leo Wattenberg]

Users with weaker hardware would benefit from this as it lowers the CPU a VP9 video needs. While it may be 4K for my new machine, it's anything HD for my 2003-ish laptop and potentially "lag free video at all" for even weaker machines. The only thing that would increase is hard drive space, apparently by half a megabyte, and possibly RAM. Now, I don't know which resource is most scarce on all devices, but I'd assume that hard drive space is not at the top. But again, I can only judge by reports I see in the help forums/reddit/twitter, I don't have any insight on UX studies and platform stats.

[Jorrit Visser]

Chrome 56 -> 57 went from 123MB to 126MB on Android. Is using an extra MB (less probably, since you can strip out the decoder in libvpx) going to have such an impact, guys? Almost every site the user visits loads more than that in ads. The user saving one MP3 or big PNG would have more of a storage impact. To give some current perspective on the energy benefits: Safari on macOS has an 'energy impact' of 20-40 when playing YouTube with MP4 codec. Chrome has an 'energy impact' of 70-100 playing the exact same video with VP9 codec.. ~2x-5x more consumption. Obviously getting to Safari level would be near-impossible, but getting closer to it would be amazing. Especially considering MP4 is hardware-accelerated whereas VP9 is (usually) not. And battery & smoothness improvements would be even higher on weaker devices!

Op maandag 11 januari 2016 18:16:32 UTC+1 schreef Daniel Bratell: