Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

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.

http://www.counterbalance.tv/stars-ool/index-dbg.html

I'd appreciate any ideas, initially on why qualitymonitor doesn't work. This will let me check how many frames are being dropped...

Adrian

33 Community Answers

Ethan Feldman

JW Player Support Agent  
0 rated :

I am not able to replicate the droppes frames/low cpu issues, but QualityMonitor needs an update so it works properly with the JW Embedder.

JW Player

User  
0 rated :

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...

Ethan Feldman

JW Player Support Agent  
0 rated :

I am using an Intel Core2Duo, 2GB Ram, not bad, but not exactly top of the line.

JW Player

User  
0 rated :

Hmmm. I updated the link above to use minimal standard SWFObject code from the configuration page, and qualitymonitor still shows no data.

Ethan Feldman

JW Player Support Agent  
0 rated :

This is because you are not using any sort of streaming here, just progressive download.

More information / example – http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v4/27/bitrate-switching

JW Player

User  
0 rated :

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?

Ethan Feldman

JW Player Support Agent  
0 rated :

xmoov is not compatible with h.264. I don’t think frames should be dropping, though.

JW Player

User  
0 rated :

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.

Ethan Feldman

JW Player Support Agent  
0 rated :

Try to set the “smoothing” flashvar to “false”, that might help.

JW Player

User  
0 rated :

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?

Ethan Feldman

JW Player Support Agent  
0 rated :

I am not sure. Both of those variables should do the trick. For the record, I don’t see the issue on my machine, on your link.

JW Player

User  
0 rated :

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.

Any help would be greatly appreciated.

Ethan Feldman

JW Player Support Agent  
0 rated :

Can you provide a link?

JW Player

User  
0 rated :

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.

Ethan Feldman

JW Player Support Agent  
0 rated :

Do you have a new test page we can check out?

JW Player

User  
0 rated :

OK, some interesting test results:

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.

JeroenW

JW Player Support Agent  
0 rated :

Interesting .. I wonder what results you’ll see when testing this with various versions of the Flash player? 10.0, 10.1, 10.2 …

My guess is, your framedrops and/or CPU usage might change dramatically.

JW Player

User  
0 rated :

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.)

JW Player

Flash 10.0, IE 9
CPU: 10% windowed, 90% full screen (~15fps)

Flash 10.1, IE 9
CPU 15% windowed, 70% full screen (~15fps)

Flash 10.2, IE 9
CPU 15% windows, 75% full-screen (~15fps)

JW Player

User  
0 rated :

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...

JW Player

User  
0 rated :

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

http://www.counterbalance.tv/stars-ool/index-dbg.html

has a 128x96 video file, and smoothing set to false, but in full-screen appears smoothed.

Thanks,
Adrian

JeroenW

JW Player Support Agent  
0 rated :

We’ll investigate this issue too. 60% CPU while being idle is not a good thing indeed:

http://developer.longtailvideo.com/trac/ticket/1051

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).

JW Player

User  
0 rated :

Would using the current release of the player v.5.5 make any difference as I notice that you are using 5.4.

Have you tried it?

JW Player

User  
0 rated :

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.



JW Player

User  
0 rated :

Willie: I have updated to 5.5, and don't see any noticeable difference in performance so far...

Q to anyone: Am I correct in thinking the 'deblocking' value will have no effect on h.264 video playback?

JW Player

User  
0 rated :

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?

JeroenW

JW Player Support Agent  
0 rated :

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.

JW Player

User  
0 rated :

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?

JeroenW

JW Player Support Agent  
0 rated :

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.

JW Player

User  
0 rated :

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

Ethan Feldman

JW Player Support Agent  
0 rated :

Can you provide a link?

JW Player

User  
0 rated :

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.

JW Player

User  
0 rated :

The Safari link above is wrong:
http://stage2.silverorange.com/work/nick/jwplayer-video-test/screenshots/safari-5.png

JeroenW

JW Player Support Agent  
0 rated :

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.