9 ms·
Modern codecs like AV1 can bring better quality video to the open web
- orastor 8y agoI hope this takes over HEVC and x264 in the near future!
- gallerdude 8y agoThe thing I'm most excited about for AV1 is film grain synthesis. I can't articulate why, but I really love the look of film grain in video. Unfortunately, on most codecs, film grain is a huge hassle which takes up a lot of bandwidth. But AV1 can automatically remove the grain, encode, and add it back in.
- tambourine_man 8y agoThat’s amazing. I use grain to disguise compression all the time and always this should be possible.
- paavoova 8y agoWhy not keep the bitrate higher? Or are you re-encoding already over-compressed video? In which case re-encoding and adding noise only reduces the amount of detail and bloats the encoded size with, well, noise.
- tambourine_man 8y ago>Why not keep the bitrate higher? Sure, that would be the optimal situation. However, for a variaty of reasons you sometimes have to deal with overly compressed images. Adding noise on the client during play back disguises compression, making it nicer to the eye at no bandwidth cost.
- bscphil 8y agoCurious about this. Does the grain it algorithmically adds back look the same as that it takes away? In other words, is it just a better way to compress existing film grain? Different film sources have extremely different grain profiles, and people who encode movies (both production companies and pirates) will have no interest in the aspects of a codec that remove the real grain in a film to replace it with a generic alternative. I suppose they might adopt AV1 with that feature turned off, but otherwise AV1 will mostly be adopted for web video which currently doesn't have grain due to low bitrate encoding.
- tfha 8y agoDepends how good you are with an encoder. It's not compression, the grain does change, but since it's just random anyway, the human eye can't notice so long as it's the same type of grain. Encoders generally have a few options to tune the grain that gets added back in to get it as close as possible to the original source.
- bscphil 8y agoI would be interested in seeing a post on these options and their results if you know of one. Even though grain is "random", it's not random noise and is very distinctive. No two film stocks (and probably no two movies) will have the exact same grain. It would require incredibly precise tuning to manually add back grain that matches the original in the film.
- severine 8y agoSearch for "film grain modeling".
- lucb1e 8y agoWhen I do that, I get (1) a Wikipedia page literally titled "film grain modeling", but it's only a redirect to H.264 and the only mention of "grain" on that page is in the redirect notification; (2) a patent; (3) some scientific paper supported by a few images that only show noise (is that what we're talking about? I expected grains in the sense of particle generators); (4-5-6) paywalled scientific papers; (7) a Facebook page... A link would be nicer than an apparently very specific search term.
- paavoova 8y agoIs this similar to DNR schemes? Because that's a lossy process that reduces find detail, and is notorious for having been misused in many bluray releases of analog film remasters. And adding digital grain "back in" doesn't sound very authentic to the original analog source.
- sjwright 8y agoFilm grain is so expensive to encode that in bit-rate-constrained situations you would be forced to choose between obvious ugly compression artefacts, a reasonably good image without grain, or a reasonably good image overlaid with inauthentic grain. Besides, "authentic" is such an overhyped pile of poo anyway. Everything is a reproduction; what matters should be that the artistic intent remains unaltered.
- jacobush 8y agoI am probably kind of crazy, but I love grain and worry when movies lose it. Like the fine old "Predator" movie on Bluray. Nice colors, but the grain is kind of gone. The DVD has more of it, and it looks better. I feel a ramble coming on, but I believe movies should be available in a version close to how they were viewed on theatrical release. If you think about it, the first 100 years of this artform is always going to be special.
- Veedrac 8y agoTruncated graphs are really misleading; I ended up doing a double-take. There are more honest ways to compress the height of a graph if vertical space is at a premium, like showing %savings.
- justinjlynn 8y agoOr using log charts, if you're required to use given units.
- ksec 8y agoI think Mozilla should advocate for patents free Software or get rid of Software Patents completely. The graph starts at 50%? And they didn't mention in the Moscow State University test, AV1 was 300x to 1000x slower. While I like competition from AV1, whatever they are doing in terms of marketing really doesn't resonate with me.
- semicolon_storm 8y ago> And they didn't mention in the Moscow State University test, AV1 was 300x to 1000x slower. Reference implementations of codecs are always slower. AV1 hasn't had the benefit of years of optimizations yet, so this slowness is to be expected.
- okket 8y agoIf the codec can not be implemented efficiently on existing battery powered handheld devices, it is pretty useless. That is the only metric that counts. Even if, it will take many years to a decade to spread, considering the replacement rates of those devices.
- aseipp 8y agoHEVC/H265 implementations were initially very poor also, but it doesn't mean much now. Plus, mobile devices will use embedded fixed-block ASICs for this, just like they already do for every existing codec. All codecs are completely impractical on mobile devices if you're basing your estimates off software numbers, even extremely well optimized software will kill your battery. So it's basically meaningless to try and extrapolate from optimized numbers, much less preliminary ones. Besides, encoding AV1 is what's expensive, but mobile devices also do not necessarily need AV1 encode support anyway. They will need decode support. Slow encode support is going to be a problem for people creating and serving video. But better compression rates from AV1 substantially help mobile devices, too, by reducing bandwidth needs for providers. You're likely to see major video content providers taking the hit of AV1 encoding, while users only need to decode, and this will largely be how it is used.
- LeoPanthera 8y agoLast time I checked (very unscientific test using Handbrake) the AV1 encoder was something like 10x slower than the hevc encoder on the same system. Is this likely to improve?
- ysleepy 8y agoIt did with H265, the prototype implementations were horribly slow.
- threeseed 8y agoExcept that "The AV1 reference encoder is [as of today] a hundred times slower than an HEVC one" https://www.ibc.org/delivery/codec-wars-the-battle-between-hevc-and-av1/2710.article https://www.ibc.org/delivery/codec-wars-the-battle-between-h...
- baobrien 8y agoDoes it matter? It's still a reference encoder. AFAIK, the AV1 bitstream is barely frozen. Is he talking about the working model HEVC encoder right after they froze it, or the final reference encoder before people started working on hardware implementations? The Current AV1 reference being some amount slower than some HEVC reference says nothing in itself about room for improvement.
- matt4077 8y agoThis is dangerously close to becoming a standard talking point nthis topic. It’s dangerous because it’ll be wrong as soon as anyone implements an encoder with speed as an objective, and especially when dedicated hardware starts to appear in devices (about 12 to 18 months from now)
- vortico 8y agoYes, currently there is no hardware encoder/decoder for AV1, but there is for h264 on many processors. This may change in the future if companies and users adopt it.
- shmerl 8y agoHow is the progress of the encoder? To be able to use it in real time it must be very efficient.
- snvzz 8y agoMozilla is working on a performance-optimized encoder, and has demonstrated realtime encoding recently on a lots-of-cores cpu.
- NelsonMinar 8y agoI've been using a lot of H.265 (aka x265/HEVC); some pirate scene TV and movie releases come out in it. It's fantastic. About 1/3-1/4 the size of H.264, which makes a huge difference both with download and with archiving. The downside is that there's not a lot of hardware support for encoding or decoding. Doing it on the CPU isn't bad but definitely not as energy efficient. The problem with H.265 is the IP situation is a mess. AV1 looks to be better in every way. Looking forward to its adoption. So far the pirate scene doesn't seem to be using it at all.
- CryoLogic 8y agoThe biggest downside is not energy efficiency IMO, it's speed. The speed difference between h.264 and h.265 encoding can be easily 10 fold. More-so on CPU reliant servers without GPUs. There is a big upfront sacrifice to get the small video size.
- xxpor 8y agoEven for decoding, you really need hardware acceleration. Trying to decode H.265 on one of these ARM based TV media players is an exercise in futility unless you have HW.
- zamadatix 8y agoPascal GPUs h265 encoding is 50% or higher than h264 encoding speeds. A single GTX 1080 can nvenc h265 8k@30 10bpp. A 150 dollar GPU will outperform a 3,000 dollar CPU only server in encoding (regardless if it's h264 or 265). The REAL blockers are licensing and, more importantly, legacy consumer hardware. Whether you want to call the latter a speed or power problem isn't the real issue, it's that not all consumers have the dedicated hardware and the older CPU then has the speed and power problems.
- kevingadd 8y agoWith GPU encoding it's important to take into account that GPU encodes are usually delivering way lower quality levels per bit, especially if you're looking for fast speeds. The difference is dramatic if you compare a Twitch stream (for example) encoded with NVENC to one encoded with x264. Of course, hardware encoders let you achieve things that you simply can't do with CPU encoding, so sometimes that quality hit is irrelevant... but if you're talking about whether to use h265 instead of h264, it's possible the bitrate and quality improvements aren't that dramatic when you're using nvenc.
- kuon 8y agoHow does AV1 performs when encoding fast (like realtime for twitch)? Is it possible? If yes, what is the gain over h264? I really hope an open format will win "the war", but I can't see it work at scale if it doesn't support streaming.
- clouddrover 8y agoLast year Bitmovin demonstrated a live 1080p AV1 stream using 32 cores: https://bitmovin.com/constantly-evolving-video-landscape-display-ibc-2017/ https://bitmovin.com/constantly-evolving-video-landscape-dis... Twitch wants to use AV1 for their streaming. They want to use the switching frame feature of AV1: https://www.youtube.com/watch?v=o5sJX6VA34o https://www.youtube.com/watch?v=o5sJX6VA34o And the chroma from luma feature of AV1 works well on video game content: https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml https://www.youtube.com/watch?v=yKEDf5-2sT4 https://www.youtube.com/watch?v=yKEDf5-2sT4
- kuon 8y agoThat's really promising. I really hope we will see an open video format as standard.
- nstart 8y agoI've seen a few mentions of patents in this discussion. Does anyone know how close AV1 is to infringing on any patents or when we might find out? This is the most recent article I found - http://www.streamingmedia.com/Articles/News/Online-Video-News/AV1-Is-Finally-Here-but-Intellectual-Property-Questions-Remain-124134.aspx http://www.streamingmedia.com/Articles/News/Online-Video-New... and it seems that the market doesn't/didn't know enough to know if there are patent infringements. Yet this article from Mozilla seems like that from June the situation might have changed now that a 1.0 stable spec is out. Given that inspection for infringement has been part of the codec creation process it seems promising that they will be safe. But patents have proven themselves to be funny things. That said, have there been any updates since June from lawyers/other blogs/etc about the patent situation yet?
- cordite 8y agoWhat happened to webm, which apple doesn’t even support yet?
- sparrc 8y agoYou might be mixing up containers and codecs. webm is the container format that most av1 video will be delivered in. With Apple the problem was not so much webm, but the vp9 codec, which is the codec most webm containers use (see youtube). ie, codecs: av1, vp9 <> h.264, h.265 containers: webm <> mp4