This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Is this still an issue or was this resolved with the deferred reset?

it seems about the same as before.  ~3 seconds of seeking around caused ~25 codecs to be created.  i also turned off deferred reset, and it didn't seem to affect much.

the deferred reset doesn't seem to happen except on a DRAIN_TYPE_FLUSH.  i tried including ..._RESET too.  this cut it down to ~6 codecs during a 3 second seek.

i don't know if i should be happy about a 4x improvement or sad about wasting 83% of the codecs that are still allocated.

i also don't know if it's safe to defer on reset.  i think so.

Not much we can do if we get past the seeked point and are asked to provide a frame. I thought watk@ fixed the defer on reset stuff recently. We previously were creating codecs on destruction too. I agree that it should be safe and though we were deferring...

I don't remember if I tried deferring after a Reset().

The only thing I'm wondering is how long after the Reset() does the first frame arrive? Because we Reset() at MSE config changes, and I wouldn't want to introduce any more latency there. I suspect it's just a couple of ms, and doesn't really matter.

weird, https://codereview.chromium.org/2789773002/ landed three hours ago and it didn't add an update here.

anyway, i don't know how long after a reset does it arrive.  i'll measure.