Better web video with AV1 codec(evilmartians.com)
evilmartians.com
Better web video with AV1 codec
https://evilmartians.com/chronicles/better-web-video-with-av1-codec
67 comments
One thing jumps out to me in the article: they're recommending crf 30 as a starting point for the x264 encode, and they suggest experimenting with values as high as 40.
Unless there's some detail I'm missing... crf 30 is going to look awful for anything ≤ 1080p, and I can't think of a time I'd ever use a value that high. Maybe for 4K content it would be alright, but I don't think that was specified. 40 is just ridiculous.
(I have no idea what the crf scale is like for x265 or av1, so no comment there.)
Unless there's some detail I'm missing... crf 30 is going to look awful for anything ≤ 1080p, and I can't think of a time I'd ever use a value that high. Maybe for 4K content it would be alright, but I don't think that was specified. 40 is just ridiculous.
(I have no idea what the crf scale is like for x265 or av1, so no comment there.)
You are correct. CRF 23-27 is a sane range for good quality and compression. Once you hit 30 there are too many artifacts and it looks bad. Not sure why the author chose to recommend that for x264.
[deleted]
Good idea. I will change the number in the article.
You're correct. An x264 CRF of 30 would look pretty miserable on almost anything compared to the source.
The article also uses the Main profile in that `-crf 30` example, negating quality even more. The author writes that this must be done to enable compatibility with Safari, but AFAIK Safari has supported H.264@High 5.1 for a while now. Using High profile would help reduce some of the compression artifacts that will result from using a CRF of 30.
EDIT: Looking at this "Evil Martians" webpage, it appears this blog post is just marketing for some generalized programming contracting company. I doubt they have actual video experts under their employ - these guys are just web devs who know enough bash to use FFmpeg from the CLI. I doubt they understand the implications of the commands they're running.
The article also uses the Main profile in that `-crf 30` example, negating quality even more. The author writes that this must be done to enable compatibility with Safari, but AFAIK Safari has supported H.264@High 5.1 for a while now. Using High profile would help reduce some of the compression artifacts that will result from using a CRF of 30.
EDIT: Looking at this "Evil Martians" webpage, it appears this blog post is just marketing for some generalized programming contracting company. I doubt they have actual video experts under their employ - these guys are just web devs who know enough bash to use FFmpeg from the CLI. I doubt they understand the implications of the commands they're running.
It has basically been the case for every AV1 advocate to compare about video codec using commands that doesn't make sense and benchmarks that were meaningless. Actually that is not strictly true because this happen with every On2 codec prior to their acquisition from Google.
You could also get much higher VMAF scores if you put some time into x264. x264 was never tuned for VMAF, I wish it had a mode just like SSIM and PSNR. But then those were done during early days just to prove a point. I doubt anyone on x264 cares about it.
As much as I like VMAF, and I thought we finally made something with Big Data and Machine Learning so we don't have to rely on PSNR and SSIM, VMAF it is still far from perfect. But my guess Netflix will constantly refine the model and add more improvement to it.
You could also get much higher VMAF scores if you put some time into x264. x264 was never tuned for VMAF, I wish it had a mode just like SSIM and PSNR. But then those were done during early days just to prove a point. I doubt anyone on x264 cares about it.
As much as I like VMAF, and I thought we finally made something with Big Data and Machine Learning so we don't have to rely on PSNR and SSIM, VMAF it is still far from perfect. But my guess Netflix will constantly refine the model and add more improvement to it.
> I doubt they understand the implications of the commands they're running.
I put a description for every arguments used by me in FFmpeg commands.
https://evilmartians.com/chronicles/better-web-video-with-av...
Is it not enough?
I put a description for every arguments used by me in FFmpeg commands.
https://evilmartians.com/chronicles/better-web-video-with-av...
Is it not enough?
Not really, no.
Encode quality has become a science:
https://medium.com/netflix-techblog/dynamic-optimizer-a-perc...
For a deeper dive on FFmpeg options you can crib from the ‘scene’ community:
https://scenerules.org/t.html?id=tvx2642k16.nfo
Or grab Handbrake, pick some built-in device or streaming target, and see the tuned default CLI options.
Encode quality has become a science:
https://medium.com/netflix-techblog/dynamic-optimizer-a-perc...
For a deeper dive on FFmpeg options you can crib from the ‘scene’ community:
https://scenerules.org/t.html?id=tvx2642k16.nfo
Or grab Handbrake, pick some built-in device or streaming target, and see the tuned default CLI options.
This is great links, thanks.
What arguments can be added to FFmpeg AV1 encoding command to improve the result for browsers?
Was this dynamic optimizer framework from Netflix released already to be used in web video encoding for webpages?
What arguments can be added to FFmpeg AV1 encoding command to improve the result for browsers?
Was this dynamic optimizer framework from Netflix released already to be used in web video encoding for webpages?
Using these codecs isn’t going to be better for your users if their hardware cannot natively decode it. Sure, it might shave a few gigabytes off their data plan, but it’ll also drain their batteries quicker.
Firefox Nightly switched to dav1d, which for many users is only going to use a fraction of their CPU. https://code.videolan.org/videolan/dav1d/issues/15#note_2345...
It will still be a measurable difference if you are watching hours of video, but for the gif replacement that this site suggests, it's negligible.
It will still be a measurable difference if you are watching hours of video, but for the gif replacement that this site suggests, it's negligible.
They did not switch to av1, they simply added support for it. H264 is still supported.
They switched their AV1 decoder from libaom to dav1d.
As always, it depends on the tradeoffs!
In general, encoding will cost you a whole lot more than decoding. Software encoders need to be really good to ship on the encoding side, and they're not there with AV1 yet.
Decoding, on the other hand, is pretty cheap. Hardware is still better, but it's been a long time since mobile CPUs were in a state that forced you to use a hardware decoder meet typical performance requirements. Bandwidth is so much more limited that using a software decoder to achieve a higher quality at a given bitrate is almost alway worth it.
Depending on the OS, if you watch a lot of video it is not unlikely that you are using a mobile app that uses, say, a software VP9 decoder.
In general, encoding will cost you a whole lot more than decoding. Software encoders need to be really good to ship on the encoding side, and they're not there with AV1 yet.
Decoding, on the other hand, is pretty cheap. Hardware is still better, but it's been a long time since mobile CPUs were in a state that forced you to use a hardware decoder meet typical performance requirements. Bandwidth is so much more limited that using a software decoder to achieve a higher quality at a given bitrate is almost alway worth it.
Depending on the OS, if you watch a lot of video it is not unlikely that you are using a mobile app that uses, say, a software VP9 decoder.
>Decoding, on the other hand, is pretty cheap. Hardware is still better, but it's been a long time since mobile CPUs were in a state that forced you to use a hardware decoder meet typical performance requirements. Bandwidth is so much more limited that using a software decoder to achieve a higher quality at a given bitrate is almost alway worth it.
It is not. Not with Modern Codec. Battery is so much more limited you will always want to trade high bandwidth than Software Decode. Apple tried VP9 software decode for youtube and all we got was very bad user experience. For most use case within a 20% bitrate, the difference between x264, VP9, x265 and AV1 are small, and you will always want to choose the one your user has hardware decode.
No one expect their Laptop , PC, Mobile, Tablet to get burning hot just watching a video for a few mixtures. Hardware decoding is literally the most important hardware on Mobile usage, and I argue the same for PC.
It is not. Not with Modern Codec. Battery is so much more limited you will always want to trade high bandwidth than Software Decode. Apple tried VP9 software decode for youtube and all we got was very bad user experience. For most use case within a 20% bitrate, the difference between x264, VP9, x265 and AV1 are small, and you will always want to choose the one your user has hardware decode.
No one expect their Laptop , PC, Mobile, Tablet to get burning hot just watching a video for a few mixtures. Hardware decoding is literally the most important hardware on Mobile usage, and I argue the same for PC.
My language was too strident. But there are shipping production applications that are using software VP9 encoders successfully, with improved user experience.
Yeah just look at the linked dav1d benchmarks. The decoder consumes a whole core for a single video at 30fps.
> might shave a few gigabytes off their data plan
I think I pay about $10 a gigabyte? If I actually used that many gigabytes a month, the savings would pay for a new phone!
I think I pay about $10 a gigabyte? If I actually used that many gigabytes a month, the savings would pay for a new phone!
I feel bad for you! here is a encoding format that might work for you http://takeovertheworld.org/matrix/
Because of this reason, AV1 is now disabled for mobile devices.
On desktop hardware support is not critical.
On desktop hardware support is not critical.
My Notebook's fan starts spinning quite annoyingly because youtube does vp9.
Just for comfort I prefer hardware decoding.
Just for comfort I prefer hardware decoding.
'media.webm.enabled' set to 'false' in Firefox's about:config will disable VP8 and VP9, gracefully falling back to (hardware accelerated) MP4 in almost all cases. This will break .webm and .webp images though.
Could there be some way to only disable webm on youtube? Disabling webm for all of the web just because it makes youtube annoying seems unfortunate.
There's an addon called h264ify that does just that. To test if it's working, go to https://www.youtube.com/html5 and 'WebM VP8' and 'MSE & WebM VP9' are unchecked. Alternately, go to any youtube video and right click->stats for nerds.
So far the pirate scene has totally ignored AV1. Most stuff is still H.264, with some H.265 (HEVC) releases.
It's only recently been possible to actually use HEVC/x265 for transparent encodes, previous versions of x265 removed film grain/digital noise to such a degree that the quality was worse than x264 at equivalent bitrates. Combine that with the massively increased costs in both encoding/decoding time (and worse x265 encoding tools/knowledge), x265 simply wasn't worthwhile except for crappy re-encodes at super low bitrates for people with crappy internet.
AV1 is far from ready even for crappy bitrate starved releases, but that's where you'll see it used first.
Recently you've begun to see a lot of x265 releases though, usually with HDR, the only significant feature x264 can't provide.
For sub-4K SDR content there's really no incentive for pirates to switch to x265 or AV1, it's just a nuisance. With torrenting people don't pay for the extra bitrate x264 requires, unlike streaming services like Netflix, the ~20-40% bitrate savings of x265 and AV1 are not important at all, especially compared to the other "costs" of compatibility issues and 10X-100X longer encode times.
AV1 is far from ready even for crappy bitrate starved releases, but that's where you'll see it used first.
Recently you've begun to see a lot of x265 releases though, usually with HDR, the only significant feature x264 can't provide.
For sub-4K SDR content there's really no incentive for pirates to switch to x265 or AV1, it's just a nuisance. With torrenting people don't pay for the extra bitrate x264 requires, unlike streaming services like Netflix, the ~20-40% bitrate savings of x265 and AV1 are not important at all, especially compared to the other "costs" of compatibility issues and 10X-100X longer encode times.
> It's only recently been possible to actually use HEVC/x265 for transparent encodes, previous versions of x265 removed film grain/digital noise to such a degree
And even then I've found that it still requires tweaking. With x264, pick a preset, crank the RF high enough, and it'll come out transparent. I haven't seen any of my own x265 encodes, even for high RF encodes (RF16+), come out transparent without adding '--no-sao --aq-mode 3' (without aq-mode 3 - dark areas are prone to blocking (especially SD sources), without no-sao - film grain is easily lost).
And even then I've found that it still requires tweaking. With x264, pick a preset, crank the RF high enough, and it'll come out transparent. I haven't seen any of my own x265 encodes, even for high RF encodes (RF16+), come out transparent without adding '--no-sao --aq-mode 3' (without aq-mode 3 - dark areas are prone to blocking (especially SD sources), without no-sao - film grain is easily lost).
Exactly this, it's slightly annoying to see the claim scenes are "slow" or "not what they used to be". They use the technology that it makes the most sense to use, weighing up encoding speeds, tooling, quality at the resolutions they care about, and output size. They will actually move when some of these technologies actually start providing major benefits that outstrip the existing technologies in these categories.
I disagree with your reasoning, the scene hasn't slowed because new technologies don't offer anything it's slowed because optimizing every bit of the transfer like you had to on old internet is no longer relevant and so "use the technology that it makes the most sense to use" has become "use h.264 or h.265 because dedicated players and hardware offload support it". If anyone really cares about extreme quality at this point they'll just download a rip of the original media rather than a transcoded copy
There is no longer a driving force behind pushing the limit of encoding in the scene and so the scene HAS slowed.
There is no longer a driving force behind pushing the limit of encoding in the scene and so the scene HAS slowed.
Another point is that the pirate scene obviously does not care at all about patents/openness, so their choices are driven strongly by technological factors. Plain old conservatism also plays a role.
This can be seen in warez too, where RAR is still popular despite 7z being often just as good in compression ratio while also open.
This can be seen in warez too, where RAR is still popular despite 7z being often just as good in compression ratio while also open.
They don't care about violating patents but they care about open source more than the general population. Taking a look at the stats from a large private tracker, a huge chunk of the users are running firefox on linux and the forums are full of open source talk.
FLAC tends to be the only allowed lossless codec over all the proprietary ones.
FLAC tends to be the only allowed lossless codec over all the proprietary ones.
It is exactly this reason I wonder if we should just stick to x264. You can do very decent x264 encode in low bitrate if you don't care about about film grain and noise. x265 also has advantage in 4K release due to increase in block size.
But x265 has made lots of improvement, I was watching some late 2016 encode the other day, and the current 2019 encode looks a lot better on the same ( Low-ish, 3Mbps) bitrate.
One reason I am looking for next generation VVC and AV2. The current AV1 an HEVC just don't give enough improvement that matter to me. They are far from what marketing slides want you to believe in 50% reduction.
But x265 has made lots of improvement, I was watching some late 2016 encode the other day, and the current 2019 encode looks a lot better on the same ( Low-ish, 3Mbps) bitrate.
One reason I am looking for next generation VVC and AV2. The current AV1 an HEVC just don't give enough improvement that matter to me. They are far from what marketing slides want you to believe in 50% reduction.
The AV1 codec was finalized last summer, I'd wager we will need a couple of years before the encoders are able to show the capacity of AV1, including getting the best out of encoding performance optimizations.
As for the pirate scene, my impression is that outside of 'anime' they are very conservative and follow rigid specifications. And even in the 'anime scene', I'd estimate that ~90% of new releases are still h264 encodes.
For some reason there was never a transition from h264 over to HEVC in the pirate scene, and I don't think this will happen for AV1 either.
In my opinion, while AV1 improves on previous codecs, it's not a big enough technical improvement when taking into consideration the increased encoding time (perhaps further optimizations will help mitigate this).
Instead, I think the big draw is the lack of royalties. But royalties is not a factor for the pirate scene, so for them I believe it boils down to quality/encoding time and hardware support, and here h264 still reigns supreme.
As for the pirate scene, my impression is that outside of 'anime' they are very conservative and follow rigid specifications. And even in the 'anime scene', I'd estimate that ~90% of new releases are still h264 encodes.
For some reason there was never a transition from h264 over to HEVC in the pirate scene, and I don't think this will happen for AV1 either.
In my opinion, while AV1 improves on previous codecs, it's not a big enough technical improvement when taking into consideration the increased encoding time (perhaps further optimizations will help mitigate this).
Instead, I think the big draw is the lack of royalties. But royalties is not a factor for the pirate scene, so for them I believe it boils down to quality/encoding time and hardware support, and here h264 still reigns supreme.
The pirate scene is usually slow to adopt new codecs. They are generally shooting for compatibility.
There is a reason XVid stayed around forever.
There is a reason XVid stayed around forever.
The pirate scene isn't what it used to be when it comes to adopting new technology. In the past the scene would adopt whatever codec gave the highest compression efficiency with little regard for anything else. You could see this in the adoption of MPEG4 ASP even though it was not widely adopted by the commercial market.
Today compatibility with set-top boxes is much more of a consideration than it used to be. The increased speed of internet service and reduced cost of storage have also lessened pressure to pursue ultimate efficiency.
Today compatibility with set-top boxes is much more of a consideration than it used to be. The increased speed of internet service and reduced cost of storage have also lessened pressure to pursue ultimate efficiency.
> In the past the scene would adopt whatever codec gave the highest compression efficiency with little regard for anything else
> Today compatibility with set-top boxes is much more of a consideration than it used to be
My experience was the opposite, they seemingly stuck to Xvid in AVI containers for the longest time to support those divx-compatible DVD players even when newer codecs were more performant. Whereas these days while not the most common codec, most things do end up getting a release in h265.
> Today compatibility with set-top boxes is much more of a consideration than it used to be
My experience was the opposite, they seemingly stuck to Xvid in AVI containers for the longest time to support those divx-compatible DVD players even when newer codecs were more performant. Whereas these days while not the most common codec, most things do end up getting a release in h265.
> Today compatibility with set-top boxes is much more of a consideration than it used to be.
My experience with the anime and tokusatsu fansubbing community is the opposite. There's a lot of "you must use mpv or CCCP", and a ton of disdain for people who watch on something other than a PC.
A small handful of groups will provide alternate "toaster-friendly" downloads for people on set-top boxes. For example, for ongoing TV shows, the main release will be a 720p or 810p softsubbed MKV with Hi10P video, and the "toaster-friendly" release will be a 480p hardsubbed MP4 with 8-bit video. This is mostly in the tokusatsu scene, though; for set-top boxes, the anime community mostly relies on dedicated encoding groups like DeadFish who provide "toaster-friendly" versions of other groups' releases because most groups won't even consider releasing something that's set-top-box-friendly. Also, there is an assumption that if you don't want to watch on a PC, then you don't mind SD video.
For fansubs that use Blu-ray-sourced video, there are no "toaster-friendly" options. You can basically expect groups to do a 720p Hi10P release alongside a 1080p release which is either Hi10P or HEVC, both of which are softsubs-only and in MKV containers. The audio is often, but not always, FLAC.
For those unfamiliar with how subtitles work, softsubs are incompatible with pretty much every set-top box. And there are some groups that will use intricate typesetting that can bring even decent PCs to their knees. For example, Commie is notorious for releasing an episode of JoJo's Bizarre Adventures with typesetting so over the top that it crashed most people's computers (I've never seen the episode myself, but I understand it involved hundreds of lines of text all continuously zooming in and out).
But even the anime/toku community doesn't use AV1, and HEVC is only for 1080p releases sourced from Blu-ray video (and to reiterate, a lot of groups will still use Hi10P even for 1080p).
My experience with the anime and tokusatsu fansubbing community is the opposite. There's a lot of "you must use mpv or CCCP", and a ton of disdain for people who watch on something other than a PC.
A small handful of groups will provide alternate "toaster-friendly" downloads for people on set-top boxes. For example, for ongoing TV shows, the main release will be a 720p or 810p softsubbed MKV with Hi10P video, and the "toaster-friendly" release will be a 480p hardsubbed MP4 with 8-bit video. This is mostly in the tokusatsu scene, though; for set-top boxes, the anime community mostly relies on dedicated encoding groups like DeadFish who provide "toaster-friendly" versions of other groups' releases because most groups won't even consider releasing something that's set-top-box-friendly. Also, there is an assumption that if you don't want to watch on a PC, then you don't mind SD video.
For fansubs that use Blu-ray-sourced video, there are no "toaster-friendly" options. You can basically expect groups to do a 720p Hi10P release alongside a 1080p release which is either Hi10P or HEVC, both of which are softsubs-only and in MKV containers. The audio is often, but not always, FLAC.
For those unfamiliar with how subtitles work, softsubs are incompatible with pretty much every set-top box. And there are some groups that will use intricate typesetting that can bring even decent PCs to their knees. For example, Commie is notorious for releasing an episode of JoJo's Bizarre Adventures with typesetting so over the top that it crashed most people's computers (I've never seen the episode myself, but I understand it involved hundreds of lines of text all continuously zooming in and out).
But even the anime/toku community doesn't use AV1, and HEVC is only for 1080p releases sourced from Blu-ray video (and to reiterate, a lot of groups will still use Hi10P even for 1080p).
>But even the anime/toku community doesn't use AV1
It is much too early for AV1 do see any real adoption. The existing encoders are very slow and/or lack features/tuning, and hardware support is non-existant.
In a year or two we will see encoder(s) at a sufficiently high optimization and quality level that it will be a candidate for high quality encodes, and if AV1 gains traction (outside of streaming) at that point I'm certain it will start in the anime scene.
edit: went and searched on Nyaa, and there are actually some AV1 encodes of various content, so some people are already experimenting.
It is much too early for AV1 do see any real adoption. The existing encoders are very slow and/or lack features/tuning, and hardware support is non-existant.
In a year or two we will see encoder(s) at a sufficiently high optimization and quality level that it will be a candidate for high quality encodes, and if AV1 gains traction (outside of streaming) at that point I'm certain it will start in the anime scene.
edit: went and searched on Nyaa, and there are actually some AV1 encodes of various content, so some people are already experimenting.
The anime piracy community is kind of its own beast. And we like it that way. :) Also, I would assume that there are different considerations for primarily dealing with animation as opposed to primarily live action.
> Also, I would assume that there are different considerations for primarily dealing with animation as opposed to primarily live action.
Eh, I've noticed similar from the tokusatsu community, and that's live action. The only difference is that some (but not all) toku groups will also provide toaster-friendly encodes in addition to their top-quality encodes, while anime groups rely on DeadFish for that.
The only toku group I can think of that touches HEVC is Pocket Universe, who specializes in muxing other groups' subs with Blu-ray-sourced video. Everyone else is mostly Hi10P.
Eh, I've noticed similar from the tokusatsu community, and that's live action. The only difference is that some (but not all) toku groups will also provide toaster-friendly encodes in addition to their top-quality encodes, while anime groups rely on DeadFish for that.
The only toku group I can think of that touches HEVC is Pocket Universe, who specializes in muxing other groups' subs with Blu-ray-sourced video. Everyone else is mostly Hi10P.
The pirate scene is about playing stuff on current consumer hardware. Not to mention, they also need the hardware to encode stuff. Neither of which is attractive for av1 at the moment. Some pockets of the pirate scene used to be about open standards, but I think a lot of that died out. One tracker that I know moved from flac audio in remuxes for a long time to dts-hd ma. I don't remember the exact reasons. Maybe multi-channel flac isn't good, or people have better luck with receivers and dts-hd ma.
It's possibly because Atmos requires DTS-HD MA (there's no free alternative), or because people playing on standalone hardware are more likely to support DTS-HD MA than FLAC. In general though, FLAC will compress to smaller than the equivalent DTS-HD MA.
I think the pirate scene will be the first, which will take AV1. They always are very advanced in terms of technologies.
AV1 is just a very new codec. You can use it in the Web for Chrome and Firefox. But it is too early to use for downloadable video files. For video files you need a OS support. Microsoft has it only in Beta. Android will support it in Q. Linux supports AV1 already.
I think in next year we will see more and more AV1 everywhere, including pirate torrent trackers.
AV1 is just a very new codec. You can use it in the Web for Chrome and Firefox. But it is too early to use for downloadable video files. For video files you need a OS support. Microsoft has it only in Beta. Android will support it in Q. Linux supports AV1 already.
I think in next year we will see more and more AV1 everywhere, including pirate torrent trackers.
"in theory, it does not matter, but MP4 is recommended and seems to be the most popular at the moment."
If I'm not mistaking, the <video> tag can't play MOV[0] so MP4 is the way to go.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_...
If I'm not mistaking, the <video> tag can't play MOV[0] so MP4 is the way to go.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_...
Huh. That's kinda surprising, since MP4 containers are really just a standardized extension of QuickTime.
IIRC, it reads like they took the QuickTime spec, did a find-and-replace to change the word "atom" to "box," then added a couple of MPEG-specific enhancements.
IIRC, it reads like they took the QuickTime spec, did a find-and-replace to change the word "atom" to "box," then added a couple of MPEG-specific enhancements.
Yeap. But technically, you can use WebM container (a subset of MKV) for AV1. Chrome and Firefox support it. But size is a little bigger and WebM container seems like is not really official for AV1.
AV1 has source code from VP10 (never published) of the VP8/VP9 fame. It is essentially what VP10 was going to be plus Daala and Thor.
https://en.wikipedia.org/wiki/Daala (Xiph/Mozilla)
https://en.wikipedia.org/wiki/Thor_(video_codec) (Cisco)
https://en.wikipedia.org/wiki/VP9#Successor:_from_VP10_to_AV... (Google)
Updated: to clarify that AV1 is not only VP10 but also Daala and Thor, credit to iskin.
https://en.wikipedia.org/wiki/Daala (Xiph/Mozilla)
https://en.wikipedia.org/wiki/Thor_(video_codec) (Cisco)
https://en.wikipedia.org/wiki/VP9#Successor:_from_VP10_to_AV... (Google)
Updated: to clarify that AV1 is not only VP10 but also Daala and Thor, credit to iskin.
Not only. It is also based on Xiph's/Mozilla's Daala and Cisco's Thor.
Thanks, I updated my comment.
Yea, but what about AV1.1 [0] ? Isn't it better to wait for that?
[0] https://old.reddit.com/r/AV1/comments/a1038a/av11_is_launchi...
[0] https://old.reddit.com/r/AV1/comments/a1038a/av11_is_launchi...
I don't know a lot about the specifics of this release, but isn't there always going to be a N+1 version which is better?
After a new version comes out it's going to take a while to work through the pipeline of inclusion into various projects, and that'll take a while, then people need to upgrade, etc.
After a new version comes out it's going to take a while to work through the pipeline of inclusion into various projects, and that'll take a while, then people need to upgrade, etc.
Nope, you can use AV1 without waiting for AV1.1.
AV1.1 players will support AV1.
AV1.1 players will support AV1.
Players will support both, but what about HW acceleration that will come eventually? That's my concern - for future proofing with mobile devices you should use AV1.1, correct?
If I'm parsing what I read right: 1.1 prohibits some narrow tiles--not the little 4x4 transform/prediction tiles, larger independently decompressible tiles that are used to allow parallelism. I suspect nobody was generating the narrow tiles before: it would be bad for compression, since the whole idea of these tiles is you can't predict across their boundaries. But they were technically allowed even if they didn't make sense.
The other things I see are a new option that doesn't break existing AV1 streams, and a couple changes that look like essentially editorial cleanups that were deferred during the spec freeze to avoid confusion.
They were right not to do these changes during spec freeze, but (at least from what I can see) they're not practical issues for folks considering AV1 encoding today.
The other things I see are a new option that doesn't break existing AV1 streams, and a couple changes that look like essentially editorial cleanups that were deferred during the spec freeze to avoid confusion.
They were right not to do these changes during spec freeze, but (at least from what I can see) they're not practical issues for folks considering AV1 encoding today.
I'm not super familiar with how HW acceleration is implemented in practice, but I imagine that a lot of the "building blocks" for HW accelerated AV1 will be reusable for AV1.1. If that's the case, as long as a mobile device gets the right software updates the hardware for AV1 will still be beneficial for AV1.1.
Don't delete the source gif and reencode when needed? Is there some situation in which AV1.1 > GIF > AV1 such that it would be worse to use AV1 today but better to use AV1.1 later?
Hardware will support both AV1 and AV1.1 too.
Wow this font is too large for my screen and it doesn't change if I zoom out, great!
Here’s a Rust AV1 mplementatuon by xiph https://github.com/xiph/rav1e
https://code.videolan.org/videolan/dav1d