Jump to content

Talk:AV1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 2601:4b:300:5d46:a061:c63a:2959:7bbf (talk) at 16:37, 30 April 2018 (→‎Release is just a PR statement: Article now says the bistream is frozen, that chips could shiph in 6 months, and products based on chips could ship in 12 months. I have my doubts, but I don't strongly feel that I can assert/prove that the "freeze" or "ship dates" are false. So it's a gray area regarding how to sort the truth out, but for lack of citeable evidence that (hypothetically) there's "no freeze," or that "chips/products won't ship on time," I'm leaving the article alone for now.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Lossless?

Does this codec support lossless RGB encoding/decoding? That seems like it would be useful information to have in this article. I came here looking for that information, but it was missing. -AlexFolland (talk) 11:29, 31 January 2017 (UTC)[reply]

I second that request. I've been reading up on all kinds of sources but could find no information regarding support for a lossless mode.2A02:8109:8700:11A0:8DD1:24F3:1D5D:BEB3 (talk) 14:41, 16 March 2017 (UTC)[reply]
If I read the specs correctly, it does: https://webmproject.github.io/av1-bitstream/ 83.87.131.205 (talk) 21:44, 4 July 2017 (UTC)[reply]
Yes, it does, see Changelog v1.3.0 too: https://github.com/mbebenita/aom/blob/master/CHANGELOG Slhck (talk) 12:23, 18 September 2017 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

The official spec is abandoned

Documentation work has moved to github, apparently.

  • What I initially noticed: The documentation is written for GitHub Pages. Googlesource's source code view does not render it very well (for one thing, the images are gone), whereas those able to guess the github pages url will find a glorious document.
  • The nail in the coffin: The documentation repository on googlesource[1] hasn't seen updates in 2 months, whereas the github one[2] has, and is based on the last googlesource commit (90adec).

I'm changing the bitstream link back to github.—84.209.101.182 (talk) 20:18, 13 February 2018 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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,"[1] 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)[reply]

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)[reply]

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)[reply]

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,"[2] 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)[reply]

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)[reply]

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,[3] I think it's what rav1e is doing,[4] 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.)[5]

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)[reply]

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.[6][7][8] Bitmovin mentioned which experiments they enabled/disabled, in addition to the commit hash and date.[9]

---

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,[10] 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.[11][12])

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)[reply]

  1. ^ Armasu, Lucian (28 March 2018). "Next-Generation And Royalty-Free AV1 Video Codec Is Released". Tom's Hardware. Retrieved 6 April 2018. The release of the AV1 video codec includes a bitstream specification for future chips, an experimental software decoder and encoder to create and consume the bitstream, as well as reference streams for product validation.
  2. ^ peterderivaz. "restrict the min_tile_width if "in-loop-filtering" is enable · Issue #59 · AOMediaCodec/av1-spec". GitHub. Retrieved 6 April 2018. This spec is just based on reverse engineering the reference code - just changing the spec by itself has no meaning unless accompanied by changes to the reference code (or an official accepted design document).
  3. ^ Ralph Giles; Martin Smole. "DASH playback of AV1 video in Firefox – Mozilla Hacks - the Web developer blog". Mozilla Hacks – the Web developer blog. Retrieved 20 April 2018. The AV1 bitstream is set to be finalized in early 2018. You may ask – "How does playback work on the bitstream that is not yet finalized?". Indeed, this is a good question as there are still many things in the bitstream that may change during the current state of the development. However, to make playback possible, we just need to ensure that the encoder and decoder use the same version of the bitstream. Bitmovin and Mozilla agreed on a simple, but for the time being useful, codec string, to ensure compatibility between the version of the bitstream in the Bitmovin AV1 encoder and the AV1 decoder in Mozilla Firefox: 'av1.experimental.<git hash>'
  4. ^ "xiph/rav1e/README.md". GitHub. Retrieved 20 April 2018. rav1e is an experimental AV1 video encoder. . . Because AV1 is not yet frozen, it relies on an exact decoder version and configuration that is periodically updated.
  5. ^ Yu Liu. "AV1 beats x264 and libvpx-vp9 in practical use case". Facebook Code. Retrieved 20 April 2018. snapshot-03-28-2018 with commit 23c1d63b191a3c94b0dae6334ff04261f124a96f
  6. ^ "Results of Elecard's latest benchmarks of AV1 compared to HEVC| Elecard: Video Compression Guru". www.elecard.com. 24 April 2017. Retrieved 20 April 2018. Note: AV1 standard is work in progress. The given streams are encoded with AV1 update of 2017.01.31 (commit befcc42572b88c6ff983d1000fa4eddc4bb41f26). If you try to playback the stream using other AV1 commits, it may not be played properly.
  7. ^ Dan Grois; Tung Nguyen; Detlev Marpe (December 2016). "Coding Efficiency Comparison of AV1/VP9, H.265/MPEG - HEVC , and H. 264 /MPEG - AVC Encoders" (PDF). Video Coding & Analytics Department, Image & Video Coding Group, Fraunhofer Heinrich Hertz Institute (HHI), Berlin, Germany. p. 3. Retrieved 20 April 2018. AOMedia Project AV1 Encoder, Version: b6724815f22876ca88f43b57dba09a555ef4e1b0
  8. ^ Dr. Dmitriy Vatolin; Dr. Dmitriy Kulikov; Dr. Mikhail Erofeev; Stanislav Dolganov; Sergey Zvezdakov (17 January 2018). "MSUCodec Comparison2017 Part V: High Quality Encoders". p. 6, 56. Retrieved 20 April 2018. AV1 AOMedia 0.1.0 (Rev. c8b38b0bfd36)
  9. ^ Martin Smole (18 April 2017). "Bitmovin Supports AV1 Encoding for VoD and Live and Joins the Alliance for Open Media - Bitmovin". Bitmovin. Retrieved 20 April 2018. AV1: Build f3477635d3d44a2448b5298255ee054fa71d7ad9, Enabled experiments by default: adapt_scan, ref_mv, filter_7bit, reference_buffer, delte_q, tile_groups, rect_tx, cdef Passes: 1, Quality: Good, Threads: 1, Cpu-used: 1, KeyFrame-Mode: Auto, Lag-In-Frames: 25, End-Usage: VBR
  10. ^ Ozer, Jan (28 March 2018). "AV1 Is Finally Here, but Intellectual Property Questions Remain". Streaming Media Magazine. Retrieved 30 April 2018. On March 29, AOM announced the public release of the AOM Video 1.0 AV1 specification, aka the bitstream freeze. . . According our conversations, AOM expects AV1 decode in several browsers and some content from member companies over the next few months. This will be followed by hardware implementations in about 12 months that can be integrated into devices that will ship in early to mid-2020.
  11. ^ Daniel Baulig; Yu Liu (24 April 2018). "Facebook video adds AV1 support". Facebook Code. Retrieved 30 April 2018.
  12. ^ Ralph Giles; Martin Smole (28 November 2018). "DASH playback of AV1 video in Firefox – Mozilla Hacks - the Web developer blog". Mozilla Hacks – the Web developer blog. Retrieved 30 April 2018.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:AV1&oldid=838999371"