I am trying to get my video with crossorigin attribute play in Chrome (version 20.0.1132.47 m). It does not even load. The network panel shows that the OPTIONS (so called "preflight") request gets aborted by the browser for some reason.It works without the crossorigin attribute. Firefox loads and plays it successfully. I would appreciate any suggestions.
<video
id='vid'
autoplay
crossorigin
src='http://videos-cdn.mozilla.net/serv/mozhacks/demos/resources/immersivevideo/dubai.r.webm'>
</video>
http://jsfiddle.net/ZVgr2/
The cause of this turned out to be missing Access-Control-Allow-Headers response header with the list of HTTP headers that matches the list passed in Access-Control-Request-Headers request header.
In the video tag set crossorigin to "anonymous" like this:
<video crossorigin="anonymous"></video>
In case this is helpful to anyone else, I was having the same issue after supposedly fixing the CORS settings on the source file. Turns out Chrome was caching the CORS setting along with the file, so I had to clear the cache and then it worked.
Related
Is it possible to play a video via the HTML5 video tag using HTTPS as the video source? Our page is entirely in HTTPS, however when you browse we are getting the mixed http/https mode message. The video configured to use HTTPS as the source is changing to HTTP somehow. We don't see any 302 redirects coming from the web server. Is this browser dependent? We've tried all possible browsers. Code snipplet below from the developer tool output.
<video id="homepageCenterVideo_html5_api" class="vjs-tech" preload="auto" data-setup="{}" poster="/CMSImages/static_image.jpg" src="https://www.domain.com/Video/Makes_It_Easy.mp4" controls="">
<source src="https://www.domain.com/Video/Makes_It_Easy.mp4" type="video/mp4">
</video>
If you were to copy that URI and paste it into the URL bar, you can see that it changes from https to http and we still don't see any 302 redirects coming from the server.
We got the HTML5 video to work using HTTPS, however we still don't know why. The back-end server is IIS. The directory housing the video file is named "video". If we change the name of that directory, or put the video file in another directory it's able to stream using HTTPS just fine. If we rename the directory back to "video" it won't work and uses HTTP. Very weird, but we're assuming it has something to do with IIS settings somewhere.
I ran into this peculiar problem that I couldn't get HTML5 video to loop on my local development environment (ASP.NET + IIS7). The video autoplays just fine. My code looks like this:
<video id="frontpage-video" autoplay loop>
<source src="http://test-site:8084/video_mp4.mp4" type="video/mp4">
<source src="http://test-site:8084/video_webm.webm" type="video/webm">
</video>
If I change video source URLs to some publicly available URLs (for example to dropbox), loop works just fine. This is not a major problem since I think (hope) it will work once my site goes live and the video is publicly available.
My question is: Can I make the video loop if my video is not publicly available?
I couldn't find similar problems by googling. Could it be some kind of IIS setting that prevents videos to loop?
Update 1: The problem seems to occur only in Chrome. Firefox and IE works fine.
Update 2: It seems that the video will stop at the end but never returns true for element.ended
> document.getElementById('frontpage-video').duration;
< 16.12
> document.getElementById('frontpage-video').currentTime;
< 16.12
> document.getElementById('frontpage-video').ended;
< false
Update 3: Problem is either in IIS or in Telerik's Sitefinity CMS. Server should send a "206 Partial Content" status but instead it sends 200 OK. Has any Sitefinity users had this problem and know how to solve it?
It looks like your problem is that you're not using HTTP Byte Serving. Your server is sending a "200 OK" response, but it should be sending "206 Partial Content" along with these headers:
Accept-Ranges:bytes
Content-Range:bytes 0-1492370/1492371
The byte range request allows the browser to request only the portions of the file that it needs. So if you seek around, it can skip right to that point.
With the regular 200 response, you will usually at least find that you can't seek in the video. But, depending on how your video file is encoded and where in the file the metadata is placed, you may see more problems. Sometimes the file might not even play at all. WebM is usually more robust than MP4, which can be all over the place.
I don't know IIS well enough to tell you how to configure it, but try starting here:
http://blogs.visigo.com/chriscoulson/easy-handling-of-http-range-requests-in-asp-net/
Chrome/Opera can't loop the video if the video itself is not served with HTTP 206 Partial Content response but 200 OK instead.
The problem is that Sitefinity's storage providers do not support partial content (version 7.0). They are planning to implement this for the future.
At the moment the possible workaround is to use an external blob storage provider such as Azure, Amazon or ExternalFileSystem (ExternalFileSystemStorageProvider).
I got this information from Sitefinity's support team.
May be MIME type in IIS is not set up for MP4.
Open IIS, and locate you default page. You'll see MIME type in right pane.
Click Add and put field1=.mp4 and field2=video/mp4.
Restart IIS.
Hope this might work.
In your question, your video-element doesn't have the id frontpage-video (but i guess it's copy paste?)
check if the video end event is called in your webkit browsers, and if so, restart your video.
.
<script type='text/javascript'>
document.getElementById('frontpage-video').addEventListener('ended',myHandler,false);
function myHandler(e) {
if(!e) { e = window.event; }
//restart your video
}
I'm new to using the audio tag in HTML 5 and wanted to build a player. I wanted to test using a VTT file in a track tag to see how closed captioning could work.
Here is my code:
<audio controls>
<source src="myaudio.mp3" type="audio/mpeg">
<track kink="caption" src="myaudio.vtt" srclang="en" label="English">
</audio>
According to what I've read, track is supposed to work for both audio and video, which makes sense from an accessibility stand-point. What doesn't make sense is the error I get trying to load it:
"Text track from origin 'file://' has been blocked from loading: Not at same origin as the document, and parent of track element does not have a 'crossorigin' attribute. Origin 'null' is therefore not allowed access."
When looking up the crossorigin attribute, I get a lot of confusing articles about CORS and the expected values of "anonymous" and "user-certificate". Trying either results in a similar error.
Any ideas as to why this won't work?
This is an old post, but the first I hit when Googling for Text track from origin 'SITE_HOSTING_TEXT_TRACK' has been blocked from loading: Not at same origin as the document, and parent of track element does not have a 'crossorigin' attribute. Origin 'SITE_HOSTING_PAGE' is therefore not allowed access.
The OP seems to be having this issue locally and he could fix that by disabling Chrome's web security as shown above. But users will more often see this when accessing their text tracks from a different domain. To fix it in a production environment for all users, you need to do two things:
Add the right CORS headers to the site hosting the VTT file.
Add the crossorigin="anonymous" attribute to your site's audio/video element.
If you do not have access to the site hosting the video file, you might be stuck. But if you do, you should add the header Access-Control-Allow-Origin:'*'. I'm handling it on a Node/Express server like this:
var app = express()
app.use(function (req, res, next) {
res.header('Access-Control-Allow-Origin', '*')
res.header('Access-Control-Allow-Headers', 'Origin, X-Requested-With, Content-Type, Accept')
next()
})
The audio/video element is an easier fix. In your site's HTML page, add the following crossorigin attribute.
<audio controls crossorigin="anonymous">
<source src="myaudio.mp3" type="audio/mpeg">
<track kind="caption" src="my_file_hosted_on_a_different_domain.vtt" srclang="en" label="English">
</audio>
I hope this answer helps someone... it was an annoying issue to troubleshoot.
See here for an update list of browser with native WebVTT support. If your browser does not support native CC as WebVTT you have to construct your own parser in JavaScript to display them (note there are other CC format like SRT and TTML/DFXP).
You can find reliable information about the track element here and here. Note that there is a difference between what is referred to as subtitles, captions and descriptions.
Most browsers won't support a track tag when used with an audio tag - though in theory they should - you will find practically it does not work as of today. Maybe it has something to do with WebVTT meaning Web Video Text Tracks. This is described here.
You have to build your own parser if you want to display your closed captions along an audio tag. I would suggest you take a look at the source of mediaelementjs to get an idea on how to tackle this.
CORS is only required when you are requesting CC files that are not on the same domain as the page hosting the audio/video tag. It should not be necessary in your case. More about CORS.
Your error message seems to indicate you have a misconfiguration somewhere in your system (maybe your vtt file is on NFS?).
I've been dealing with the same issue: the media player works fine, but the closed captioning file runs into cross-domain issues. Some browsers choke, others do not. Some browsers want a specific CORS policy and will not accept a wildcard in the allowed origin. And that makes my life complicated.
We could store the caption files on our primary content server. But we prefer to maintain the video and caption files in the same location (in my case, on Amazon Web Services S3/CloudFront). To get around the CORS complications, we built a small server-side script to grab the tiny caption files from the CDN. That eliminates all cross-domain issues.
https://github.com/videogular/videogular/issues/123
Add crossorigin="anonymous" to the video tag to allow load VTT files
from different domains.
It is a strange issue, even if your CORS is set correctly on the server, you may need to have your HTML tag label itself as anonymous for the CORS policy to work.
Here's how I get this working in my web-component (lit-html based) by fetching the webVTT via a seperate HTTP call and injecting the content into the SRC property of the <track> element whenever the subtitle/metadata track changes or is rendered:
<video class="video__player" #click=${e=> this._onVideoPress(e)}
poster=${this.poster}
preload="auto"
>
<source src=${this.URL} type="video/webm" />
<source src=${this.URL2} type="video/mp4" />
<track
default
kind="metadata"
type="text/vtt"
#cuechange=${e => this._doSomething(e)}
src=${this.metadata}
/>
</video>
updated(changedProperties) {
if (changedProperties.has('metadata')) {
const tracks = this.shadowRoot.querySelectorAll('track');
tracks.forEach(track => this.loadTrackWithAjax(track))
}
}
// eslint-disable-next-line class-methods-use-this
loadTrackWithAjax(track) {
const xhttp = new XMLHttpRequest();
xhttp.onreadystatechange = function () {
if (this.readyState === 4 && this.status === 200 && this.responseText) {
// If VTT fetch succeeded, replace the src with a BLOB URL.
const blob = new Blob([this.responseText], { type: 'text/vtt' });
track.setAttribute('src', URL.createObjectURL(blob));
}
};
xhttp.open('GET', track.src, true);
xhttp.send();
}
My videos and tracks are stored in the same firebase storage bucket but the browser refused to load the tracks even when changing the CORS and crossorigin settings (which stopped even the videos from loading).
I faced a multitude of error and I'm listing all of them here just in case if it helps someone:
First error related to CORS exactly same OP as mentioned in his question.
Text track from origin 'file://' has been blocked from loading: Not at
same origin as the document, and parent of track element does not have
a 'crossorigin' attribute. Origin 'null' is therefore not allowed
access.
The problem was that I was loading my html file in browser directly from disk so when it tries to access the vtt file then browser gets a feeling of cross origin request and hence the error. You can get rid of this error simply by hosting your web page inside a web server like IIS. It is a 2-minute job to create a website in IIS. Or you can simply add a new application inside the existing "Default Web site" which comes with default installation of IIS.
The moment you start fetching your html page like a website all the files like video, or *.vtt are all relative so issue of CORS gets resolved.
After CORS issue got resolved I started getting below error for *.vtt file:
Failed to load resource: the server responded with a status of 404
(Not Found)
Now this issue relates to the fact that *.vtt is an unknown file type for IIS and your IIS is not configured to server any resource with extension .vtt. For this you need to configure the MIME type for your web application in IIS with below details:
File Name Extension: .vtt
MIME type: text/vtt
This resolved my file not found error.
Now no errors were being shown in the developer tools console tab but my subtitles were still not getting shown. Then came the final trick. I had forgotten to mention default attribute in my track tag as shown below. It is a mandatory hint for the browser to pick up the appropriate vtt file:
<track label="English" kind="subtitles" srclang="en" src="./data/abc.vtt" default />
Now my subtitles finally worked :)
You might want to add the following lines in your Web.config if you get a "404: not found" error:
<system.webServer>
<staticContent>
<remove fileExtension=".vtt" /> <!--REMOVES SERVER .vtt extention if it exists-->
<mimeMap fileExtension=".vtt" mimeType="text/vtt" /> <!--ads it again (needed when debuging)-->
</staticContent>
</system.webServer>
</configuration>
Note that .vtt is not supported from scratch, and thus Chrome (among others) blocks the content for security reasons.
i solve this problem using Blob !
(async () => {
const result = await axios({
url: `http://ROUTE_TO_YOUR_VTT_FILE`,
method: "get",
responseType: "blob",
});
playerRef?.addRemoteTextTrack(
{
src: URL.createObjectURL(result as Blob),
mode: "showing",
id: subtitle.languageId,
language: subtitle.languageName,
kind: "subtitles",
default: true,
label: subtitle.languageName,
srclang: subtitle.languageName,
},
true
);
})();
Does anyone know if Safari supports crossorigin attribute on the HTML5 <video> tag? I serve video from a server that responds with all needed CORS headers, and I use the markup below to embed the video to my page. The page is served from a different domain.
<video controls crossorigin="anonymous" src="http://example.com/movie.mp4">
I then draw the video to a canvas and get the image from the canvas using toDataURL API. This works in Chrome and Firefox, but Safari throws the security error as if there were no crossorigin attribute on the video.
Any ideas?
It appears that Safari does not support the crossorgin attribute, but I can't find anything official. There is this tweet https://twitter.com/sonnypiers/status/187513545397776384 with a work-around for images, but I don't think it helps for video.
From our tests we safari did not support crossdomain. We are adding crossorigin attribute to use CORs in audio requests (will report how does that goes).
Funny how crossdomain seemed to work fine under http but not under https. If you read the w3 spec for audio/video tags (called media tags) it does say they subjected to cross-domain restrictions.
Support of CORS in audio tag:
https://developer.mozilla.org/en-US/docs/HTML/CORS_settings_attributes
Now, other interesting fact is that safari was choosing the myme type based on the file extension (what?). A file with *.mp4 as an extension played fine. Same file renamed to something else did not.
Here's the workaround for video:
$.ajax({
type: 'get',
url : videoUrlFromAnotherDomain,
crossDomain: 'true',
success: function(data) {
// get a base64 version of the video!
var base64 = window.btoa(data);
// get a new url!
var newURL = 'data:video/mp4' + ';base64,' + base64;
// set the src on the video source element to the new url
video.find("source").attr("src", newURL);
}
Substitute whatever type of video it is for "video/mp4" in newURL.
At first, do you need CORS?
Linking to it directly seems to work in safari. I tried it using htmlinstant.com
<video src="http://www.quirksmode.org/html5/videos/big_buck_bunny.mp4" controls />
If you need CORS, then the following page says that support for it was added in May 2011. Haven't tested it though.
https://developer.mozilla.org/en-US/docs/HTML/CORS_settings_attributes
For an example with video on canvas, see section 5.4 at this link:
http://www.html5rocks.com/en/tutorials/video/basics/
I tested and it runs in my safari.
For an internal website, I'm trying to show an inline video of an avi file on the network.
<video class="VideoTagLink" src="file://\\network\path\file.avi" controls="controls"></video>
In IE9 I get a red X and Chrome only shows a play button -- is this a supported scenario in HTML 5?
edit:
I have changed my html to this:
<video class="VideoTagLink" controls="controls">
<source src="http://localhost:99/Handlers/GetVideo?path=\\network\path\file.avi" type="video/x-msvideo">
</video>
and my handler is just:
public ActionResult GetVideo(string path)
{
return base.File(path, "video/x-msvideo");
}
So I believe i'm sending the right content type. I verified in IIS that *.avi is mapped to video/x-msvideo. If I navigate to that src URL directly in either browser, I get a download prompt for the video file, so I assume that works fine.
See HTML5 Video Error - Internet Explorer 9. This happens because IE9 cannot determine the content type, and your file server is not sending a Content-Type header.
If you serve the file via HTTP, you can configure your web server to specify the correct content type.