I'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.
I think you're eating into quality loss if you're getting 33%-25% size, most every benchmark puts it at about 50%-60% size for equal quality to h264.
Pirating scene hasn't been using av1 at all because the bitstream hadn't been stabilized (an encode you made last month probably won't work on versions from this month) and, as a result of work still being done on the bitstream, no encoding hardware or software optimizations are available making it on the order of 3 magnitudes slower than existing options. Towards the start of 2019 you should start to see more hardware support pop up though.
> I think you're eating into quality loss if you're getting 33%-25% size, most every benchmark puts it at about 50%-60% size for equal quality to h264.
Do the benchmarks include animation? Perhaps flat surfaces like one sees in anime compress a lot better than average in x265?
Often, oddly enough. Anime groups in particular are obsessive about bitdepth, quality, and file size to the point it's not hard to find comparisons of lossless compression in newer codecs.
On the development and academic benchmarking side any comparison worth it's salt should have more than 5 different categories of video style. The paper linked in the article based their results on 20 different sequences, 3 or 4 of which looked to be animated.
One of the main reasons for the anime groups obsessing about the comparisons is that it's a lot easier to measure final quality on anime, with it's clearly-delineated artwork, instant transitions, and (comparatively) simple backgrounds.
I would also have guessed that many approaches for video/image compression like assuming lots of nice smooth gradients without hard edges, and so flat shaded but detailed drawn things might fare badly.
Hard edges are difficult for the DCT/DST used in most video codecs. A wavelet-based codec would most likely be better suited.
However, all modern codecs that I know of have directional intra prediction, which should be pretty effective in anime. Basically, what it does is that the decoder is able to follow lines with a variety of angles.
There are other things that help compression in anime: static frames, large flat areas, lack of film grain in computer drawn animation.
I would guess so, but looking at Nyaa atleast, there seem to be very little content encoded in HEVC compared to h264, which seems weird given how the 'anime scene' saw adoption of x264 10bit which is not even hardware accelerated.
With the supposed savings of HEVC versus h264, and the rather widespread HEVC hardware support in devices, I would have guessed that they would have embraced it at a larger scale by now.
Thanks for correcting me on quality. I'm getting confused because often the H.265 releases have low bitrate 2.0 audio compared to high quality 5.1 in the bigger file releases. They're optimizing for size, not fidelity. (I'm blessed with a tin ear and tin eye.)
Subtitles have (almost) nothing to do with the video codec. AVI, MKV, MP4, etc. are container formats that are used to multiplex multiple streams of media (video, audio, subtitles) into a single stream/file. In contrast, AV1, x264, HEVC, etc. are video codecs stored inside a multiplex. Perhaps confusingly, he MPEG LA (which standardised x264 and HEVC) is also responsible for the MP4 container.
> the MPEG LA (which standardised x264 and HEVC) is also responsible for the MP4 container.
The MPEG LA is just a licensing administrator formed by companies owning MPEG patents, they didn't standardize anything nor are they responsible for MP4 container.
You're absolutely right, sorry for getting this wrong. My mistake was to assume that the body that sells you the license is also responsible for the standardisation, but as you described, this is not true.
This is correct. The reason that the scene uses MKV is because it has better support for multiple audio, video, and subtitle streams and handles streaming as well as "streaming" from RAR compressed and split archive files.
Damn. How embarrassing! Two major factual mistakes in two sentences while nitpicking at someone else's mistakes on the internet. I of course meant to write h264 ;-)
Unless you encode the subtitles directly on the video stream, this is a container solution, the previous Google codecs (vp8/vp9) uses webm, which in turn is based upon mkv, so I would assume AV1 supports subtitles as easily if it uses webm as well.
webm is just a subset of MKV. They limited the codecs/options so that it would be easier have complete webm compatibility. (Whereas "full" MKV compatibility doesn't really make sense because it has ~infinite codecs you would need to support)
So far the pirate scene doesn't seem to be using it at all.
Pirates, quite understandably, don't care about patents or IP. They can be a good indicator of whether there is any other reason to use AV1 over H.265.
AV1 is not simply ready. The specification is finished, but the encoder-decoder is not yet optimized. (It's considered experimental by ffmpeg for example. https://trac.ffmpeg.org/wiki/Encode/AV1 )
In one of the tests rav1e encoded 1080p source at 0.013fps (i5-7600K @5GHz). That's half a year for a 2 hour movie.
Private torrent communities are already reluctant to use x265 which provides marginal gains compared to x264 at a great increase in encoding time.
A part of the process in pirate movie encoding (p2p, not really scene) is testing optimal encoder parameters (adaptive quantization strength, psychovisual rate-distortion, quantizer curve compression etc) on short clips meant to be representative of the whole movie (e.g. 60 frames every 4000 frames). If encoding a single test clip takes an hour as with x265 that sure puts a damper on things.
About the only place in movie torrent communities where x265 makes sense is 4K encodes as x265 can retain HDR metadata (h264 can too to an extent with the 2017 revision to T-REC H264 but it's hardly supported anywhere).
This may be different for pirate _streaming_ services.
> In one of the tests rav1e encoded 1080p source at 0.013fps (i5-7600K @5GHz). That's half a year for a 2 hour movie
This is easily explained by 1) no hardware acceleration, and 2) the reference implementation is currently intended for clarity and ease of changing, not efficiency or speed. After the bitstream solidifies, both problems will be solved.
> Private torrent communities are already reluctant to use x265 which provides marginal gains compared to x264 at a great increase in encoding time
Because there would be a clear quality loss. The websites they're ripping from (amazon, netflix, whatever) are using H.264, and to recode into H.265 would lose significant quality.
>Because there would be a clear quality loss. The websites they're ripping from (amazon, netflix, whatever) are using H.264, and to recode into H.265 would lose significant quality.
This is wrong for two reasons: the source codec doesn't matter (it gets decoded to raw yuv420 first anyway), and netflix/amazon/UHD BluRays already use HEVC for 4K which I alluded to earlier.
The 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.
>There is a big upfront sacrifice to get the small video size.
Still, the benefit to the millions of people who might download and watch a video surely outweighs the cost of the one individual computer that spent 10x the amount of CPU cycles encoding it.
Pascal 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.
With 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.
Anecdotal evidence, and possibly an FFmpeg/Nvenc bug
I've found that I'm not able to encode video above the size of the VRAM on the GTX 1050 in my home server. It seems to spew out errors, despite the GPU's memory usage being roughly 60MB from ffmpeg
My GTX 1080 meanwhile seems to happily churn through anything and everything thrown at it
Even 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.
The biggest downside is that your phone / tablet / etc can hardware decode h.264, and has to run h.265 or av1 decoding in software. As a result, your battery life gets killed when watching h.265 / av1.
Where are you finding HEVC encoded pirate content?
I railed against "scene" groups for many years over the quality (or lack thereof) in releases they put out. To the point I simply started buying the media I wanted, ripping it myself and then converting it to HEVC
Doing as close to a 1:1 DVD rip as I can, I've shrunk things like Seinfeld from 152GB of MPEG-2 video to just 31GB in HEVC, and it still looks absolutely fantastic
HD video fares even better. The X-Files on Blu Ray is roughly 1.7 terabytes. HEVC encoded brings it down to 240GB or so
PSA Rips is a good place to look if you're curious about how H.265 is used in practice. (Note the 10 bit video.) Their stuff tends to be tagged "hevc-psa". Here's an article they wrote about encoding quality: https://psarips.com/why-psas-releases-are-sometimes-late/
I don't think so; their releases seem mostly to be WEB-DL from the original source streams. They seem pretty sophisticated about it, I don't think they're doing something stupid like trying to turn an 8 bit source into a 10 bit rip.
Hardware support for decoding should be pretty good these days. Any TV or streaming box that supports 4k streaming should support HEVC, since AFAIK all the streaming sources use it (except for YouTube, last I checked). I suppose if you’re streaming on a laptop you might be stuck with software decoding.
I’m also very impressed with HEVC, but mostly from the angle of UHD Blu-rays. The quality is remarkable. For the same size or slightly larger than 1080p Blu-rays (around 50GB, sometimes up to 70), you get 4k resolution (4 times the pixels as 1080p) and HDR.
>The problem with H.265 is the IP situation is a mess.
I really wish the next gen codec, H.266 VVC could sort this royalty mess out before hand.
Why cant we keep things simple. USD $1 Per devices Royalty on Hardware encode and decode, that is roughly $3B + Royalty every year for the next 20 years.
Software Implementation should be free. So an H.266, VVC based image and video decoder could be immediately rolled out to all PC, and browser vendor could support it.
One of the problem with current MPEG codec is that they are too worry about free software implementation take over their royalty. Well we don't have huge increase in IPC anymore. We have a roadmap from TSMC that shows us the next 10 years of leading edge transistor is going to be more expensive then ever. We don't have any breakthrough / theory on hand they we could make those a lot cheaper. The days of Moore's Law are long gone.
This allow hardware maker to sell "faster" video and picture decoding. Consumers are a lot easier to spend money on physical object, then paying $x for faster software. Once they felt how slow their images and video were, it give them an incentive to upgrade, PC, Tablet, Phone etc.
The 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.
Curious 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.
Depends 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.
I 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.
When 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.
That's interesting and matches my a priori expectations. That (effectively) makes it a way of compressing grain, rather than just masking lower bitrates. You have to store information about the analysis for the decoder to work, and so there are the usual tradeoffs that come with compression.
I don't think it really counts as compression. It's like taking the statistics of a text and generating a new one with a Markov chain.
In other words, it is complete nonsense, texture synthesis, like the way some people go for printing a digital image on a fake "canvas" for a "textured, 3D look"... or maybe one of those flickering flame light bulbs.
Can anybody here imagine an audio codec that added simulated hiss and crackles to make it sound like you were listening to a vinyl record? That's what this is.
Some artists will intentionally put scratching or crackling into their music for atmosphere. Imagine an audio codec that eliminated all scratching and crackling from music. Some people may not mind but many artists would hate it.
Film is the same. Directors choose the film type and grain patterns that match the look and feel they want. A more grainy film feels darker and more serious. Splotchiness contributes to an unrefined or maybe even psychotic feel.
You don't want your encode removing that. You want the atmosphere of the visuals to match the original, because the director likely had that atmosphere in mind and made other decisions around it.
Well, the problem is that the encoding process in AV1 does remove grain, only to add fake synthetic grain back in. My objection is not to the idea of encoding grain, it's with replacing it with fake synthetic grain.
It's kitschy, ersatz, whatever you want to call it. I used to spend a lot of time with artist filmmakers (many of whom are very nostalgic about celluloid) and there is no way in hell they would accept this solution. It wouldn't meet their standards of authenticity. It also "fakes" a medium-specific property in a way that is unprecedented in audio or visual coding. Their solution would be to either code at high enough bitrate to capture the grain, or insist on screening on physical celluloid.
That might sound extreme and unrealistic—it's what artist's film people are like—and even a bit snobby. After all, a lot of the options out there for adding film grain effects (or scratches etc.) to video are not intended for use by professional filmmakers, depending on how you define professional. There is definitely an element of snobbery to the statement that film grain should never be faked, whether by compositing something onto your home video or in a hidden way inside AV1.
I hope you can see that I respect the director's prerogative in choosing grain, I just don't think this AV1 grain synthesis methodology is sound from an aesthetic/authenticity point of view. It's digital faking of an chemical/analog effect, which IMO makes it unavoidably kitsch for reasons to do with old modernist ideas of "medium specificity".
I couldn't easily pull up any screenshots, but I've been a video encoder for some years and I can tell you that psy-rd (the x264 option to add film grain) does wonders in terms of grain fidelity.
The problem with matching the grain perfectly without the randomization is that it drives the bitrate crazy. A movie with 99% fidelity grain and 0 psy-rd will have a bitrate of 30mbps+.
If you use psy-rd though, you can get to 99% fidely grain at closer to 20mbps. The two screenshots will be visually indistinguishable, even when you are rapidly switching between the source and encode, even though you know that the grain is being randomly generated you can't tell.
If I get a chance later today I'll drop some comparison screenshots for a film encode that used a lot of psy-rd, I think the results will surprise you.
https://jmvalin.ca/papers/AV1_tools.pdf has a brief technical description, but no results. It cites a DCC paper from the authors of the tool, but I couldn't find a copy online.
Why 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.
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.
I 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.
Is 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.
Film 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.
Truncated 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.
I'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-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?
If 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.
HEVC/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.
> All codecs are completely impractical on mobile devices if you're basing your estimates off software numbers
I have an iPhone 7 which has no hardware VP9 support but VP9 video works well at 720p in VLC. I'm sure the battery won't last as long as playing H.264 video in hardware but I wouldn't call VP9 playback impractical.
Yes, but my point was don't underestimate software decoders on modern mobile devices. As an experiment, I left a local 720p30 VP9 video with Opus audio running in a loop in VLC on my iPhone 7 for 3 hours. Both video and audio are being decoded in software.
My battery started at 90% and at the end of three hours it was at 55%. I think that's pretty good for software decoding.
I'm not sure which VP9 decoder VLC uses on iOS. I presume it's ffvp9:
>but mobile devices also do not necessarily need AV1 encode support anyway
I would highly, highly argue that they do. There is no reason in modern day that we need to all be uploading the full size of images and videos to servers to be re-compressed. It creates a significant barrier to entry for any social media platform when it should be as simple as the device itself being able to encode it, with the server checking it and creating other sizes. If AV1 becomes the great standard we can reduce a lot of costs. We already could do it with jpeg compression, but hasn't seemed to happen.
Slightly less compression rates for faster compression is perfectly acceptable. I would hope theres profiling options for that.
Whether or not they use it is a completely different matter from whether AV1 is useful for those scenarios.
Assuming a gargantuan encoding slowdown, even in the face of hardware-based encoders on mobile devices (which, again: hardware decoding/encoding is the fact of the matter on how it will happen), then there's no reason to support AV1 encoders since it will hurt battery. You're better off with something else, because users care more about their battery than compression ratios or minor artifacts on their Insta videos.
Assuming no gargantuan slowdown, and devices are equipped with AV1 encoders that perform admirably, then your problem is solved. Just use the hardware encoder. (Personally, it's unclear to me how much of AV1 encode support is fundamental slowness that can't be mitigated by hardware and implementation, but I suspect a lot of this fear is tied up in early-stage numbers. I bet it can go much faster, even if it's still slower overall.)
If you're a media provider like Netflix for example, though, the bandwidth savings will utterly dwarf the cost of the more expensive encoding process. They encode once and serve thousands of times, and they don't run Netflix (the company) on old mobile phones. So they'll do it anyway, because they want their users to use AV1. It saves them bandwidth on a high quality video, and it saves users on their data plans and their battery.
This isn't really very hard to think about. Either AV1 encoding is fundamentally too inefficient for mobile, or it isn't. If it isn't, users can still get fast decoders (that wasn't the bottleneck), since the bandwidth savings are going to be highly desirable for everyone, basically, and they'll be pushed for. If they can be efficient enough, then there's no problem.
The problem is that reference implementations of AV1 are 100x slower than HEVC at encoding. And so hardware decoding may ether be (a) impossible on current devices or (b) likely to destroy battery life. The only option is some breakthrough in the complexity of the encoding algorithm.
These issues unless solved relegates AV1 to being a Youtube and Netflix format and pretty much irrelevant for everyone else.
> Youtube and Netflix and pretty much irrelevant for anyone else
I like it when the goalposts move in such a way that "used by services in over 50% of US households and services where 70% of all video usage come from mobile, and offers excellent bandwidth improvements for millions of users" apparently means AV1 is a failure, somehow, based on preliminary numbers for a use case (encoding) that largely isn't relevant to mobile devices (and will improve dramatically over time making encoding more usable, anyway, as all prior codecs did.)
Unfortunately for the AV1 designers, they could have realized this fatal flaw sooner, had they only consulted the grand expertise of..... a random internet forum user.
>Reference implementations are not about performance, they are documentation. They are not supposed to be used for anything else but documentation.
That is valid for all H.262 , H.263, H.264 and H.265, as well as the up coming H.266 VVC. The current Av1 isn't a documentation. Nor it is a Reference Implementation in the regards of all MEPG codec. The AV1 is built on a working, professionally made libvpx encoder built on VP9.
>There is absolutely not reason assume that av1 is fundamentaly more power consuming that HEVC.
It definitely will be more complex, both encoding and decoding. Its fundamental complexity is much higher then HEVC, how far could they optimise so they are close to 5 - 10x of HEVC is a different story.
>And so hardware decoding may ether be (a) impossible on current devices or (b) likely to destroy battery life.
The development of the codec has been done with constant input from the hardware developers who are backing AV1 (Intel,AMD,Broadcom,NVidia etc) in order to make it effective when used with hardware acceleration. Just watch some of the developer presentations on Youtube.
Your fear that all the streaming and hardware giants would cooperately develop a codec that won't be effective on mobile hardware is unfounded.
The most computationally efficient encoding algorithms can do hundreds of frames per second at 720p even on mobile. The price you pay is quality and filesize - it'll be large and look awful.
h265 had the exact same problems too. AV1 is not implemented on mobile, yet. Both Apple and Google are on board with this, as soon as it is completed I believe it will spread quite quickly.
Also TV boxes and embedded SBCs. Having an AV1 decoder on board of say a Raspberry PI or other similar board would make a difference. There's a lot of them around playing movies through Kodi.
Not sure why this was down voted. It really is the only thing that matters.
The trend is overwhelmingly towards mobile being the dominant platform for video. And if your videos can't play on the majority of the iOS and Android it's simply a non-starter. Look at what happened to Flash once Apple banned it on iOS.
It’s downvoted because this comment appears in literally every discussion about new codecs, is misguided and trivially countered every time, and yet it persists. People enjoyed this discussion the first, second, and maybe even third time. By the twentieth time, people get tired of commenters making these kinds of baseless assertions that fundamentally boil down to an accusation of staggering incompetence on those involved in designing the codec.
Yes, the reference implementation of encoding is slow. Being fast is not a high priority for a reference implementation. Optimized implementations will come later. ASIC implementations will come later. The H.265 reference implementation was similarly slow, and it’s not a problem. And mobile devices primarily care about decode performance.
>> The H.265 reference implementation was similarly slow,
> Please provide evidence. Because all other data has shown it to be 100x slower.
I got this!
H.265/MPEG-HEVC is the latest video coding standard... it's well known that reference implementation of HEVC codec, HM, acts an important role during standardization... However, HM is far from a practical codec because of very slow coding speed even on modern multi-core computers.
Encode speed hasn't seen much optimization, the bitstream was frozen just weeks ago.
Also there are already an alternative AV1 encoder in the works, RAV1E, written by Mozilla in Rust, so there will be competition which will likely speed development, and the x265 developers have stated that they will create an AV1 encoder if that's where the market goes, which at this point seems very likely given that all the major players are backing this codec, coupled with the fact that it's royalty free and thus can be implemented anywhere.
The article also incorrectly calls AV1 "patent free".
It's royalty-free, but what that really means is that contributors are licensing their AV1-connected patents to everyone for free. That's all fine and good as long as AV1 isn't found to infringe on patents owned by non-AOM members.
AV1 is almost guaranteed to infringe on patents too.
VP8/VP9 both were patent encumbered and required licensing from MPEG-LA. It's going to be interesting to see what happens if AV1 does take off whether the big MPEG-LA patent contributors decide to go for royalties.
Last 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?
Yes, 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.
I might be mistaken, but I believe most high quality encodes in both h264 / hevc are not done using dedicated hardware encoders built into processors or graphics cards. While it's much faster there's usually some quality tradeoff. Instead, I believe that newer processors have additional instruction sets that enable much faster software encoding on the same codecs. Someone correct me if I'm wrong about this.
You're right, there are fewer h264 encoders than decoders in consumer software, but still dozens. https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC_products_and_...
There are precisely 0 for AV1 so far (except some may have a subset of the standard in FPGA by now).
> Yes, 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.
Does x86/x64 have any? What's the name of one of the instructions (for example)? I feel like mostly all I see is just bigger vector instructions...
Yeah, its called a VPU aka Video Processing Unit. If your hardware implements video decoding, they likely have licensed or designed their own VPU IP block.
This 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)
Does 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.
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.