GitLab

Looks like the new video rendering path caught a pre-existing bug
with how deferred video underflow is handled \o/

If audio underflowed first, the video renderer's underflow would
still be deferred.  If a Flush() comes in, the VideoRendererImpl
would think it's in the HAVE_NOTHING state and send no update to
its buffering state.

Once Flush() completed and playback was restarted the renderer
would start playback as soon as the audio renderer was ready since
the old buffering state for video was have enough.

The fix is to never defer video renderer underflow if audio has
already underflowed.  I've also added a DCHECK() to make it clear
that the audio renderer is expected to clear deferred underflow for
the video renderer during Flush().

BUG=485324
TEST=new unittest.

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

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