Wait till audio element fully downloaded. HTML - html

I searched a lot but didn't find any good solution for this.
I want to load an audio file fully and play after.
canplay, and canplaythrough event didn't do this.
The browser (chrome latest) didnt load all the audio,just partial content. Chrome sometimes in show in network tab "pending". I develope it in localhost, and i disabled all extension, and i use cache.
Any idea?
var tAudio = document.createElement('audio');
tAudio.src=src;
tAudio.preload="auto";
tAudio.volume=1;
tAudio.muted=true;
tAudio.load();
tAudio.addEventListener('canplaythrough',function() {
audioLoaded++;
if (audioLoaded==audioCount){
$('.loadingOverlay').fadeOut(1000);
}
});

Related

How to set a breakpoint where a sound plays

I want to find out where in a webpage's source code does a sound effect play. That'd allow me to better understand the code and obtain the audio file as well. I searched in the "Sources" and "Network" tabs of the Chrome Inspector, but there are no audio files there. The sound is probably fetched by an AJAX request or generated using the HTML5 Web Audio API. How do I set a breakpoint in the Chrome Debugger to pause when a sound plays?
As suggested in Abarnett's comment:
Use a browser add-on/extension/plug-in such as Chrome Audio Capture to record internal sounds in the browser.

video replaying issues with video.js on google chrome

