Hmm, unseekable videos should be the norm for 200 type responses. The behavior shouldn't be dependent on the OS unless Python on each OS is doing different things. +hubbe.

agoode@, were you using the same videos when you got different behavior on linux and windows?

All videos are supposed to become unseekable when we're lacking range support.

Of course, there are some badly muxed videos which cannot be played properly without seek support, and we should probably have better diagnostic for those.
(Not sure what happens today actually...)

agoode@, can you give precise instructions for how to reproduce the case where videos don't become unseekable? (Including sharing the video you used for the test.)

I tried to reproduce with single videos and everything works as expected. Then I went back to my original test, which is an export of a large (>300 post) blog to a single HTML page. There are 38 <video> tags on that page, and that's where I had the problems.

The page gets stuck loading, even though it is served locally. I had to reload a few times to get it to load. The videos don't load properly though, and the console gets several of these messages:
[1:13:0504/130153.790684:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: data source error"}
[1:13:0504/130153.791118:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: failed creating video stream"}
[1:1:0504/130153.791990:ERROR:render_media_log.cc(30)] MediaEvent: PIPELINE_ERROR pipeline: read error
[1:13:0504/130153.815547:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: open context failed"}


So it looks like the issue may be only tangentally related to range requests, if at all.

Are there stress tests that try loading a variety of videos on a single page from the network?

Are all of these videos loaded from the same server? same TLD?
The network layer has a limit on the number of simultaneous connections. It should still load eventually though...

Either way, an actual test page or url would be very helpful.

Version 60.0.3088.3 (Official Build) dev (64-bit)


I will try to get a repro with some non-private movies/images.

All images are loaded from http://localhost:4000. Something goes wrong though. The server reports a couple of "error: [Errno 32] Broken pipe" messages and net-internals shows:
Name	Pending	Top Priority	Active	Idle	Connect Jobs	Backup Timer	Stalled
localhost:4000	7	HIGHEST	6	0	0	stopped	false

6 active connections, but nothing being transferred. The server is idle. And I cannot load anything more from localhost:4000.

Here is a test with 100 videos on the same page. Sockets will get stuck and nothing more can be loaded.

Deleted: crbug-716748.tar.gz 3.6 MB

crbug-716748.tar.gz 3.6 MB Download

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

commit 1d6585623812b57dca641bb5ecb0fff82f9c9da4
Author: hubbe <hubbe@chromium.org>
Date: Fri May 26 20:58:39 2017

fully cache small audio/video

Also, make fully cached audio/videos re-usable even if the server doesn't
support ranges.

This only fixes  BUG 716478 , for videos smaller than 25 Mb, and only if
we decide to read the whole video during preloading.

Next step: Make fully cached videos seekable.

BUG= 716748 

Review-Url: https://codereview.chromium.org/2910553002
Cr-Commit-Position: refs/heads/master@{#475122}

[modify] https://crrev.com/1d6585623812b57dca641bb5ecb0fff82f9c9da4/media/blink/multibuffer_data_source.cc
[modify] https://crrev.com/1d6585623812b57dca641bb5ecb0fff82f9c9da4/media/blink/multibuffer_data_source_unittest.cc
[modify] https://crrev.com/1d6585623812b57dca641bb5ecb0fff82f9c9da4/media/blink/resource_multibuffer_data_provider.cc
[modify] https://crrev.com/1d6585623812b57dca641bb5ecb0fff82f9c9da4/media/blink/url_index.cc
[modify] https://crrev.com/1d6585623812b57dca641bb5ecb0fff82f9c9da4/media/blink/url_index.h

I think range is not the problem. The real issue is getting stuck at 6 videos.

Take a look at issue 735583.

Issue 735583 has been merged into this issue.

In issue 735583 it was observed that this can block all further connections to a host.

As noted on that issue, that issue is different. We use a different loading path for <video> than <img>.

And a clarification:

Ranges are only part of the issue because if the server supports ranges we can safely close the connection after having loaded enough data.

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

commit e2cc88c09afab5f066c83032548c1180d99c5ae7
Author: hubbe <hubbe@chromium.org>
Date: Fri Jul 14 23:11:01 2017

media: Allow suspend on HTTP 200 videos

Currently, connections are kept open indefinitely, which
can block future loads from a server if there are 6 or more
<video> tags on the same page.  This should fix that in most
cases.

BUG= 716748 

Review-Url: https://codereview.chromium.org/2979893002
Cr-Commit-Position: refs/heads/master@{#486919}

[modify] https://crrev.com/e2cc88c09afab5f066c83032548c1180d99c5ae7/media/blink/multibuffer_data_source_unittest.cc
[modify] https://crrev.com/e2cc88c09afab5f066c83032548c1180d99c5ae7/media/blink/resource_multibuffer_data_provider.cc
[modify] https://crrev.com/e2cc88c09afab5f066c83032548c1180d99c5ae7/media/blink/resource_multibuffer_data_provider.h
[modify] https://crrev.com/e2cc88c09afab5f066c83032548c1180d99c5ae7/media/blink/webmediaplayer_impl.cc
[modify] https://crrev.com/e2cc88c09afab5f066c83032548c1180d99c5ae7/third_party/WebKit/LayoutTests/http/tests/media/gc-while-network-loading.html

Unless the videos are *playing*, this problem should be fixed now.