New issue
Advanced search Search tips

Issue 884820 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Loading many src= videos is very slow.

Project Member Reported by hubbe@chromium.org, Sep 17

Issue description

Chrome Version: all

When multiple media elements appear on the same page, it can take along time for them to load enough video to show the first frame. In particular, videos that require seeking to the end to read the index can be very slow because of how we schedule the reads. As an example, let’s assume we have a page with 10 video elements, all of which require three requests to show the first image. The first request reads the beginning of the data to figure out what kind of video it is. The second seeks to the end to find the index of where all the frames are. The third goes back to the beginning to read the data for the first frame.

Normally, the media code will attempt to do all of these things in parallel, but there is a limit on 6 open requests from the same tab at any given time. So what happens is that the first 6 requests starts to process, while the next 4 has to wait. Once one of the first six completes, the second request for that video is immediately queued, but it’s placed at the end of the queue. Four more requests has to finish before any of the videos get to process the second request. Of course, once the second request is done, and the third is scheduled, it has to go to the back of the queue too.

 
Project Member

Comment 1 by bugdroid1@chromium.org, Sep 25

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

commit 395ca8adef07ee3e2a8644dbb9c5725373f246b2
Author: Fredrik Hubinette <hubbe@google.com>
Date: Tue Sep 25 20:52:11 2018

limit parallel media preloading

When loading many media files, we normally end up having to wait
for the first request for ALL media files to load before we can
process the second request of the first media file. By limiting
the number of parallel preloads, time-to-first frame should improve
for all but the last media file.

However, this feature is checked in behind a feature flag, so that
we can run some expriments on it before turning it on by default.

Bug: 884820
Change-Id: Ib0c366325d82fb59e6ad896bf985b1e828143a82
Reviewed-on: https://chromium-review.googlesource.com/1228486
Commit-Queue: Fredrik Hubinette <hubbe@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594090}
[modify] https://crrev.com/395ca8adef07ee3e2a8644dbb9c5725373f246b2/media/base/media_switches.cc
[modify] https://crrev.com/395ca8adef07ee3e2a8644dbb9c5725373f246b2/media/base/media_switches.h
[modify] https://crrev.com/395ca8adef07ee3e2a8644dbb9c5725373f246b2/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/395ca8adef07ee3e2a8644dbb9c5725373f246b2/media/blink/multibuffer_data_source.h
[modify] https://crrev.com/395ca8adef07ee3e2a8644dbb9c5725373f246b2/media/blink/multibuffer_data_source_unittest.cc
[modify] https://crrev.com/395ca8adef07ee3e2a8644dbb9c5725373f246b2/media/blink/resource_multibuffer_data_provider.cc
[modify] https://crrev.com/395ca8adef07ee3e2a8644dbb9c5725373f246b2/media/blink/resource_multibuffer_data_provider.h
[modify] https://crrev.com/395ca8adef07ee3e2a8644dbb9c5725373f246b2/media/blink/url_index.cc
[modify] https://crrev.com/395ca8adef07ee3e2a8644dbb9c5725373f246b2/media/blink/url_index.h
[modify] https://crrev.com/395ca8adef07ee3e2a8644dbb9c5725373f246b2/media/blink/url_index_unittest.cc

Project Member

Comment 2 by bugdroid1@chromium.org, Oct 25

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

commit 7ae8707d8b516cdfc218e7d1f91dcc674646531c
Author: Fredrik Hubinette <hubbe@google.com>
Date: Thu Oct 25 17:59:04 2018

track timetofirstframe when loading many videos

This should tell us how big of an impact any optimization may have,
and should also tell us how often this happens.

Bug: 884820
Change-Id: I74a4d5b8722c6bb55f1994dafdbba8c6368f9f63
Reviewed-on: https://chromium-review.googlesource.com/c/1297476
Reviewed-by: Jesse Doherty <jwd@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Fredrik Hubinette <hubbe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#602785}
[modify] https://crrev.com/7ae8707d8b516cdfc218e7d1f91dcc674646531c/media/blink/url_index.cc
[modify] https://crrev.com/7ae8707d8b516cdfc218e7d1f91dcc674646531c/media/blink/url_index.h
[modify] https://crrev.com/7ae8707d8b516cdfc218e7d1f91dcc674646531c/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/7ae8707d8b516cdfc218e7d1f91dcc674646531c/tools/metrics/histograms/histograms.xml

Project Member

Comment 3 by bugdroid1@chromium.org, Dec 1

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

commit 41acf323131607a16cea75718e40676b4aafbb47
Author: Fredrik Hubinette <hubbe@google.com>
Date: Sat Dec 01 00:42:15 2018

Cleanup parallel media preload limit code.

Experiment showed that limiting media preloading generally
slows things down rather than speed things up, presumably because
there are a lot of other things loading as well.

Bug: 884820
Change-Id: I5baa15c465ef83a73eecbdad77c5cb0ad589e5d6
Reviewed-on: https://chromium-review.googlesource.com/c/1355257
Reviewed-by: Jesse Doherty <jwd@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: Fredrik Hubinette <hubbe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#612877}
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/base/media_switches.cc
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/base/media_switches.h
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/blink/multibuffer_data_source.h
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/blink/multibuffer_data_source_unittest.cc
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/blink/resource_multibuffer_data_provider.cc
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/blink/resource_multibuffer_data_provider.h
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/blink/url_index.cc
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/blink/url_index.h
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/blink/url_index_unittest.cc
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/41acf323131607a16cea75718e40676b4aafbb47/tools/metrics/histograms/histograms.xml

Components: Internals>Media>Network
Owner: ----
Status: Available (was: Started)
Ideally we should still do something about this, but what?

Sign in to add a comment