Multiple Network request for a simple video file

Sushanth Rajasankar

unread,

Jun 6, 2022, 6:18:16 PM6/6/22

to media-dev

Hello,

I am seeing some strange networking behavior with respect to media playback and wanted to know if there is an explanation for this.

For a simple markup like

<!DOCTYPE HTML>

<HTML>

</HTML>

I would expect the video file – the whole 200 MB of it to be downloaded once.

Instead, fiddler sees two downloads of the entire file upon page load in chromium plus an additional connection when I click play.

The server I am using here is just python3 -m http.server to serve this file from my disk.

Looking at the code

Some URL properties are populated from the first response and if any property changes, for example an accepts header is discovered the code redirects to a new URLData

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/media/resource_multi_buffer_data_provider.cc;drc=d87f10f4671473938a344e7d02ba330018f8a48b;l=339

As a part of this redirect some cached bytes are copied over, but what should stop the original HTTP connection ? the original one seems to download to completion.

FWIW, I checked with Firefox and see a single network request so this doesn’t seem like a spec compliance overhead, atleast right away.

Q1. Is this a known issue with a reason for it to be this way ?

Q2. Is there a specific response expected from the server to prevent these multiple downloads ?

Thanks,

Sushanth

Dale Curtis

unread,

Jun 6, 2022, 6:21:19 PM6/6/22

to Sushanth Rajasankar, media-dev

Hmm, I wouldn't expect two downloads, just one -- we shouldn't keep a connection open for a 200 OK resource either. Have you tested with a real server like Apache or even just CherryPy? Without range requests you're apt to see unfortunate behavior with large video on the web -- especially so if the file is muxed poorly.

- dale

--
You received this message because you are subscribed to the Google Groups "media-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to media-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/media-dev/CH2PR00MB077915A931C97D64122BAC40FDA29%40CH2PR00MB0779.namprd00.prod.outlook.com.

guest271314

unread,

Jun 6, 2022, 10:29:31 PM6/6/22

to media-dev, Dale Curtis, media-dev, Sushanth Rajasankar

Cannot reproduce.

I merged big_buck_bunny_480p.webm (37.4MB) to itself six (6) times with mkvmerge producing a 224MB video. Started PHP built-in local server and requested the file. The first request is for the document, the second for the media.

Observing the Network tab at DevTools the displayed Size and Time indicate the file is not downloaded to completion before playback begins. The file is progressively downloaded, during playback.

Of interest, on Chromium 104 developer channel, when Media Fragment URI https://www.w3.org/TR/media-frags/ on http://localhost Status is not 206, and playback does not begin/start at the set temporal dimension.

This does not work as expected on localhost

<video src="test.webm#t=240,300" autoplay controls></video>
<script>
const video = document.querySelector('video');
video.onplay = () => console.log(video.currentTime);
video.onended = () => console.log(video.currentTime);
</script>

Playback begins at 0, not 3 minutes. When onplay is fired "currentTime" is 0.

Media Fragment URI being ignored on http://localhost appears to be a bug.

When "suspend" even is attached to the <video> the handler is fired multiple times during playback. 7 times as of 3:30 "currentTime".

Dan Sanders

unread,

Jun 7, 2022, 6:27:15 PM6/7/22

to Sushanth Rajasankar, media-dev

I can confirm this behavior for 03_caminandes_llamigos_1080p.mp4.

What's happening here is that the first request is looking for the MP4 metadata, which in this case is at the end of the file (moov box starts at byte 200,316,690). Because the server does not support range requests, this ends up fetching the whole file.

Then playback starts and the initial bytes are not cached, so a new request is started from the beginning. This second request is restricted to the active region of playback and will only download as much as has been played back.

There can be differing behavior in caching between browsers; for example Edge avoids caching media fetches under the assumption that they will only be fetched once and the energy cost to write to disk is not likely to be worth it. I do not know the state of any similar optimization in Chrome, but this case (IsStreaming() + unoptimized file) may be hard to distinguish early enough to behave better.

The best fix is to use a server that supports range requests, but nearly as good would be to rewrite the MP4 to put the metadata at the start. (Something like `ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4`, although GPAC MP4Box or Shaka Packager would be more appropriate.)

- Dan

On Mon, Jun 6, 2022 at 3:18 PM 'Sushanth Rajasankar' via media-dev <medi...@chromium.org> wrote:

--

Sushanth Rajasankar

unread,

Jun 7, 2022, 9:33:02 PM6/7/22

to Dan Sanders, media-dev

Thank you – Dan !

I see, that makes sense now. Ill try with a server that supports range requests and report back.

Is there a log or place in code (breakpoints) you looked at to figure out the reasons for these requests ?

Dan Sanders

unread,

Jun 8, 2022, 1:43:37 PM6/8/22

to Sushanth Rajasankar, media-dev

Not really; this example takes long enough to load that I just visually correlated the load state with the network requests, and I confirmed the file structure using https://gpac.github.io/mp4box.js/test/filereader.html.

Reply all

Reply to author

Forward