Note: There are pieces of CORS and perhaps other functionality that may require some interaction with the main thread in our current model, so it's not expected that this may be easy to accomplish.

Ultimately Multibuffer uses the blink loader under the hood, so +Blink>Loader team in case they have hints/direction for looking into using the loader or something similar off the render thread.

This is complementary to similar MSE investigations to potentially move async appendBuffer-parsing (and perhaps also async remove()) off the render main thread that I'll be investigating soon. Thanks for cc'ing me, Dale.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cbd817fb8b417bbe16994b62f31e895cbee7e848

commit cbd817fb8b417bbe16994b62f31e895cbee7e848
Author: Fredrik Hubinette <hubbe@google.com>
Date: Wed Sep 20 21:25:42 2017

Benchmark page testing video load time when javascript thread is busy.

Bug:  765313 
Change-Id: I5aaad4b2cffdfccffc52d220ba6cedd29e7642d2
Reviewed-on: https://chromium-review.googlesource.com/673135
Reviewed-by: Xiaohan Wang <xhwang@chromium.org>
Reviewed-by: Ned Nguyen <nednguyen@google.com>
Commit-Queue: Fredrik Hubinette <hubbe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503252}
[modify] https://crrev.com/cbd817fb8b417bbe16994b62f31e895cbee7e848/tools/perf/page_sets/tough_video_cases.py
[modify] https://crrev.com/cbd817fb8b417bbe16994b62f31e895cbee7e848/tools/perf/page_sets/tough_video_cases/video.html

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ff3b31782d552b03104a6d831c7530605b52b13f

commit ff3b31782d552b03104a6d831c7530605b52b13f
Author: Fredrik Hubinette <hubbe@google.com>
Date: Fri Sep 22 21:11:16 2017

avoid thread-jump in multibuffer_datasource::read()

This establishes a short-cut when the data is already
available in the multibuffer, avoiding a potentially
slow jump to the renderer thread and back.

Doing this improves the new time-to-play-when-loaded
benchmark from 298ms to 124ms on my machine. When not
loaded, this benchmarks takes ~80ms.

Bug:  765313 
Change-Id: Icee120ee0573eb14e75240c6850822583df6a0fa
Reviewed-on: https://chromium-review.googlesource.com/677747
Commit-Queue: Fredrik Hubinette <hubbe@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503850}
[modify] https://crrev.com/ff3b31782d552b03104a6d831c7530605b52b13f/media/blink/multibuffer.cc
[modify] https://crrev.com/ff3b31782d552b03104a6d831c7530605b52b13f/media/blink/multibuffer.h
[modify] https://crrev.com/ff3b31782d552b03104a6d831c7530605b52b13f/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/ff3b31782d552b03104a6d831c7530605b52b13f/media/blink/multibuffer_data_source.h
[modify] https://crrev.com/ff3b31782d552b03104a6d831c7530605b52b13f/media/blink/multibuffer_data_source_unittest.cc
[modify] https://crrev.com/ff3b31782d552b03104a6d831c7530605b52b13f/media/blink/multibuffer_reader.cc
[modify] https://crrev.com/ff3b31782d552b03104a6d831c7530605b52b13f/media/blink/multibuffer_reader.h

Any opinions on if we should call this fixed or if we should spend more time on it?

Seems there's still a ~55% improvement which could be achieved if we pursued this further right?

I think we should spend a bit more seeing if there are more low hanging fruit to pick up. If not, do you think it's worth keeping this as available and reconsidering it once blink::WebAssociatedURLLoader can be instantiated on a given thread?

How is that working with worker threads today? Do they use a different loading mechanism?

Good question, we should probably clue in some loader folks and see what they say.

One data point...

I was working on https://bugs.chromium.org/p/chromium/issues/detail?id=768553
I modified the benchmark so that it would run 100 times, which takes a while. While it's doing that, the renderer thread is using 100% cpu and is busy for several seconds at a time. This happens while a video is playing.

Without the changes in #5, the video would hang for seconds at a time. With the changes in #5, the video would play smoothly. In this benchmark, the entire video was probably in the multibuffer cache though, so loading was probably not an issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/439465f8724d4b502355d3683aa8dad2ff076ebf

commit 439465f8724d4b502355d3683aa8dad2ff076ebf
Author: Fredrik Hubinette <hubbe@google.com>
Date: Thu Oct 05 06:47:49 2017

Delay and batch seeks to make them smarter

Previously we would call SeekTask for every
completed read. This often cause us to seek
to somewhere and change our mind a very
short time later. By delaying our seeks and
batching them together, we can reduce the
number of times this happens.

I've tested this on a a bunch of badly muxed
videos, and generally got improvements. For
my primary test video, the number of connections
went from ~110 to ~70. As far as I can tell,
this has no impact on well-muxed videos.

Bug:  765313 
Change-Id: I1cfdd803e9cda8fd45fae30ec2c0343f08a79edd
Reviewed-on: https://chromium-review.googlesource.com/690978
Commit-Queue: Fredrik Hubinette <hubbe@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Frank Liberato <liberato@chromium.org>
Cr-Commit-Position: refs/heads/master@{#506667}
[modify] https://crrev.com/439465f8724d4b502355d3683aa8dad2ff076ebf/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/439465f8724d4b502355d3683aa8dad2ff076ebf/media/blink/multibuffer_data_source.h
[modify] https://crrev.com/439465f8724d4b502355d3683aa8dad2ff076ebf/media/blink/multibuffer_data_source_unittest.cc

I think this is as fixed as it's going to be for the foreseeable future.
We may still want to move more things off the renderer thread, but it's not simple and nobody is working on it right now.