[Webkit-unassigned] [Bug 197358] [MSE][GStreamer] Volume level sometimes changes inappropriately

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=197358

Charlie Turner <cturner at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cturner at igalia.com

--- Comment #9 from Charlie Turner <cturner at igalia.com> ---
I am not convinced this is specific to MSE. I believe it may be due to inconsistent application of cubic scaling in our volume code.

There are three places volume is handled here
  1) In the MediaPlayer class, this takes whatever the JS app tells us is the volume. The scaling function is unspecified, so it's stored absolute (i.e., linearly).
  2) In the assigned GstStreamVolume element, in our case a playbin. Here we are inconsistently using a cubic scale.
  3) In the PA server, which uses cubic scaling anyway for software volumes, and for hardware volumes/pass-through I don't understand what it does, but it seems like the scaling function may again be undefined.

On a new video load, we would set the GstStreamVolume element (in our case the playbin) using a raw value from the MediaPlayer (unscaled).
Any volume changes (which can happen in myriad ways, sometimes depending on network conditions and/or ads playing) would cause a volume change and an inverse cubic evaluation (i.e., v^3 where v in [0..1]), causing the volume to jump down to something unexpected. This can also jump up when volumes are set in the wrong order, in this case it would be v^1/3, causing v to jump upwards in this range.

With YouTube, some of the ways this can happen are,
  1) When you are in autoplay and change the volume, that volume will be remembered (sometimes). After you set it, it will be stored as the cubic interpolation, but when the new video loads, it will be stored linearly (jumping audio)
  2) Sometimes the JS media players set a seemingly random starting volume, maybe based off some kind of perceived loudness? Anyway, we have the same problem here as 1, this is set linearly, and it can be bounced by things like point 3)
   3) When ads play, or when network conditions change, we get resolution changes. Playsink in GStreamer has a condition variable which fires whenever a new audio chain is generated which can happen when caps change like this (and for a couple other reasons that I won't explain further). When this happens, we again hit the cubic/linear bug, but at times which are non-deterministic. This explains most user reports I've seen.

I'm in the unfortunate position that on 2.24.3, I can't reproduce the volume changing randomly during playback. I could trigger some strange things by manually switching resolutions and faffing with PA controls and seeing how subsequent resolution changes and/or ads playing affected the volume.

I will post a speculative patch and ask that affected users try and let me know if it helps. I was developed on 2.24.3 and ported to current trunk.

One unresolved issue I have noticed is that the settings of the PA controls do not reflect into the YouTube player. It seems like it doesn't care about volumechange events. I notice the same behavior with FF, but for example if you drop the PA volume down to 10% with YouTube on its interpretation of 100%, YouTube will still be on 100%. If you then drop YouTube to 50$, you do not get 5% volume, you get an increase in volume to 50%... Without seeing the decompiled YT player source code, I'm not hopeful I'll understand why that happens. Needless to say, with native controls, this is not an issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190618/0bb2e718/attachment.html>