Share a thread per process for high resolution vp9 decodes.

vp9 decodes > 1024 in width can block the media thread for too long,
causing stalls in audio decoding, demuxing, as well as control type
interactions from the user.  For such decodes, a new thread will be
created (max 1 per process) for the call to vpx_codec_decode().

I considered instead pushing audio decoding into the raster worker
pool, but this is a very invasive change and doesn't actuall solve
the problem since the post back from the worker pool will be blocked
by the vpx decode still (we saw the same issue with GpuMemoryBuffers).

The boost thread will shutdown after 5 seconds of inactivity (delayed
to avoid config changes spinning it up and down).

On a Z620 the buffering time improves by ~24.8% while time to play
worsens by ~1.57%, neither is unexpected or worrying given the user
visible playback improvements (no glitching).

TEST=new pipeline integration test.
720p60 vp9 playback on N4 device no longer glitches
./tools/perf/run_benchmark --browser=exact \
--browser-executable=out/Release/chrome media.tough_video_cases \
--page-repeat=5 --story-filter=".*crowd.*vp9.webm"

Review URL: https://codereview.chromium.org/1651683002

Cr-Commit-Position: refs/heads/master@{#372851}

0 files changed, 0 insertions, 0 deletions