Since this Chrome issue resulted in jPlayer 1.6.0 using the Flash solution for mp3 playback in Chrome 36, I've discovered my mp3s won't play via the Flash plugin. The mp3s play fine via the HTML5 solution in Firefox 30 and IE 11.
Note I'm not interested in fixing playback to use HTML 5 instead of Chrome - the newest version of jPlayer does that. Instead, I want to understand why playback via Flash is not working.
The mp3s are hosted on archive.org.
What I observe when I start playing is that in the Chrome Network inspector, I get one request for the mp3 URL with Status Finished, and then another request for the same URL that sits in Status (pending) forever.
What I see in Firefox from the HTML5 solution is two requests to the mp3 URL that both receive 302 redirects, and then a long running request to the actual mp3 URL which successfully streams the mp3 for playback
jPlayer inspector shows the progress and timeupdate metrics twitching between 3 and 4, and loadstart, play and waiting having all occurred but sit at 0.
So I think the Flash player isn't handling the redirect probably. But I'm unsure of how to go about troubleshooting this issue.
I've created a JSFiddle http://jsfiddle.net/e4WnF/4/ to demonstrate the issue.
I've attempted to use Wireshark to work out what is going on. Whilst with Firefox using the HTML 5 player I see the GET request that results in a 302, I see no sign of this GET request under Chrome.
I've worked around the issue by moving to jPlayer 1.6.4, but this doesn't change the fact that my mp3s will not work in browsers without HTML 5 audio support.
Thanks
This is a problem affecting loads of people, and it's caused by a recent Chrome change, which has now been rolled back, however until that filters through to the updates, you'll need to make some changes. Over at the jPlayer group there are at least ten threads and a jplayer bug ticket about this issue. There's also a Chrome bug tracker ticket about this.
It turns out that jPlayer and other sites like Soundcloud weren't actually sticking to the RFC 3003 spec, and when Chrome tightened up their code, this broke it. Chrome have now rolled back this change, but until that filters through, you can either download the latest jplayer code from github, or make the following immediate change to the jquery.jplayer.js file around line 696 so that it looks like this:
mp3: {
//codec: 'audio/mpeg; codecs="mp3"',
codec: 'audio/mpeg',
flashCanPlay: true,
media: 'audio'
},
Please let me know if this fixes things.
Related
The problem:
On my website mrgigi.me, I have 3 videos that start playing once the videos are visible in the viewport with javascript's .play()/.pause() API.
However, after a few seconds of playing the videos they all freeze on a frame. Checking in the console if the videos are paused with videoID.paused, returns the boolean false.
Meaning that the browser still thinks that the video is playing without any problems.
Using the play/pause buttons also do not work after the video freezes.
A few things to be noted:
This only happens on mobile, on desktop it works perfectly fine.
I am using an iPhone 13 Pro on, at the time of writing, iOS 15.4.1
I tried different mobile browsers which include:
The default browser, Safari
DuckDuckGo Browser
Brave Browser
This only happens when the website is deployed/hosted (so going to the website's domain). It works perfectly fine when using a local server like Live Server
For hosting, I'm using Firebase and Cloudflare
All the code can be found on the GitHub repository: DarthGigi/mrgigi.me
Here are a few videos demonstrating the issue:
Video showing the bug
Video showing the console output
It seems like there was nothing wrong with the code but with the hosting platform I was using, Firebase.
I do not know what the problem exactly was with Firebase, so I switched to Vercel (GitHub Pages would have fixed it too).
Thanks to Jack Latimer for helping me find the cause of the problem and also providing a fix for it!
I'm currently attempting to integrate a custom audio filter on a video player handling both HLS and raw MP4 files. I'm having little to no issue integrating it on Chrome and Firefox - Safari on the other hand is not behaving accordingly. I've stumbled upon an inconsistency in the way safari routes the audio from a createMediaElementSource call.
I've created a small demo to illustrate the problem (Safari ONLY for native HLS support), I've expressedly left out any audio filter code as it has little relevance concerning the main issue :
https://codepen.io/edvincandonus/pen/ZEGVbPG
In the demo, once the audioContext is instantiated and "unlocked" via a user gesture, I create the MediaElementAudioSourceNode via audioCtx.createMediaElementSource(video) and leave it dangling (as in unconnected). As a consequence, the HTMLMediaElement will be re-routed into the processing graph of the AudioContext, and as no connections were made to the audioCtx.destination, audio playback should be missing when video playback starts.
This is the behaviour on Firefox. Chrome goes even further and blocks video playback if the MediaElementAudioSourceNode has no final destination node (try playing the MP4 from the demo on chrome)
As for Safari : this expectation is only met when the video source is a raw MP4 file - But when switched to an m3u8/hls stream, the HTMLMediaElement's audio is not correctly routed to the AudioContext as you can clearly hear the video's sound.
Is this a known safari limitation ? If not, would anyone have any workarounds to correctly access and route the audio from an HLS stream using Safari's native support for this protocol?
I've stumbled upon old stackoverflow answers indicating createMediaElementSource had always been buggy on Safari, but I figure they would have fixed it by now.
I'm using a .mp3 file, the .mp3 file plays okay when viewed directly and also when embeded using the HTML5 audio tag, however when creating the HTML5 audio tag in JS it does not play! (very strange)
I do not have this issue in any other browser/device, for example Desktop - Chrome works perfectly.
sound = document.createElement('audio');
sound.setAttribute('src', 'sound.mp3');
sound.play();
I've tested sound.canPlayType('audio/mpeg') and this produces true (so it is supported).
Perhaps there's a bug in Android - Chrome? (it is the latest version)
Looks like this is intended feature that spans more then just the Chrome browser. User interaction is required to get media elements to play.
Blink and WebKit have a setting for requiring a “user gesture” to play or pause an audio or video element, which is enabled in Opera for Android, Chrome for Android, the default Android browser, Safari for iOS and probably other browsers. This makes some sense, since mobile devices are used in public and in bed, where unsolicited sound from random Web sites could be a nuisance. Also, autoplaying video ads would waste bandwidth. Block Quote from 'blog.foolip.org'
Duplicate Threads from Other Users
Autoplay audio on mobile safari
How can I autoplay media in ios 4.2.1
Autoplay audio with ios 5 workaround?
Current Status
Developers have requested the deletion of 'mediaPlaybackRequiresUserGesture' which was reviewed and denied (for now). "We're going to gather some data about how users react to autoplaying videos in order to decide whether to keep this restriction."
Upon further inspection i found this...
"I misunderstood the outcome of the discussion (removing mediaPlaybackRequiresUserGesture) surrounding this topic. We need to keep this code in order to not break google.com while gathering data about this feature."
Google.com relies on the feature being disabled, otherwise it breaks (they didn't say what it breaks).
Original Bug Report
Try appending it to the document body.
document.body.appendChild(sound);
Though it is possible that mobile devices will not automatically play the audio or videos. If you are targeting mobile devices, autoplaying is considered bad practice since it can consume bandwidth. So it may be worth considering adding controls.
sound.setAttribute('controls', 'true');
OK, well, now that we know it won't work with audio, the only path left to you is to switch to the Web Audio API. You'll need to load the mp3 into an ArrayBuffer (e.g. using an XHR), then pass that to the decodeAudioData method, which gets you an Audio buffer that you can play back at will from an AudioBufferSourceNode.
Not every browser on every platform can play the mp3 audio format. Generally, as I would recommend, you should provide two <source> elements within your audio element, one providing the mp3 format, and another one providing the ogg vorbis format.
You can read more here: https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats
reproduce:
go to http://jsbin.com/bules/1/
open console
go to net panel
see a lot of requests almost every 3seconds from youtube
With open console in chrome it causes memory leak after an hour or so.
Can someone explain why is that happening and why is this call so frequent?
The HTML5 youtube iframe do pulling every ~10 seconds, I guess they are doing it with some sort of socket with Flash and couldn't find a more reliable way to do it with HTML5 (eg: WebSockets are not implemented everywhere).
So this is just part of the normal YouTube HTML5 iframe behavior. Hopefully it will get fixed and replaced by a better system one day.
It's caused by a polling from the player. It checks whether I have my paired smartTV is turned on or not. So it can hide/show the remote-screen button on player.
I found this question when googling to solve the problem. I have the same problem (still, YT haven't solved in a better way). I had requests every ~5 sec. The client (FF) was sending the requests no matter if I had a youtube page up or not.
I found this is solution:
https://support.google.com/youtube/answer/3230451?hl=en
I couldn't manage to turn it off with the instructions for On computer, I had to do it from the TV. And the restart FF to get rid of it.
I'm writing a platform with an audio playback component. Audio is uploaded to the server as an wav/mp3/ogg file, and then (like the rest of our media), converted to base64 and stored within our redis database.
To play the audio back at the client side we make an AJAX request to the server for the base64 encoded audio. We have a desktop version that compliments the mobile application, at the moment audio playback works like this:
recording.sound = new Audio("data:audio/ogg;base64," + recording.audio);
recording.sound.play(); // this works
Today we started our tests on mobile devices, and have so far been unable to get it working, even on mobile browsers that apparently support HTML5 audio.
Any ideas? Or if this is not possible, is there a different approach we can take? Ideally there should be a mobile compatible version of the web app, and there has to be a phonegap version.
The reason might not be a technical one here, from Apple developer site:
In Safari on iOS (for all devices, including iPad), where the user may be on a cellular network and be charged per data unit, preload and autoplay are disabled. No data is loaded until the user initiates it. This means the JavaScript play() and load() methods are also inactive until the user initiates playback, unless the play() or load() method is triggered by user action. In other words, a user-initiated Play button works, but an onLoad="play()" event does not.
same applies to Android devices.
read more here: Safari HTML5 Audio and Video Guide
But „audio/wav“ doesn't exist. See spec here: http://www.iana.org/assignments/media-types/audio
You should use „audio/vnd.dts“ for .wav file, „audio/mpeg“ for .mp3 file and „audio/ogg“ for .ogg file...
OK, try StackOverflow search, see:
https://stackoverflow.com/search?q=audio+codec+support+mobile+devices+html5
or https://stackoverflow.com/search?q=audio+codec+support+mobile+devices+html
or try Google
Some search results, that might be useful:
In search for a library that knows to detect support for specific Audio Video format files
or html5 vs flash - full comparison chart anywhere?