I'll take a look. Thanks for filing this one, Caleb.

I got back around finally this evening to looking into this. I think I have a repro. Media-internals is showing a very suspicious 15 second delayed transition to kSuspending again (very much like bug 592706) :

Players

blob:http%3A//localhost%3A8000/bd895cd5-5590-4c68-9686-5a4102fcd2cc
Player Properties Copy to clipboard

Property	Value
audio_codec_name	opus
audio_dds	false
audio_decoder	OpusAudioDecoder
duration	210.021
event	WEBMEDIAPLAYER_CREATED
found_audio_stream	true
found_video_stream	true
pipeline_state	kSuspended
player_id	4
render_id	7
url	blob:http%3A//localhost%3A8000/bd895cd5-5590-4c68-9686-5a4102fcd2cc
video_codec_name	vp9
video_dds	false
video_decoder	VpxVideoDecoder
Log 

Timestamp	Property	Value
00:00:00 00	pipeline_state	kCreated
00:00:00 00	event	WEBMEDIAPLAYER_CREATED
00:00:00 01	url	blob:http%3A//localhost%3A8000/bd895cd5-5590-4c68-9686-5a4102fcd2cc
00:00:00 01	pipeline_state	kInitDemuxer
00:00:00 159	duration	210.021
00:00:00 241	found_audio_stream	true
00:00:00 241	audio_codec_name	opus
00:00:00 243	found_video_stream	true
00:00:00 243	video_codec_name	vp9
00:00:00 244	pipeline_state	kInitRenderer
00:00:00 245	audio_dds	false
00:00:00 245	audio_decoder	OpusAudioDecoder
00:00:00 251	video_dds	false
00:00:00 251	video_decoder	VpxVideoDecoder
00:00:00 251	pipeline_state	kPlaying
00:00:15 290	pipeline_state	kSuspending
00:00:16 525	pipeline_state	kSuspended

Chatted with sandersd@: he has a hypothesis that likely explains this behavior: Blink doesn't trigger WMPI play until HAVE_FUTURE_DATA. So, even starting the timer at HAVE_METADATA (which fixed bug 592706) doesn't fix this problem. Once suspended and having not previously received play() from blink, WMPI won't resume automatically once HAVE_FUTURE_DATA (IIUC; sandersd@ please confirm).

I suspect the shaka-player based VP9 AVA test's use of a very simplified manifest (just one huge chunk for each of A/V) makes the fetching + appending + reaching have_metadata slow, as well has delays HAVE_FUTURE_DATA.

Over to sandersd@ to confirm his hypothesis and fix.
If hypothesis is true, fix could be either to:
1) never suspend until HAVE_FUTURE_DATA, or
2) only service OnHidden suspensions if prior to HAVE_FUTURE_DATA (because OnShown should resume regarless of readyState if previously suspended).

I prefer the latter fix. Dan, please see https://bugs.chromium.org/p/chromium/issues/detail?id=592706#c25 for a tarball of a set of repro files - (I already confirmed the various pieces in AVAnalyis appear to be the same as in the previous bug).

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

commit 50a635ebbf250f8f35ea060d564b102b804dcea7
Author: sandersd <sandersd@chromium.org>
Date: Mon Apr 04 22:50:09 2016

Convert WMPI state management to level-triggered.

Calling NotifyPlaybackStarted()/NotifyPlaybackPaused() at the correct
times has been a recurring source of bugs. This change moves all of the
logic to a single method, which will hopefully be easier to understand
and debug.

This new method handles delegate state, suspend/resume, and the memory
usage reporting timer together in one place. It's not simple, but it is
commented liberally.

The new suspend/resume logic does not rely on the suspend/resume
callbacks (instead it's only based on the goal state, never the current
state). As a result I was also able to remove the resume callback from
PipelineController in this CL.

BUG=595900, 597692 

Review URL: https://codereview.chromium.org/1830913005

Cr-Commit-Position: refs/heads/master@{#385038}

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

sandersd@, did #8 fix this?

Looks like the bug is fixed since here is a working m51 result for MSE VP9 Spitzer: https://av-analysis.corp.google.com/#/get-testpass-details/2/Video%20Stack/123368