I have problem of replaying a video for the first time on Google Chrome if it is not cached. I'm using VideoJS which contains the video URL as something like "http://somedaim.com/?querystring=value". I noticed this works for the URL something like "http://somedomain.com/video.mp4". Is this an issue of videoJS and how can I solve this?
I totally agree with #Andrew. But what what we can do is at "ended" event if we set the source again it works! :)
myPlayer.on("ended", function () {
this.src({ type: "video/mp4", src: URL });
});
The issue is general webpage linking not videojs. The physical movie couldn't be located at http://somedaim.com/?querystring=value
Most likely the server or back end code redirect it to the mp4 path without you knowing (videojs wouldn't know this is happening and nor should it). Theres no way around it, you need the physical path to the mp4 file.

HTML5 video element request stay pending forever (on chrome)

I have a weird issue in Chrome.
Each time I load a <video> element, chrome will start two HTTP request.
The first one will stay pending forever (I guess this is the "meta-data", "partial content" request. But the point is that it stay pending)
The second one to the same file is ok and goes on and close after the loading is over.
The problem here is that the first request stay pending until I close the browser page. So at some point, if I load multiple video, Chrome will break and stop downloading anything because every available request is occupied by these pending requests.
I created a reduced test case here: http://jsbin.com/ixifiq/3
I've check to reproduce the issue, and it is happening on both Video.js and MediaElements.js frontpages. Open your network tab when loading the page, you'll see the first pending request. Then press play on the video, and you'll see the second request working, but the first one will stay pending forever.
Does anyone knows a fix to this bug?
(This bug still exists in Chrome 38.0.2125.111, OS X 10.10)
This may be a Chrome bug & you may solve it without any dummy ?time-suffix trick, just helping Chrome releasing sockets faster:
I had the same bug on a RevealJs HTML presentation, with 20+ videos (one per slide, autoplayed on slide focus). As a side effect, this unreleased socket problem also affected other ajax-lazy-loaded medias following immediately the first pending/blocked video, in the same HTML DOM.
Following Walter's answer (see bug report), I fixed the issue following the next steps:
1- Set video preload attribute to none:
<video preload="none">
<source src="video.webM" type="video/webM">
</video>
2 - Use a canplaythrough event handler to play and/or pause the video once it is loaded & ready. This helps Chrome releasing the socket used to load that video :
function loadVideos(){
$("video").each(function(index){
$(this).get(0).load();
$(this).get(0).addEventListener("canplaythrough", function(){
this.play();
this.pause();
});
});
}
Apparently that's a bug from Chrome. And there's nothing to do about it ATM.
I reported the issue a while ago on the Chromium project and it's been assigned. So hopefully it'll be fixed in near future.
Bug report: https://code.google.com/p/chromium/issues/detail?id=234779
I don't know if it will be functional right now, but I remember solving this issue by adding a parameter to the video URL, just like "video.mp4?t=2123". Of course, everytime you load the video, the parameter should be different. I'd use
var parameter = new Date().getMilliseconds();
to get it, and add it.
With this, at least a few months ago, I was able to play the same video multiple times without Chrome waiting forever the response.
Hope it helps.
This bug still exists. I'm using an HTML5 video player on a single page application. After loading about 7 players with pre-buffering, I hit the limit and no more videos load. I found another answer having to do with images and I was surprised to find that this answer solves this problem.
if(window.stop !== undefined) {
window.stop();
} else if(document.execCommand !== undefined) {
document.execCommand("Stop", false);
}
reference: Javascript: Cancel/Stop Image Requests
I found this issue when using html5 video inside dynamic content such as carousels, to release the blocked sockets you have to unload the video source:
var video = $('#video');
video[0].pause();
video.prop('src','');
video.find('source').remove();
video.remove();
The bug claims to be fixed but I still had to do this on Chrome 42. At least I could still set preload="auto".
We had the same symptoms, but the problem was that we were calling load() on the same video twice in succession: same video control, same video source (MP4). Two identical 206 requests showed up in the dev tools, and then, after switching video a few times, Chrome would cancel the first request, turn off progressive playback, and wait for that second request to complete.
Also note that if you're using an MP4 source and it isn't formatted for progressive playback (meaning the MOOV atom is at the beginning of the file), then you will have 1-2 additional requests for the file, which makes it even more confusing.
#sidonaldson 's answer is the only one that worked for me. However I did not remove the video or source. The following code worked for me, run this just before putting the correct src and playing it.
const video = document.getElementById('player')
video.pause()
video.setAttribute('src', '')
video.load()
#ecropolis's answer also worked but my SPA would end up having no images so it was not an option.

Stop audio buffering in the <audio> tag

I am currently working in using the HTML5 audio player to provide a audio stream (24/7 radio stream) via the (mobile) browser. Loading in the stream and playing it works fine.
The major problem is that the HTML5 <audio> tag will keep downloading (buffering) content even when its not active. This could be a major issue for mobile users since most of them pay for data use. So far I have not been able to find a decent solutions that works cross browser to prevent this.
I tried so far:
Unload the source when pause is pressed. < This does not work cross browser
Remove the audio player element and load a new one. This works but
lets be honest, this is a very hacky way of performing an extremely
simple task.
I was simply wondering if there is something I'm overlooking in this whole issue since I am convinced I'm not the only one with this issue.
The <audio> element includes a preload attribute. This can be set to "none" or "metadata" which should prevent the audio preloading.
Source: https://developer.mozilla.org/en/docs/Web/HTML/Element/audio
I found a workable solution for the problem described above. A detail description can be found here: https://stackoverflow.com/a/13302599/1580615
You can do the following to stop buffering load without errors:
var blob = new Blob([], {type: "audio/mp3"});
var url = URL.createObjectURL(blob);
audio.src = _url;
or, shortened up:
audio.src = URL.createObjectURL(new Blob([], {type:"audio/mp3"});
Now you're not loading a "" which is a bad url for the audio tag to try and load. You're instead loading an actual url made from a Blob that just contains no data for the audio to playback.

HTML5 Audio files fail to load in Safari

[EDIT: using a simplified test page without Javascript etc.]
I've got a webpage that contains four audio files. These files are served as HTML5 <audio> with .mp3 files, which should play in Safari. (I've had no trouble with .ogg files in Firefox and Chrome.)
Each time I reload the page, between one and three of the files load properly, and the rest fail to load -- although they don't give an error, and the 'loading' message disappears; it's as if they're loading with a size of 0B. Which files work and which don't seems completely random: I've seen each of them load and each of them fail more than once.
How can I make all these files load properly?
I was having a similar issue with files not loading and came up with this solution. It seems that HTML5 audio/video can "stall", meaning that is just stops loading. Luckily, there's a "stall" event that fires when this happens. What I did was listen for this event and when/if it fires, just try to force the audio to load again.
Example using jQuery:
// the event is 'onstalled' - 'stalled' in the jquery case
$("audio").bind("stalled", function() {
var audio = this;
audio.load();
// Threw in these two lines for good measure.
audio.play();
audio.pause();
});
Looking at generated source of your page you load as first source an ogg file then a mp3 file in this exact order
But, as specified in http://html5doctor.com/native-audio-in-the-browser/ file are in inverse order, so try to do the same
otherwise try to serve in your sources also an aac audio in a m4a/mp4 container