I have this javascript audio player which plays mp3 files. On FF v23.0.1 (Mac) it doesn't work (the reason for this is explained everywhere and here)
What I don't understand is, if I point the URL directly to the mp3 file FF shows its own player and the song plays just fine. But when using the javascript Audio API
var audio = new Audio('/my-song.mp3') ; // --> HTTP “Content-Type” van “audio/mpeg” not supported
audio.autoplay = true ;
it doesn't work. Can someone explain to me why this is ?
Thnx
The error is (note that I've translated it to english): HTTP “Content-Type” of “audio/mpeg” is not supported.
Your Firefox build does not seem to support MP3 yet.
The player that is shown when directly browsing the .mp3 might be just some plugin handling the Content-Type, such as QuickTime, VLC, etc... That won't fly when using that file in an <audio> element, though.
See the "Media formats supported..." article for information on what codecs are supported by what version of Firefox on what platform.
Related
I'm implementing a WebRTC Audio chat. I have everything working, and was initially using <audio> elements to output the audio, which worked fine.
But then I wanted to implement a "Speaking indicator" feature, and decided to go with AudioContext.
It works, in Safari + Firefox, but no Chrome. I just don't get any output.
This is my code:
const audioContext = new AudioContext();
// Create an audio source node from the stream received by the
// RTCPeerConnection with peerConnection.ontrack()
const audioSourceNode = audioContext.createMediaStreamSource(stream);
// Connect the audio source to the destination
audioSourceNode.connect(audioContext.destination);
Am I missing something? Do I need to somehow use an <audio> element to get sound on Chrome?
It's an old known bug in Chrome that wasn't fixed so far.
A common workaround is to create a muted <audio> element to make the audio flowing (it can be deleted after). See this answer for an example.
I'm looking for a solution to fully preload an html5 video so that I can play it through and seek to different times without any risk of buffering. I've seen solutions that involve using xhr to download the video file as a 'blob' type and subsequently construct a url to that blob using the createObjectURL method. This is the code example in the solution I mentioned above:
var r = new XMLHttpRequest();
r.onload = function() {
myVid.src = URL.createObjectURL(r.response);
myVid.play();
};
if (myVid.canPlayType('video/mp4;codecs="avc1.42E01E, mp4a.40.2"')) {
r.open("GET", "slide.mp4");
}
else {
r.open("GET", "slide.webm");
}
r.responseType = "blob";
r.send();
This works for me in Chrome and Firefox, but not in Safari when using a video hosted on a CDN. This solution does work in Safari if I use a video hosted on the same server. I found this Safari bug, although I'm not sure if the bug is still valid. There's no mention of the Safari bug on the page with the above solution. I've seen another method which essentially pauses the video and waits for it to buffer to 100%, but Chrome doesn't seem to ever fully buffer the video.
I looked into PreloadJS, which apparently supports video preloading, but I couldn't find any working examples. I also looked into html5Preloader, but again I couldn't figure out what to do once the finish event was fired.
I'm not sure if it makes any difference, but I'm using Videogular to play my video, which needs to be fed a video url. I suppose if I use some preloader library such as PreloadJS or html5Preloader, which I'm guessing would in turn use xhr for video, I would need access to a new blob url in my finished handler.
Has anyone come up with a video preloading solution that works in Safari? Thanks in advance.
It turns out the problem was being caused by the content type response header on the videos coming from Amazon S3. They were set to octet-stream, which Chrome and Firefox were able to handle, but Safari threw a media error 4. Changing the content type in the Amazon S3 admin site to 'video/mp4' solved the problem for me.
More info about Safari and octet-stream here in the 'Known issues' tab: http://caniuse.com/#feat=bloburls
I'm attempting to display a video in Firefox. The video has to be in MP4, converting the video isn't an option. However this will only work in some situations as Firefox relies on OS level support for MP4, rather than built in support.
It's ok that it won't always work, but I want to be able to detect when it will fail.
I've tried several existing solutions on StackOverflow ( How to check if the browser can play mp4 via html5 video tag? )
My current testing code reads:
var mp4Supported = (!!document.createElement('video').canPlayType('video/mp4; codecs=avc1.42E01E,mp4a.40.2'));
if (!mp4Supported) { console.log("MP4 not supported") } else { console.log("MP4 supported") };
However since Firefox now does (technically) support MP4, this seems to always return true, whether the video can be decoded or not.
Console output from the above on Firefox where there's no native support for MP4:
"MP4 supported"
Media resource <My resource URL> could not be decoded.
Does anyone know of a reliable way to detect successful running now that Firefox has partial support?
The following JavaScript running in canvas should play audio fine:
var audio = new Audio('tune.wav');
audio.play();
Most of the time it does work, the wav is 24bit 14100kbps and plays fine on several machines, but on my laptop (Win7, using Firefox 22.0) I get the error:
HTTP "Content-Type" of "x-unknown/unknown" is not supported. Load of media resource file:///C:/code/sound/tune.wav failed.
I'm aware that there are other libraries to play sound, but I want to keep this pure JavaScript and since it works fine on other machines it might be a hardware problem.
But I am able to play other audio files fine, so I'm not sure what's going wrong here. Any ideas?
Hmm. Based upon my experience with the JS Audio elements, you're missing a line.
var audio = new Audio('tune.wav');
audio.load();
audio.play();
I don't think that's causing the error though. Based upon the responses to this question:
Firefox won't play .WAV files using the HTML5 <audio> tag?
and the back-and-forth in this forum: https://bugzilla.mozilla.org/show_bug.cgi?id=524109 (comment 7)
It looks like Firefox simply doesn't support 24-bit WAVE files. 16-bit is probably a safer option.
Neither Safari or Firefox are able to process audio data from a MediaElementSource using the Web Audio API.
var audioContext, audioProcess, audioSource,
result = document.createElement('h3'),
output = document.createElement('span'),
mp3 = '//www.jonathancoulton.com/wp-content/uploads/encodes/Smoking_Monkey/mp3/09_First_of_May_mp3_3a69021.mp3',
ogg = '//upload.wikimedia.org/wikipedia/en/4/45/ACDC_-_Back_In_Black-sample.ogg',
gotData = false, data, audio = new Audio();
function connect() {
audioContext = window.AudioContext ? new AudioContext() : new webkitAudioContext(),
audioSource = audioContext.createMediaElementSource( audio ),
audioScript = audioContext.createScriptProcessor( 2048 );
audioSource.connect( audioScript );
audioSource.connect( audioContext.destination );
audioScript.connect( audioContext.destination );
audioScript.addEventListener('audioprocess', function(e){
if ((data = e.inputBuffer.getChannelData(0)[0]*3)) {
output.innerHTML = Math.abs(data).toFixed(3);
if (!gotData) gotData = true;
}
}, false);
}
(function setup(){
audio.volume = 1/3;
audio.controls = true;
audio.autoplay = true;
audio.src = audio.canPlayType('audio/mpeg') ? mp3 : ogg;
audio.addEventListener('canplay', connect);
result.innerHTML = 'Channel Data: ';
output.innerHTML = '0.000';
document.body.appendChild(result).appendChild(output);
document.body.appendChild(audio);
})();
Are there any plans to patch this in the near future? Or is there some work-around that would still provide the audio controls to the user?
For Apple, this something that could be fixed in the WebKit Nightlies or will we have to wait until Safari 8.0 release to get HTML5 <audio> playing nicely with the Web Audio API? The Web Audio API has existed in Safari since at least version 6.0 and I initially posted this question long before Safari 7.0 was released. Is there a reason this wasn't fixed already? Will it ever be fixed?
For Mozilla, I know you're still in the process of switching over from the old Audio Data API, but is this a known issue with your Web Audio implementation and is it going to be fixed before the next release of Firefox?
This answer is quoted almost exactly from my answer to a related question: Firefox 25 and AudioContext createJavaScriptNote not a function
Firefox does support MediaElementSource if the media adheres to the Same-Origin Policy, however there is no error produced by Firefox when attempting to use media from a remote origin.
The specification is not really specific about it (pun intended), but I've been told that this is an intended behavior, and the issue is actually with Chrome… It's the Blink implementations (Chrome, Opera) that need to be updated to require CORS.
MediaElementSource Node and Cross-Origin Media Resources:
From: Robert O'Callahan <robert#ocallahan.org>
Date: Tue, 23 Jul 2013 16:30:00 +1200
To: "public-audio#w3.org" <public-audio#w3.org>
HTML media elements can play media resources from any origin. When an
element plays a media resource from an origin different from the page's
origin, we must prevent page script from being able to read the contents of
the media (e.g. extract video frames or audio samples). In particular we
should prevent ScriptProcessorNodes from getting access to the media's
audio samples. We should also information about samples leaking in other
ways (e.g. timing channel attacks). Currently the Web Audio spec says
nothing about this.
I think we should solve this by preventing any non-same-origin data from
entering Web Audio. That will minimize the attack surface and the impact on
Web Audio.
My proposal is to make MediaElementAudioSourceNode convert data coming from
a non-same origin stream to silence.
If this proposal makes it into spec it will be nearly impossible for a developer to even realize why his MediaElementSource is not working. As it stands right now, calling createMediaElementSource() on an <audio> element in Firefox 26 actually stops the <audio> controls from working at all and throws no errors.
What dangerous things can you do with the audio/video data from a remote origin? The general idea is that without applying the Same-Origin Policy to a MediaElementSource node, some malicious javascript could access media that only the user should have access to (session, vpn, local server, network drives) and send its contents—or some representation of it—to an attacker.
The HTML5 media elements don't have these restrictions by default. You can include remote media across all browsers by using the <audio>, <img>, or <video> elements. It's only when you want to manipulate or extract the data from these remote resources that the Same-Origin Policy comes into play.
[It's] for the same reason that you cannot dump image data cross-origin via <canvas>: media may contain sensitive information and therefore allowing rogue sites to dump and re-route content is a security issue. - #nmaier
createMediaElementSource() does not work properly in Safari 8.0.5 (and possibly earlier) but is fixed in Webkit Nightly as of 10600.5.17, r183978