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!!!
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 think I have exhausted every avenue in trying to solve an issue whereby an HTML5 video won't play on my site. I have a simple demo page (below) to demonstrate where I am. I originally had a video in various formats for different browsers but for easier testing I am now just working with webm and testing in Chrome (Version 41.0.2272.89 (64-bit) on Mac OSX Yosemite). You will see the basic markup from the page above.
Demo 1 - .webm video hosted locally on the server - No video playing
I have tested the following:
Video file itself is accessible (cURL shows 200 response header)
Video file has correct MIME type (cURL shows video/webm set by .htaccess)
Video file has ok permission (644)
...so unless I am missing something obvious the markup is fine (for the browser I am testing) and the file itself is available and in the correct format.
OK, so the issue must be with the file itself then? Perhaps a codec issue or something, maybe something corrupted in the compression? Well, I don't think so...
The file came from an external source and if I embed it directly from the third-party's server it works fine. Check out this demo which is identical in markup other than the fact the video file is hosted externally:
Demo 2 - Same markup but video hosted elsewhere
Works fine for me!
So to confirm, the markup is the same in each case, the file when hosted externally loads fine, the exact same file when downloaded from the external source and uploaded to my server and referenced locally does not work.
I can only think that my testing here has ruled out issues with the video file itself and also with the HTML. It must be a server config issue with the parsing of the file surely? But, with the 200 response, the correct MIME type added via .htaccess and correct permissions I don't know what else to try.
Is everyone else seeing the same issue? What else should I be checking?
Thanks all!
For anyone else with HTML5 Video not displaying as expected check the following:
MIME types are supported
Rule out issues with the video file itself
Check your server for support of range request
In this case Apache 2.2.23 did not support an empty range request. The option is to update Apache to 2.2.27 as detailed in the following thread Range: bytes 0- FAILS in Apache 2.2.23
Thanks to Pablo Montilla for the guidance!
I think your problem lies in byte range support.
If you use curl:
curl "http://alkemist.partners/video-js/small.webm" -H "Range: bytes=0-"
You'll see the Empty reply from server response, but if you remove the Range header, your server returns the file correctly.
Every time I try to view a video file on my server I get this error on iOS in Safari, Chrome.
I am using a blob server and then an Apache server so I am not sure what the problem is. However, when I only use Apache, I do get this error but then I have the video rendering too.
However when I render this using my server this is not working. Does anyone know why this is? The videos work fine on other devices and in browsers also works fine if accessed through Apache only.
The solution to this problem was just a work around. The reason being the that blob servers aren't streaming servers. iOS devices expect the videos to arrive in small chunks. So for instance a streaming server is able to do this. However, a blob server just hands the video as a blob which is not what the iOS device expects. Some browsers are smart enough to handle this but others not.
The way I solved this was to add the video files outside of the blob server in a folder within the project and then render this through the Apache server instead of serving it via the actual blob server we were using. I hope this helps.
I was also getting this error for some mp4 videos. Turns out it wasn't a server issue for me it was a video encoding issue.
Issue
A "moov atom" needs to be placed at the front of the video file. It serves as a table-of-contents for the video. That "moov atom" has to be read first for html streaming or it won't play on some devices.
The Fix
To fix, I used handbrake to transcode my video. Turn on 'web optimize' Also turning on zerolatency and 'fast decode' may help (found in the video tab).
We were getting a similar error here. I thought it may have been the streaming issue since our video was hosted in blob storage on Azure. After setting up a Media Service for streaming, the video still didn't work. It turns out, the cause of the bug for us was Safari using a Service Worker. Below is some further explanation of what we found:
Safari first sends a byte range request for a Video tag that expects a 206 response. However, if you use a Service worker, the response returns with a 200 and it appears Safari doesn't know how to handle this. Our solution was to exclude using a Service Worker for Safari.
We found this by using the network tab of the Safari debugger on a Macbook to troubleshoot the issue we were seeing on the iPad. Attached is a screenshot for comparison/reference. The left tab shows what the call should look like by default. The right tab shows what you would see if using a Service Worker.
Add the following line of code to your .htaccess (located in the root of your WordPress installation):
SetEnvIfNoCase Request_URI .(?:mp4)$ no-gzip dont-vary
The following screenshot is the new complete .htaccess
Reference: https://clickshepherd.com/blog/solved-elegant-themes-divi-and-cloudflare-mp4-media-error-formats-not-supported-or-sources-not-found/
In our case, we created a URL pattern for our blob assets and then set headers in that URL pattern definition page which sent back a mime type of 'video/mp4'. This should instruct the browser to treat the binary stream as chunked, which in turn meant we didn't need to download the whole thing before it started playing.
Google Cloud Platform Solution
This issue caused me a lot of headache, so I just wanted to add my specific solution here, if anyone else encounters this while deploying to Google Cloud Platform.
When trying to load MP4 videos in Safari, I was getting the same error:
"Failed to Load Resource, Plugin Handled Load"
Which was preventing the videos from playing.
Still, I wanted to try to keep everything inside Google Cloud, so I created a Storage Bucket for the site, and added the videos there.
Of course, trying to retrieve the videos from the storage URL from the main site resulted in a CORS error.
Fortunately, you can configure CORS pretty easily on storage buckets:
Configuring cross-origin resource sharing (CORS)
Once that configuration was deployed, I was able to retrieve and load the videos on the site in Safari without the "plugin handled load" error.
I saw the error "Failed to Load Resource" and though that this is reason, why my videos are not playing.
Turned out, my videos were missing the hvc1 tag. And when I added it - they're playing fine.
In my case issue was with H256 HEVC videos, but in your case some other encoding / tagging issues can be the reason.
In my case, issue was fixed with ffmpeg:
ffmpeg -i input.mp4 -tag:v hvc1 -acodec copy -c:v copy -movflags faststart out.mp4
I am seeing, in firebug, that my .ogv video(770KB) is being downloaded in several partial content requests while if I replace this with another video(1.7 MB) that I got from somewhere else then this is downloaded always in a single request.
What may be causing this ?
I think it's just firefox trying to be smart. I would not worry about it.
By reading https://developer.mozilla.org/en/Configuring_servers_for_Ogg_media and https://bugzilla.mozilla.org/show_bug.cgi?id=502894#c1 I think firefox first start downloading the file, then if it finds the file header doesn't contain the duration of the movie, it downloads the last part of the file, which contains the timestamp of the last frame, after that it will continue downloading where it stopped at the beginning of the file.
My guess is the other file has the duration coded in the header somehow, or, if you are hotlinking it from some other server, that the other server is not supporting http-ranges
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.