I think in order to fix this we need to ensure that when a tab is foregrounded, we re-enable video stream before the RendererImpl is created/initialized. Then the newly created renderer will be able to access the enabled video stream and should be able to continue playing it from the expected position.

Hm, but RendererImpl is reinitialized at the step 4, way before 5, when the audio stream is resumed via the notification and the tab is still in the background.

Bummer.
IIUC the main problem here is that currently disabled video streams are inaccessible via DemuxerStreamProvider::GetStream interface, and it was done that way in order to avoid breaking old code that didn't expect streams to have enabled/disabled state. I was planning to change the DemuxerStreamProvider interface anyway, to allow supporting multiple audio/video tracks anyway. But since DemuxerStreamProvider is such a central interface which is being used in many places, it's going to be a pretty big CL. In fact I already have a prototype CL for this (https://codereview.chromium.org/2491043003/, which depends on https://codereview.chromium.org/2491043003/), but I have been only using it for prototyping multiple video track support and haven't thoroughly discussed these changes with Xiaohan and Dale, I'm planning to restart that conversation next week, when Dale is back in the office.
After landing that CL we'll be able to access all demuxer streams (even disabled ones) from the RendererImpl, and thus we'll be able to register stream status notifications even for deselected/disabled streams. So then when a stream gets re-enabled later when the tab is foregrounded the renderer will get notified. I hope that will solve this issue.

Great but before this is fixed the backgrounded video track optimization will break background video playback on Android and we wanted to at least launch an experiment with the optimization on in M57... Do you think the big CL will make it into 57 (branch point is in two weeks)?

Well, I personally believe it's ready, but it's a fairly significant design change, so I'll need to convince Xiaohan and Dale that this is good. I'll try to accelerate this, but AFAIK Dale is OOO till next week.

+dalecurtis@ who is back today.

Without looking over the changes more closely I can't say. xhwang@ is our expert  on the renderer, so starting those discussions asap would increase your chances, but may not be enough for m57.

Actually another potential fix would be to not deselect the video track when the audible video is backgrounded (as we pause it anyway) but only once the playback is resumed by the user and so the renderer is recreated. I'll look into that.

So it seems like I could maybe disable the video track after the pipeline is resumed and the video renderer is created. I can't find a good place in WMPI to get notified about this - seems like pipeline_controller_.Resume() will post a few tasks to the media thread including renderer initialization that will eventually result in PipelineController::Dispatch(PLAYING) call but with pending_seek_cb_ being false. Can't think of anything better than adding a resume_cb_ (WMPI to pipeline_controller - pass in Resume()) that would fire from the bottom of Dispatch() if set at this point.

Dan, wdyt?

Or just setting pending_seeked_cb_ to true in Resume...

I also need to reselect the video track before the pipeline is suspended and the renderer is destroyed: https://codereview.chromium.org/2618883002

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2135a640a1547f44b62828bac84dc713d39652c6

commit 2135a640a1547f44b62828bac84dc713d39652c6
Author: avayvod <avayvod@chromium.org>
Date: Fri Jan 13 00:17:14 2017

[Media, Video] Enable the video track for a new renderer.

Video track needs to be reenabled before the new renderer is
created so that the callbacks attach properly. For that, add
two new callbacks to PipelineController for when the pipeline
is about to resume and is resumed.

This adds a potential problem when the video is shown or hidden
in between the two events. So don't change the video track if
the pipeline is resuming or seeking but check for the necessary
conditions in the resumed callback.

BUG= 678374 
TEST=media_[blink_]unittests + manual testing

Review-Url: https://codereview.chromium.org/2618883002
Cr-Commit-Position: refs/heads/master@{#443404}

[modify] https://crrev.com/2135a640a1547f44b62828bac84dc713d39652c6/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/2135a640a1547f44b62828bac84dc713d39652c6/media/blink/webmediaplayer_impl.h
[modify] https://crrev.com/2135a640a1547f44b62828bac84dc713d39652c6/media/blink/webmediaplayer_impl_unittest.cc
[modify] https://crrev.com/2135a640a1547f44b62828bac84dc713d39652c6/media/filters/pipeline_controller.cc
[modify] https://crrev.com/2135a640a1547f44b62828bac84dc713d39652c6/media/filters/pipeline_controller.h
[modify] https://crrev.com/2135a640a1547f44b62828bac84dc713d39652c6/media/filters/pipeline_controller_unittest.cc