Make AVDA errors terminal; don't destruct until Decode() for Reset().

Make AVDA errors terminal; don't destruct until Decode() for Reset().

This expands our workaround for deferred ResetCodecState() to include
cases where we might destruct the codec since that can be slow. As
part of this fix, we also no longer let ResetCodecState() leave the
error state and only reconstruct a codec when there are no errors.

The latter change avoids codec destruction and recreation on all
platforms if we happen to hit an unlucky SurfaceView destruction
error.

On the whole this doesn't seem to matter much on my N7v1 running
4.3.0 (API 18). Total suspend resume cycle time goes from ~297ms
to ~287ms if I force codec destruction for this device.

BUG=tbd
TEST=timing.

[DaleCurtis, 2016-05-25 00:09:02]

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

[DaleCurtis, 2016-05-25 00:09:02]

At least on the N7v1 this doesn't seem to make much difference, but it might
reduce some occasional jank in the field.

[watk, 2016-05-26 20:53:28]

lgtm

https://codereview.chromium.org/2008933004/diff/1/media/gpu/android_video_dec...
File media/gpu/android_video_decode_accelerator.cc (right):

https://codereview.chromium.org/2008933004/diff/1/media/gpu/android_video_dec...
media/gpu/android_video_decode_accelerator.cc:1212: // TODO(liberato): revisit
this once we sort out the error state a bit more.
Could probably delete this whole comment since it's talking about recovering
from errors other than fullscreen transitions. I don't think we need to consider
that any more.

https://codereview.chromium.org/2008933004/diff/1/media/gpu/android_video_dec...
media/gpu/android_video_decode_accelerator.cc:1218: // done mid-stream.
Do you think this comment belongs on codec_requires_destruction?

https://codereview.chromium.org/2008933004/diff/1/media/gpu/android_video_dec...
media/gpu/android_video_decode_accelerator.cc:1228:
g_avda_timer.Pointer()->StopTimer(this);
unrelated, but it's a bit weird that the other branch doesn't also stop the
timer..

[DaleCurtis, 2016-06-02 20:54:20]

liberato: Any thoughts?

[liberato (no reviews please), 2016-06-02 22:10:44]

sorry, forgot about it.

lgtm % one potential change.

-fl

https://codereview.chromium.org/2008933004/diff/1/media/gpu/android_video_dec...
File media/gpu/android_video_decode_accelerator.cc (right):

https://codereview.chromium.org/2008933004/diff/1/media/gpu/android_video_dec...
media/gpu/android_video_decode_accelerator.cc:1204: codec_needs_reset_ = false;
the idea here is to make the first call defer, and the second call wait, right?

it might be better to send in a flag with each call "may defer reset / new
codec", so that Decode can indicate that it always wants a ready-to-use codec. 
it seems more clear.

https://codereview.chromium.org/2008933004/diff/1/media/gpu/android_video_dec...
media/gpu/android_video_decode_accelerator.cc:1228:
g_avda_timer.Pointer()->StopTimer(this);
On 2016/05/26 20:53:28, watk wrote:
> unrelated, but it's a bit weird that the other branch doesn't also stop the
> timer..

i don't think that it should.  the next decode will restart it, but i don't
think that we want to depend on that.  it'll be okay now since there aren't any
cases where we'd need the timer and decoding is paused waiting for flush, i
think.  but, soon, there may be for switching SV <-> ST.  in that case, we don't
want to stop the timer in the reset case.

in this branch, it's fine.  when the codec is ready, it'll restart it in
OnCodecConfigured.