I have been working on a jquery plugin that uses a HTML5 audio player () to play back mp3's. I noticed that in various browsers multiple GET requests were made for the same MP3 file when the audio player was loaded.
I created a simple standalone HTML file to test this out.
<html>
<head></head>
<body>
<audio controls src="http://localhost:5000/files/one.mp3" type="audio/mp3"></audio>
<body>
<html>
When opening the page in OS X Safari 5.0.1, I saw the following logs from my web server (3 GET requests):
>> Thin web server (v1.2.7 codename No Hup)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:5000, CTRL+C to stop
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0022
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0012
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0010
Note, the requests are for "GET /one.mp3" and not "GET /files/one.mp3" because my Thin web server is running off a prefix of /files.
When opening the same HTML file in OS X Chrome, I saw 2 GET requests for /one.mp3.
When opening the same HTML file in OS X Opera, I saw 1 GET request for /one.mp3.
What is the reason for the multiple GET requests for a single files? The bandwidth on my server is limited and I throttle connections at 75KB/s (thats HTTP connection, not user). My worry is if Safari is making 3 HTTP connections to download (stream) a single mp3 file, it will reduce the number of concurrent users my server can handle.
Is this something I should be worried about in terms of performance/bandwidth? Also, I am curious as to why certain browsers make multiple requests for the same file, while other do not.
In the case of Firefox, three requests are made for audio. This is to support playback regions and seeking of media files that aren't downloaded yet. It's essentially downloading the file and determining it's duration in three chunks. The following was given as an explanation when this behavior was reported to Mozilla as a bug:
The first GET reads the first chunk of the ogg file. From this we can ensure it's a valid ogg etc. The data downloaded should be cached by Firefox.
The second GET: Unfortunately Ogg files don't contain their duration, so we terminate the initial download, and we seek to the end of the Ogg file and read a bit of data to extract the time duration of the media.
The third GET: After we've ascertained the duration of the media, we'll resume download of the media. We don't need to redownload data which is already cached, so we resume from wherever the previous download stopped.
Though this explanation only applies to Firefox, you can presume that similar methods are used by webkit browsers as well.
I don't think you should be concerned about this affecting the number of concurrent users. If your server logs showed the timestamp in milliseconds you would see that the three requests fire consecutively and that each request is cancelled before a subsequent request is made.
Is it possible that Safari is making additional requests to fetch metadata? Try different values of the preload attribute to see if it makes any difference:
preload="none" - no data is prefetched (shouldn't see any GETs)
preload="metadata" - basic metadata like duration, bit rate, sample rate, etc. is prefetched (should see one GET)
preload="auto" - the whole file is prefetched (may see multiple GETs)
See http://dev.w3.org/html5/spec/Overview.html#attr-media-preload for a full description of this attribute.
Related
I have audio files in OGG format and embed them with:
<div class="audio-container">
<audio controls>
<source src="/u/audiofile.ogg">
</audio>
</div>
I play the embedded file with Chrome (same issue with Internet Explorer/Edge).
If the file is about 3 seconds long, the progressbar/playbar appears at the beginning as expected:
If the file is longer, in the example 25 seconds, the progressbar/playbar does not work, that means: Clicking on the playbar does not jump to the audio time:
However, after 22 seconds (3 seconds before the end), the playbar suddenly appears and the user can jump through the audio times by clicking on the playbar.
As we can see here, only after the entire OGG file has played (not only loaded, but played) the 206 partial content request suddenly works.
Of course I want that the playbar shows the entire audio length and that navigate-clicking is possible from the beginning.
How to achieve this?
Update:
I have tried a Javascript plugin (green audio player). The player shows up like this:
There is Infinity showing up. So I guess the file length is not sent by the server. And this is strange, because the file is linked directly (file system location).
The response headers look like this (for the 25 seconds file):
My Apache server replies with status code 200 for the first load. When hitting the playbar for a video it does a 206 Partial content request as needed. However, this does not happen when clicking on the audio playbar in Chrome. No request is sent.
Contrary it sends the Accept-Ranges: bytes which should enable seeking through the file:
The Accept-Ranges header indicates that the server accept range requests for a resource. The unit used by the remote web servers is in bytes. This header tells us that either the server supports download resume or downloading files.
I assume that one way of solving this issue is to always supply OGG files with 206 Partial content, already with the first request. But I could not find out yet how to enable this in the Apache server.
Notes:
I read that Apache does 206 by default, but not if caching/GZIP is enabled. So I disabled caching in htaccess (SetEnvIfNoCase Request_URI . (?:mp4|mp3|ogg|webm)$ no-gzip dont-vary) but it still does not work.
Update:
I tried with another OGG file (test.ogg). This one plays and jumping with the playbar is possible without problems!
The OGG files I am using are created by recording them browser-side (Javascript new MediaRecorder(stream);), then send to the server and stored by PHP as OGG file.
Seeing the file properties of the example file:
Seeing the file properites of the test.ogg file:
Obviously, there is meta data missing with the problematic file!
Follow up: How to save MediaRecorder stream to OGG file in PHP? Including Metadata
I have Disable cache tick removed and still request is made on each video loop iteration(Only on chrome).
What Initiator: Other mean in chrome inspector network section? First time the video is loaded from the host, but after that all requests are loaded from Other.
Each iteration video size is the same, not (from cache). Is that mean the browser download it every time?
Can it be avoided somehow without saving the video in localStorage(I saw it in similar question), because this solution will not work in private browser mode and localStorage have size limit?
UPDATE
With Disable cache checked
Without Disable cache checked
UPDATE
Bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=680063
The meaning of this is that another process than Chrome initiated the request:
Some other process or action initiated the request, such as the user
navigating to a page via a link, or by entering a URL in the address
bar.
In the case of Chrome, video is decoded using ffmpeg which likely is this other process. The process is likely reopening the file from the cache which is why the request is initiated, or, the cache only holds the latter part (or max content length in sum) of the file in case the file is large and has to re-stream parts of the content over again - though, you state that when cache is disabled this doesn't happen.
localStorage has a very limited size and is not very suitable for storing video data (it can only hold strings so video must be encoded as mime-64 which increases the size 33% + each char takes up two bytes due to unicode).
A better alternative would be to use IndexedDB - this can hold much larger data as well as store the data in binary format (Blob). But it comes with an initial limit as with localStorage but contrary to the latter method you can request a larger size which the user need to confirm. I haven't tested, but I would assume you will run into the same limitations with private mode as with any other storage mechanism.
Yesterday I had the same issue. I found that Chrome's tab crashes after a couple of minutes. It looks it happens only when Disable cache is checked, but if this still bugs you, you can store the video into the local storage. More code in this answer.
I have a html5 video embedded as follows:
<video controls poster="/wp-content/uploads/2015/12/screenvid1.png">
<source src="/wp-content/uploads/2015/12/Speeltuin-de-Vaan-montage-met-muziek.mp4" type="video/mp4">
<source src="/wp-content/uploads/2015/12/Speeltuin-de-Vaan-montage-met-muziek.mp4.ogg" type="video/ogg">
Your browser does not support the video tag.
</video>
This works fine on the test server. However, it doesn't work on the 'real' server. On this 'real' server, Internet Explorer 11 says "Invalid Source", and Firefox 43.0.4 says "No video with supported format and MIME type found."
I am quite positive that the source file is in the correct map and believe that the browsers find the file, but somehow refuse to play it. At least I don't see how the source file could possibly in the wrong place. It's true that I get the same error message when I change the file path into a non-existing path, but as I said, I don't see how it could be a simple case of 'file not found'. And if it is a case of 'file not found', it's not because the file isn't actually there (unless I'm tragically mistaken of course!)
Note: the only difference in the path for the source file between the two servers is that on the test server the path begins with an extra map '/wptest', because that's the submap the Wordpress site resides in, whereas on the 'real' server it resides in the root folder. After copying the site to the 'real' server, I've made the corresponding change in all relevant places for many files (e.g. images), and the files are always found. I've also checked three times that the file is actually there, in the correct map, on the 'real' server. In fact, let me upload a screen shot of the map structure as it is on the 'real' server (with the video file selected):
http://www.test2468.nl/wptest/Screenshot%20(3137).png
[NB: On this server, the map called 'svvreewijk' always counts as the root folder!]
I've found other questions regarding this error message, but the proposed solutions seem quite complicated (like changing the format with special audio formatting software), and I'm still hoping that the issue is actually simple to resolve - especially given that the video plays without problem on the test server.
Link to the relevant page on the test server: http://www.test2468.nl/wptest/foto-vid/ (video more to the right)
Link to the equivalent page on the 'real' server:
http://www.svvreewijkdevaan.nl/nl/foto-video/
Thanks.
Its definitely the case that the sever is returning a message saying that the file is not available as Sarah says.
Given the info in your question this might be caused by a number of things:
different relative vs absolute paths between test server and real server (although if your other files, images etc work this looks less likely).
the video file is very large - your server or your network may have restrictions on very large files
there may be difference in the servers video serving capability (for example see this similar issue with mp4 on IIS: http://robwillis.info/2012/04/iis-7-404-file-not-found-when-the-file-really-does-exist/)
In first case, file exists:
$ wget --spider test2468.nl/wptest/wp-content/uploads/2015/12/Speeltuin-de-Vaan-montage-met-muziek.mp4
HTTP request sent, awaiting response... 200 OK
Length: 587940629 (561M) [video/mp4]
Remote file exists.
In second case, file does not:
$ wget --spider svvreewijkdevaan.nl/wp-content/uploads/2015/12/Speeltuin-de-Vaan-montage-met-muziek.mp4
HTTP request sent, awaiting response... 404 Not Found
Remote file does not exist -- broken link!!!
I'm having some trouble getting Firefox to cache an exe file that we have on our web site. If I download it with IE or Chrome and start the download a second time then the second download finishes immediately but with Firefox it downloads everything from the start.
I've attached screenshots from the network tab in Chrome and Firefox. Notice that both receive HTTP Status Code 200 but Chrome says (from cache). What response headers do I need to add to make Firefox cache it?
Chrome:
Firefox:
Here's the url if you wish to try downloading it it yourself: https://dlud0tbph7s2n.cloudfront.net/Production/Windows/DegooSetup-Production-1.0.1052.exe.
You can check if the exe file is cached by looking in 'about:cache' or using a tool like HttpWatch.
Your EXE file is not getting cache. In older versions of Firefox that could be due to the file exceeding the maximum size for a single cache entry. By default, the maximum entry size is now 50 MB. You can check this by looking at 'browser.cache.disk.max_entry_size' in 'about:config'.
The problem might be caused by the very large value of max-age that you have set - 2000000000 seconds is about 63 years. The HTTP spec only recommends using periods up to one year and some browsers refuse to cache for very large values of max-age:
https://stackoverflow.com/a/25201898/66911
The recommended maximum value of max-age is 31536000 seconds or less.
I am trying to store a mp4 video file (rather small ~ 2.5MB) in the local app cache.
Manifest looks like:
CACHE MANIFEST
viddy.mp4
Chrome (22.0.1229.94 m) will log the following in the console:
Creating Application Cache with manifest http://example.net/cache.manifest
Application Cache Checking event
Application Cache Downloading event
Application Cache Progress event (0 of 1) http://example.net/viddy.mp4
Application Cache Error event: Resource fetch failed (-1) http://example.net/viddy.mp4
When I click the link right next to the Error it's opening the file quite fine.
My manifest is served with the correct MIME-type (I'm using the HTML5 Boilerplate .htaccess-file) and the video is served Content-Type:video/mp4
Is my file too big? I am perfectly able to cache a 1MB image this way, so I thought filesize should not be a problem? Safari on desktop and iPad does cache the video just fine.
Remark: I have seen this question but it does not cover my problem as the solution seemed to be something Python-related.
Chrome does not allow data to be stored in Incognito Mode.
I experienced similar problem and this is how I solve it. In this case Chrome does not give any helpful information about error. I've tried to load same page in Safari (Mac, but Windows should work as well), and I got description, that response for specified resource returns 302 (Redirect) and HTML5 Application Cache cannot handle it.
In your case it might be the same, but I'd suggest you to enable the sniffer and see, what response you get from your resource. If it's different than 200 - you figured the issue.
P.S. I've cached files up to 32 MB without any problems.