This is a kinda big fish and I feel like maybe it might have been forgotten about. Firefox not working on youtube usually gets a quick fix, as we've seen recently. That seems appropriate when a web browser doesn't work on the biggest web site :) Is there any chance we could revisit this?
TL;DR
That bugzilla has several bugs rolled into one. The important part is in the title. Changing the application volume does not change the volume of the youtube html video player.
The result is that when you change volumes using any of the usual media controls outside the player (eg pavucontrol, media buttons on keyboards), they work immediately, by changing the stream volume, but that volume is not reflected in the slider on the video player.
Youtube remembers the volume set in the player, storing it in a cookie, and re-setting it each time the player acts - so, when skipping, buffering, loading ads, etc. - the reports of volume jumping to 100% / jumping to silent / quiet / loud / etc, are results of this intentional behaviour. It is jumping back to whatever is set in the player.
If youtube worked like other HTML video players, changing volume eg in pavucontrol, would move the slider in the player, and then when youtube sets the volume "back", it would set the same, pre-existing volume, and there is no audible change.
In all other HTML players I've tested (netflix prime stan kayo, plus a few randoms from the search engine) it works like that - volume control between player and app is mirrored and bidirectional. It doesn't matter where I click stop or pause or play, or where I set the volume, it is consistent between firefox and the html player. On youtube it is unidirectional from player to app, but not the other way, so if the app volume is set, a desync from the player occurs, and the volume jump happens when the player corrects the desync by setting the only volume it knows - its own.
I do understand that there is an additional, deeper issue, regarding the creation of streams (the 'start a whole new stream for every time something changes' thing) and while it would be nice to fix that, just taking care of this relatively simple issue, will provide a scenario where the software will have the audible behaviour which the user expects. The creation of new streams won't be an actual problem, if those streams all have the expected volume as set by the user.
This is a kinda big fish and I feel like maybe it might have been forgotten about. Firefox not working on youtube usually gets a quick fix, as we've seen recently. That seems appropriate when a web browser doesn't work on the biggest web site :) Is there any chance we could revisit this?
https://bugzilla.mozilla.org/show_bug.cgi?id=1422637
TL;DR That bugzilla has several bugs rolled into one. The important part is in the title. Changing the application volume does not change the volume of the youtube html video player.
The result is that when you change volumes using any of the usual media controls outside the player (eg pavucontrol, media buttons on keyboards), they work immediately, by changing the stream volume, but that volume is not reflected in the slider on the video player.
Youtube remembers the volume set in the player, storing it in a cookie, and re-setting it each time the player acts - so, when skipping, buffering, loading ads, etc. - the reports of volume jumping to 100% / jumping to silent / quiet / loud / etc, are results of this intentional behaviour. It is jumping back to whatever is set in the player.
If youtube worked like other HTML video players, changing volume eg in pavucontrol, would move the slider in the player, and then when youtube sets the volume "back", it would set the same, pre-existing volume, and there is no audible change.
In all other HTML players I've tested (netflix prime stan kayo, plus a few randoms from the search engine) it works like that - volume control between player and app is mirrored and bidirectional. It doesn't matter where I click stop or pause or play, or where I set the volume, it is consistent between firefox and the html player. On youtube it is unidirectional from player to app, but not the other way, so if the app volume is set, a desync from the player occurs, and the volume jump happens when the player corrects the desync by setting the only volume it knows - its own.
I do understand that there is an additional, deeper issue, regarding the creation of streams (the 'start a whole new stream for every time something changes' thing) and while it would be nice to fix that, just taking care of this relatively simple issue, will provide a scenario where the software will have the audible behaviour which the user expects. The creation of new streams won't be an actual problem, if those streams all have the expected volume as set by the user.
Thanks for your time.