Update AV1 info (links and notes) #4699
Comments
|
I would be happy to do a pull request for this, if that's helpful, once it's clearer what should be updated and how. Going to wait for some comments/feedback first, though. Also, happy holidays! |
|
Going to try to collecting interesting sources for things, particularly to support these changes to caniuse's data. Might update this comment if I find more sources.
(Edit 16 Feb '19: Added another relevant bug ("Fix handling of AV1 pref") that was filed five days earlier, and which explicitly mentions the decision to play AV1 beyond Nightly.) Interesting extra stuff:
(It's apparently only approved for beta 65 so far, but as long as that goes smoothly, I infer it would then "ride the trains" (beta for 6 weeks -> stable) into stable, as Moz employees like to say.) |
|
Short version of what the data should look like for latest stable browsers:
|
|
Already reflected on caniuse.com ✔️ : AV1 is enabled by default in Firefox 65+ "on Windows"... Complicated stuff about Windows 32-bit ℹ️ : The AV1 decode feature has just been allowed to be built on Windows 32-bit Nightly as of a couple days ago. Also, it's approved for "uplift to beta" so I guess that means Firefox 66 for Windows 32-bit may also get AV1 built (usable at all) and enabled by default.
(Edit: Already taken care of.) (Edit: I hadn't noticed #4716. Updating this comment...) |
|
I created a pull request to correct the fact Firefox 65 Windows does support AV1. (I didn't revise the notes, I just made the FF66 note also apply to FF65, which is more accurate.) |
|
I'm noticing that 0e26ddf accurately set FF65 as supporting AV1 for Windows (line 119), but then I'm not sure what happened, but I'm hoping putting a note here will clarify things a bit, and we can accept the pull request I just submitted. |
|
On another topic (support on mobile browsers):
Sources that indicate there's no support on Chrome for Android (as of 6th Feb '19):
|
|
The only thing from the initial comment/description that hasn't been resolved yet concerns the Facebook's sample AV1 video. I agree with you that it is not useful at all, since the video is supposed to always play, even when AV1 is not supported by your browser. Also, as you said, the player doesn't provide any info about used codec. Instead of the Facebook's sample AV1 video we can provide the well-known AV1 sample videos by Netflix. What do you think? |
|
(Summary: The Facebook demo is subtly better now than I thought at the time (maybe it's been updated?), so I feel it could stay, but maybe there are one or two additional demos or videos that can be added.) The Facebook demo works okay now. I've gone and tested it again, and noticed that it works roughly on-par with the Bitmovin demo. Testing details: (click to expand)
So given it only appears to play with AV1 (or else errors out) I'd say it's technically on par with the Bitmovin demo for purposes of showing that AV1 works in your browser. I'd say the messaging is still a bit unclear. First of all, this old text is not applicable anymore:
... And judging solely by the text beneath the video, it wouldn't be a very useful demo:
.... But my testing shows this line is also not true anymore. It simply won't play if you don't have AV1 enabled. (By way of contrast, Bitmovin's demo has "AV1" plastered everywhere, and actually includes the bitrate and such into the video file. It has also never been able to play if AV1 was disabled. So that's a step above the Facebook demo, IMO.) That said, it's not so bad as to warrant removing the Facebook demo I guess (nothing against Facebook). But maybe some additional demos would be okay, like the Netflix clips, or YouTube's AV1 beta playlist. It's not a huge priority in my view, since we have two demos that basically work. But maybe some better sources can be added, so long as it's not an excessive number of them. That's my take. |
This works fine with Bromite, which is a Chromium fork as I mentioned in #4626 so I would expect upstream Chromium (for Android) to close soon the gap. Using regular Chrome (for Android) I can only see in the gear icon menu SD/HD while with Bromite there are 360p and 240p AV1 options. I use https://tools.woolyss.com/html5-audio-video-tester/ for some AV1 tests as well, which has a nice interface to add support for basically any media URL. |
|
If mobile browsers can play the Facebook demo, without using AV1, then maybe the Facebook demo should be replaced with a better one. I'll take a look at that when I get a chance... But if anyone wants to double-check and confirm that, then I think the Facebook demo should be replaced with a clearer example that only works with AV1. P.S. Thanks @csagan5, that page looks helpful (https://tools.woolyss.com/html5-audio-video-tester/). Edit: I can confirm what @csagan5 said above: The Facebook demo plays in Chrome for Android, even though Chrome for Android doesn't support AV1. But it's plausible Chrome will play the demo with actual AV1 soon... So it could be sort of a moot point? 🤷 |
I assume they have not enabled it because it needs more testing (or similar). By the way, in order for the Javascript side to be aware of the capability with This is a console one-liner to test the availability of AV1 on Chrome (for Android): ( Other AV1 test files from Netflix: http://download.opencontent.netflix.com/?prefix=AV1/Chimera/ (no HTML5 player there) For the purpose of this project I would simply run the test with https://tools.woolyss.com/html5-audio-video-tester/?u=https://github.com/chromium/chromium/raw/master/media/test/data/bear-av1.webm and if it does not play then AV1 is not supported. Edit: added this information to https://github.com/bromite/bromite/wiki/AV1-support |
|
Looks like Firefox 66 on Windows 32-bit and on macOS in general may get AV1 on by default: (Both have Status: |
|
Confirmed that Firefox 66 on Windows 32-bit and on macOS are getting AV1 by default.
|
|
Looks like Linux will get AV1 "on by default" as well, in Firefox 67:
(Neat side note: So far it looks like (starting Firefox 67) the |
|
I have a suggestion. What do you think about removing the info that in Firefox 65.0 AV1 is enabled by default only for 64-bit Windows users (I'm talking about removing only the "64-bit", not the entire sentence), and moving it to the bugs section, since not only Firefox 65.0 was affected by the Bug 1475564 (but also older releases)? |
|
Maybe put (64-bit) in parentheses and add the bug? The way we have it now largely matches the Firefox Release notes. I think they summarize the changes stable release channel users would see pretty well. Also, FWIW, and for comparison's sake, HEVC and WebM have fewer notes. We can think about the best way to arrange or present support info for AV1, maybe removing some details or moving them over to the bugs section. (e.g. Maybe the details about the "media.av1.enabled" pref should be simply deleted, or else moved to the bugs?) Now that we know support only in windows is unique to 65, maybe we should list that as: Or "Windows (64-bit)", whichever amount if detail we go with). |
|
But this isn't the only caniuse feature with pre-release browser support info. So the level of detail we have already is probably not a hard "too much." I think there is no one right way to do it. https://github.com/Fyrd/caniuse/search?q=beta&unscoped_q=beta https://github.com/Fyrd/caniuse/search?q=nightly&unscoped_q=nightly |
|
I think having this amount of notes is not too many. E.g. on Wikipedia there are a way more references at the bottom of an article and I'm pretty sure that less than 1/2 of visitors scroll intentionally to the bottom to see them all. For me, it's not necessary to remove anything from the notes. My intention of removing the "64-bit" was that we now have support for AV1 in Firefox divided into Windows, macOS and Linux, so dividing it also into 64-bit and 32-bit can be too detailed. Additionally, lacking support for AV1 in Firefox 65.0 for 32-bit Windows was not intentional, but caused by the bug in MSVC, which is not developed by Mozilla. Also, the bugs section is empty, so it can be easily filled :D |
|
I don't disagree with your take on this, especially from a developer/behind-the-scenes perspective, and any way is probably fine, but from a more end-user perspective, IMO the 32-bit vs 64-bit distinction remains important. For sake of discussion, a counterpoint: (First, some background for my counterpoint...) What you say is technically true: The big distinction of AV1 on by default in Windows" was on purpose, and leaving out 32-bit was due to a separate bug-response process that looks to have been a bit forgotten-about at the time Windows AV1 was flipped on by default. So far we are on the same page. (More background...) The end result was, support in 32-bit Windows got left out until 66. In terms purely of Firefox "Release" edition, it was Windows 64-bit --> all Windows* (other than ARM!) plus all macOS, --> soon to be all official Linux, macOS and Windows builds (except on ARM!) (and while not widely talked about, there is apparently some level of support on the BSD's? Maybe the toggle is at a "Unix-like OSes" level, rather than Linux-specific?) (End of background and now the counterpoint...) So as far as many "regular Firefox users" (or developers who target same) are concerned, the "bug" with MSVC was a highly relevant piece of information, and materially affected the amount of support shipped in 65. (Meanwhile, there are no other 32-bit vs 64-bit distinctions to make.) Maybe we can say in the note for 65: "(64-bit only, see bugs section)", to point people that way? I'd hate to leave out the fact that Ffx 65 users on Windows 32-bit could not play AV1 unless they figured out the way to recompile it with Clang and change the build config themselves... So I'm resistant to taking the 64-bit distinction out of the 65 note. Just my 2 cents; If you remove it I won't try to put it back, but that's where I'm at personally. Better to tell people than leave it out, IMO. (Tl;dr I leantoward keeping "64-bit" for 65's note, add the bug to bugs section, and mention the bug in 65's note. But I won't get in the way if anybody uses a different way to represent the information.) |
|
That makes sense. I like your idea to add an info to notes section, which points users to "Known issues". Also, since the sentences about Windows and macOS are yours, I won't remove them without resolving this conversation. |
|
Hmm, I'm sort of ambivalent regarding the details. I don't want to hold everything up. Maybe to break the impasse: I (or you) can put up a PR, or just a diff here and we can try to agree on an exact change? Edit: working on a draft commit, will link here. |
|
How's this? DeeDeeG@abdaf50 Can tweak it and/or post as a pull request when it looks good. |
|
For me it generally looks good. Personally I prefer naming Firefox versions like that: 65.0, 66.0, etc., rather than 65 and 66, but it's just my preference. Additionally, I think titles next to bug numbers are not necessary. Anyone interested in can click on the link and read the full description. What will you change is your decision :) |
|
Thanks for the feedback.
It looks as if the support will be the same for all of the 65 cycle, then updated for all of the 66 cycle, and finally updated for all of the 67 cycle. If there is, say, a 66.1 release, one would anticipate this to have similar support as 66.0. So I think referring in the most general way to "66" captures the level of detail we can zoom in on without being "over-precise." (Admittedly, there probably won't be a 66.1... They usually do minor versions only for ESR, which is on the 60 series and isn't going branch off again until 68... https://wiki.mozilla.org/Release_Management/Calendar) But also for Nightly, there are meaningful changes right in the middle of a cycle, whereas the version number is stable as So I personally feel with Firefox it is best to only give the Major version, unless a minor/patch version introduced relevant changes.
This is true. I was thinking to add the title for quick skimming, adding context, and conveying at least some information for those who have little time. It's not many more characters of text, so I feel it is worth it. There are varying examples of folks giving more or less context to these links in the data files: https://github.com/Fyrd/caniuse/search?q=bugzilla&unscoped_q=bugzilla (So overall I lean toward my way, but I see your perspective and it makes sense to me either way basically.) On another note: I need to change support in 67 to "yes", not "partial" because otherwise it will have a note about 66 attached to it. I don't think the Firefox folks have anything radical planned to re-disable AV1 on Linux, so it would be fine. Just going to keep an eye out if they have a change of plans so we update the data for caniuse.com. So I will add a commit to update 67's support to "yes" for the pull request. |
|
The "Edge based on Chromium" era is soon to be upon us... https://arstechnica.com/gadgets/2019/04/hands-on-first-public-previews-of-chromium-based-edge-are-now-out/ Meaning that future versions of Edge will likely support AV1 (via the Chromium code-base it is forking/patching to make Edge now. Very few changes are actually made relative to Chromium, as of this first preview.) |
|
News here. According to their bug tracker https://bugs.webkit.org/show_bug.cgi?id=207547 Their changeset is a bit dubious and it sems they only want to use/enable it if there is a fast Rust decoder though:
|
|
Thanks for the update! I take the actual changed code as indicating Vector<String> av1DecodersBlacklist { "av1dec"_s };
if ((matroskaSupported || isContainerTypeSupported("video/mp4")) && hasElementForMediaType(m_videoDecoderFactories, "video/x-av1", false, makeOptional(WTFMove(av1DecodersBlacklist)))) {
m_codecMap.add(AtomString("av01*"), false);
m_codecMap.add(AtomString("x-av1"), false);
}Also, this is news to me, but there is in fact a gstreamer plugin of
Reading this comment from the bug tracker, It looks like this targets an eventual WebKitGTK 2.30 release. And that it won't really work (will be blocklisted) possibly until an eventual GStreamer 1.18 release. Still, plumbing this support in does lay the groundwork for eventually being able to play AV1 in the likes of Safari and Gnome Web. Not today, but tomorrow ™️. (I'm actually pretty sure Safari doesn't use WebKitGTK, since GTK is more of a Linux-first thing. So maybe Safari will have its own timeline for this.) |
|
Is there something left to do here? Given the recent PRs and current state of https://caniuse.com/?search=AV1? 0:-) |
|
I haven't been tracking AV1 support in browsers very closely. And it seems folks have mostly moved on from using this issue to track and discuss changes. As long as someone keeps updating the data, that's great! I'm comfortable closing this though. (Before I close the issue, even if this is a bit off-topic: Kudos to everyone involved with caniuse and MDN!! Both are really great resources, and it's super neat to see the cross-collaboration going on! Thanks for all that you do!) |
Edit 4th February 2019: This original comment has been addressed, and the data is largely up-to-date now. Keeping this issue open though, since AV1 support is still changing quickly.
For more up-to-date info, see comments at the bottom, and/or check the history of Pull Requests involving AV1 in this repository...
Original comment is left below for reference, though it is out-of-date and can be safely ignored at this point.
Hi,
Now that AV1 post-1.0 has been out for a while, support is getting more and more stable in more browsers.
As such, a few of the links and notes can be updated for
av1.json:Links
This works in Chrome stable, and also Firefox stable if the relevant flag is enabled.Edit: This has been addressed in #4708 (this line).
I believe the Windows Nov 2018 update introduced AV1 support across Windows, including Edge. Wikipedia says so, anyway: https://en.wikipedia.org/wiki/AV1#Software Maybe remove this note?On further reading, AV1 in Edge still requires the AV1 extension pack for Windows, which is still listed as "beta". https://www.microsoft.com/en-us/p/av1-video-extension-beta/9mvzqvxjbq9v?activetab=pivot:overviewtab
However, Edge will be switching to be a Chromium-based browser soon, and while they could conceivably disable AV1 decode, I would not expect them to. So Edge may see AV1 support via the Chromium code base some time soon.
This demo video at Facebook can play back with another codec, even if your browser doesn't support AV1. The page doesn't display any feedback or info on which codec it is using, so I am not sure how useful it is as a demo. I can't really tell if it's using AV1, or just a nice VP9 or MP4. I guess I am suggesting to remove this link? Or to replace it with another demo?I went and tested this again; The Facebook demo does not play with other codecs, only AV1. And if you click the "gear" icon in the video player, it will say e.g.
360p AV1. See #4699 (comment) for details.Notes
Firefox stable 63 and newer can have this flag enabled and play AV1, even outside of Nightly. Maybe split this note into its current text (still accurate for 62 and earlier) and a new one for 63 and more-recent.Edit: This has been addressed in #4708 (this line) and #4716 (this line).
Supported in Edge out-of-the-box (no beta plugin) as of the Nov 2018 Windows update, I suppose, per Wikipedia?: https://en.wikipedia.org/wiki/AV1#Software (Have not tested this myself.) Maybe update this note (or the browser version support data, whichever is the relevant thing to update)?Actually, this note is accurate as-is. I misread the Wikipedia article. The sources Wikipedia cites in turn only mention the Beta AV1 extension pack, and I cannot find any sources that say otherwise. This note can be left alone, since it's still 100% correct as-is.
The text was updated successfully, but these errors were encountered: