Dropped frames even with low CPU use on latest player...
I've encoded a video that plays back in JW Player 5.4 using less than 25% of the CPU but has many dropped frames. I'm a little baffled as the streamrate is 500Kbps and my connection is 10Mbps+.
I've tried to use the qualitymonitor plugin to diagnose the issue, but this shows no data, which makes me wonder if I'm looking at a setup/configuration problem. Here's the video.
Thanks, Ethan. I'll re-implement using another technique to get the qualitymonitor data. In the meantime, I should say that dropped frames do occur less on faster systems. But my goal is to find a stream-spec and player that works on older systems. My test system is a Pentium M 2GHz. So, that's not a lot of horsepower, but according to Task Manager, only 25% of this CPU is being used during playback. This would be great if it in fact displayed all the frames...
I have an old xmoov streaming setup, but this doesn't work with my current h.264 videos. I'm trying to add iOS compatbility, so moving away from FLV.
Anyway, while I don't have qualitymonitor statistics to back it up, would people believe h.264 playback is dropping frames when there's plenty of spare CPU?
I've tried all kinds of encoding options for h.264 and they all stutter, all with the cpu not being taxed. (I've double-checked the metadata is at the front of the file). Also, similar data-rate encoded (450Kbps) FLVs do not stutter.
At this point, I might just give up on h.264 (and with it iOS compatibility) and go back to FLV in order to get smooth video to the larger number people who don't have GPU-enhanced rocketships.
For the record, all the h.264 videos playback fine when downloaded to the local machine and played with VLC, even in full-screen. I realize there is overhead when you're in a browser plugin, but it's too bad it's this significant.
Thanks for the suggestion, but I've already tried that. It certainly makes a difference in full screen mode, but not in windowed mode where pixels are rendered 1:1.
I was hoping the bufferlength variable might help by delaying the start, but this doesn't seem work, i.e. the video plays back immediately regardless of the setting. Perhaps it doesn't work for progressive download?
I am having a similar issue. I am building a new site for video playback using JW Player and Wowza Media Server to do RTMP streaming of both live and recorded content. All the video is encoded with H.264 + AAC at multiple bit rates.
I heard complaints from some users that video playback was jerky. When I finally found a machine that I could observe it on I installed the qualitymonitor plugin to see what was up. It seems to only be on Dell Desktops when using Internet Explorer 8. Unfortunately, Dell desktops are the norm in my organization. The same machine using Chrome plays the video back just fine. I'm a little stumped as they are both using the same Flash runtime. Qualitymonitor shows an average of 6 frames dropped per second regardless of it playing either a 2Mb/s file or a 400Kb/s file in IE. Windows reports that the CPU utilization is hovering around 25% when the video is playing in IE.
Chad, it turns out I first noticed the problem on a Dell laptop (2GHz Pentium M). It plays back the files perfectly in VLC when opened directly. It has stock Intel GM Graphics.
One test I thought of is to remove JW player from the equation and set up a progressive h.264 download web page using just Adobe software. If that drops frames, then we know where the problem lies.
I'm sure it's not difficult, but I'm swamped right now so any pointers on how to do this would be welcome.
First I made the most stripped down player I could, utilizing Adobe's fpdownload.adobe.com/strobe/FlashMediaPlayback.swf, and then compared this with a JW Player version mentioned above. (Note: there's no <embed> html, so you'll need Chrome or Safari).
Adobe code: http://www.counterbalance.tv/stars-ool/index-dbg2.html JW Player: see http://www.counterbalance.tv/stars-ool/index-dbg.html
There's no doubt that the CPU is taxed considerably more by the JW Player version but the frame rate seems comparable. This is also true when you run the videos in full screen, where it drops to what looks like 15fps or so. On my Sony 1.3GHz Pentium M, the full screen 15fps video shows the CPU at just 60% for Adobe, and 70% for JW Player code.
So, there might be room to tune up the JW Player code so it uses as little CPU as the minimal Adobe player, but the fact that the Adobe player only hits 60% CPU usage in full-screen leads me to believe the numerous dropped frames are a design choice within Adobe's player code.
Unless there are ways of changing the way that Adobe renders full-screen video, we might be out of luck. It's a shame; these days 15fps is just too embarrassing to deploy (and remember both machines render the same media files at full frame rate using VLC).
But all this is mostly guesswork on my part. Anyone else care to weigh in? ________________________
PS Chad: The Dell-related performance issue does seem to be within Adobe's code rather than JW's. Full-screen playback on my 2GHz Pentium M takes 100% of CPU with both JW Player and Adobe, using Chrome.
I tried Flash 10.0, 10.1, and 10.2 on the Dell, and didn't see that much difference with JW Player on IE. I don't think there's any hardware acceleration for Flash to take advantage of.
FWIW here are the numbers for IE9. (I haven't been able to install older versions of Flash in Chrome.)
More strange CPU usage: Once a full-screen clip has completed, CPU usage stays at about 60% until full-screen has been exited. So far this only seems to occur on Chrome, on my Dell, using the minimal Adobe-only code. It might not be relevant to low frame-rate in full-screen in JW Player, but it's certainly an indication that something's wrong somewhere...
Q: should setting smoothing to false show large defined pixels in full-screen, or still smooth the edges after scaling? It appears that JW Player always smooths to some degree, which must be taxing the CPU a little. The current version of
The smoothing in fullscreen is normal, becaus in FS the hardware scaling of Flash kicks in. This does a bit of smoothing too (in addition to the “smoothing” flag, which smoothes as part of the video decoding).
Jeroen: thanks for clarification on smoothing. I'm pretty certain that hardware scaling is not being used by the Flash player in this hardware/browser config because FS framerate degrades as display resolution increases. (But the same file played with VLC uses the same tiny amount of CPU for smooth 30fps regardless of the window size, so hardware scaling is in use here.)
I wonder if this is a limitation that affects all browser plugins, because YouTube also has an increased problem with FS framerate as screen resolution increases.
And finally, just to be sure I don't lead you on a wild goose chase with the memory leak: the 60% CPU was with the minimal Adobe code, not the JW Player.
OK, heading back to the original issue, i.e. dropped frames in non-full screen, here's some new test results:
I changed my sample video file in the example urls above to one that readily shows dropped frames, a white bar that bounces smoothly up and down. Using the minimal Adobe code, it settles down to smooth playback soon after pressing play. With JW Player 5.5, it continues to stutter/drop frames once in a while, and uses roughly double the CPU as the minimal Adobe code. (On my test machine, thats 15% CPU for Adobe and 30% for JW Player.)
This leads me to think that the extra functionality within JW Player is impacting frame rate on last generation systems (2GHz in this case).
So, could there be some way to decrease these dropped frames by looking at the way JW Player handles multi-tasking; perhaps yielding back the CPU more often?
I realize the easy answer is to tell everyone to get a faster machine, but could this be looked at in case there's an easy way to get smoother playback?
Correct, the “deblocking” feature is only applied to VP6 video. Not to H264.
And we are investigating this issue as part of the 5.7 release. We already have identified a few issues that “leak” memory (runaway MovieClips), fixing these should make a difference.
Thanks for the clarification on deblocking, and good luck with 5.7. You may find my new test video file will help show improvements in video playback smoothness.
Also, as far as full-screen hardware scaling goes, I've always wondered why RealPlayer was able to do this when Flash/JW did not, and it just occurred to me that Real installed a full application on the client. Do you think that's what allowed them to achieve the better fs performance?
I think the biggest difference is that Real (or Quicktime or VLC) are solely rendering a video in fullscreen. Flash is rendering the entire Flash stage in fullscreen, which can potentially contain (3D) vector drawings, bitmap images, text areas, etc.
Fullscreen Flash is better compared to Chrome’s fullscreen option than to Real/Quicktime in that regard.
I also have this problem. Video is perfect and smooth in full screen mode but jerky in non full screenmode. Is there a solution? I have the latest jw player
I believe I may have a related problem. I have a video that is hosted on Bits-On-The-Run, and that I'm embedding manually using JW Player. The video works perfectly as it should for most people, but there's replicable problem on some machines running Chrome with very high frame-rate loss.
I have a demo of the video embed here in a simple stripped-down page: http://stage2.silverorange.com/work/nick/jwplayer-video-test/
*Chrome* (16.x) * I get over 16 fps dropped. http://stage2.silverorange.com/work/nick/jwplayer-video-test/screenshots/chrome-16.png
*Firefox* (10.x) * I get about 4 fps dropped. http://stage2.silverorange.com/work/nick/jwplayer-video-test/screenshots/ff-10.png
*Safari* (5.x) * Less than 4 fps dropped. http://stage2.silverorange.com/work/nick/jwplayer-video-test/screenshots/ff-10.png
* All tests on OS X and using Flash 11.1.x
I've tried: <ul> <li>removing the 720p video (only somewhat helps)</li> <li>making a longer buffer time (no help really)</li> <li>turing off smoothing (no help really)</li> </ul>
This is a hard problem to debug. I've tested it on my network with an older laptop with less memory, and Chrome works fine. I work with a team of developers based in different parts of the world, and have tested the above video with all of them, and on two other systems we have the same problem. It's not obvious what the difference is between the systems that work, and the ones that don't.
Any help or suggestions would be much appreciated.
The difference between systems is very likely that some contain a GPU that is not supported by Flash for hardware rendering of H264. When that happens, Flash falls back to software rendering and performance drastically drops.
The difference between Chrome and Safari/Firefox is strange, though Chrome does run a different version of the Flash player than the other browsers. They ship a version of Flash with the browser and do not use the plugin installed by the Adobe Flash installer.
Can you find out which OS/GPU combo’s are present in setups with bad performance?
This question has received the maximum number of answers.
