I have been building a streaming chatroom page and started to notice during my stress tests that it would grind to a halt after about 30m - 1h, after isolating all my ajax scripts I finally narrowed it down to the actual video itself, and it seems to happen in both IE and Chrome, both youtube and ustream. Even just browsing to the embedded video URL thus removing my code from the equation completely shows the problems persistence. The problem even compounds when in video ads from ustream pop up as it eats a chunk of memory and does not seam to garbage collect. Any ideas, comments, suggestions?
I am on a fresh Win10 install with nothing but note plus plus and all the latest windows updates, and no not insider builds.
Related
I'm trying to ensure (to the extent possible) that an HTML5 video begins playing only only when it is able to play through completely without buffering. For context, the MediaStream of the video is then used to mix with another audio source and sent over peer WebRTC connections. The videos are typically 5-10MB and a few minutes long (i.e. a decent broadband connection should have no trouble loading the entire video well before it's done playing).
To achieve this, my code currently waits for the canplaythrough event on the video element to begin and calls play() when it fires.
This "works" in the sense that the video begins playing and, in most cases, buffering is sufficient for the video to play through uninterrupted. But, in a few cases (specifically for two people so far that happen to both have been running Chrome on MacBook Airs and with apparently not incredible but decent broadband Internet connections) the video plays staggered and choppy---which I believe to mean the video has not sufficiently buffered.
Are there better techniques for either ensuring that video is sufficiently buffered on most browsers?
Would using fetch() to buffer the entire video in memory probably do the trick? Or is a resulting blob() also actually lazily buffered behind the scenes?
Are there good practices for testing and debugging these sorts of issues given that I can't really replicate this locally?
I have built a tool called Stream or Not that might help on the network side. It will tell you how long the video takes to start, how many stalls, etc. You can use your browser's devTools to throttle the network (and in Chrome, you can emulate the CPU).
Honestly - to see if the network is the issue, as long as the bitrate (use FFprobe https://www.streamclarity.com/probe?url=) is lower than the network speed, you are not network constrained.
There is another possibility. What are the dimensions of your video? How what are the dimensions of the viewport on the browser? If you are asking the device to chop down a lot of pixels - the playback limit might move away from bandwidth to CPU processing speed. I have seen this happen on mobile devices and on older Macs trying to play 4k videos - there just isn't enough CPU to process that many pixels.
I'd test the network speeds, just to be sure.
Make sure you are not sending more pixels than you need. Underpowered devices will have issues.
I have two different videos, both (as far as I know) generally captured in the same manner, that I'm trying to play using an HTML5 video tag in Chrome. Both videos open and play perfectly in VLC, so I don't think there's any issue with a corrupted file, and both are mp4's with an H.264 format, using YUV color space. However, when I try to play one in Chrome (Version 21.0.1180.89) it gives me a grayed-out play button, while the other works perfectly. For reference, my OS is Ubuntu 10.10, although I've seen the same problem in newer versions of the OS. This is whether I'm loading the video into the HTML5 tag, or navigating directly to the URL where the video is being stored. I'm somewhat at a loss here, does anyone know what direction I should go to find what the significant differences are between the two videos?
Edit:
This one works: https://dl.dropbox.com/u/100841270/1_G101_20120914_0139PM_Course_101.mp4
This one does not: https://dl.dropbox.com/u/100841270/1_G101_20120914_1156AM_Course_101.mp4
Update:
It appears to have nothing to do with OS, since I've seen the same problem in both Windows and Linux. Chrome 22 beta in Ubuntu didn't seem to work either.
We had this problem and found that encoding the files in accordance with iPhone's webview's standards created files that played fine in Chrome. Chrome and iPhone webview share the same render engine, and it appears they have similar HTML5 video requirements.
Not all H.264 encoded Mp4 files are supported by Chrome and slight differences in the encoding process can produce videos that do not work. Even if the EXACT same encoding settings were used, H.264 is a variable bit-rate encoder, so different videos may exceed bitrate limits.
The encoding settings that were successful for us were:
Only use the H.264 Baseline Profile Level 3.0
Resolution below 640 x 480 and framerate up to 30 fps
B frames are not supported in the Baseline profile.
bitrate limit of 900kb.
Here is the reference we used to arrive at those settings. Likely not all of these are required for Chrome, but we stuck to these rules and found that all videos worked on both platforms. Further research could likely determine the exact setting that is/was causing Chrome to not play the video.
I am running Windows XP, and chrome doesn't like the second one either.
My best guess of the cause is that, the working one is only 6.4 MB, but the other one is about 21.7 MB. Chrome might just be refusing to directly play a video that big. Have you tried having YouTube host it, and embedding their player into your site? That may solve the problem. (If you are worried about random strangers watching the videos, why did you post them here? Why would anybody even want to watch them? Though, you can make videos private on YouTube, in case these are just two videos that demonstrate the same problem you are facing with the real videos.)
That may also be compounded by a different problem that exists with both videos, manifested when I try to use Windows' built-in player. Both videos appear distorted when I use my computer's video player, stretched like 300% horizontally.
Are there other videos you have that fail in exactly the same way? Since these are only test videos for the real thing, if this is the only video with that problem, I would not say that it really is a problem unless it recurs. The dysfunctional video may have just run into that one-in-a-million chance that it has just the right contents for it to not work.
I'm having some serious problems with flash at the moment. I have a swf loaded that uses Stage3D, displaying 3D content. When I overlay a video player, on full screen size, it will cause massive lag/jitter in the video content. The video content is loaded locally so there is no streaming to take into account. This only happens on some machines but considering the project this cannot be neglected.
I have since recoded my project to remove any form of loading i was doing with a Loader and just directly put the file path into the netstream and have then attached the netstream to StageVideo. But the problem still persists and I am at my wits end. I even set Stage3D to invisible during video playback.
It's a complete horror to debug because it's simply not a problem on my machine, but out of 10 people 4 of them have reported this problem and we can't release our product like this.
Any help to resolve this would be greatly valued and appreciated.
Regards,
Kevin
Well as StageVideo is using GPU like Stage3D does. So I guess those two stages are interrupting each other processing on GPU (especially on older video cards).
So my answer is to try to stop that video while you are working on Stage3D.
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.
I have pages where i need to play dozens of small audio file when the user clicks on things. Responsiveness is very important.
I'm thinking of using one for each file, and preloading the audio files. Is this the a reasonible approach?
Thanks.
What I experience using SoundManager2 (audio Javascript lib) is that Chrome nor Firefox have no issues loading and playing multiple (100+) sounds through their Html5 capabilities
(Firefox must play OGG though)
With IE9 it's a different story. Looks like it has a limit to load and play no more than 40 sounds. :-(
As, the game we develop requires constantly to have 50+ sounds played within 1 minute period, we have to fallback to Flash for playing sounds on IE9.. luckily SM2 does it too
I also confirm this behaviour with html5 mode using jPlayer. I'm only able to create 40 instances of jPlayer. Each can preload and play sound that it defines.
41st and following instances will fail with an error on IE9/Windows7
Error: "Media URL could not be loaded"
It's reasonable, and probably the correct solution. I recently wrote a demo application (http://www.soundscribe.com) that makes heavy use of individual (and simultaneous) audio clips in HTML5. IE9 and FF3/4 handle it well. Chrome has some issues that seem to be specifically related to simultaneous playback (which probably won't apply to your app). The biggest block I hit was in IE9, which seems to have a mysterious limit on the number of audio objects that can exist at once. The max is about 40, after which IE9 will silently fail to download the file. FF and Chrome both try to support an unlimited number.
The alternative approach of putting all the audio in a single file and changing the offset to play is a bad choice for several reasons. It's much more complicated to code, you need to keep up with additional metadata (where does the clip start, how long is it), and it's likely to work slightly different between browsers. And the worst part, there's really no way to know when your clip is fully loaded. You can only tell when the clip "can play through", which is determined by the browser based on the size of the audio file and the current download rate. This means that even after the browser reports the audio clip is ready, you may not be able to play a clip somewhere near the end.
It seems like a reasonable approach. However you need to consider a couple of things.
Each sound clip will need to be held in memory. While this is will not matter for most cases, users with a lot of tabs open, multiple programs open or old computers may get slow down on their computer. Especially if the sound files are large.
From a usability point of view, if I hear a sound every time a click a button on the site, I'll leave immediately