Talk:AV1

Logo

Is the logo supposed to be an A+1+v for Av1? Anyway, please add an infobox here. –193.96.224.9 (talk) 12:47, 2 March 2017 (UTC)

lists

Shouldn't we describe important features and the process how features are added in prose instead of bloating the article with those questionable excessive lists? I find such lists to add little value and regard them mostly as a sign for low quality articles.--Flugaal (talk) 20:14, 25 December 2017 (UTC)

For current experiments, let's drop those lacking explanations – that's no sacrifice at all. Actually, it doesn't matter, since that list is supposed to be empty in a month's time. Meanwhile, the list of former experiments will gain at most 5 more (J.Krishnan, STSWE 2017) before it's final. That list, in list form, is golden: All sources we have about the features of the format so far are sparse or outdated, while this list, to the best of our knowledge, is complete! If/when an official or better list or overview of any sort is revealed, we should of course link to that instead.—84.208.177.88 (talk) 22:10, 26 December 2017 (UTC)

I see how you may profit from the knowledge that the list is complete. Maybe it's a useful aid for our work as authors here. But I still don't see how readers profit more from having this info in list form instead of having it in prose. (I don't see what kind of an argument "is golden" is supposed to be.) Therefore, I'll move forward with prosifying this stuff.--Flugaal (talk) 21:06, 14 January 2018 (UTC)

There is no point in putting WP:Too much detail into an encyclopedia article. Regurgitating what can already be found in documentation (rather than coverage in independent reliable sources) doesn't add encyclopedic value to the article. The lists should be removed. ~Anachronist (talk) 21:21, 14 January 2018 (UTC)

I added the feature lists. It was an information vacuum when all we had was source code — only after finalization have I seen reasonably complete feature overviews elsewhere. I intend to carefully remove what we either have in prose now or can discard as uninteresting. Anachronist, thank you for discouraging me from completing this work – now, we don't know what I missed in the finalization phase. Painstakingly sifting through git commits is far from what I call regurgitating.—2A02:FE0:C400:4:2D1C:11E6:3286:801 (talk) 23:42, 19 December 2018 (UTC)

extended from VP10

VP10 is not a thing. It never made it past the vaporware state. AV1 is the successor to VP9, not VP10. There was an internal research project at Google whose results would have been named VP10 if AV1 and AOM had not happened and if it would have made reached publication. They decided against publishing a VP10. So, User:MennasDosbin, please leave VP10 out of the list in the "extended from" item of the infobox.--Flugaal (talk) 22:36, 15 January 2018 (UTC)

That wasn't me, that was MennasDosbin with this edit. Regardless, just because something wasn't published doesn't mean it didn't exist. Stickee (talk) 22:46, 15 January 2018 (UTC)

To add some detail: There is definitively a libvpx branch called nextgenv2, and it seems to have been that "internal research project" for VP10.[1] As an academic distinction, the AV1 research codebase was not based on nextgenv2, but all the experiments from nextgenv2 was backported later anyway.[2] 84.208.187.57 (talk) 22:55, 22 October 2018 (UTC)

I think this is a distinction without a difference. Indolering (talk) 02:23, 22 April 2020 (UTC)

Ambiguous wording/meaning in cited source: "binding specification," or software "bindings"? (AV1 Spec release, March 28th)

Hi all,

I am wondering what "binding" or "bindings" means in the context of this release. The source we cite isn't totally clear on the matter.

Relatedly, I just updated a sentence in the Wiki article: "The Alliance announced the release of the AV1 bitstream specification on 28 March 2018, along with a reference encoder, a reference decoder, test files ("reference streams"), and software bindings."

But the source seems a little vague with its usage of "binding" and "bindings":

"Designed at the outset for hardware optimization, the AV1 specification, reference code, and bindings are available for tool makers and developers to download here to begin designing AVI into products."

(This sentence seems to refer to software "language bindings".)

"Binding specifications to allow content creation and streaming tools for user-generated and commercial video"

(Does this sentence mean that the whole set of specs is "binding," in the sense that all implementers must now follow the specs? (Whereas before, the draft-status specs were "non-binding"?) Or does this refer to specifications that describe how to write/use bindings that ease use of the encoder and/or decoder libraries?)

In my own research on the subject, I have heard no reference to "bindings" anywhere else but this announcement. (No cite-worthy sources turned up, that I can remember.) I fear this might have been a typo or a brain fart or Freudian slip by the editor of the release announcement, and there may in fact be no bindings to speak of, only "binding specifications". But who can tell?

If anyone can help clear that up, I think it would help improve the factual accuracy of our treatment of this release event. — Preceding unsigned comment added by 68.81.226.126 (talk) 05:41, 29 March 2018 (UTC)

I deleted the claim about "bindings" in the article, since there weren't any references to bindings in coverage around the net, that I could find (other than a source or two that directly copy-pasted from the release announcement). 2601:4B:300:5D46:CC75:736C:89F2:FFC5 (talk) 19:20, 6 April 2018 (UTC)

Mystery solved: If we take the AV1 Codec ISO Media File Format Binding as an example, then a binding in this case is a containerization specification, but that would be an unreasonably specific interpretation. Reduce specificity out of the video domain, and we arrive at inter-standard standard.2A02:FE0:C400:4:2D1C:11E6:3286:801 (talk) 22:31, 19 December 2018 (UTC)

Found an informative (probably not citeable-quality?) source; Seems to clarify the meaning of "reference streams" as mentioned in spec release announcement (28 March)

http://www.argondesign.com/products/argon-streams-av1/

This company, Argon Design, is directly editing the spec document itself, which according to their site (see URL above) contains psuedo-code that they actually compile and use to generate "reference streams," which (near as I can tell) are just tiny, correctly-formatted video files matching the encoding spec. They have some mechanism to run these files through a given decoder programatically, and see if the output is "formally correct" per the encoding/decoding specs.

So basically, reading between the lines, Argon Designs will likely author the "reference streams" mentioned in the AV1 spec press release today (28 March). (They have already done similar for VP9 and HEVC, according to their site.)

(My reasoning here is something like original research, plus heavy reliance on primary sources, I know, so please don't put any of this into the article until we have proper source(s) to site. But I thought this was informative, and useful in interpreting the AOMedia announcement from today, so I wanted to mention it here in the mean-time.) — Preceding unsigned comment added by 68.81.226.126 (talk) 06:32, 29 March 2018 (UTC)

The article no longer mentions "reference streams" (with regard to the 1.0 announcement), because most secondary or third-party sources didn't mention reference streams, so verifiability is poor IMO, and in any case the fact of their existence is doubtful IMO. Tom's Hardware mentions "reference streams," but they're the only source I found that mentions them without directly copy-pasting from the release announcement. I don't think the one source is enough incentive to add this back to the article, since as far as I am aware, the streams aren't real just yet. I do expect them to come in due time, but if I'm reading between the lines correctly, Argon Designs needs to spec to be finalized before they can produce the reference streams. And I don't know of any other likely source of the reference streams, but I could be wrong. Just working with what I can find. Until there is a more-substantial source on reference streams for verifiability, I personally don't think it's worth changing the article to mention them. 2601:4B:300:5D46:CC75:736C:89F2:FFC5 (talk) 19:35, 6 April 2018 (UTC)

Although as of today there is a "v1.0.0" tagged version of the libaom reference code, and although the spec is now explicitly targeting this "1.0.0" milestone, the reference streams from Argon Design are not publicly available as of this very second. Presumably these are now possible to make, and they will be available soonish. On another note: I'm not clear if these are free as in beer, free as in freedom, both, or neither. That will probably become more obvious when they're released.

68.81.226.126 (talk) 22:35, 26 June 2018 (UTC)

References

Release is just a PR statement

(Hi all, sorry for adding so many topics to the Talk lately, but if wer're discussing a 1.0 release, that seems important to cover well here on Wikipedia.)

The announcement from AOMedia makes a number of claims about releasing stuff, but I can't verify any of it as actually released in a final state. Close-to-final maybe, but not final.

(As noted in the article, the spec is still being edited. The likely reference streams, as mentioned in an above section of this Talk page, aren't released yet, and I can't find any other ones released yet, so as far as I know there are none released as of today. I don't personally know exactly what to look for, and I may be missing them in the "aomedia" repo, but I'm not sure the "bindings" are released either.)

I tried to find sources that clear this up, but no sources so far have actually fact-checked the release announcement; They've all repeated its claims, and maybe framed them in some context. But the actual facts of the release need clarifying and confirmation IMO.

(And perhaps AOMedia and constituent members are about to wrap the 1.0 release, and we'll see all the things from the announcement within a short amount of time. That much may be genuine. But as it stands of today, none of the release's basic claims look to be accurate; Nothing is released in any final format. (Which, for the record is not to say they aren't close to ready to release. They look very close. But "very close" and "done" is an important difference in my view.))

In short, until we can cite a source that fact-checks the release, our coverage will be factually dubious as per the factually dubious release announcement itself. — Preceding unsigned comment added by 2601:4B:300:5D46:92:E79C:3778:76D6 (talk) 14:35, 30 March 2018 (UTC)

Removed details that couldn't be found in a secondary/third-party source. (I guess the number of edits to the spec are sort-of minor at this point, so in a close but no cigar way I guess the spec is "final enough" to start implementing.) (To rail on factual accuracy too much at this point, without appropriate sources to back it up, I think risks losing the spirit of Wikipedia:Verifiability, not truth.) 68.81.226.126 (talk) 18:29, 2 April 2018 (UTC)

The meat and potatoes of the announcement, a "1.0" release of the spec, seems only vaguely/loosely real. AOMedia's announcement is apparently signalling "we'd like to think of it as done," or even "We'd like you to think of it as done"... but the spec itself is still being edited, using a process of "reverse-engineering the reference code," and I'm finding no clear communication that the code-base was ever frozen, although I admit I can't claim to have done an exhaustive search for such a code-base freeze. What I can say is that "[NORMATIVE]" changes keep landing at the source repo's master branch: https://aomedia.googlesource.com/aom/+log/master. Perhaps there was a "1.0" tag placed in the repo at some point, and that is considered the "freeze" point. That would make plenty of sense and be a typical thing to do these days (tag the milestone and keep going.) I just don't get the sense there has actually been a freeze. (I personally need to confirm a freeze or milestone tag has happened, or else I will believe the release's claims are misleading.)

Again, I'm just putting this out there so we can consider how accurate our coverage is; I don't advocate for breaking Wikipedia editing guidelines by trying to assert truth over verifiability. I just wish there were sources out there questioning and confirming the details of the release announcement.

2601:4B:300:5D46:CC75:736C:89F2:FFC5 (talk) 19:13, 6 April 2018 (UTC)

Let me sum up the events:

1. They did a paper release in time for NAB.
2. They had a party at NAB.
3. Still editing the spec after NAB. At time of writing, it is still a draft.

I see this in light of the classic surprise that things take time: Remember, a year overdue at the start of the year, they were going to put the last touches on the code and release it within January. In other words, allotting zero time to fix the >500 bugs they had in their bugtracker at that point, finish the PR review, and actually write the spec, which they put 2 people on – no wonder the spec isn't finished. —84.209.101.182 (talk) 19:19, 18 April 2018 (UTC)

Yeah, I agree. I get the same gist, that they had self-imposed deadlines, blew past them (predictably) and still aren't finished.

I think it doesn't phase them to plunk a "release" milestone down without formally materializing it as a code freeze. It doesn't hinder them, since they're neck deep in the code. They know how it works, and can do what they want with it. The trouble is, there is no stable code-base to work with. I don't know how substantial or insubstantial the edits they're making are, but it seems like everyne who wants to work on AV1 software projects has to take a snapshot of the code-base, do their work, and occasionally update to anew snapshot. That's what Firefox Nightly did, I think it's what rav1e is doing, and that's essentially how the performance benchmarks have been undertaken (using arbitrary snapshots of the AV1 code.)

So rather than version numbers (1.0, 1.1-RC1, whatever), people are referring to calendar dates (as in the Facebook compression-efficiency study), or more commonly noting down an exact commit hash from the upstream AV1 repo.

(Update: Facebook specifies the AV1 hash they used. It's shown in a PNG, not as copy-pasteable plain text.)

If they had done a proper 1.0 tag, or even a full public-facing code freeze while they continue working in private (or just work on a non-master branch, such as "AV-next")... People could start working based off of actual easy-to-identify release milestones.

Long story short, I think they're being a little callous (or oblivious) from a PR perspective to say one thing and do another. Maybe that will work out fine, since most consumers don't know or care about freezes and milestones. But for the independent people or groups looking into the open-source code, looking to implement in hardware, etc. that's confusing and doesn't promote strong collaboration or a strong ecosystem.

And maybe this will be sorted out and everyone can move on and forget this happened (I hope so, and I expect as much), but in my personal opinion they should get their act together, or clear the record.

Not much I can do for the article, since again no sources are commenting on this, to my knowledge. I wish AV1 devs well, and I hope they get a 1.0 tag or frozen "master" branch out there soon, or something. Or maybe admit publicly that it's not stable, despite the release announcement. Honesty is the best policy in open-source, where lots of strangers have to trust one another in order to make things work.

Not really supposed to go on a diatribe unless it pertains to editing the article, so I'll leave my commentary at that.

2601:4B:300:5D46:CC75:736C:89F2:FFC5 (talk) 16:40, 20 April 2018 (UTC)

Here's some more past examples of performance studies (taken from the Wiki article this Talk page is associated with) using hashes/dates as snapshots. Bitmovin mentioned which experiments they enabled/disabled, in addition to the commit hash and date.

---

New comment 30 April 2018 (previous edit somehow got in unsigned. That was me as well.)

There've been recent edits to the article saying that the bitsream is frozen, chips could be out in 6 months, and products based on those chips could be out in 12 months.

The cited source does support that, and in fact some of the various constituent members of AOMedia have been fairly freely saying as much (shipping timeline, and I think referring to a bistream freeze?) in conversation. Given continued progress on implementations, it seems quite possible AOMedia members are moving ahead just fine, to actually ship on or near this schedule. (For example: Mozilla Firefox and Google Chrome so far have already added experimental AV1 support, Bitmovin and Facebook have demos running using Firefox Nightly and Chrome Canary, respectively.)

Perhaps the member companies in general are comfortable working with snapshots of the source repo, and/or using a still slightly-evolving spec. For them, it is quite possible to move forward on shipping. And I suppose it is possible for anyone else to do so if they are comfortable working with snapshots and a slightly changing spec. More examples: rav1e has had Xiph involved, so that's not exactly a third party effort, but they demonstrate how to develop based on snapshots. Likewise, Mozilla Firefox is basing its work so far off of snapshots. Perhaps VLC, GStreamer and FFmpeg have taken the same approach, but regardless they have experimental implementations already.

All this begs the question: Does a hard code freeze, along with a "1.0" tag, really matter? And even if these are nice-to-haves, are they must-haves?

Since the whole world of implementations (and citable sources) seems to be moving on as if everything is on track, it seems hard to assert otherwise in the article with much force. For now, I'm not planning to do anything to the article to suggest they're not on track. We already point out that the spec is marked "draft" and still being edited.

Perhaps the "Adoption" section should not say the bistream is frozen like it currently does: "The bitstream was finally frozen on 28 March 2018. . ." But as I laid out above, everyone is acting like the bitstream is frozen. Perhaps the bitstream is stable enough to constitute a soft freeze. It's a bit debatable.

Leaving this here for further discussion, not taking any action about it right now.

2601:4B:300:5D46:A061:C63A:2959:7BBF (talk) 16:37, 30 April 2018 (UTC)

Just going to leave a quick comment. There could be problems if anyone tries to put an encoded AV1 bitstream or file out, under a snapshots-only development scheme. Using an arbitrary snapshot-based encoder, and assuming you can't guarantee that the recipient's arbitrary snapshot-based decoder is based on that same snapshot, the bitstream/file may not play back appropriately. (By the way, looking at all my collected sources in this talk section's reflist, no two sources have used the same snapshot.) Possible playback/incompatibility issues are warned about a few times among the sources in this talk section's reflist.

So yeah, at some point a real release milestone has to be tagged or finalized properly. Or else I don't expect users will be able to reliably play back AV1 files/streams encountered "out in the wild."

(For what it's worth to anyone else reading this, this has largely been me, a not-logged-in user talking to myself and keeping my thoughts laid out here as to whether we are covering the release milestone(s) properly.)

2601:4B:300:5D46:7435:EED:CE45:404F (talk) 03:47, 27 May 2018 (UTC)

Okay, folks. They did it. The release is real now.

The official aomedia git repo has a "v1.0.0" tag, and an "av1-normative" branch. These currently point to the same commit, namely commit d14c5bb4f336ef1842046089849dee4a301fbbf0.

The spec itself is no longer marked draft, and explicitly links itself to the v1.0.0 git tag.

I'm celebrating in my own time. As for this Wiki article, I'm sure there will be an announcement or some sort of press coverage soon. Would like to cite said announcement/press coverage, rather than citing the repo and spec PDF directly, if possible. So I'm holding back adding this to the article for about a day or maybe two. But I have to admit, it's very tempting to just plunk it into the article with the sources available now, so we'll see. Anyway, it's really real now! Probably!

68.81.226.126 (talk) 22:28, 26 June 2018 (UTC)

This article here talks about it too. Not an official announcement from AOMedia, though. Stickee (talk) 23:31, 26 June 2018 (UTC)

We actually prefer WP:SECONDARY coverage such as this over official announcements. I'm a little doubtful Phoronix is a WP:RELIABLE source but otherwise that would be a reasonable citation. ~Kvng (talk) 14:12, 1 July 2018 (UTC)

References

Purpose section's discussion of "unknown patent holders" - Can we convey this better? And can we better-match Wiki guidelines?

The part I'm referring to reads as follows:

"The possibility of unknown patent holders has been a pervasive concern in the field of royalty-free multimedia formats; this has been raised not only for AV1,[17] but also VP9,[18] Theora[19] and IVC before it.[20] The problem is in no way unique to royalty-free formats, but it crucially threatens their status as royalty-free – a damning prospect – whereas the threat to already royalty-bearing formats traditionally has been much less regarded.[20]"

And it's followed by a color-coded table comparing/contrasting codecs that are royalty-free, royalty-bearing, or whose patents have expired totally.

(This has been edited several times recently. I did one edit, most of them are by a user at 84.209.101.182)

Okay, so that being said, my commentary begins here:

Theoretically, there is nothing wrong with trying to explain the details of royalty status... As long as it is backed up by appropriate sources.

I think the concept is conveyed effectively in this latest edit... But the tone doesn't match Wikipedia's usual tone. Also, I think this is a novel synthesis of ideas (beyond what is in the sources). Which happens a lot on Wikipedia, I guess, but it's frowned upon.

This commentary on royalty-free vs royalty-bearing codecs and the threat of unknown patent holders should hew closer to lines of thought presented within cited sources.

If needed, more good sources can be added. I think the contextualization of AV1's release is fairly strong in CNET's article, including its treatment of patents and royalty-free codecs: https://www.cnet.com/news/netflix-youtube-streaming-video-is-about-to-get-a-lot-faster-av1-compression/

Let's try to make sure ideas in the Purpose section come from cited sources (for verifiability), and that we avoid veering into original research/novel synthesis of ideas.

I'd like to take as a third guiding principle that the way we discuss this should reflect consensus of the sources out there. Just because something is true, doesn't mean it needs to be in the article. But presenting these ideas in the Wiki article is important insofar as they are an important theme in the sources (which I do think they are). That said, I suggest we keep our POV neutral, and/or stick to the POV or ideas/positions presented in the sources.

Basically, we need to stick more closely to the three core guidelines: Wikipedia:Verifiability, Wikipedia:No original research, and Wikipedia:Neutral point of view in this section. I mean nothing critical or personal, but just wanted to write down that those are my hopes / concerns for this section.

Thanks.

2601:4B:300:5D46:CC75:736C:89F2:FFC5 (talk) 04:00, 3 May 2018 (UTC)

For what it's worth, had a similar reaction that that section wasn't quite right. There's more to say (within WP's constraints) about how AOMedia plans to defend the codec--that they had IP review before things went into the codec and that there's a legal defense fund (which there are definitely external sources for), and (if there's a good source for this) that they may have some idea of the things to avoid from the patents used against HEVC and VP9. — Preceding unsigned comment added by 76.103.246.130 (talk) 20:47, 9 May 2018 (UTC)

Previous commenter writing again: I think the text is decent now, but the table's binary "safe/unsafe" ignores some of the things AOM has done to make AV1 suits less likely. The table I'd make categorizes the techniques in AV1 into patented by members, previously deployed tech, and new. Tech patented by members is definitely royalty-free; previously deployed tech (in VP9, or used in other codecs without lawsuits or patents cited) has survived some testing in the market, and new tech is only protected by AOM doing its best to avoid patents, the legal defense fund, right to defensively use members' patents, etc. Another, less clearly defined, category is the gains from AV1 changing parameters for old techniques (e.g. doing directional prediction but with more directions, or adding tile shapes/sizes); those changes arguably add less "surface area" for new patent attacks than totally new tech would. — Preceding unsigned comment added by 76.103.246.130 (talk) 20:46, 13 June 2019 (UTC)

Software support

It would be good to update the list of "software" by making it a table, where we specify whether a given piece of software allows AV1 encoding or decoding (or both), and if so, which version (and possibly with which restrictions). This could be similar to the "Software encoders" section for H.264: https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Software_encoders Slhck (talk) 15:36, 8 May 2018 (UTC)

When there's but a handful of software supporting it, I would name them individually. But later I would restrict myself to naming groups of tools and especially important things like backend implementations in order to avoid another one of these excessive lists that are as interesting a read as a phone book and maybe only really please the addiction of the collector.--Flugaal (talk) 00:18, 8 June 2018 (UTC)

Incorrect claim about pvq being dropped not backed up by citation.

https://en.wikipedia.org/enwiki/w/index.php?title=AV1&oldid=880823028#Features_that_were_dropped

The encoding complexity of Daala's Perceptual Vector Quantization (PVQ) was too much within the already complex framework of AV1.[7]

This claim is at best misleading. A more accurate description would be that PVQ was causing test encodes to take too long to do research. It's funny but libaom was actually slower than that by release.

I was in the irc with the Mozilla people at the time.

I'm sorry this is not exactly a helpful resource. It's late. I'm only doing this so that I actually do this at some point.

-- Kyle Siefring — Preceding unsigned comment added by 96.244.152.219 (talk) 05:21, 30 January 2019 (UTC)

Profiles' feature set discrepancy

There seems to be some back-and-forth editing of the profile table. Right now it is a bit ambitious as to which profile supports which features.

Example: According to the spec (section "General sequence header OBU semantics") a monochrome encode MUST be seq_profile 0 (Main) or 2 (Professional). But according to the wikipedia table the profile "High" does support monochrome. Reason is that a decoder advertised as "High profile compliant" must also support decoding Main profile encodes.

So while a "High profile" encode will NEVER be monochrome, a "High profile compliant" decoder must still be able to decode a monochrome streams. Maybe this can be better explained in the article. 2001:4DD6:7C98:0:6D97:DB4F:D757:4B9A (talk) 12:04, 17 February 2019 (UTC)

redundant images

we have two images explaining the superblock partitioning. which one to drop, what to improve, which idea/direction seems best?..--Flugaal (talk) 19:09, 22 March 2019 (UTC)

Lead section about the purpose of AV1

@User:Anordal. Regarding your revert. I don't see how the content of the removed paragraph relates to AVC in any way. Perhaps you meant to say HEVC, but even in that case I don't see what the problem is. The paragraph made no claims about HEVC having been used for non-commercial streaming. --Veikk0.ma 22:46, 8 April 2019 (UTC)

Don't blame HEVC specifically. There is a widespread myth that HEVC is a scandal and AVC is acceptible everywhere. To someone who believes this, the wording just reinforces the myth. In reality, AVC is also FRAND licensed, just less so, and both are categorically disastrous to free software. For that reason, I would blame FRAND first and foremost.—Anordal (talk) 23:12, 8 April 2019 (UTC)

The paragraph isn't about blaming anything and it doesn't mention AVC in any way. It merely states what third parties have reported to be the reason for AV1's creation. Wikipedia's aim isn't to report what's "true" (because who gets to define that), only what's been verifiably reported by reliable sources. In short, verifiability, not truth.

Since this revert seems to be based on a misunderstanding, I'll be adding the paragraph back to the lead. If you can provide sourced statements about contradicting views about the information added (see WP:SOURCES), you're of course welcome to add these to the article. --Veikk0.ma 00:44, 9 April 2019 (UTC)

What about now? Source criticism is not misunderstanding.—Anordal (talk) 01:26, 9 April 2019 (UTC)

You've still not mentioned why it's relevant to add lenghty disclaimers about AVC and its licensing to the lead when discussing the reason AV1 was created (which, according to the sources, was due to HEVC's licensing, not AVC's). The effect of FRAND licensing on free software is already mentioned in the article body and Mozilla is only one member of the AOM. If Mozilla's motivation also extended to AVC, this can be mentioned in the article but it's not significant enough on its own to be shoved into the lead. The lead is supposed to summarise the article, and the original mention about open source did that.

You also completely removed the other mentioned reason for AV1's creation, that being the uncertainty around the licensing. This was supported by two references and since it's a rather well-documented reason for the founding of AOM, I think I could find more if necessary. Mentioning the three separate patent pools and possible patent claims by currently unknown third parties would also be relevant, but I decided to link to the relevant section of the HEVC article instead and keep the mention about uncertainty short and to the point. Again, this is the article lead, not the body. Furthermore, the patent and licensing issues of HEVC are already expanded upon and even illustrated with a table in the Purpose section of the article, making further elaboration in the lead unnecessary.

Furthermore, you added unsourced information about one patent pool's asking price for their HEVC patents in relation to AVC. If sourced, I think this could be good addition to the article, but not the lead. Because if we go into specifics about the cost of one patent pool, why not mention the others? And while we're at it, we could expand upon the other reasons why AV1 was created, like the aforementioned third-party patent holders and one patent pool not even publishing pricing? No. This is the lead and thus we should be brief. --Veikk0.ma 02:55, 9 April 2019 (UTC)

My worry is oversimplification. Journalism is prone to oversimplify and perpetually recite each other, but when you dig into it, the popular opinion in this case (that AV1 was motivated by HEVC scandals) is just speculation. Not that we have any reason to doubt it; the problem is that telling a reason for something also says something implicit about what was wrong to begin with, and that if you only tell one reason, you will give a completely different impression than if you try to give a fuller picture.—Anordal (talk) 08:55, 9 April 2019 (UTC)

As for removing the licensing uncertainty reason: Sorry, I thought of it as in the same HEVC bucket, and I wanted to keep it short – I think we agree that at some point, it becomes too long for the lead section. I don't mind if you expand the main article of course. I also agree that the FRAND argument is well enough represented there (except my sources may be better). I'm all for moving and merging it into the main article, but if we must have it in the lead section, at the very least, we must not present HEVC as the only motivation behind AV1 — at that point, it becomes an oversimplification and factually wrong.—Anordal (talk) 10:35, 9 April 2019 (UTC)

My two cents: the whole "this is not to be read as" part makes the lead much harder to read, and now we're already deep in the topic of licensing. I like the references, and I think these are important additions, but I'd strongly encourage you to remove this "motivation" part entirely and explain in the main body of the article. Slhck (talk) 12:27, 9 April 2019 (UTC)

I'm pleased to see both motivations (HEVC + FRAND) now covered in the history section. I like it! If anything, I would try to present them more together first, before writing too extensively about each. But the bigger problem: The rest is in the "Purpose" section … it should be once place! As for the part in the lead section, I think at least it should be easier to summarize (or remove) now that the burden of evidence has moved.—Anordal (talk) 13:57, 22 April 2019 (UTC)

Now, you have put only your version back in the lead section again. Not cool.—Anordal (talk) 20:48, 14 June 2019 (UTC)

I changed it to not exclude other reasons than the HEVC situation, which makes me basically satisfied.

But we're both right of course: The spread of royalty bearing formats is a threat to those who can't afford it (which Google, Mozilla and Cisco can all attest to, regarding web video wars), and the overshadowingly most worrisome instance of that threat, at the time when AoM was formed, was HEVC.

So what we are debating is just the short vs the long explanation: Whether to focus on the current instance of problems, or to disignore historic precedence to see the longer lasting ones.—Anordal (talk) 15:15, 14 July 2019 (UTC)

Nobody at Wikipedia gives a damn about "competition" to AV1. The issue is that this article is based almost entirely on self-published and affiliated sources, and contains vast swathes of inappropriate WP:HOWTO / manual content. That can be ported to Wikibooks, but it doesn't belong here. Guy (help!) 11:26, 9 September 2019 (UTC)

Blanking of page

Can we please do something more nuanced than just blanking the page?

Probably the worst chunk of the page is the History section, as it is the oldest and written before other sources were available. I can do a cleanup of this section. TD-Linux (talk) 19:20, 24 August 2019 (UTC)

Because of WP:COI (I work for a company that was involved in creating the standard) I'm going to try to limit my editing to deletions. TD-Linux (talk) 19:30, 24 August 2019 (UTC)

Alright, how's that? Turns out the worst section was actually Purpose. It's gone now. TD-Linux (talk) 20:06, 24 August 2019 (UTC)

Regardless of the reasons of the edit, the technology section describes the technical characteristics which are not to be found elsewhere than on self-published sources. Same for the profiles and levels section. Other codec descriptions (such as MPEG-4 AVC) are similarly almost 100% based on the norm and have not been deleted.

Sections like History section or Purpose where quite bad but it is not a reason for deleting the whole article.

Other sections contains references to third party articles that have been thrown indiscriminately. Maybe we should also delete the pages of the other codecs the same way.

Anyway, in the light of the edit, the quality scale should be dropped from B to Stub.--Alegui (talk) 18:25, 3 September 2019 (UTC)

I've spent some time explaining the issue. What needs to happen is that the article needs to be refactored into an encyclopaedia article, rather than a technical manual, and this needs to be done with reference to reliable independent secondary sources. Wikipedia is not a technical resource. Guy (help!) 20:58, 3 September 2019 (UTC)

• Happy to help with understanding here. History, for example, is entirely appropriate, but needs to be supported by third party sources, yes? Surely there must be a proper analytical argument in the technical press? That's the bit that baffles me: so much churnalism and press releases. There must be something better, surely? Guy (help!) 21:22, 3 September 2019 (UTC)

The issue is not about the quality of the article. It is about the way you express the issue. Yes, some parts were churnalism and some others were a technical resource. Still, other were legit content that has been wiped as one block. For a page that makes about 500-600 daily views, this is quite brutal.Alegui (talk) 22:07, 3 September 2019 (UTC)

I agree. There is nothing wrong with using primary sources if they are not problematic, i.e. self-serving, POV or promotional. Neither WP:V nor WP:RS (or WP:NOR) forbid using primary sources. Primary sources are completely fine for basic facts such as release dates, version history, technical information etc. Deleting them as PR material is something that IMO can be classified as disruptive editing at best. Furthermore, I can´t see anything wrong with technical information in an article on a technical subject, as long as it´s not excessive. Technical articles on Wikipedia simply include technical details, and there is nothing wrong with it. If there are specific sources that are debatable, if there is information that is promotional, excessive etc., then it should be removed. But I completely agree that deleting basically the whole article, which mostly consisted of neutral facts, is extremely brutal, and in my opinion, incredibly ignorant, groundless and arrogant. I suggest restoring the old version, and then discussing and removing (or changing) only the really problematic parts.—J. M. (talk) 23:02, 3 September 2019 (UTC)

Exactly. Disruptive Page Edit! I am just a (right now angry) Wikipedia user who wanted to look up the AV1 page. I did so in the past, I knew it had a lot of information, also a lot of technical information, which I believe is necessary for a "dry" topic like a codec. So I find this page nearly empty and have to waste my time search through the history. It's disruptive and I don't agree with the editor who removed everything. What secondary source do you want? Another source which just got its information from the primary source because that's the only entity where the info is available? I get that maybe a some (or even a lot) of paragraphs are out of date or poorly written or whatever, but then JUST MAKE A BOX above them like on so many other articles, that it has to be rewritten because of XY. Just deleting everything is just a s s h o l e behaviour. The information wasn't wrong. The technical stuff is probably still the same. So there are other methods than just deleting everything and annoy users. (and editors who put time into this). Greetings from someone behind a keyboard in Germany. Peace out. — Preceding unsigned comment added by 5.61.181.59 (talk) 19:39, 5 September 2019 (UTC)

In fact, primary sources are the best sources for things like technical documentation (for example, ISO standards). When you cite a source for something in a technical specification, any source other than the original specification may be considered unreliable. Again, there is nothing in the Wikipedia rules that prevents anyone from using primary sources for these things.—J. M. (talk) 23:38, 5 September 2019 (UTC)

Indeed. Why would you need a secondary source for a technical specification? The whole point of a technical spec is to be authoritative (and in any event, a secondary source will just be quoting or rephrasing the spec). I think the source guidelines need some necessary caveats made (if they haven't already). Miracle Pen (talk) 11:16, 9 September 2019 (UTC)

Again, the Wikipedia guidelines explicitly permit primary sources (a quote from WP:RS: "they can be both reliable and useful in certain situations"). They just cannot be used in a way that breaks the Neutral point of view and No original research policies (for example, they should not be promotional, and you should not interpret them, just cite the facts—but neutral technical facts are neither promotional nor original research). Plus the article should not be based primarily or exclusively on primary sources (at the bare minimum, you need a couple of third-party sources to establish notability).—J. M. (talk) 18:14, 9 September 2019 (UTC)

Yeah, also don't get why it's almost completely gone, how is anyone supposed to fix it's issues if it does not exist and you can't edit it? I don't think this is a very helpful state for the page to be in. I'll try to help with the page in any way I can once it gets un-protected. Vecr (talk) 22:10, 5 September 2019 (UTC)

The article will get unprotected pretty soon, so let me suggest a couple of points:

1. The article will get restored to its previous state. There is no way around it. The consensus is clear, the page blanking is based on invalid arguments and misinterpretation of Wikipedia guidelines of policies, and is mainly a one-man action against the will of others. This shall not continue, and if it does, will be reported as disruptive editing and edit warring.
2. The original request by the page blanker to fully protect the page for one month was completely out of line and can be clearly seen as power abusing behaviour (it would mean his "blank" version would be frozen for a month a nobody but him and other admins could edit it). Again, this is not acceptable.
3. Once the article gets reverted to the previous version, we can start discussing specific things that are poorly sourced, promotional, excessive etc. And I admit they may exist, the article is certainly not perfect. So let's discuss the problematic parts and sources one by one, so that they can be either changed or removed. But no wild page blanking actions anymore. That's obviously indefensible. Thanks.—J. M. (talk) 23:38, 5 September 2019 (UTC)

So that's what I did right now. The article is restored. Now, please discuss any things you want to remove first. That's what this talk page is for, that's how Wikipedia works.—J. M. (talk) 00:38, 6 September 2019 (UTC)

First, the onus is on editors seeking to include disputed content, to achieve consensus for its inclusion, based on policy.

Second, the content has been tagged as inappropriately sourced since March last year. The only editors are fanbois, so nothing has been done. Therefore the content based on self-published sources can and must be removed.

Third, the off-wiki solicitation is meatpuppetry and wildly inappropriate. Guy (help!) 11:31, 9 September 2019 (UTC)

The problem is that the tags are so vague that they cannot be used as an excuse for deleting basically the whole article.

"Excessive or inappropriate references to self-published sources" and "This article may rely excessively on sources too closely associated with the subject"—where exactly? Again, primary sources for technical specification, source code, release dates etc. are perfectly fine. This does not violate any Wikipedia rules. And I can see plenty of decent secondary sources in the article that meet the WP:RS requirements. So that's why I think we have to be really specific and discuss which parts are poorly sourced. I don't object to removing poorly sourced sentences or sections. Yes, there are many links to aomedia.org. We just have to differentiate between them. If some of them are self-serving, promotional, non-neutral, they should be removed. But we should be specific and explain those specific removals.

"The neutrality of this article is disputed"—this is even more vague and really needs explanation.

"This article relies excessively on partisan sources"—I'm not even sure what to say here.

"This article may be too technical for most readers to understand"—yes, it may be. But there are many articles on Wikipedia that are too technical for me to understand, and it's entirely my fault. Wikipedia cannot have articles that are easy to understand for everybody. The level of detail in the article does not seem excessive to me, I would say it's quite close to many other technical articles on Wikipedia. But of course that's my opinion, I'm sure some things could be removed. For example the "Former experiments that have been fully integrated" and "Features that were dropped" sections.

"This article may contain an excessive amount of intricate detail that may interest only a particular audience"—perhaps the audience who is interested in reading the article? The article explains the basic compression methods, profiles and levels, container formats, software and hardware implementations, OS support, patents. This looks about right to me. I think an article about a video compression format should discuss basic video compression techniques. But of course the level of detail may be a subject of debate. So what exactly is the problem? The fact that the article contains the Technology and Quality and efficiency sections, or that these sections are too detailed?—J. M. (talk) 16:46, 9 September 2019 (UTC)

I agree that the "Former experiments that have been fully integrated" and "Features that were dropped" sections that should be dropped as they do not really serve the purpose of an encyclopedia while being overly complicated and pointless.

Overall, I found that the problems are on three main considerations :

1- The sources : From what I can see most of the self-published and affiliated sources are generally used in an appropriate way. Especially, the technical specifications are better served by this kind of sources because no third-party observer does know as well the technical specifications as well as a 1st-party. The exception is critical analysis of the choices made, but from third-parties these are quite rare.

There are already pertinent third-party sources in the article, maybe too few but we need to be more specific.

Can anyone give concrete examples of inappropriate or lacking sources ? (outside of parts proposed to deletion)

2- The technical level: As a reference the H.262, H.264 or the H.265 video codec articles should be read as these codecs are the references formats in the industry.

I have found the technical level of the article quite adequate. Video codecs are very, very complicated piece of math. The Technology part is just a description of the format (they all work more or less the same) without being too complex (except for the 2 sections I propose for deletion). Many Wikipedia math entries contains much more complex details and that is not considered as an issue as far as I know. I am not against a proposal for simplification of this part, through, as it is quite long.

3- The neutrality : The article states facts generally true. Some may seem to be advocacy of the codec, but as far I can see what lacks the most are arguments against the codec and why it is (for now) little used.

PS: Most of the tags were added by me when I reverted the edits, feel free to remove those inappropriate as I put them quite generously.

--Alegui (talk) 18:19, 17 September 2019 (UTC)

Article issues

I'm new to this article, after reading it (as well as discussions above) I found most critics/"issues" to be irrelevant:

• The article is not particularly biased, it's mostly a technical description of the video codec, with comparaisons with previous and competing codecs, which is what readers would expect of such an article and follows the same structure as other codecs.
• For a video codec (a specific and technical matter by essence), the article is not too technical. I don't know much about internals of video codecs but could understand most of the article. Even the most technical parts give non-technical readers hints about where ideas driving development came from.

If nobody provides significants, convincing arguments to justify the "issues", I will remove them from the article in a few days. --Wagaf-d (talk) 18:29, 29 September 2019 (UTC)

Actually just removed issues, feel free to add them back if relevant and justified --Wagaf-d (talk) 18:31, 29 September 2019 (UTC)

CS8160

The source doesn't mention support for AV1, the same applies to CS8150. --Xth-Floor (talk) 08:58, 1 November 2019 (UTC)

As I read only the Amphion CS8142 has AV1 capability. I have removed the others. Thanks for the look ! Alegui (talk) 17:52, 11 November 2019 (UTC)

Hardware section

Of all the sections, it seems that it is the worst redacted and sourced. The sources are only press releases or articles based on press releases. The text repeat the list with worse readability. It mixes SoC and VPU. Furthermore, I don't think most people give any interest about VPUs, since they are only intended to be used by SoC manufacurers. I suggest that we remove the section, and keep only a list/tab of available (and not only announced) SoC/CPU/GPU that contains specialized silicon, with a small explanatory text. Alegui (talk) 12:52, 27 November 2019 (UTC)

"Hardware support" is not necessarily dedicated silicon support for AV1. It can be in the form of new firmware for existing accelerator hardware already used for other purposes such as decoding other video formats. -- The Anome (talk) 12:55, 27 November 2019 (UTC)

Are you thinking of FPGA ? I don't think we should include such capability unless a real-world product supports AV1 decoding/encoding and a verifiable 3rd party source exists to verify it. Alegui (talk) 13:07, 27 November 2019 (UTC)

No mention of 360 degree video support?

93.185.27.64 (talk) 09:28, 13 May 2020 (UTC)

Evaluation of quality/efficiency comparisons

I thought I'd create this talk page section for clarification (and collaboration, if there's interest) on evaluating the sources used on the quality and efficiency of AV1.

Sadly, in the field of video coding, it's very common for quality and efficiency comparisons to be invalid and completely useless for one reason or another. Problematic/bad/useless studies are very common, and I thought it'd be useful to document the bad (and possibly good, if required) sources of comparisons involving AV1 and the specific reasons why they should or shouldn't be used.

I'll be listing/moving cites from the article here for posterity and listing the issues with them for better transparency than just leaving a note on the edit form.

Some general notes on what studies/evaluations should mention to be repeatable and thus scientific:

• the encoders used (AV1, HEVC, VVC etc. are not encoders)
• the encoder versions used
• the encoder settings used
• the metric(s) used
• the resolution(s) tested

--Veikk0.ma 18:42, 20 July 2020 (UTC)

---

• Removed: Zhang, Fan; Katsenou, Angeliki V.; Afonso, Mariana; Dimitrov, Goce; Bull, David R. (2020-03-23). "Comparing VVC, HEVC and AV1 using Objective and Subjective Assessments". arXiv:2003.10282 [eess].

Rationale: 10-bit encoding was used for HEVC and VVC, but not for AV1. HEVC's Main10 profile being used is mentioned in the table on page 3. No specific bit depth settings for AV1 are mentioned in the table, which means they're using the default of 8-bit. Later on page 3, under the heading "B. Coding configurations", it is mentioned that "Each codec was configured using the coding parameters defined in their common test conditions", with a reference to said conditions. According to the Test Condition document for VVC (available for download here), there are no 8-bit test conditions; they're all 10-bit. If the aim of the study was to compare the codecs in real-world conditions, there was no reason to only use 8-bit for AV1. Support for 10-bit is a requirement in all AV1 Profiles, so 10-bit could easily have been used for AV1 without any compatibility concerns.

In summary, AV1 was 8-bit, HEVC and VVC 10-bit, therefore the entire comparison is invalid. --Veikk0.ma 18:42, 20 July 2020 (UTC)

---

• Removed: "Testing AV1 and VVC". BBC R&D. Retrieved 2020-07-19. (companion document linked in the article is available here)

Rationale: Inconsistencies between bit depths: 12-bit for AV1, 10-bit for VVC, and ??? for HEVC (I was unable to find the referenced document, "JCTVC-AF1100 Common test conditions for HM video coding experiments", which supposedly contains the settings). Neither the article or the linked companion document contained the settings for the HM and VTM encoders, which is a bad sign. They only refer to the default settings of the "common test conditions" of these encoders and give the names of these documents, but don't link to them directly.

Verdict: It's not worth the bother to use this as a source. Bit depths were not normalised between encoders and no reasons were given for the bit depths chosen. Encoder settings not mentioned for HM and VTM. If someone wants to add something from this source to the article, they need to be extremely careful and mention all the caveats (especially the fact that this was a test on livestreaming applications), which will make the article even more technical and difficult to understand. --Veikk0.ma 18:42, 20 July 2020 (UTC)

And they used PSNR as the only metric for comparison. PSNR is not the best of methods anymore, and is especially inappropriate to compare different encoders with, due to the tendency to punish bit allocation smartness such as Adaptive Quantization.—Anordal (talk) 16:50, 27 October 2020 (UTC)

If I were to scrutinize the encoding parameters, I can't imagine that zero frames of algorithmic latency, which they used for AV1 (--lag-in-frames=0), was part of the “JVET common test conditions” that they followed for VVC and HEVC, as that's rather limiting (precludes B-frames). Correct me if I'm wrong, but nobody uses zero frame lag outside teleconferencing and the contribution side of broadcast. At least, it shouldn't be used in 2-pass, which they also did.—Anordal (talk) 12:17, 31 October 2020 (UTC)

Note: This doesn't mean the rest of the Quality and efficiency section is okay; these are just the two latest performance comparisons that were mentioned in the article, and I checked them first. I haven't gone through earlier ones yet. --Veikk0.ma 18:42, 20 July 2020 (UTC)

Thanks for creating this discussion. I’m no expert on this subject but I’m interested in it. I’ll wait for your judgment on the other tests. I’m afraid all of them may be somewhat problematic (if that is really the case, maybe we should re-add the tests explaining the methodology problems? I’m sure there must be reliable sources explaining those comparison problems somewhere, so it wouldn’t be WP:ORIGINAL research). daveout ^(talk) 19:26, 20 July 2020 (UTC)

It's not original research to say that video encoder comparison is hard (it is well known), and I think this should be uncontroversial in general: In any comparison, if you haven't used things correctly, it's a bad comparison. Imagine a car journalist giving a car bad score for having driven all the way in first gear when it is him who couldn't stick shift. I would say that's pretty analogous to some common complaints about aomenc, that it is slow at the slowest speed and has bad parallelism before you enable tiles.—Anordal (talk) 16:50, 27 October 2020 (UTC)