Fix deferred video underflow if audio underflows first.

Fix deferred video underflow if audio underflows first.

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.

Committed: https://crrev.com/32315ab593a4a20a7205336f66c3129658757d6d
Cr-Commit-Position: refs/heads/master@{#330463}

[DaleCurtis, 2015-05-18 22:20:30]

dalecurtis@chromium.org changed reviewers:
+ xhwang@chromium.org

[DaleCurtis, 2015-05-18 22:20:31]

Yay for finding old bugs :) We should probably see about getting this merged
back to M43.

[xhwang, 2015-05-18 23:06:16]

In CL description, "audio has already been deferred" should be "audio has
underflowed"?

otherwise lgtm!

[DaleCurtis, 2015-05-18 23:10:05]

Good catch, fixed! Thanks for the fast review!

[DaleCurtis, 2015-05-18 23:10:57]

The CQ bit was checked by dalecurtis@chromium.org

[commit-bot: I haz the power, 2015-05-18 23:11:41]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1148473003/20001

[commit-bot: I haz the power, 2015-05-19 00:58:18]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-05-19 00:59:09]

Patchset 2 (id:??) landed as
https://crrev.com/32315ab593a4a20a7205336f66c3129658757d6d
Cr-Commit-Position: refs/heads/master@{#330463}