Changelog:
2019-01-31 v1.8.0 "Northern Shoveler Duck"
This release focused on encoding performance for realtime and VOD use cases.

• Upgrading:
  This adds and improves several vp9 controls. Most are related to SVC:
  VP9E_SET_SVC_FRAME_DROP_LAYER:
  - Frame dropping in SVC.
  VP9E_SET_SVC_INTER_LAYER_PRED:
  - Inter-layer prediction in SVC.
  VP9E_SET_SVC_GF_TEMPORAL_REF:
  - Enable long term temporal reference in SVC.
  VP9E_SET_SVC_REF_FRAME_CONFIG/VP9E_GET_SVC_REF_FRAME_CONFIG:
  - Extend and improve this control for better flexibility in setting SVC
  pattern dynamically.
  VP9E_SET_POSTENCODE_DROP:
  - Allow for post-encode frame dropping (applies to non-SVC too).
  VP9E_SET_SVC_SPATIAL_LAYER_SYNC:
  - Enable spatial layer sync frames.
  VP9E_SET_SVC_LAYER_ID:
  - Extend api to specify temporal id for each spatial layers.
  VP9E_SET_ROI_MAP:
  - Extend Region of Interest functionality to VP9.

• Enhancements:
  2 pass vp9 encoding has improved substantially. When using --auto-alt-ref=6,
  we see approximately 8% for VBR and 10% for CQ. When using --auto-alt-ref=1,
  the gains are approximately 4% for VBR and 5% for CQ.

  For real-time encoding, speed 7 has improved by ~5-10%. Encodes targeted at
  screen sharing have improved when the content changes significantly (slide
  sharing) or scrolls. There is a new speed 9 setting for mobile devices which
  is about 10-20% faster than speed 8.

• Bug fixes:
  VP9 denoiser issue.
  VP9 partition issue for 1080p.
  VP9 rate control improvments.
  Postprocessing Multi Frame Quality Enhancement (MFQE) issue.
  VP8 multithread decoder issues.
  A variety of fuzzing issues.

Changelog source:
https://chromium.googlesource.com/webm/libvpx/+/v1.8.0

x86_64 Windows 7

Probably broader.

Last week's https://svnweb.freebsd.org/ports?view=revision&revision=492305 included Makefile modifications for www/firefox www/firefox-esr and more on (Tier-3) FreeBSD.

I imagine that other platforms may be similarly affected by this bug.

This also removes some local patches that are no longer necessary and
the associated #define from VPXDecoder.h.

Depends on D19846

Depends on D19847

Depends on D19848

I've posted the WIP in progress here. Unfortunately, updating the library requires changes to vp9_impl.cc in libwebrtc. Commit be71a1ee08c9ee56ba0f92955ea946556ae6593e from May 17 2018 removes the problematic function, but it does not apply cleanly. We would need to take other commits as well.

I discussed this with :drno, and in the absence of an urgent need to do the update it seems safer and easier to do this as part of an update of the webrtc.org code itself. Since we don't yet have a plan as to when we'll do the next webrtc.org update, we might end up revisiting this decision.

Changelog:
2019-07-15 v1.8.1 "Orpington Duck"
This release collects incremental improvements to many aspects of the library.

• Upgrading:
  VP8E_SET_CPUUSED now accepts values up to 9 for vp9.
  VPX_CTRL_VP9E_SET_MAX_INTER_BITRATE_PCT had a spelling fix (was VP8E).
  The --sdk-path option has been removed. If you were using it to build for
  Android please read build/make/Android.mk for alternatives.
  All PPC optimizations have been disabled:
  https://bugs.chromium.org/p/webm/issues/detail?id=1522.

• Enhancements:
  Various changes to improve encoder rate control, quality and speed
  for practically every use case.

• Bug fixes:
  vp9-rtc: Fix color artifacts for speed >= 8.

Unassigning myself for now, I may end up picking this up again later.

Do we even need now libvpx while we have for some time ffvp?

It is still used for WebRTC, and I don't think that is something that we would change any time soon as the dependency is in third party webrtc.org code.

Having had a closer look at upstream commit be71a1ee08c9ee56ba0f92955ea946556ae6593e, it disables flexibleMode for VP9 screensharing. It stayed disabled until commit 76be29555d50f5ec9b5bba1f14588e940e81fd4d which landed three months later. I'm planning to disable flexibleMode in our copy of webrtc.org until the next time we do a webrtc.org update, as it is not practical to cherry pick all of the VP9 screensharing fixes that landed in that time period.

Try run here: https://treeherder.mozilla.org/#/jobs?repo=try&selectedJob=290234111&revision=4027891d80033f0744248065a8890099a97e48be.
The failures all seem to be infra related and I think we have enough coverage on similar platforms.

This makes the following changes:

• Change update.py to use Python 3.
• Have update.py remove some unused portions of the upstream library.
• Update local patches to apply against libvpx 1.8.2.
• Remove local patches that are no longer necessary.
• Update vs build configurations in generate_sources_mozbuild.sh.
• Remove the #define for stdint from VPXDecoder.h.
• Disable AVX512 support
• Make sure float_control_word.asm is included in win64 builds

Depends on D63919

Depends on D63922

Updating to libvpx 1.8.2 removes one of the structures used for configuring
flexibleMode in the webrtc.org vp9 encoder code. Upstream commit
be71a1ee08c9ee56ba0f92955ea946556ae6593e removes the broken code and at the
same time disables flexibleMode. It remained disabled until commit
76be29555d50f5ec9b5bba1f14588e940e81fd4d landed, three months later. During
that time, a large number of VP9 screensharing fixes were made. It is not
practical to cherrypick all of those changes, so this commit disables
flexibleMode pending the next upstream webrtc.org merge.

This is a partial cherry pick of be71a1ee08c9ee56ba0f92955ea946556ae6593e.

Depends on D63924

media/libvpx/disable_avx512.patch should not be necessary because the script passes --disable-avx512:
https://dxr.mozilla.org/mozilla-central/source/media/libvpx/generate_sources_mozbuild.sh#200

media/libvpx/aarch64-windows.patch should not be necessary. A target for windows arm64 builds was added:
https://chromium.googlesource.com/webm/libvpx/+/refs/heads/master/configure#104

My apologies - in generate_sources_mozbuild.sh DISABLE_AVX would need to be set to "--disable-avx512". Then the patch could be removed.

(In reply to johannkoenig from comment #19)

My apologies - in generate_sources_mozbuild.sh DISABLE_AVX would need to be set to "--disable-avx512". Then the patch could be removed.

Thank you for pointing this out. I've removed this and the aarch64 patch.

https://hg.mozilla.org/mozilla-central/rev/6d2821c6e36e
https://hg.mozilla.org/mozilla-central/rev/4068c946ff54
https://hg.mozilla.org/mozilla-central/rev/903ac3286eed
https://hg.mozilla.org/mozilla-central/rev/abde714b3e66

I'm confirming that bug is fixed, starting in Mozilla Firefox Nightly 75.0a1 (2020-02-29), so I'm marking this bug as VERIFIED.
Thank you very much! \o/