HTML5 how to check if user has viewed the entire video? ie, without skipping through. It is straightforward on desktop based browsers, though iOS allows playback control even when you do not explicitly enable it. Therefore, simply listening to the 'ended' event is not accurate.
Try this in iOS. I can only test in Chrome and Firefox:
Use the seeked event
vid.addEventListener("seeked", function() {
}, false);
Additionally, if you only want to detect the user seeking forward, keep track of the playback position by listening to the timeupdate event and reading the currentTime property.
See this JSFiddle
Related
Though I only play audio in response to clicks, I initialize the AudioContext and buffers and such when the script loads.
In mobile Chrome 57.0.2987.132 the console shows the following warning when loaded from an iframe:
An AudioContext in a cross origin iframe must be created or resumed
from a user gesture to enable audio output.
For audio to work I recreate the AudioContext on first click. Is there a way to simply activate the existing AudioContext on the first click? Also can I detect whether the audio is currently blocked?
References:
Chromium issues
Chromium mailing list
The AudioContext.state will tell you if it's "running" or "suspended". If it's "suspended", call AudioContext.resume() from inside a user gesture, and it should start it up for you (without having to recreate state).
i am using this code and when i see the controls i see the autoplay is not working.
<audio autoplay="true" src="music/lathe_di_chadar.mp3" type="audio/mp3" loop></audio>
and its not working in the mobile devices and very well working in website.
Can anyone tell me the problem in this?.
Thanks and well Appreciated
Now, it's2020
Note that (for the below reason?) Chrome has changed their autoplay policy (see https://developers.google.com/web/updates/2017/09/autoplay-policy-changes ) so you now must either:
resume() the audio context after some (any) user interaction with the page
or be "highly ranked" (ie trust Chrome not to stop audio by default based on user's and world's behavior)
or (as far as I get it) user must be on origin A then click a link to same origin A and that new page of A can autoplay things.
You can play a sound using the AudioContext API and taking the source from any ArrayBuffer (ie: from a XMLHttpRequestor a File)
window.addEventListener('load', function () {
var audioCtx = new (window.AudioContext || window.webkitAudioContext)();
var source = audioCtx.createBufferSource();
var xhr = new XMLHttpRequest();
xhr.open('GET', 'audio-autoplay.wav');
xhr.responseType = 'arraybuffer';
xhr.addEventListener('load', function (r) {
audioCtx.decodeAudioData(
xhr.response,
function (buffer) {
source.buffer = buffer;
source.connect(audioCtx.destination);
source.loop = false;
});
source.start(0);
});
xhr.send();
});
Live example
Works on Chrome and Firefox both mobile and Desktop
Important notes
It's worth mentioning, IMO, that this "trick" can actually be considered as a browser bug, and might no longer work at any time if browser decide that this breaks user experience/becomes a widely-used annoyance (like ads).
It's also worth mentioning that, at least on my mobile and FF 54, the sound will still be played, even if your mobile is muted...
It's also also worth mentionning that user might set the autoplay behavior to fit their wishes and needs either through the browser's usual options or through the more-advanced about:config page (autoplay behavior is set by Firefox's media.autoplay.enabled and media.block-autoplay-until-in-foreground preferences).
So forcing the audio autoplay is a bad UX idea no matter how you do it.
There is no way to get autoplay working in mobile browsers. (This is not allowed)
But some tricks do this thing.
Click on the links below to view some tricks
Autoplay audio on mobile safari
iOS-Specific Considerations | Loop Attribute
I have a lot of experience with this problem. It also applies to Javascript audio that loads before the user has had a chance to interact with the page.
HOWEVER, once a user clicks absolutely anything, it's game on. I personally recommend a full-page entrance overlay right on the front page: "Click to enter my awesome site!" If the user enters the page at all, they are doomed to hear whatever sounds you want to throw at them! :D
I think this method work today both FF & Chrome. This seams as best solution from #Xenos mention above.
I am porting a vehicle in-dash display unit app over to the browser. The big goal is to get it running completely within Mobile Safari.
It's an HTML5/JS music app that relies heavily on jQuery.load to move around between different "screens" by loading in page fragments.
The issue is that when a user selects a track to play, they are taken to the "now playing" screen, which should start playback of the track. The track is not playing though once this screen is reached, and the user instead needs to explicitly click play from this screen in order for audio playback to start. Once this has happened for the first time, autoplay works for the duration of the app.
I understand that Mobile Safari intentionally put blockers in place to prevent audio from autoplaying so that web apps are kept from consuming data unless in direct response to user input.
The thing is, my audio playback IS in direct response to user input...sort of. However, a bunch of things need to happen before my playback actually starts, and those things happen within the now playing page (calling API to get URL for track to be played, report user is playing track, get track metadata, yatta yatta yatta).
To try and get around this, I have the app preload a silent .1s mp3 file into the audio element on startup. Then in direct response to a click event to transition to now playing screen, I call .play() on the audio element.
I assumed that having a call to .play in direct response to user input would the subsequent call to .play() within the now playing page to work, since this is the behavior I had previously observed.
Only, it didn't seem to make any difference.
Any ideas on how I can adjust my flow in order for audio playback to start after loading the now playing screen?
EDIT:
Added some code snippets below
Vehicle.audio = {
init: function () {
audioElement.setAttribute("src", "/audioinit.mp3");
audioElement.play();
},
play: function (source) {
log("VEHICLE: playing audio from source " + source);
Vehicle.audio.stop();
audioElement.setAttribute("src", source);
audioElement.play();
},
In response to user selecting a track:
$(document).on("click", "a.play-track", function () {
Vehicle.audio.init();
/* my wrapper function for jQuery.load() */
replace_wrap("nowplaying.html");
});
Then on the now playing page, Vehicle.audio.play() is called.
The thing is, my audio playback IS in direct response to user input...sort of. However, a bunch of things need to happen before my playback actually starts, and those things happen within the now playing page (calling API to get URL for track to be played, report user is playing track, get track metadata, yatta yatta yatta).
Try adding a "touchstart" event listener to the entire "now playing page" which will then synchronously call .play() on the audio element:
$(document).one("touchstart", function () {
Vehicle.audio.init()
})
This way as soon as an iOS user touches anywhere on the now playing page, the audio should begin loading/playing.
AFAIK it is a restriction placed intentionally by iOS. User must interract with the device (touch/click event) before the script is allowed to start playback.
How do you can detect which Event are in a HTML5 element available?
For Exampe is the Event "onvolumechange" on IOS and Android Devices unavailable but in Firefox and Chrome on Desktop its work. How can you detect it? I've tried it so
if("onvolumechange" in document) {
// DO ...
}
But it only works in Firefox.
According to the article, Everything You Need to Know About HTML5 Video and Audio, the easiest way to probe for support is along the lines of:
var video = document.getElementsByTagName('video')[0];
alert(video.canPlayType('video/ogg'));
The article goes on to say:
There are several levels of support. First, the video element might
not be supported at all. This is the case for Opera 10.10 and IE8. For
this case, you can just put content inside the video element and it
will be rendered (in the above examples, the content is just "video
not supported"). No need to do anything further for this case.
Second, the video element might be supported but the codecs you want
to use are not. Safari doesn't support Ogg/Theora/Vorbis, while Opera
and Firefox don't support MPEG-4/H.264/AAC. To detect this, you can
either use the canPlayType() method on a media element, or you could
have an onerror event listener; if a video fails to play because the
codec is not supported, an error event is fired.
As far as I can tell, there's no quick way to detect support for all the video related events (loadstart, progress, suspend, abort, error, emptied, stalled, loadedmetadata, loadeddata, canplay, canplaythrough, playing, waiting, seeking, seeked, ended, durationchange, timeupdate, play, pause, ratechange, and volumechange) without attempting to fire them first. In other words, try changing the volume and see if an error is returned.
Also note that the W3 has a nice page that demos event and property detection and firing of the <video> element at http://www.w3.org/2010/05/video/mediaevents.html
I'm developing a web app for iOs device, but I have a problem with the html5 audio tag...
I designed a custom audio player, and I control the song with javascript functions.
With safari desktop the app works well, but on safari mobile it doesn't recognize the duration of the audio; the value of the duration property is NaN.
I have to play, stop and replay the audio for retrieve the correct value.
Probably the cause is that the media preload is disabled on safari mobile...
Is there a way to read the correct value at the first shot?
This is a bug in iOS... even inside the function that gets called on the onloadedmetadata event, you MAY STILL get NaN.
In my case, this happens at random when the user selects a new mp3 and the code dynamically sets the src property. The audio plays fine, yet SOMETIMES, the duration returns NaN, screwing up any progress indicator that depends on that value.
The medata is available after this event has fired:
loadedmetadata
More info
https://developer.mozilla.org/en/Introducing_the_Audio_API_Extension