HTML5 video element request stay pending forever (on chrome) - html

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.

Related

HTML5 video player not working for Twitter videos

I am retrieving tweets via the Twitter api and attempting to embed their video attachments.
Embed Code:
<video controls="">
<source src="https://video.twimg.com/ext_tw_video/1444247208514113546/pu/vid/1280x720/6rw0rzMWMSk39eoz.mp4?tag=12" type="video/mp4">
</video>
Firefox:
The above code fails to render the video player altogether in firefox, choosing instead to simply return: No video with supported format and MIME type found.
Note: There is no issue in playback when the video url is entered directly into the address bar.
Chrome:
Chrome spontaneously stops playback after 0-4 seconds, returning to the first frame. This behavior is somewhat sporadic, occurring sometimes, but not always. When it does occur, no matter how many times the play button is pressed, the video is unable to progress any further. Once a video is in memory and has been successfully loaded by refreshing the page, it no longer behaves in this way. Like firefox, there is no issue in loading or playback if the video url is entered directly into the address bar.
Video demonstration:
Some more examples of twitter videos to play with:
Many site issues such as the No video with supported format and MIME type found error can be caused by corrupted cookies or cache.This can cause streaming problems in any browser
Firefox Solution:
I suggest you Clear the Cache and Remove Cookies in your settings
Warning ! ! This will log you out of sites you're logged in to.
To do this enter about:preferences in the url bar.
To clear Cookies: Select Privacy under History, then select Firefox will Use Custom Settings. Press the button on the right side called Show Cookies, then use the search bar to look for the site. There may be more than one cookie in use for this site. Remove All of them.
To clear cache: Select Advanced > Network. Across from Cached Web Content, Press Clear Now.
If there is still a problem, Start Firefox in Safe Mode {web link} While you are in safe mode;
Then restart.
Chrome solution:
At the top right, click the More button
Navigate to More tools > Clear browsing data .
At the top, choose a time range. To delete everything, select All time.
Next to Cookies and other site data and Cached images and files, check the boxes.
Click the Clear data button.

Internet Explorer 11 HTML5 audio duration = infinity issue

Today I've met an unpleasant issue. There is a website with a custom HTML5 audio player. After the page loads, I try to echo document.getElementById("myAudioId").duration, it is needed in order to make navigation possible. In every other browser it works just fine, the duration is showed, but IE11 works differently - it shows that duration equals Infinity. But as I noticed, when the song is buffered to the end, the duration magically appers and the navigation works. In other browsers everything works from the start. The content-length headers are set up. What could it be?
UPD: Other sites with HTML5 audio let me see the duration from the very start. The duration, I guess, is part of metadata and could be loaded even without preloading the audio file using preload="metadata", but it also doesn't work.
UPD2: I've also tried playing around with jsfiddle and created the same audio tag there with same MP3 audio - there was the same situation. But then I've inserted link to another MP3 there, from another site - and it worked!. More than that, I've uploaded this second song to the first problematic website and after that the song that worked perfectly couldn't also show me its duration and stuff. So now I think it's something on server side. But don't know what it is.
UPD3: Finally, I've been told that files are converted using FFMPEG to MP3 128bit, then they stop being OK. Now I need to find how should I convert MP3s so they are OK.
It works for me locally, but when uploaded to server, it does not.
It seems that player.duration do not work in IE 11:
https://msdn.microsoft.com/en-us/library/dn254962(v=vs.85).aspx

HTML5 video loop doesn't work on Chrome (Sitefinity CMS)

I ran into this peculiar problem that I couldn't get HTML5 video to loop on my local development environment (ASP.NET + IIS7). The video autoplays just fine. My code looks like this:
<video id="frontpage-video" autoplay loop>
<source src="http://test-site:8084/video_mp4.mp4" type="video/mp4">
<source src="http://test-site:8084/video_webm.webm" type="video/webm">
</video>
If I change video source URLs to some publicly available URLs (for example to dropbox), loop works just fine. This is not a major problem since I think (hope) it will work once my site goes live and the video is publicly available.
My question is: Can I make the video loop if my video is not publicly available?
I couldn't find similar problems by googling. Could it be some kind of IIS setting that prevents videos to loop?
Update 1: The problem seems to occur only in Chrome. Firefox and IE works fine.
Update 2: It seems that the video will stop at the end but never returns true for element.ended
> document.getElementById('frontpage-video').duration;
< 16.12
> document.getElementById('frontpage-video').currentTime;
< 16.12
> document.getElementById('frontpage-video').ended;
< false
Update 3: Problem is either in IIS or in Telerik's Sitefinity CMS. Server should send a "206 Partial Content" status but instead it sends 200 OK. Has any Sitefinity users had this problem and know how to solve it?
It looks like your problem is that you're not using HTTP Byte Serving. Your server is sending a "200 OK" response, but it should be sending "206 Partial Content" along with these headers:
Accept-Ranges:bytes
Content-Range:bytes 0-1492370/1492371
The byte range request allows the browser to request only the portions of the file that it needs. So if you seek around, it can skip right to that point.
With the regular 200 response, you will usually at least find that you can't seek in the video. But, depending on how your video file is encoded and where in the file the metadata is placed, you may see more problems. Sometimes the file might not even play at all. WebM is usually more robust than MP4, which can be all over the place.
I don't know IIS well enough to tell you how to configure it, but try starting here:
http://blogs.visigo.com/chriscoulson/easy-handling-of-http-range-requests-in-asp-net/
Chrome/Opera can't loop the video if the video itself is not served with HTTP 206 Partial Content response but 200 OK instead.
The problem is that Sitefinity's storage providers do not support partial content (version 7.0). They are planning to implement this for the future.
At the moment the possible workaround is to use an external blob storage provider such as Azure, Amazon or ExternalFileSystem (ExternalFileSystemStorageProvider).
I got this information from Sitefinity's support team.
May be MIME type in IIS is not set up for MP4.
Open IIS, and locate you default page. You'll see MIME type in right pane.
Click Add and put field1=.mp4 and field2=video/mp4.
Restart IIS.
Hope this might work.
In your question, your video-element doesn't have the id frontpage-video (but i guess it's copy paste?)
check if the video end event is called in your webkit browsers, and if so, restart your video.
.
<script type='text/javascript'>
document.getElementById('frontpage-video').addEventListener('ended',myHandler,false);
function myHandler(e) {
if(!e) { e = window.event; }
//restart your video
}

