My videos on Amazon S3 will not play through MediaElement.js. I get a black video player with the 'Download File' link. This behavior is consistent on Firefox and Chrome with a variety of video formats (MP4, MOV, OGG).
For each video, the mime type is set correctly on S3 (i.e. not application/octet-stream). When moved to my own server, the same videos load and play fine through MediaElement.js.
In Firebug > Net, I see a GET request status that returns 206 Partial Content for each video loading from S3. I tried appending a timestamp to the URLs to bust the cache, but that didn't work.
I've Googled quite a bit, but came up empty-handed. Any idea what might be the problem?
Update: I get the exact same result using Video.js, so it's obviously not limited to MediaElement.js.
Related
Perhaps this is an unprecedented problem, because I have searched the Internet and there seems to be no feasible solution to this problem.
I'm making a chrome extension for download video. I can inject my javascript into the video webpage on another site. I need to get the cached data or stream played in the <video> with this script, and then save it in blob for downloading.
I've tried MediaSource and captureStream+MediaRecorder, but it doesn't seem to solve my needs. Is there any other API that can realize this function?
I have pre signed URL from Amazon S3 something like below
https://bucketname.s3.amazonaws.com/audios/myfile.wav?AWSAccessKeyId=XXXXXXXXXXXXX&Expires=1556734678&Signature=A1BL1tnidbSM6AGXYwvlA99vXEk%3D
This URL works fine and gives me the audio file. However, browser doesn't really play the file automatically and instead I have to right click, save as WAV file and they play it on my local player.
I want it to be played/streamed then and there on the browser. The browser shows default Chrome audio player, but it stays disabled.
Is there a setting in AWS for this or can I use some audio player libraries to play it or there is different way to get the URL? I have been searching this on the forums but couldn't get a solution that will work for me.
Thanks
I am switching our video player over from normal video sources over to chunked progressive video streaming using mpeg-dash. When using mpeg-dash rather than linking to an actual video source you link to a mpeg-dash manifest file which has all the information about each chunk and allows your player to swap in and out chunks as bandwidth changes. Now all of that seems pretty straight forward, however I am also working on setting up blob urls to obscure our source file location and I am running into issues. How does this work since all the documentation I can find on blob responses are either entirely in JS or return an XMLHttpRequest.
You can see an example here within the dash.js documentation that does exactly what I want http://mediapm.edgesuite.net/dash/public/nightly/samples/dash-if-reference-player/index.html if you inspect the element it has a blob url and loads in chunks but I cannot find any docs on how to do this.
So essentially my question is, how can you get a mpeg-dash manifest file to work in conjunction with the blob url system to obscure source URLs.
I am also working on setting up blob urls to obscure our source file location
I assure you that you're not usefully obscuring anything. The data has to come from somewhere. It's trivial to determine from where no matter how you think you're obscuring it client-side.
Don't bother with this.
How does this work since all the documentation I can find on blob responses are either entirely in JS or return an XMLHttpRequest.
The reason you see blob with web-based DASH players is that they're using MediaSource Extensions (MSE) to get the data in the first place. The video player effectively has a blob source which is managed by the browser. Your JavaScript downloads the chunks and sends them off to the browser to be ran through the codec and output to the video element.
There is a decent MSE example on MDN: https://developer.mozilla.org/en-US/docs/Web/API/MediaSource
I have been trying to get this to run correctly so days now with no luck.
I have created a custom audio player, that accesses an MP3 on a S3 Amazon server. The audio player has custom controls enabled by Javascript, and a Audio Visualizer made possible by the Web Audio API.
Now the problem I am running into is this: Work fine on Chrome. Safari out right says it can't run the Web Audio API, but the audio will still play. In Firefox, the entire thing shuts down. Click play... nothing. I thought it was a CORS issue, so we set the proper headers on the server and still nothing. BUT... if I deactivate the Web Audio API visualizer, then I can get the player to play just fine.
http://jsfiddle.net/murphy1976/yqqf7uL1/1/
Here is my jFiddle. I have separated the Audio Player controls Script from the Visualizer Script with comments so you can see how it will work in Firefox, and how it will NOT work in Firefox.
I read somewhere that this issue that I'm running into MAY be a bug with Firefox. I just want to make sure so that I can stop beating my skull over this.
Could I put a call to CORS here?:
<source crossorigin="anonymous" src="audioFiles/35022797.mp3" id="srcMP3" type="audio/mp3">
The same-origin policy says that scripts run on some origin cannot read resources from another origin. (An origin is a domain, plus a scheme and port, like http://foo.example.com:80.)
Note that the same-origin policy does not prevent cross-origin media from being displayed to the user. Rather, it prevents scripts from programmatically reading cross-origin resources. Consider the <img> tag: a page on example.com can show a cross-origin image from other.com, but a script on example.com's page cannot read the contents of that image. The user can see it; the page cannot.
The Web Audio API can read the contents of audio files. If an audio file is from a different origin, this kind of reading is not allow by the same-origin policy. A user can listen to a cross-origin audio file, but a script on the page cannot read the contents of the file. When you attempt to feed a cross-origin audio file into an analyzer script (e.g., so that you can draw a visualization on a canvas), the same-origin policy should stop you. You are attempting to violate the same-origin policy, and the browser is correctly stopping you by refusing to play the audio in way that would allow you to read the file contents.
Note that Chrome does not prevent such cross-origin file reading for audio files, and this is incorrect behavior.
The correct solution is to have your media servers serve the audio files with a CORS Access-Control-Allow-Origin: * HTTP response header. However, this currently does not work in Firefox, which is incorrect behavior. If Firefox hopes to have a compliant implementation, this will be fixed eventually.
Confirmed that there is a bug in Firefox for using the createMediaElementSource method on a cross domain source:
https://bugzilla.mozilla.org/show_bug.cgi?id=937718
Basically trying to play some live audio streams in an app I'm porting to the browser.
Stream example: http://kzzp-fm.akacast.akamaistream.net/7/877/19757/v1/auth.akacast.akamaistream.net/kzzp-fm/
I have tried HTML5 audio tag and jPlayer with no luck. I know next to nothing about streaming audio, however, when I examine the HTTP response header the specified content type is "audio/aacp" (not sure if that helps).
I'm hoping someone with more knowledge of audio formats could point me in the right direction here.
The problem isn't with AAC+ being playable, the issue is with decoding the streaming ACC wrapper called ADTS. The Audio Data Transport Stream [pdf] or "MP4-contained AAC streamed over HTTP using the SHOUTcast protocol" can be decoded and therefore played by only a couple media players (e.g., foobar2000, Winamp, and VLC).
I had the same issue while trying to work with the SHOUTcast API to get HTML5 Audio playback for all the listed stations. Unfortunately it doesn't look like there's anything that can be done from our perspective, only the browser vendors can decide to add support for ADTS decoding. It is a documented issue in Chrome/WebKit. There are 60+ people (including myself) following the issue, which is marked as "WontFix".