Parallel background download of all available video sizes - massive bandwith usage

[raffaelj]

I watched a talk from the rC3 right now and left my network tab (browser dev tools) open. After finishing the downloaded video with VLC, I realised, that my open browser window downloaded 1.44GB in the background.

Video: https://media.ccc.de/v/rc3-891673-rage_against_the_machine_learning

Steps to reproduce:

• open url on media.ccc.de
• press play button
• video stutters --> press pause button --> decide to download and to watch with VLC
• start download (138MB)
• leave the browser window open

I was able to reproduce the behaviour with a "smaller" data set (only 592MB).
Video: https://media.ccc.de/v/rC3-teaser-mincorrect

System:

OS: OpenSUSE Tumbleweed
Browser: Firefox 83.0 (64-bit)

FF-Addons: BlockTube, Decentraleyes, Facebook Container, KeePassXC-Browser, NoScript, uBlock Origin

edit:
Now I started another video and I only pressed play. In the background first "webm", than "sd" and than "hd" downloaded completely.

[manno]

Hey @raffaelj, I can reproduce that. However I'm not clear on the exact conditions.
Initially opening the page (without cache, full reload) and clicking the play button, the videoplayer selects video source and starts playing it from a mirror. Clicking on a download video link (plays mp4 in browser directly) and navigating back to the event page, shows all videosources have been downloaded.

I suspect turbolinks and the videoplayer js initialization?

[raffaelj]

However I'm not clear on the exact conditions.

I digged a little bit and it seems, that the conditions are that simple:

• use Firefox browser
• open a website with a html5 video tag with preload='metadata' (or maybe any preload state...?)

No user interaction is necessary, just wait (not sure, if media.ccc.de starts a play event somewhere in the background). Now all available sources inside the video tag are preloaded if the proper codecs are available.

I'm not very familiar with media hosting etc, but I remembered, that I had this issue before with the html5 audio tag - so knew, where to look for this issue.

I also found an open issue from 7 years ago on bugzilla: "Metadata" state for preload attribute of video element being ignored when buffering. In short: The feedbask was to limit the traffic server-side.

Possible solutions (not tested):

as a user to preserve bandwith

• use a chromium based browser
• or tinker with about:config in Firefox to disable some preloading of media files

server side

Maybe limit/drop the traffic if a different video source is already loading...

client/player side

Inject video sources dynamically instead of providing 4 different sources on page load. I'm not sure, how much this might impact the usability with enabled script blockers. And I'm not sure, how it impacts caching when switching between SD/HD/MP4/WEBM.

edit:
Now I read some js in the html source. Maybe it is the mirror search? This code looks a bit like it would start a request to all sources to see if it gets a response, which might start the actual download.

$('video source').each(function() {
  var $source = $(this);
  // Prop always presents the fully resolved URL
  promises.push(
    MirrorbrainFix.selectMirror($source.prop('src'), function(mirror) {
      $source.attr('src', mirror);
    })
  );
});