For a live demonstration see: http://codepen.io/rrorg/pen/WxPjrz?editors=0010
When playing a HTTP audio live stream in Safari, the analyser's getByteFrequencyData fills the Array with zeroes.
In all other browsers this works as expected, and Safari has no problems correctly populating the frequency data for static files.
CORS headers are correctly set, the Apple documentation mentions no special cases.
You're not going to like this: Safari does not support createMediaElementSource.
Source: http://caniuse.com/#feat=audio-api ,
It's due to not support for: http://caniuse.com/#feat=stream
Solution? ...adobe flash :(
Latest Safari nightly webkit seems to have solved this but that doesn't solve the problem for now :/
Related
I'm building an application in React in which I need to record the users' webcam video and audio. Thus far it works in Chrome and Firefox (as expected), but I'm currently trying to find a fallback or a polyfill for Edge and Safari, since I want to be able to support those browsers as well.
Have any been made available? I have not been able to find any information whatsoever in regards to this.
We are building a mobile barcode-scanner using QuaggaJS that reads barcodes directly from the device's camera stream. Works fine on desktop/Android, but doesn't work at all on iOS.
From initial research, I've found that iOS simply does not support WebRTC/getUserMedia through Safari or iOS Chrome (related links below), which is what QuaggaJS uses to read the camera stream.
I've also seen this question about capturing a still image on iOS, but the answer provided is only for capturing a still image, not for reading the stream real-time.
My question - is there any other way to grab the stream from an iOS camera? Perhaps an alternate library other than QuaggaJS that does not use getUserMedia? I am not well-versed in Javascript, so I am not sure if there even is a possible way to access the camera stream other than getUserMedia.
A "no" is an acceptable answer here; I'm simply looking for someone more experienced to provide guidance.
Appendix/related links:
navigator.getUserMedia alternative API for iOS safari mobile browser?
https://www.quora.com/Why-is-navigator-getUserMedia-not-supported-in-Safari
https://bloggeek.me/webrtc-apple-or-microsoft/
HTML5: getUserMedia iOS issue?
2017 update: Apple just announced that getUserMedia will finally be supported in iOS11.
Aug 2019 update: ONLY works in Safari, not in a WebView of any kind. Thanks #Klathmon for the comment.
The quaggaJS page has a feature compatibility matrix which answers your question:
getusermedia is not supported on iOS safari.
As per the quaggaJS documentation (https://github.com/serratus/quaggaJS#browser-support)
Quagga makes use of many modern Web-APIs which are not implemented by all browsers yet. There are two modes in which Quagga operates:
analyzing static images and
using a camera to decode the images from a live-stream. The latter requires the presence of the MediaDevices API. You can track the compatibility of the used Web-APIs for each mode:
Static Images
Live Stream
I would suggest that you use static image mode on iOS as live stream mode is not supported.
I am able to establish WebRTC connection between Firefox and Chrome, but renegotiation between Firefox-Chrome does not work properly.
There is no problem in renegotiation between Chrome-Chrome pair and Firefox-Firefox pair.
With Firefox-Chrome pair, when I start the renegotiation from chrome after removing or adding a track, renegotiation is successful and onremovestream or onaddstream callbacks are triggered on firefox correctly.
But when I start the renegotiation from Firefox after removing or adding a track using pc.removeTrack or pc.addTrack, renegotiation was successful without any error. But in Chrome onremovestream or onaddstream callbacks are not triggered. When I get the MediaStream using pc.getRemoteStreams I can see that tracks' ids are changed after renegotiation, but MediaStream does not work when I tried to play it.
One odd thing I notice is, the actual local track id from Firefox does not match with the remote track id in Chrome (even before renegotiation).
Does Chrome and Firefox support renegotiation across the browsers(mainly from firefox to chrome)?
Have anyone achieved renegotiation between firefox and Chrome?
Is there any workaround for this problem?
This is not a complete solution but the reason why this is happening. I encourage posting an solution if you find one.
There are two plans UnifiedPlan and PlanB for multiple streams in WebRTC. PlanB was dropped and UnifiedPlan is becoming the standard. Firefox implemented UnifiedPlan but chrome still has PlanB implementation. There is an Chromium Bug about this.
There was a polyfill written for this, spd-interop. But this polyfill has a limitation, it supports only renegotiation from Chrome to Firefox.
If I find a workaround for this before chrome fixes the issue, I will update the answer.
I have Firefox nightly, Opera next, and Google Chrome, but I can't test the mouselock API on them (why?). I downloaded a special version of FF nightly, which should support it, but it also doesn't support.
May be an error with my computer?
Thanks in advance,
https://developer.mozilla.org/en/API/Pointer_Lock_API
The Pointerlock isn't supported in any browser.
Our company develops ERP and CRM, and so far our products support IE and Firefox. Now we want to support Chrome, Safari and even Opera. Is there any comprehensive materials that introduce browser compatibility of JS and CSS? thks!
theres the mozilla dev-center that has a great CSS- and JavaScript-reference. Every entry has information about browser compatibility.
For a quick overview, you cauld also take a look at caniuse.com (CSS and JavaScript) that provides simple tabular lists for the different features.
I've been coding the front-end for over a decade and a half now, and things seem to get better over time in regards to cross-browser compatibility. I've found that if I write and test my code using Firefox, most everything will work flawlessly on Chrome, Opera, Safari and the only thing you'll end up having to debug would be MSIE. 10 years ago I would have told you to code and test using MSIE and debug your code in the end with Netscape.
But yeah, if you follow this, you'll find it easier to make all your scripting and markup fully cross-browser compatible with no bugs at all. Enter IE9, of course, a different monster altogether.
Is there any comprehensive materials that introduce browser
compatibility of JS and CSS?
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(Cascading_Style_Sheets)
http://html5test.com/
http://caniuse.com/
"Comprehensive" can change overnight, but there is a great deal of information available.
If your products work for the latest version of Firefox, Chrome, Safari, and Opera will work without major flaws most of the time. If your markup is invalid, you are using many vendor-specific extensions, or you are using cutting-edge features, this may not be the case.