Chrome ignoring audio preload="metadata"

My code is basically this
<audio controls preload="metadata">
<source src="linktofile.wav" type="audio/ogg">
</audio>
In Firefox 18.0.1 - it results in 8.4 KB data download (checked on Firebug).
But in Chrome 24.0.1312.52 m - it starts downloading the entire file (In developer tools - it shows download size in MBs).
What gives?
As I understand preload values are hints for the browser, not absolute commands. In other words, they are a suggestion for how the browser should behave. The browser may or may not follow the hint so don't be surprised if it doesn't always work.
http://www.mediacollege.com/internet/html/audio/preload.html
Version v42 and above now seem to respect this. Yay!
(current beta version as of yesterday)
You can see now a 206 partial content request, and 66kb downloaded (my video is 600kb+)
However: VERY IMPORTANT
In case you didn't know, Chrome can only have 6 simultaneous connections at the same time to the same server.
Currently in v42 + v43 they have a terrible bug which means that once the metadata is loaded that file is not released back into the 'pool' for available connections. So if you load 6 or more videos the 7th blocks and won't download.
I've reported this as a bug https://code.google.com/p/chromium/issues/detail?id=468930
This may not be the case for all videos, but I have 10 short MP4 videos encoded with Adobe Media Encoder and they get stuck.
If in doubt, or experiencing this problem you've got no choice but to set preload='auto' for now. Hopefully this bug will never make it into the wild.
preloading is fixed, and has been for a while
the behavior with preloading with it holding the connection is not a bug.
It keeps the connection open to allow for stream protection by use of one time tokens.
If it didn't do this, the audio or video wouldn't even play if it is protected by a token.
Therefore, chrome MUST keep the connection open until the page is left or closed.

Chrome HTML5 Videos stop working if too many tabs are open - Memory issue?

I'm using jQuery to dynamically write <video> objects, and running videojs to init them. After I play a video, SOMETIMES when I try to play it again, it just won't play, and from that point on, even after refreshing the page, no videos will play. Each time, the <video> object renders, but the video just doesn't play. Nothing is written to the console. There don't appear to be any errors. Restarting Chrome resolves the issue, but only momentarily. After playing a few videos, the issue comes back again.
I found that closing other tabs in Chrome does indeed fix the problem, so it appears to be some kind of memory issue.
I'm running Chrome 19.0.1084.46
Exactly how many video tags to you have? What do they look like? Do they include preload='none' attribute? Are the source videos all on the server?
I ask because if you have more than six video tags on a single page pointing to the same source server then you could be experiencing "connection starvation":
Chrome allows only six open connections to a single server (based on DNS name in the URL)
the html5 video tag's preload attribute default value is 'auto'
Chrome's auto behavior is to preload some data and leave the connection open ready to pull more data for the video
So, with more than six video tags on a single page pointing to a single server, the videos will not play. To resolve this particular problem, set the preload attribute to 'none'
Stu is correct. But sometimes, in my experience, Chrome ignores the preload="none" attribute and goes ahead and opens a connection anyway. I've had much problem with this when developing a site which had many smaller videos on it. The connections blocked the rest of the content (images, custom fonts (and when custom fonts are delayed, the text does not even render)) My solution was to build an own preloader which loads the images. This made sure I could control at least when the images (which was the most crucial aspect from a design point of view) was loaded.
That solved the problem with images not showing but the problem still remained. So the best solution is to set up subdomains pointing to the same server, like: v1.server.com, v2.server.com, and so on. This means you won't have to move your files and you get the benefit from enabling browsers to have more open connections. Watch out for increased dns lookup time though.
There is a known bug with Chrome. It will not play the same video in multiple tabs at the same time. This is probably what you are running into if you are a developer and happen to have your page open in two tabs at the same time.
The bug has been known for almost 5 years as of this writing. Feel free to visit the Chromium bug report and star the issue. Hopefully it will increase in priority for the Chrome devs.
In the meanwhile, a workaround is to use a random query parameter in your video src. For example, instead of <video src="vid.mp4">, use <video src="vid.mp4?_u=1253412">. This will break Chrome's caching mechanism and allow the same video to be streamed to two different tabs at the same time.
I had a similar but related issue which I can expand on slightly here.
I had 14 different small videos on a page but only 2 were available at a time. Setting preload = 'none' didn't fix the issue so I also used a data attribute to store the src, and remove the src for all videos that aren't currently being viewed.