Transition to have nothing if background rendering evicts all frames.

Transition to have nothing if background rendering evicts all frames.

If we're background rendering it's possible for us to expire all
frames if the audio renderer advances too far ahead. In this case
we need to transition into the HAVE_NOTHING state so the Renderer
is aware we don't have frames.

It seems possible for this bug to permanently hang video playback
in release builds since the renderer has no idea what state we're
in and the video renderer will never transition to have enough.

BUG=630860
TEST=new unittest.

Committed: https://crrev.com/fdde31284d8d1fb76451c55e6a579b34f5aa35f1
Cr-Commit-Position: refs/heads/master@{#420808}

[DaleCurtis, 2016-09-23 23:36:50]

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

[DaleCurtis, 2016-09-23 23:36:56]

The CQ bit was checked by dalecurtis@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-23 23:37:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[watk, 2016-09-24 00:26:18]

lgtm

[DaleCurtis, 2016-09-24 00:27:05]

The CQ bit was unchecked by dalecurtis@chromium.org

[DaleCurtis, 2016-09-24 00:27:07]

The CQ bit was checked by dalecurtis@chromium.org

[commit-bot: I haz the power, 2016-09-24 00:27:21]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-24 01:26:06]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-09-24 01:28:23]

Description was changed from

==========
Transition to have nothing if background rendering evicts all frames.

If we're background rendering it's possible for us to expire all
frames if the audio renderer advances too far ahead. In this case
we need to transition into the HAVE_NOTHING state so the Renderer
is aware we don't have frames.

It seems possible for this bug to permanently hang video playback
in release builds since the renderer has no idea what state we're
in and the video renderer will never transition to have enough.

BUG=630860
TEST=new unittest.
==========

to

==========
Transition to have nothing if background rendering evicts all frames.

If we're background rendering it's possible for us to expire all
frames if the audio renderer advances too far ahead. In this case
we need to transition into the HAVE_NOTHING state so the Renderer
is aware we don't have frames.

It seems possible for this bug to permanently hang video playback
in release builds since the renderer has no idea what state we're
in and the video renderer will never transition to have enough.

BUG=630860
TEST=new unittest.

Committed: https://crrev.com/fdde31284d8d1fb76451c55e6a579b34f5aa35f1
Cr-Commit-Position: refs/heads/master@{#420808}
==========

[commit-bot: I haz the power, 2016-09-24 01:28:24]

Patchset 1 (id:??) landed as
https://crrev.com/fdde31284d8d1fb76451c55e6a579b34f5aa35f1
Cr-Commit-Position: refs/heads/master@{#420808}

[watk, 2016-09-26 23:12:43]

https://codereview.chromium.org/2363983003/diff/1/media/renderers/video_rende...
File media/renderers/video_renderer_impl.cc (right):

https://codereview.chromium.org/2363983003/diff/1/media/renderers/video_rende...
media/renderers/video_renderer_impl.cc:320: base::AutoLock al(lock_);
I just noticed this. The comment on l.292 says not to hold lock_ :\ Is this a
deadlock?

[DaleCurtis, 2016-09-26 23:23:42]

https://codereview.chromium.org/2363983003/diff/1/media/renderers/video_rende...
File media/renderers/video_renderer_impl.cc (right):

https://codereview.chromium.org/2363983003/diff/1/media/renderers/video_rende...
media/renderers/video_renderer_impl.cc:320: base::AutoLock al(lock_);
On 2016/09/26 at 23:12:43, watk wrote:
> I just noticed this. The comment on l.292 says not to hold lock_ :\ Is this a
deadlock?

I think the comment is out of date since we no longer issue buffering state
changes w/o posting. I don't see any other cases where this could be reentrant
now.