-
dalecurtis authored
I don't think we need to keep starting a thread per <audio> or <video> element anymore. Instead we can use a shared pool that only spins up a new thread when needed. This change switches FFmpegDemuxer from creating its own thread to using base::TaskScheduler for executing blocking network reads. The TaskScheduler API is perfectly suited for our use case and required little changes. Doing this required some changes to our BlockingUrlProtocol to make it safe to access after FFmpegDemuxer and potentially the DataSource have been destroyed. This should reduce the number of out of threads crashes we see on a fairly regular basis. BUG=61293 TEST=existing tests all pass, no slowdown noticed on pages like gfycat.com Review-Url: https://codereview.chromium.org/2710133003 Cr-Original-Commit-Position: refs/heads/master@{#453470} Committed: https://chromium.googlesource.com/chromium/src/+/5384b9fe1cf67869e1bf98ab8ff6bd21ae4216da Review-Url: https://codereview.chromium.org/2710133003 Cr-Commit-Position: refs/heads/master@{#454452}
f4a6dbf4