I’ve been reviewing several Intel Bay Trail, Cherry Trail, and Braswell mini PCs in the last year or so, and I always end up recommending Microsoft Edge browser over Firefox or Chrome for people wanting to watch YouTube videos, as the last two browsers always drop many frames with the video stuttering regularly. However I noticed that while Edge is playing MP4/AVC (H.264) video, the other two browser would normally stream WebM/VP9 videos, and it could be the cause of the problem as H.264 can be hardware accelerated, but VP9 not, and the low power processor might not quite powerful enough to handle 1080p VP9 video decoding smoothly.
So I investigated the issues with Vorke V1 mini PC powered by an Intel Celeron J3160 processor (6W TDP) with the three browsers by first checking enabled codecs in YouTube HTML5 page.
- Microsoft Edge has both VP8 and VP9 disabled
- When I tested Firefox 47 in other mini PCs VP9 was enabled, but I decided to install Firefox 48 Beta instead, and while WebM VP8 is enabled, MSE & WebM VP9 is disabled.
- Chrome stable has both VP8 and VP9 enabled.
I’ve selected a video and played it in Edge, Firefox, and Chrome. The first had no frame drops using H.264, but the later had many using VP9 as verified using “Stats for Nerds” option in YouTube.
That’s the result in Edge (and the same in Firefox).
No dropped frame after 1 minutes and 30 seconds using MP4/AVC1 (H.264) video streaming. Power consumption while playing the video was 7 to 8 Watts. Compared that to Chrome results:
461 frames dropped out of 2,788 after 1 minutes and 56 seconds using WebM/VP9 video streaming, and power consumption around 11 Watts, or 3 to 4 Watts greater than with Microsoft Edge. So what’s the solution? Let’s try to disable VP9 using h264ify extension, also available as a Firefox add-on.
Magic! No frames dropped after one minute and 30 seconds (and the rest of the video), and power consumption drops to around 8 Watts.
I’ve tested this in Windows 10, but it should also work with Linux distributions on Intel hardware. ARM based mini PCs running Linux may not benefit as I’m not aware of any ARM Linux mini PC or boards that support 1080p hardware video decoding inside any web browsers.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
wow, thanks! i dont have h264 hw decoding at all (old ati card) but no frame drops with sw decode anymore now!
Should be interesting to report it to Firefox team, so the can take care of this case.
Very interesting and useful article.
Question @CNX: with WebM/VP9 still enabled, did you monitor the CPU load? If so, was the CPU (almost) fully loaded?
I have a laptop with an Intel Celeron N2840. Is the above true for that CPU?
@Sander
I did not check CPU load, but I’m sure with VP9 it was pretty high considering it consumers 4 watts more.
Your laptop should have the same problem, and it will also affect the battery life.
You just need to check whether VP9 is enabled @ youtube.com/html5 to find out.
The problem is chip manufacturers implementation of VP9 hardware decoding. VP9 is still not as prioritized as HEVC or H.264 so chip manufacturers really only make sure that those latter codecs are working nicley.
@cnx-soft, that could be an interesting topic for a new blog post by yourself? I think it is unfortuante that VP9 is still considered a second-class citizen by chip manufacturers.
Why is VP9 still considered a second-class citizen by chip manufacturers? Compared to HEVC and H.264, the VP9 video codec is royalty free and promoted by Google through Android and YouTube. VP9 hardware acceleration is supported via Android MediaCodec API, Nvidia’s VDPAU, Intel’s VA-API (on Linux/Unix) and Microsoft DXVA2-accelerated VP9 decoding on Windows, and of course FFmpeg and Libav software decoding.
having troubles on my linux desktop (nvidia gtx670, no VP9 hw decoder, amd fx 8 cores) in chrome, i’m actually wondering how good (or real) is hw decoding in that browser.
I have enabled html5 player and in chrome i get all the videos formats enabled by youtube.
But when playing youtube h264 videos in chrome (i don’t have vp9 hw decoding, so i’m forcing h264) i get those results :
– 1080p h264 in chrome will bring my cpu to 60-80% load on 2-3 processes, the Gpu at 30% load, Vpu stays at 0% (!?).
– mpv will play (stream with “-ytdl -ytdl-format=137+251”, vdpau hw) the same h264 video using 5% on 1 process, 5% Gpu (same load as when nothing is being played) and around 20% Vpu load.
– mpv 1080p vp9 will use 60% cpu on 1 process, 5% Gpu and 0% Vpu (no hw decoder).
So i’m wondering if i’ve broken something in my system or if linux chrome html5 player is not capable of vpu hw decoding ?
It sure is using the gpu heavily but the overall performance cpu+gpu is extremely poor.
So yes i use an external player (mpv with youtube-dl / livestreamer) on my overpowered desktop system to play long youtube videos. I have not tested firefox which i dropped over a year ago.
I will test my various arm tv boxes with linux desktops to see how they perform with h264 and vp9.
@Harley
Actually for low power Intel processors the problem starts with the hardware, as VP9 is simply not supported by the GPU.
This also happens in Chromebooks. The issue here is that sites should be interfacing with the browser to check for what is available as hw decoding support. Since Google is pushing VP9, they don’t even seem to care at all and one has to use h264ify to fix this.
@mdel
Same here on AMD FX8350 + GTX960 in Firefox with H.264 YouTube videos. Video Engine Utilization: 0%.
@cnxsoft
i also tested that in my current firefox 43.0 which also registers all the codecs on youtube’s html5 player, and i get the exact same thing 0% vpu.
hw video decoding could work in firefox on windows (check about:support “Supports Hardware H264 Decoding”) but i looks like it’s only in a DXVA context, so not available on linux.
But from what i gather html5 engines are much more WebGL (openGL ES 2) GPU acceleration oriented (3D), than hw video decoding.
@toto Firefox hides VP9 functionality where it isn’t going to be a win for the user. MSE/VP9 is enabled by default on machines that don’t have hardware decoding enabled or machines that can decode 720p VP9 at over 150 fps. Another way to put it is that MSE/VP9 isn’t enabled on slow machines unless they’re constrained to software decoding anyway.
If you are concerned about either power consumption or performance then the first thing you should so is upgrade your graphics driver. I also recommend looking at the graphics section of about:support to see if hardware H.264 decoding is available.
Tested it on my HP Stream 13 with Intel(R) Celeron(R) CPU N2840 @ 2.16GHz, and Chromium 50 on Ubuntu 16.04 LTS.
Short: I can confirm the above.
Details:
Default in Chrome is webm/vp9. Traffic is 14 Mbps, stuttering youtube clip, 50% (!) dropped frames, and CPU at 100%. So: absolutely unusable.
After installing h264ify: Traffic is 25 Mbps, just a bit of stuttering and frame drops at the beginning of the clip, but after that: no more frame drops, CPU load between 60% and 90%. So: very usable.
So, @CNX, impressive and useful article. And now we can wonder the clever boys and girls at Google do not take care of this themselves within Chrome/Chromium. So “if a lof of stuttering due to overloaded CPU, switch from Webm/VP9 to AVC1”. Pushing the VP9 codec is one thing, but bad videos is not good.
Related article: http://www.howtogeek.com/227940/why-youtube-in-chrome-and-firefox-is-draining-your-laptop%E2%80%99s-battery-and-how-to-fix-it/
QUOTE:
How to Make YouTube Play Videos More Effeciently
It’s a chicken and egg problem, really — manufacturers aren’t going to implement hardware-accelerated VP9 until it’s actually being used in the real world. Google solved this problem by adding VP8 and VP9 to Chrome and telling YouTube to serve VP9 and VP8 videos to Chrome. YouTube may also serve VP8 and VP9 videos to Firefox.
This might save some download time, but it means that YouTube drains more battery power and CPU cycles in Chrome. On devices with particularly slow CPUs, videos may even stutter instead of playing back smoothly.
To get more efficient playback, you could just switch to Safari, Microsoft Edge, or Internet Explorer. But you don’t have to do that. You can install the h264ify browser extension for Chrome, which will force Chrome to request H.264 videos from YouTube. They’ll look the same, but Chrome will play them back more smoothly
UNQUOTE
@Sander
I think the reason is here:
VP9: 14 Mbps
H.264: 25 Mbps
Google probably pays for traffic per Mb (TBC), and higher bandwidth also requires more infrastructure, so it should be less expensive for them to stream VP9 videos compared to H.264. I’m also not sure how MPEG LA licensing enters into the equation.
@cnxsoft
i think
there’s a misunderstanding here, the bandwidth you saw in your html5 player is not the video bandwidth it’s the buffering (download) bandwidth used by the player at that time.
for the video used above by cnxsoft, the video bitrates are much much lower :
– VP9 video only is 50.4MB, 3.37min ~ 1.85Mbps
– h264 video only is 56.2MB, 3.37min ~ 2.07Mbps
You can also verify that by playing them in VLC and open the stats data which will show you the bitrates.
So the actual difference between the two video codecs is around 10% in favor of VP9.
That was easily identified here because i scarcely see a buffering speed above 5Mpbs where i’m located, and my DSL link is maxed at 12Mpbs so there’s not way i could watch those videos at the speeds displayed above.
And yes youtube is “struggling” (google being an insanely rich company that word somehow doesn’t feel right), as many other content providers are (twitch), with bandwidth and infrastructure, although in most (all?) the countries i know of they are not (officially) paying for the bandwidth they emit and this is a problem mostly for local ISPs.
The way youtube handles that is to localize datacenters so the bandwidth emitted for local users can be achieved through peering (some sort of direct physical link between youtube’s server and your ISP’s server), this is most of the infrastructure cost mentioned above.
From an infrastructure standpoint i could speculate that the buffering bandwidth difference you saw when playing the vp9 and h264 versions, is due to player or server configurations, allocating bandwidth in various ways, or to infrastructure inconsistencies, for example h264 medias and vp9 medias not being hosted in the same locations.
@Sander
Firefox uses ffvp9 https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/ which gives a 2x improvement on machines with 4 physical cores. How does Firefox compare on your machine and what GPU and CPU do you have?
Thanks for the information. I have an Intel Braswell box (Vorke V1) and noticed dropped frames under certain circumstances. I’ll try that extension.
Any workarounds for Kodi?