15 ms·
Introducing Dav1d: a new AV1 decoder
- dzdt 8y agoI understand AV1 has attempted to avoid existing patents. Is there a consensus that they succeeded? Or might the HEVC patent pool come after them still with lawsuits?
- hannob 8y agoPatent law is complicated and noone can give a final guarantee that AV1 will be fine. However given AV1 has some large companies like Google, Facebook and Microsoft behind it and they probably have an interest in making this a success they probably asked for their legal teams opinion. I'd say chances are high that it's gonna be fine.
- class4behavior 8y agoThose three would not be enough for the kind of push we see here, but a lengthy list of major players in tech makes a difference: Amazon, AMD, Apple, ARM, Broadcom, Cisco, Facebook, Google, Hulu, IBM, Intel, Microsoft, Mozilla, Netflix, Nvidia [1] [1]: https://en.wikipedia.org/wiki/Alliance_for_Open_Media https://en.wikipedia.org/wiki/Alliance_for_Open_Media
- twotwotwo 8y agoThe cluster of non-AOMedia cos. I'm most curious about is mobile/SoC folks: Samsung, Qualcomm, Huawei, MediaTek. Not sure what it signals--the optimistic version is they just want to keep their options open at this stage, and figure they can integrate ARM's or Google's design when the time comes. Pessimistic version is that at least one of them would like to impede adoption by using patents + not supporting AV1 on their chips or devices, maybe in hopes of squeezing money out of the rest of the world. If Apple (a member, as you noted) ships hardware AV1 support and Google and content providers keep backing it, seems like that would put pressure on the holdouts: your flagships may have to go without a feature a competitor has until you get on board. No idea--I don't know much about these cos' strategy/politics at all. Just speculating like most others here.
- londons_explore 8y agoSimple AV1 accelerators are small enough that they might put them in the silicon of shipping devices to hedge their bets, giving themselves the ability to enable AV1 or HEVC perhaps as little as a few weeks before a device is released. There are also substantial overlaps in hardware video decode accelerators, and they could well both share silicon.
- microcolonel 8y agoThe largest owners of video coding IP have agreed publicly not to litigate on the enormous body of existing patents that apply to AV1.
- twotwotwo 8y agoIt's pretty hard to definitively succeed. The threat is not just the HEVC companies that aren't in AOMedia; unknown unknowns are a factor too. Like submarine patents: patent applicants can intentionally delay the issuance/publication (keep amending their application for example), and because the initial filing date is all that matters, they still get to use that patent to go after others. And the whole situation is complicated enough that I wouldn't be shocked if there are published patents where legal review decided it wasn't a threat (that it doesn't apply to AV1) but someone sues anyway, or review simply didn't consider the key patent/claim at all. Some things AV1 has going for it: - Some techniques are already in use out there (like in VP9), are patented by AOMedia members, or are essentially just bumping some numbers to take advantage of stronger hardware (prediction directions, reference frames you can use). So those parts seem less likely to see patent claims, either because they may not be patentable or because we'd've seen it in someone suing over VP9 or such. - There is a legal defense fund. And, more informally, there are large companies to which it's worth a lot to keep the codec as unencumbered as possible. - AOMedia members are allowed to use their patents against entities filing patent suits, which might discourage cos. that actually have products (as opposed to pure patent holding companies) from suing, or strengthen the AOMedia member's position in negotiating for a settlement etc. (I wonder whether this part is structured to also allow retaliation when a company e.g. sells their patents to hostile pools or holding companies.) I'm sure there will be threats and suits (the system just seems to make it inevitable someone will try to profit off this) and it might be someone in one of the HEVC pools doing it in hopes they can help HEVC win. But seems possible AOMedia could win or settle any essential ones (things core to the codec rather than just specific implementation techniques). If the whole thing failed catastrophically--a lawsuit covering all approaches to implementing some essential codec feature succeeded--AV1 would still likely end up much less expensive and encumbered than HEVC, which of course didn't even try to avoid patents. I also wonder if AOMedia might get to work on a workaround (like, define a codec or profile that's more or less AV1 with the specific feature from the lawsuit disabled, removed or replaced). That could obviously be hugely expensive depending on things like compatibility with existing HW/SW, but could still work out cheaper than royalties or whatever.
- bcheung 8y ago"Under patent rules adopted from the World Wide Web Consortium (W3C), technology contributors license their AV1-connected patents to anyone, anywhere, anytime based on reciprocity, i.e. as long as the user does not engage in patent litigation." https://en.wikipedia.org/wiki/AV1#cite_note-patent_license-23 https://en.wikipedia.org/wiki/AV1#cite_note-patent_license-2... We can't know for certain, but with the number of big players joining the alliance, I find it unlikely that a company would want to give up their rights to use AV1. Not to mention the PR nightmare, boycotting, and developer exodus that would ensue for that company.
- taneq 8y agoWait, is that "as long as the user does not engage in patent litigation" against that consortium member? Or at all? I can't imagine a big corp. forfeiting the right to all patent actions.
- MaxBarraclough 8y ago> PR nightmare, boycotting, and developer exodus that would ensue Perhaps, but I have less and less faith in these 'corrective forces'. Tech companies often seem to discount such consequences, and they get away with it just fine. More optimistically though, I can't recall any instances of a major tech company reneging on a promise like this. The 'Microsoft Community Promise' has been honoured, for instance. (I accept it's quite possible I'm just being forgetful, mind.)
- sp332 8y agoIs there an advantage to writing ASM without intrinsics?
- rbultje 8y agoYes. For intrinsics, the compiler chooses whether and when to spill variables to the stack. For hand-written assembly, you are explicitly burdened with this yourself, usually causing you to optimize the flow of the function so it minimizes stack spilling. In addition, your function will perform the same regardless of the compiler. In FFmpeg, we have found in the past that functions written in pure assembly are typically a few % faste than those written in intrinsics. Depending on your use case, that may make it worth it. The obvious disadvantage is that pure assembly is harder, so writing functions takes a bit longer.
- Const-me 8y ago> the compiler chooses whether and when to spill variables to the stack. In my experience the behavior is stable i.e. doesn't often change between rebuilds (at least in VC++). I can manage this by looking at compiler's output: when I find there something I don't want, be it stack spilling or other reasons for me not liking the assembly, I go fix my C++ code. > so writing functions takes a bit longer Also reading is hard, therefore refactoring/improvements is hard, too. I have an impression the assembly is write only language.
- Daemon404 8y ago> In my experience the behavior is stable i.e. doesn't often change between rebuilds (at least in VC++). This is less true when you try and support many versions of many compilers, however, in my experience.
- Const-me 8y agoYeah, that makes sense. I usually deliver results of my work in binaries so I can choose the compiler, and inspect compiler output of performance critical parts. Authors of that decoder didn’t have that luxury.
- prablenha 8y ago>BSD is not copyleft, why? Really? People are going to complain because a licence is too free? ...
- stagger87 8y agoComments like this will only lead to arguing/flaming/etc.
- metajack 8y agoSince Vorbis, we've all worked to make the codec code as restriction free as possible because we need wide deployment for success. It's more important for a royalty-free codec to win than for these codebases to be copyleft. Once AV1 is the default solution, we can start worrying about software licenses :)
- laken 8y agoThe complaint usually comes in due to an interpretation of "free." The author includes RMS' opinion, which is true for this particular piece of software, though in many cases it's a warranted complaint. It gets into a political argument usually, but it boils down to this argument: "If I don't require copyleft, then I can't always guarantee that users of my code will get all the freedoms I provided to them."
- class4behavior 8y agoHere in detail: Why Open Source misses the point of Free Software - https://www.gnu.org/philosophy/open-source-misses-the-point.en.html https://www.gnu.org/philosophy/open-source-misses-the-point....
- groestl 8y agoMaybe I missed something, but this essay seems to deal with the relationship of Open Source v Free Software, not Free Software v Copyleft Software.
- 8y ago
- dallen33 8y agoAre the Alliance for Open Media not allowed to use Apple's logo/trademark? Weird. https://aomedia.org/membership/members/ https://aomedia.org/membership/members/
- dochtman 8y agoI'd be interested in comparisons to https://github.com/xiph/rav1e https://github.com/xiph/rav1e.
- jbk 8y agoRav1e is an encoder. dav1d is a decoder. (Hence the last letter).
- aerodog 8y agoAm I right to conclude that av1 takes like 100x+ the duration of the video to encode? Like it's extremely impractical at the moment?
- ghostly_s 8y agoNot impractical, just resource intensive. :) IIRC extreme optimizations in favor of the decoder even at the expense of encoder burden was an explicit design goal of the codec, to meet the needs of Netflix-esque 'encode once, decode thousands of times' scenarios.
- tracker1 8y agoImprovements for performance as well as hardware specific versions of the algorithm or parts of generally come a few years after a specific encoding has a first working release. h.265 for example still has room to grow in hardware accelerated encoding, it's very fast. And x265 being software based is much better, but slower. It takes time.
- nickik 8y agoIt depends on what your usecase is. If you are Netflix and you have a show that gets watched 5 million times then having 100x on encoding is no big deal. However if you want to do live-streaming to a group of friends, its very impractical. Its only really worth doing a lot of work the encoder once you are sure its not gone change anymore, so work on that is surely ongoing.
- unlord 8y ago
- ggregoire 8y agoTIL what is a recursive acronym.
- nagVenkat 8y agoCould someone confirm if dav1d uses hardware acceleration to decode?
- BeeOnRope 8y agoWhat does it mean that the ask is written in NASM/GAS syntax? Those are two wildly different asm syntaxes with different macro languages etc. Is some asm written in one variant and some in the other, or is it all written both ways? Maybe for some targets GAS is used and others NASM (<-- it's this one as answered below)?
- kuroguro 8y ago> Therefore, the VideoLAN, VLC and FFmpeg communities have started to work on a new decoder Isn't VideoLAN the same as VLC?
- agumonkey 8y agomaybe VLC is just one project worked on by VideoLan people ?
- kuroguro 8y agoSeems so, but they are listed as if they are different "communities". I wonder if it's just bad wording.
- adrianmonk 8y agoIf there are people in the VideoLAN community who don't work on VLC, then they are different communities. One might be a superset of the other, but they aren't equivalent. To me, it's not bad wording to mention communities that have a lot of overlap. There's no rule that says you should only list things that are disjoint.
- jbk 8y agoVideoLAN has several projects, including VLC. But many people confuses both, so they are both listed.
- Retr0spectrum 8y ago> written in C99 (without VLAs) Can someone fill me in on why VLAs are a non-feature?
- jbk 8y agoBecause MSVC does not support those, and VLA became optional in C11. That's why we decided to not use them in dav1d.
- cesarb 8y agoThe most obvious reason is portability. Even though it's been nearly twenty years since the C99 standard, some compilers still haven't implemented VLAs. To make things worse, the next revision of the C standard (C11) made VLAs optional, so these compilers now have an excuse to never implement it. But even discounting that, there are still some issues with VLAs. For instance, the Linux kernel decided to remove all uses of VLAs they had, because they generate worse code than a partially-used fixed-size buffer, and also make it easier to overflow the kernel stack. VLAs, like their ancestor alloca(), seem convenient but often are more trouble than they're worth.
- gilnaa 8y agoVery easy to blow up your stack with unsanitized input
- codys 8y agoThough that is true of a lot of elements of C.
- AlotOfReading 8y agoThey're universally regarded as a dangerous, difficult to use feature (yes, even by C programmers) and are no longer required in C11. VLAs can have nasty side effects like stack corruption and are a leaky abstraction at best. You can't expose a VLA's size through the ABI, for instance.
- codys 8y ago
- nickik 8y agoGreat, so awesome to see the AV1 ecosystem grow like that. This will make the end of the old patent mafia. One thing I would like to see is that this runs on RISC-V. Both are very important new open technologies and it would be great to see it run on that officially.
- deleted 8y ago[deleted]
- ninjakeyboard 8y ago"AV1 has the potential to be up to 20% better than the HEVC codec" Can you clarify what is meant by better here? More compressed?
- rbultje 8y agoBitrate reduction for the same quality. So a file of identical quality - in some metric - will be 20% smaller (e.g. 8 MB instead of 10 MB for a video).
- vbezhenar 8y agoHow quality is measured? I never saw any quality estimations in software, e.g. when I'm exporting JPEG image, I'd like to have some kind of result quality estimation, it might be hard to judge it yourself.
- yekm 8y agoPSNR for example https://en.wikipedia.org/wiki/Peak_signal-to-noise_ratio https://en.wikipedia.org/wiki/Peak_signal-to-noise_ratio
- vsl 8y agoSome function of the difference in pixels between the original and decoded compressed version. This is a complicated subject, because a good error function should account for human perception and weight unimportant differences less.
- voltagex_ 8y agoCan anyone test this on a Raspberry Pi 3?
- Const-me 8y agoI think if they want wider adoption of the codec, they have to port this to GPU. They are much faster in term of throughput. They are more power efficient per FLOP. Also for players, the result needs to be in VRAM anyway. Unfortunately, it’s very hard to do in cross-platform way, for Windows you have to use D3D, for iOS Metal, etc… AFAIK, cross-platform GPGPU doesn’t work yet, at least when you want to target wide audience i.e. both Intel/Nvidia/AMD GPUs including older models, with default drivers.
- lpghatguy 8y agoIt's always possible to use GL compute or Vulkan compute with MoltenVK/gfx on MacOS/iOS.
- tormeh 8y agoWell, some people are working on this: https://github.com/gfx-rs/gfx/blob/master/README.md https://github.com/gfx-rs/gfx/blob/master/README.md I think at this point it's clear that we'll NEVER have a cross-platform graphics API. The incentives for platform holders speak against it, and design by committee means the attempts are so inferior that devs would rather avoid them. We have to make wrappers. Ideally, they should translate at compile time.
- Const-me 8y ago> it's clear that we'll NEVER have a cross-platform graphics API. I think we will, in a few years. I never used VK in production but I’ve read about it a lot, and I like the technology. Only I don’t think it happened just yet. On PCs Intel is problematic, VK requires Skylake GPUs (2015), i.e. most PCs older than 2-3 years don’t support it.
- iuysdgsdi7fgi 8y agoNever say never.
- twotwotwo 8y agoYeah, I bet GPU-aided decoding will get there, but a cross-platform CPU decoder seems like a reasonable place for work now--provide a baseline that can work a lot of places.
- eridius 8y agoWhy is this written in C? I would have thought Rust would be the perfect fit for this.
- steveklabnik 8y agoThere are some: https://github.com/xiph/rav1e https://github.com/xiph/rav1e The projects behind this project are all in C, so I imagine that’s why. They probably don’t want to commit to Rust on the basis of this codec alone.
- devwastaken 8y agoafaik safe rust would not perform that well compared to unsafe. The main safe part could be the command line or API but using Rust brings you into the Rust ecosystem and it may just not be worth it to do if most of their code is going to be unsafe and purposefully use performance hacks and SIMD.
- steveklabnik 8y agoSafe Rust can outperform unsafe Rust. It really just depends.
- eridius 8y agoI don't see why most code would have to be unsafe. Presumably some of it would, but that unsafe code can generally be wrapped up in a safe interface (this is practically the entire purpose of libstd).
- shakkhar 8y agoWhy is this a stand-alone library and not a part of libavcodec? To avoid LGPL?