I'm using an extension[0] to force youtube to serve me with h264 in order to be able to watch 4K videos & maintain reasonable battery life.
(They do mention "More than 20 device partners across the industry are launching products in 2015 and beyond using VP9.", so perhaps some of those will feature working hardware acceleration.)
Basically no one but Google is particularly interested in VP9. Most of the key players in the IT industry are part of the H.26x camp. And when you have Apple who dominates mobile browsing not interested then content creators won't be interested. This flows onto component suppliers.
On OSX there is a noticeable difference in performance of video playback in Safari and Chrome, and I'm pretty sure it's all down to hardware accelerated decoding.
They've got hardware accelerated CSS3 working right in the latest versions, but VP8/VP9 won't work. The explanation is that Safari doesn't support VP8/VP9, so a fallback to h264 happens and the hardware accelerates that properly.
H.265 and VP9 will (most likely) have a lot of difference when we consider hardware encoders/decoders. I guess H.265 hardware decoders will be present on all platforms in the next couple of years. There are mobile processors that have hardware H.265 decoder. H.265 encoder seems to be a bit far. I am not sure whether someone has a production ready hardware encoder. On the other hand, VP9 is not a priority for most of the companies.
Set media.mediasource.enabled=true to enable MSE and everything on https://www.youtube.com/html5 will be enabled except for VP8/9.
I'm on Windows, btw.
For youtube&everything-else, you got two major tools: 1. CPU usage, just watch it, if you don't see spikes while playing video, you're good(on quad core 4th gen Intel core I get around 7% increase in load for HW-accelerated youtube 1080p video). 2. Even better: Tools like GPU-Z[0] have "Video Engine Load" meters for some GPUs(e.g. Nvidia GTX), where you can see if the GPU dedicated accelerator is working(and how much). For other GPU-Z(e.g. Intel HD) you can monitor the general "GPU Load", you will see an increase there as instead.
[0] http://www.techpowerup.com/gpuz/
P.S. In addition to the above, in some browsers(in chrome, via chrome://flags) & media players you can disable the hardware acceleration support and observe the results using the tools I've mentioned.
I just tried h264ify and I don't notice any improvement on Firefox. Chrome CPU usage seems to be a little lower.
This is my go-to video test: https://www.youtube.com/watch?v=7SRTEXSpcyI
Chromium: I get around 140% CPU usage, spread on 3 processes, video smooth without dropped frames.
Firefox with MSE+HTML5 video: Goes from 30% to 170% CPU, on single process, but the video gets stuck for 3 seconds every second of play time. Totally unwatchable, unless I drop down to 30 fps.
like https://emericdev.wordpress.com/2011/07/10/a-vp8-hardware-de...
http://www.ittiam.com/key-technologies/vp9/
Your link is just to a software layer that takes advantage of any hardware present on the system i.e. on an intel system with vp8 hardware decode it'll use that, if not then it'll use software.
edit: on a second read I see your link intends to create a GPU accelerated VP8 decoder backend for those libraries, not just create the interface layer.
To my knowledge, webm hardware acceleration designs has only been available to hardware manufacturers since around 2011. I also could not find a open mozilla bug ticket regarding hardware acceleration.
Windows: https://bugzilla.mozilla.org/show_bug.cgi?id=922314
Android: https://bugzilla.mozilla.org/show_bug.cgi?id=986381
Linux supports HW decoding via gstreamer, if you have gstreamer set up to use your hardware (this can take some work).
Well, yeah, but they focus first on the significance of this for the 240p to 480p crowd for which that is less relevant.
Touting impressive-sounding and strongly-needed improvements of an activity many people engage in, evangelizing, Google is taking advantage of what may be a position to influence hardware to enable, for example, the 80% of Indian youtubers who can only watch 240p youtube clips to watch 480p now with this Google math.
And those who can only watch 480p instead can enjoy silky smooth 720p, and those who just cannot get enough pixels and want 4k but don't have Google Fiber just yet can now enjoy VP9 WebM 4k video on their Nexus 6 without excessive battery drain, as others with 4K displays could do too if they had some HW acceleration, which, while not written in the article, is visible to someone like you and someone like a hardware engineer at Apple and some codec whiz of the Surface and Windows Phone guys at Microsoft.
For all you enthusiasts, Google says? Here's your ffmpeg how-to link, right in this blog post. No need to worry about patents either y'all! And this VP9 vs H264 side-by-side is to write home about, ain't it.
Note that VP9 users are not quite edge cases, as they claim 25 billion hours of youtube was watched in the trailing twelve months. Not sure how many unique visitor sessions that is but that's a big number.
So the blog post, in addition to proclaiming this magical, newsworthy math most relevant to that list of countries I'm glad I don't live in, plus Google's running the youtube show, plus Google's web properties, plus Chrome and so forth, they can add some pressure to the hardware guys, the gods of official standards and of course the browser foot-draggers that make other browsers, to help Google help everyone else make the web faster.
Kind of like with SPDY. :) https://plus.google.com/explore/makethewebfaster
edit, from the end of the post:
> Where can I use VP9? > Thanks to our device partners, VP9 decoding support is available today in the Chrome web browser, in Android devices like the Samsung Galaxy S6, and in TVs and game consoles from Sony, LG, Sharp, and more. More than 20 device partners across the industry are launching products in 2015 and beyond using VP9.
Here's a stack of 4K/60FPS youtube clips (don't hit play using your daddy's codec): http://techcrunch.com/2015/03/26/youtube-is-experimenting-wi...
Actually you likely do. VP8 was patent encumbered and needed a licensing deal with MPEG-LA. It is very likely that VP9 would need a similar deal.
Another problem seems to be YouTube's player that just sometimes stops to play although the video is completely loaded, or you try to skip or go back a few seconds and it just stucks completely.
Luckily I found this Firefox extension that just uses the native player and allows me to use high quality by default:
Try letting it play for a bit and you'll notice everything get sharper. Especially in full screen.
DASH is annoying as hell.
I watch a lot of youtube these days and when I'm sub'ed to a channel, I shouldn't have to deal with buffering just to skip excessively long intros that I've seen for the 50th time.
Fine, don't load the whole video ahead of time, but can you just load the first say 30 seconds? Or maybe even - and I know this is going to sound crazy - a whole minute ahead of time?
I remember a time when it seemingly didn't load even 5 seconds ahead of time. That's just ridiculous. Fire the bean counters who are in charge of that short-sighted idea.
It's been removed from the Chrome Web Store though, so installing it on Chrome on Windows is a pain. Still on AMO for Firefox users though.
[0]: http://yuba.stanford.edu/~nickm/papers/Confused_Timid_and_Un...
https://github.com/SirCmpwn/ExternalPlayer
I got fed up with the YouTube player and wrote this in an afternoon instead.
I see you are using youtube-dl. I did too at first, but quickly swapped for YouTubeCenter plugin - it extracts link to mp4 directly in the javascript, my additional javascript grabs that and substitutes YT player window with big PLAY button with a link to custom protocol "magnet1:https://r2---sn-2apm-f5fee.googlevideo.com/videoplayback?sou....
Copying the way browsers open magnet links was the quickest and easiest way I found of passing links directly to a third party program. I simply made a new one, called it magnet1, and directed it towards \AppData\Roaming\smplayer\mplayer.bat %1
.
mplayer.bat:
echo off
set var=%1
start "" "C:\Users\bofh\AppData\Roaming\smplayer\smplayer" "%var:~9%
exit
.
cut first 9 characters (magnet1:) and run mplayer, that again was the only way I found of starting new program without keeping command line window open. No delay between clicking and starting video, no unnecesary command prompt window with youtube-dl running. I also have a second custom protocol that starts yet another bat file sending link directly to my TV - one click on a page and YT clip starts playing on the TV in the next room :o)
Feels like duct tape and glue, but works flawlessly :)
Side note, oh boy do you need to get some Linux in your life. That's the hackiest thing I've ever seen on Windows for something that'd take minutes to implement on Linux.
Edit: I just noticed that Firefox is currently using Flash on Youtube for video playback. The video referenced in the article: https://www.youtube.com/watch?v=pwnefUaKCbc
Youtube only used VP9 with MSE but even then not all content is available as VP9, some is only available as H.264/MSE.
You can check https://www.youtube.com/html5 to see what your browser supports.
That being said, YouTube does also encode audio-only versions of all their videos; they're not available from the web player though. You can use external software such as youtube-dl[1] to take advantage of it.
[1]: https://github.com/rg3/youtube-dl/ (using an invocation such as "youtube-dl -g -f bestaudio [url]" to retrieve the URL of an audio-only encode)
[1]: http://iphome.hhi.de/marpe/download/Performance_HEVC_VP9_X26...
Table VI. Encoding Run Times for Equal PSNR_{YUV}, HEVC vs. VP9 (in %): 735.2
I.e., HM is over 7x slower than VP9's slowest settings. VP9 speeds have improved dramatically since then, and it is now being used real-time (Google is working on adding it to WebRTC), while still demonstrating significant quality improvements over prior generations.
See also https://news.ycombinator.com/item?id=9329580 w.r.t. the quality aspect.
I would strongly argue that h264 can ever outperform vp9 in video quality (given same number of bits), however, hardware/browser support will decide whether vp9 is adopted or not.
It's still H.265. Like past standards, HEVC/H.265 is a joint effort between ISO's MPEG and the ITU's VCEG. They're different identifiers for different organizations.
http://compare-codecs.appspot.com/results/
https://github.com/google/compare-codecs
It's early days though, e.g. only PSNR for now, but the basic idea of repeatable, open source codec testing so that if someone complains about any aspect they can fork and show the difference, and hopefully get it rolled back in to future versions, is very cool.
Both of those are much older encoders, of course (nearly 2 years old in the case of the PCS paper), and some of the settings they used were questionable, e.g., what HEVC calls "constant QP" actually varies the quantizer based on the frame type, while VP9 really uses the same quantizer, which can make a big difference on metrics. Talking to the authors at PCS, they re-ran results later with more relaxed QP settings, and VP9 got somewhat better, but still didn't catch up with HEVC (on metrics).
Keep in mind all of these results are from people who have spent significant time working in MPEG/ITU/JVT/JCTVC, and may have some inherent biases. Google's own results looked much better: http://ieeexplore.ieee.org/iel7/6729645/6737661/06737765.pdf... (sorry for the paywall, I'm not aware of a free version available online, tl/dr: 30.38% better rate than H.264, 2.49% worse than HEVC), but obviously come with their own set of biases.
I don't know how to explain the discrepancies in the two sets of results, but they at least demonstrate the magnitude of the differences you can obtain by varying how you do the testing.
But to play the VP9 Youtube URLs, you need to be able to play DASH format too.
And this, DASH extension used by Youtube is not supported yet in VLC. However, it should be, for the next major release.
I think making a comparison without providing information how they obtained the results is much worse than the particular choice of codecs pitted against each other.
How much CPU time did they burn on each encode? Which settings were used? did they pick a frame at random or was cherrypicking involved? Or for that matter, which encoders did they use?
Don't get me wrong, I think the "patent-free" VP9 is really nice, but I'm afraid it won't win if it's not better technically, especially if HEVC-patent pool prices are reasonable. Or maybe the only goal of Google is keeping patent licenses affordable by maintaining competition ?
