New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 599288 link

Starred by 2 users
Status: WontFix
Owner:
█ w...@chromium.org
Last visit > 30 days ago
Closed: Jun 2016
Cc:
ddorwin@chromium.org
liber...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

AVDA should lazily reinitialize MediaCodecs on JB

Project Member Reported by w...@chromium.org, Mar 30 2016 
On JB, AVDA::Reset() releases its MediaCodec and creates a new one. MediaCodec creation can take 100-200 ms so we should avoid doing it unless it's necessary. Suspends result in AVDA::Reset() followed by AVDA::Destroy() so there's no point in reinitializing the MediaCodec in this case. Removing it will speed up fullscreen transitions. 

The other unnecessary case is Reset at EOS.

Comment 1 by dalecur...@chromium.org, Mar 30 2016 

Is this not calling Reset() during Suspend()/Seeks() anymore? for m51/m52 I thought that was the route we wanted to take. If this dove tails with franks work that sgtm though for now.

Comment 2 by w...@chromium.org, Mar 30 2016 

That's true, but I thought avoiding Flush() before suspend was more of a speculative task that we may not be able to do because it depends on us being able to cancel ffmpeg reads in a recoverable way. 

Doing this lazy reinitialize may actually hinder what Frank is doing, I'm not sure.

Comment 3 by w...@chromium.org, Mar 30 2016 

CL is here https://codereview.chromium.org/1828033002/

We can leave it pending more investigation into not flushing for suspend.

Comment 4 by w...@chromium.org, Jun 27 2016

Status: WontFix (was: Started)
►

Sign in to add a comment