BigVideo.js
BigVideo.js copied to clipboard
Looping video seems to redownload the video for each loop
I've noticed with a looping video that every time it loops, it seems to request the video again, which keeps a pretty constant network connection.
Is there an option to simply replay the video after it's been downloaded the first time? Or is this a constraint of video.js that it will request the video each time?
same behavior here.
I believe it's a browser cache setting?
I looked into this and thought it was because BigVideo didn't use the loop-attribute on the <video>, but even with the loop-attribute set, Chrome seems to make conditional gets for the video source.
I've noticed that on the videojs site the video re-downloads every time the video plays all the way through and then I hit play again, or if I click back on the timeline. I'm not sure if this is a Chrome issue or a videojs issue, but either way I don't think it's a BigVideo problem.
Also worth noting: I turned the option "Disable cache (while DevTools is open)" on and off and neither state affected the video, and it re-downloaded it each time I hit play.
It might not be a BigVideo problem, but unless @johnpolacek decides to comment on the issue, I guess we'll never know.
This is a video.js issue, the problem is reproducible there and the bug lies within chrome, against which the videojs guys filed a bug. Until that is fixed one must rely on caching. When I make sure the video is served with appropriate headers, the 206 Partial Content response is fetched quickly from the cache and no network traffic occurs. Note if you have 'disable cache while devtools open' enabled then you won't see the workaround take effect when you're looking for it in the network tab - d'oh.
I retract what I said earlier, after using BigVideo on a new website, I did come across the problem described by @jlbruno. Video is re-downloaded each time the video is looped.
Thanks @spacebat for the link, it does seem there is an issue with Chrome caching.
--- EDIT --- @johnpolacek replied to this thread https://github.com/dfcb/BigVideo.js/issues/90 a while ago. The example he posted doesn't re-download the video, with browser caching working properly. Am not sure why my video would download again. I have mod_expire and mod_headers configured. I have the same problem with a past client (even if there is partial CDN caching by CloudFlare).
--- MOAR EDIT --- Ok I figured out the problem, seems like Chrome doesn't catch any videos over 5MB. Need an official reply on this.
Thanks for figuring out what the problem was @thejae .
I can't find any solution though. This situation will cause severe bandwidth burn on both the server and the users part, especially if they leave their window open!!
This seems a bit dangerous on Chromes part. Do you know if a chrome bug-report has been opened regarding this issue?
I think I'm currently being bitten by this issue, but I don't know for sure... something, somewhere appears to be re-requesting the video background of my site every time the video loops. I can't reproduce the issue in my own copy of chrome, it always pulls from the cache. Do you have any tips for debugging this, or do you know which browser(s) are affected by this bug? The video is being served by a CDN so I don't have visibility into where it's being requested from.
I was able to figure out that offending browser for my case was an older version of Chrome, as suspected in this bug report. Unfortunately I don't have the version number, but after it was updated to the latest release, it began pulling the video from the cache -- this Chrome bug may be fixed!
Can confirm this is fixed on the latest chrome if cache headers are set properly
and how do you set cache headers properly?
@aariacarterweir would you mind elaborating?
@aariacarterweir also wondering about this. I'm seeing this behavior as well.
Hi Guys, @tconroy, @ryanschmidt, @luismesejo.
What I mean is that the caching headers need to be set properly on the server. So if you run apache, you would do something like this:
# BEGIN Expire headers
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 5 seconds"
# cache.appcache needs re-requests in FF 3.6 (thanks Remy ~Introducing HTML5)
ExpiresByType text/cache-manifest "access plus 0 seconds"
ExpiresByType application/x-shockwave-flash "access plus 2592000 seconds"
ExpiresByType video/mp4 "access plus 86400 seconds"
</ifModule>
# END Expire headers
Working on a project I noticed the exact same behaviour on Chrome, and not on other browsers, even with a very basic HTML5 video tag (no js library). I narrowed down my code and tested various hostings to the point I can be sure this is just chrome being responsible for this. The cache-control headers only ensures content is fetched from cache instead of server, but still the request occurs on each loop. Now, looking at the airbnb website, they also play a big video seemingly with the same video tag, but the video is only loaded once. I then also tested copying HTML code from airbnb website just replacing the source to my video's , and it had the exact same effect, SO, there MUST be a KS workaround for this...
@Bartdude airbnb combine their videos to one so...
Do you have [√] Disable cache checked in DevTools? Chrome will re-download each time when DevTools is opened when that preference is checked.
Also, if you see (from cache) that means Chrome did not download the content. It fetched it from local cache.
I must say however that even when loaded from cache, a small request is still made to the server that results in a small response with headers only and status 304
This happens with html5 tag and today this is not solved, the best workaround i found is to use base64 for short videos
https://www.iandevlin.com/blog/2012/09/html5/html5-media-and-data-uri
Actually @odamfm this issue seems to have been resolved by Google Chrome. I went back to this website I developed back in 2013 and we haven't updated bigvideo.js since then. Surprisingly enough the video started caching. I was pretty sure my .htaccess was correctly configured and today this is proof that it was the case :)
You have to make sure the correct headers are sent, I have the following properties enabled: etag, expires, last-modified, cache-control (with max-age).

I just checked another client and his too is caching perfectly. Video is over 7.5mb there.
I can attest to the above report from @thejae. Old sites that I've developed 2 years ago are no longer downloading multiple versions. This is great news!
I checked again the headers after your replies @thejae & @ryanschmidt, you are right! i don't know what step i missed but now is working fine.
@thejae @odamfm I have the same issue but my headers in the .htacces don't seem to work. Maybe you could send/show me the part of your header code that works?
I used the same that posted @aariacarterweir a few entries above.
I had the same issue, in my case after some hours of tension i tracked it down to the following:
https://bugs.chromium.org/p/chromium/issues/detail?id=110649 "Any kind of SSL error will prevent us from caching anything from that site"
So check if you develop your site with a faulty certificate. Maybe it will help you out.
Johnny come lately... I was at a complete loss... and to be honest I still don't fully understand I had two identical sites, the broken one was downloading the clip on each loop the other not. After a number of failed attempts to fix it, I "think" I might have found the issue. My html5 video tag was this.
For me adding CACHE MANIFEST did solve the problem. I was using a device with an old browser (safari 5) for video playback and without the cache manifest it was streaming the videos all the time.
<html manifest="cache.manifest">
</html>
cache.manifest content:
CACHE MANIFEST
http://192.168.0.80:8080/video_1.mp4
(...)
For me adding CACHE MANIFEST did solve the problem. I was using a device with an old browser (safari 5) for video playback and without the cache manifest it was streaming the videos all the time.
<html manifest="cache.manifest"> </html>cache.manifest content:
CACHE MANIFEST http://192.168.0.80:8080/video_1.mp4 (...)
This solution is not work for dynamic resources link and cache's limit is 5M...