Chrome can disable video tracks on an audio-video element when the element's frame is backgrounded. There are other scenarios similarly being considered/experimented with, such as disabling video track on AV element when the element is not visible, but the frame is foregrounded.

MSE apps currently depend upon SourceBuffer.buffered and HTMLMediaElement.buffered to predict where playback stalls can happen. They can also (once servolk@'s work completes) directly {en,dis}able/{de,}select tracks (and observe AudioTrackList, VideoTrackList 'change' events are produced when they do this).

However, with an MSE app with A/V in distinct SourceBuffers, without any signalling of track changes to the app by Chrome when the element is backgrounded/foregrounded, then a couple problems:
1) The app doesn't know that it could reduce network usage and not fetch+append video while backgrounded, and
2) Chrome will happily play through an unbuffered video region without stalling so long as there is audio and the element is backgrounded, confounding app expectation that playback should have stalled.

ISTM we need a few changes:
1) Chrome should signal agent-originated track changes appropriately to the web app.
2) The HTML5 spec (and perhaps MediaSession spec or similar as is being done/discussed around video-only-element backgrounding pausing the element) should indicate that user agents MAY perform such app-visible track changes for various scenarios (like audio playback from an A/V element that is backgrounded or not visible, or other cases not yet identified), and if they do, they MUST comply with the existing HTML5 spec requiring 'change' events to AudioTrackList or VideoTrackList objects, as appropriate, and
3) Standardize the expectation around the behavior of an app selecting a video track in an element that is currently backgrounded: what should happen, and also what should happen when the element is foregrounded later?

If some of this has already been clarified, my apologies. I'm seeking less fragmentation and more clarity so web authors, especially those using MSE, can take advantage of adapting their behavior (network, etc) based on user-agents making changes to the set of enabled/selected tracks. Conceivably, even regular src= web apps could also benefit, for example by switching their src to adapt similarly to track changes made by the user agent.