All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=650028

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg-Y2xhQkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICghavdsQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg-Z_xvwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICghd2XjwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICghanroQkM


Bot(s) for this bug's original alert(s):

linux
mac
win

johannkoenig: Your change appears to have regressed sizes.
https://chromium.googlesource.com/chromium/src/+/8d5b2859f6245d3e84a53e985de4b8a9f64afc9d

The change adds support for high bit depth vp9 streams

WAI, although it would be nice if it was smaller...

cc kerz: binary size regression necessary for high bit depth vp9 stream

This looks like 200k. That's expected? That seems pretty huge.

Yes, it is expected.

A good chunk of that is in the highbit encoder, which we don't use as far as I know, but it's a significant amount of work to support highbit in the decoder only. Johann should know more.

It duplicates a lot of functions. In the worst case, we go from one function to 4:
- standard 8 bit input with standard precision and clipping
- 8 bit input but higher internal precision which prevents clipping in the intermediate state but still returns to 8 bits for output
- 10 bit input/calculations/output
- 12 bit input/calculations/output

So unfortunately, yes this is expected.

Although some it is from the encoder, the encoder and decoder share a lot of code. Isolating and removing the encoder pieces would save some size. We are discussing it but it doesn't look likely to happen because it doesn't save much.

I did a really ugly hack a while back which managed to get the encoder compiling without highbit support. (Not sure if it worked though..) In my experiment, libvpx grew by 500kB with both encoder and decoder highbit, but only by 76kB when I only had highbit support in the decoder.

My hack could be all wrong and was certainly ugly, but I'd be surprised if we didn't save at least half of the 200kB if we had highbit support only in the decoder. However, as I stated earlier; It is a fair amount of work to do so.
(Unless we can figure out some way to compile and link libvpx twice maybe..)

My first go-to for getting space back would be removing ffvp8 ...

I'm curious if there are stats on how often it is used and on which processors. WebRTC is a big user of vp8, but only via libvpx. I don't know if YT serves vp8 to Chrome. My guess would be vp9, maybe h.264.

Not going to make any changes for this.