AV1's been making good progress in Firefox. This 1080p60 video has gone from being essentially unplayable in AV1 to now being almost perfect on my 5-year old, AVX2 enabled laptop in Firefox 68 beta:
My system consistently drops frames at the point the jeep drives up the hill and then recovers for the remainder of the video. Other than that it's fine.
You can enable AV1 on YouTube via TestTube (https://www.youtube.com/testtube) and you can check if a video is in AV1 via right clicking on the video and selecting Stats for Nerds. If it's AV1 the codec will be "av01".
Can't enable AV1.. clicking that button throws a QuotaExceededError: The quota has been exceeded.
Nice web. I'd like it if such decisions were made in the user agent, but once again all the functionality is baked into webshites that reinvent the wheel badly and the user agent is just a dumb client :(
On Linux Firefox suffers from lack of hardware decoding and encoding (it doesn't plug into vaapi), which makes performance quite bad on laptops. I suspect something like WebEx, for example, works horribly in result. Or may be it's just Cisco not doing a good job. Conferencing experience with their WebRTC client in Firefox on Linux is horrendous.
Current state of Vulkan port is that the correctness is on par with GL, minus a few driver bugs. We still need to re-architect WebRender a bit in order to get the performance advantage over GL.
I just switched to Firefox again after some shortsighted changes on Chrome. Neither give me GPU decode on Linux, but FF is SIGNIFICANTLY worse than Chrome on CPU decode. I can do a build in the background using all 12 threads and have no issues with video play back on Chrome (well, maybe not 4k60) but FF it's unwatchable, even at 900p60. (i7 8700k if you're wondering hardware wise, not OC'd because horrible chip and not worth it)
So VAAPI support can soon land in Firefox for Linux? Cool. This is great news for me.
Can you give us some details? When? Can I somehow help in testing, for example in Firefox nightly?
What hardware can be supported? What formats, h264 or/and vp9?
Well at least Chromium has support for this. I don't know why it is taking Mozilla so long honestly, but I'm guessing most of their developers don't use Linux and the org just loves to virtual-signal and not practice what they preach.
google refuses to support this on desktop linux though, it requires a patched chromium build. The only reason vaapi support is there at all is because their chromeOS uses it.
It's weird, my Firefox seems to use the vaapi (but my iGPU is only able to hw-decode h264 and VP8 and VP9.Too old for AV1.)
I have a not so powerful laptop so I think the HW decoding capability of the iGPU is actually used, otherwise I couldn't play 1080p videos at 60 FPS (h264 and VP9).
I use the static Firefox from Mozilla. Not distro repo's one.
Nope. It's just software decoders from FFmpeg project that are heavily optimized. Also Firefox disables VP9 on slower machines, so websites serve H.264 instead.
At least on YouTube, I use VP9 (we can check that with the "advanced stats" showed when right-clicking on the video).
My laptop is usually noisy when the CPU is in demand. I am a bit surprised because playing HD videos on YT does not make the fan too noisy (comparing to loading a website with a ton of JS,for example).
So, I concluded that some HW decoding was in use, somehow. I can, of course, be wrong.
There is no way that ffmpeg uses a HW decoding decoder under the hood? It may explain why it's so smooth. Besides, when I run VP9 video with MPV, it tells me that it is explicitly using HW decoding via vaapi. And MPV is based on ffmpeg libs for the playback, if I am not mistaken.
I've just checked Firefox 67.0 source code and found no evidence of hw-accelerated decoding. Firefox uses part of FFmpeg source code under the name "ffvpx", for VP9. There are some remainders of such decode-and-then-download-to-CPU-memory code there, but actual part interfacing with VA-API or any other hw-accelerated API is removed.
Although it's possible to utilize hardware decoders with FFmpeg, frames need to be shown somehow. Downloading decoded frames back to CPU memory just to copy them back to GPU to display is not a good idea. Generally graphics adapters expect a lot more data coming to them, not from them. It may be so slow, that it makes the whole idea infeasible. To make hardware decoding actually useful, one needs to figure out how to combine everything together on GPU side. It's harder to do it in Firefox than in a video player, since browsers have a complex rendering model. And now even run in multiple processes.
> My laptop is usually noisy when the CPU is in demand.
Not only software codecs are highly optimized, CPUs are also power-efficient.
1080p VP9 decode on my Skylake laptop doesn't produce enough heat to start the fan.
I am checking that with the "about:support" page. My iGPU and the Intel drivers are correctly recognized so I was assuming that HW decoding was enabled.
But I can certainly be wrong, good platform detection does not necessarily mean that I use HW decoding. I just assumed it was the case.
Does it work for conferencing too? I often get "low bandwidth / low CPU" warning and no video feed, despite having quite good hardware. The more people are in the room - the worse (it's as if instead of multiplexing on the backend, it tries to multiplex on the client side). Very annoying.
Thanks, I used the Halo video[0] to compare, a couple of notes.
- Youtube seems to have limited the AV1 support to 1080p, 1440/2160p are not available, anyone any idea why?
- The load on my CPU (MB Pro 2018 quad-core/ FF DE 67.0b9) seems about the same but I do seem to be dropping significantly less frames, not sure though.
it was probably encoded at a time when they didn't do 4k av1 tests but only 1080p, but since then they also did a 4k one if you wanna test it https://youtu.be/LXb3EKWsInQ
On the one hand this is great, it's hard to argue that it isn't a good thing to have a very fast CPU-based AV-1 decoder built into Firefox.
On the other hand, I'm wondering how long this decoder will be relevant, especially considering it could still take a while before AV-1 video will be widespread on the web. I fully expect everyone and the kitchen sink will have hardware decoding before long, which is vastly superior over any software implementation.
YouTube started testing AV1 - I would not be surprised to learn that’s most of that number alone. Video format market share is tricky to measure because just a few sites like YouTube, Netflix, Vimeo, Twitch, etc. represent a huge fraction of the total streaked bandwidth even though there are so many other sites which publish video on the web.
Yeah, last I remember, Netflix and Youtube alone use something like 50% of the internet's entire bandwidth. Video is pretty data heavy though so I'm sure there's a huge push to switch to something more efficient.
As for HEVC's obsolescence, Leonardo Chiariglione, founder and chairman of MPEG, thinks AV1 has the bigger future because HEVC's licensing is too messy:
True, but if I am watching videos I'm feeling lazy and I shouldn't have to turn down resolution just for his videos because they're in 60fps instead of 30 when in Chrome it works fine (I'm using tampermonkey script which switches all videos to the highest resolution with 4k as a limit).
And you'll find many other YouTube videos encoded in AV1 up to 720p. Try popular music videos or movie trailers for examples. Check that it's AV1 by right clicking on the video and selecting Stats for Nerds.
I've filed bugs about this before, part of the problem is that every node in the chain needs to handle video ranges correctly. Once you introduce hardware decoders you can be in bad shape here because the range becomes a guess. Depending on which GPU vendor you have and what OS you're on, there may be a system-wide default output range (and a separate default for videos without range information), and the range assumptions may depend on application. If you use nerdy video compositors like madVR you can get them to tell you how much info they have on video ranges, and in many cases the answer is 'none' so they guess. At least on Windows, it is a fact that some of the range issues are not under Firefox's control, because some of this stuff is delegated to the decoder and to the video driver. (You can configure it in NVIDIA's Control Panel application, fwiw.)
In practice people seem to solve this by just using limited range all the time because it's much better to have limited range content displayed without expansion than to have full range content erroneously limited->full expanded and have a bunch of the range destroyed. If you try to stream to Twitch, for example, they tell you to use limited range, and it will look VERY bad in most players (not just Firefox!) if you disregard the advice. I've also had problems with full range uploads to YouTube that can't be attributed to Firefox.
EDIT: Checked my bug history. For the NVIDIA + Windows + Firefox combo, here is the workaround for range issues along with an explanation of why Mozilla has no way to fix it in this scenario. https://bugzilla.mozilla.org/show_bug.cgi?id=1229304#c8
Firefox's video support in general is pretty poor compared to Chrome. It doesn't support RGB or 4:4:4/4:2:2 YUV video either.
>here is the workaround
I knew that bug too, but that's a different story. That is about Firefox having problem to playback limited range video properly with nV graphic card (and it's partially nVidia's fault than Firefox).
Chrome used to have that bug too, but they have fixed it.
https://www.youtube.com/watch?v=Fmdb-KmlzD8
My system consistently drops frames at the point the jeep drives up the hill and then recovers for the remainder of the video. Other than that it's fine.
You can enable AV1 on YouTube via TestTube (https://www.youtube.com/testtube) and you can check if a video is in AV1 via right clicking on the video and selecting Stats for Nerds. If it's AV1 the codec will be "av01".