I got confused when I read Chrome DevTools |Timeline.
Keep in mind that just tracking the FPS counter may lead to you not noticing frames with intermittent jank. Be careful when using the content. It is also worth noting that FPS on desktop does not equal FPS on devices and special care should be taken to profile the performance there too.
does frames with intermittent jank means the frame that fail to use real hardware frame?
Apparently "jank" is a neologism:
"Jank is any stuttering, juddering or just plain halting that users see when a site or app isn't keeping up with the refresh rate. Jank is the result of frames taking too long for a browser to make, and it negatively impacts your users and how they experience your site or app."
From http://jankfree.org/
So "frames with intermittent jank" means ... well ... intermittent jank.
does frames with intermittent jank means the frame that fail to use real hardware frame?
Nope. You can't make that inference.
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 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.
I need to display several items on a page that represent videos. Embedding video players (even just a couple) causes a ton of load on the user's CPU (you can hear your computer's fan spin up immediately to the maximum speed). My thought to mitigate this is to generate animated GIFs to represent clips of the videos. This seems to cause a load on the CPU but not nearly so great. It seems that once the GIFs have finished loading, the CPU load is less of an issue.
I'm only testing this by putting about 15 GIFs on a page, loading it up in Chrome on my MacBook Air and watching Activity Monitor.
http://yawmp.com/temp/anigif_test.php
Is my logic sound that Animated GIFs require much less CPU resources than embedded videos? Are there memory issues I should be concerned about? Are there any downsides to going this route in terms of system resource pain for my users?
If there are a few frames in the animated gif, the browser is just cycling through those frames - that isn't a particularly big deal. The memory issue would become a problem if you put enough of them on a page.
However, that is a lot of stuff moving, flickering and otherwise demanding attention. Maybe you could switch from a static preview image to the animated gif on mouse over so there is a bit less going on at once. Then if it interests them they can click through and load the video.
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
What is the most accurate way to measure framerates, i.e. FPS, in modern HTML5 browsers? I'm specifically interested in FPS for Canvas animations.
http://weblogs.mozillazine.org/roc/archives/2010/11/measuring_fps.html will tell you that trying to measure framerate by counting how often your setTimeout runs is not accurate. The browser can run your Timeout callback multiple times between screen paints.
Turns out Mozilla has a window.mozPaintCount https://developer.mozilla.org/en/DOM/window.mozPaintCount available, which should provide an accurate FPS. However, this only works for Mozilla.
There's an open issue for Chrome for something similar: http://code.google.com/p/chromium/issues/detail?id=65348
A manual way to check for hardware accelerated FPS in Chrome is to grab the Chrome Beta channel (as of posting date) and go to about:flags and turn on FPS Counter. However, on a Mac, acceleration only turns on when using WebGL. So, no way to check FPS for Canvas on Chrome for Mac.
What are other strategies for accurately measuring HTML5 FPS?
Thanks!
Please check:
https://github.com/mrdoob/stats.js - it's the best FPS monitor I know. It also gives you some stats about mem/cpu usage (you have to run your browser with special parameter to expose that data), but may also suffer from the inaccuracy you described.
https://github.com/pcwalton/firefox-framerate-monitor
Also, in new chrome builds (probably canary stream) there should be an option for displaying FPS in about:flags.