
Better web video with AV1 codec - feross
https://evilmartians.com/chronicles/better-web-video-with-av1-codec
======
steeve
Huge shout out to the VideoLan team for writing dav1d, possibly the best AV1
decoder right now.

[https://code.videolan.org/videolan/dav1d](https://code.videolan.org/videolan/dav1d)

------
Wowfunhappy
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.)

~~~
AndrewUnmuted
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.

~~~
iskin
> 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...](https://evilmartians.com/chronicles/better-web-video-with-
av1-codec#understand-compression-options)

Is it not enough?

~~~
Terretta
Not really, no.

Encode quality has become a science:

[https://medium.com/netflix-techblog/dynamic-optimizer-a-
perc...](https://medium.com/netflix-techblog/dynamic-optimizer-a-perceptual-
video-encoding-optimization-framework-e19f1e3a277f)

For a deeper dive on FFmpeg options you can crib from the ‘scene’ community:

[https://scenerules.org/t.html?id=tvx2642k16.nfo](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.

~~~
iskin
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?

------
deanclatworthy
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.

~~~
TD-Linux
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...](https://code.videolan.org/videolan/dav1d/issues/15#note_23456)

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.

~~~
grapeli23
Chrome (74) also:
[https://bugs.chromium.org/p/chromium/issues/detail?id=924370](https://bugs.chromium.org/p/chromium/issues/detail?id=924370)

------
NelsonMinar
So far the pirate scene has totally ignored AV1. Most stuff is still H.264,
with some H.265 (HEVC) releases.

~~~
kristofferR
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.

~~~
worble
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.

~~~
userbinator
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.

~~~
canofbars
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.

------
doubleorseven
"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_...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Supported_media_formats#File_formats)

~~~
favorited
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.

------
ElijahLynn
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](https://en.wikipedia.org/wiki/Daala)
(Xiph/Mozilla)

[https://en.wikipedia.org/wiki/Thor_(video_codec)](https://en.wikipedia.org/wiki/Thor_\(video_codec\))
(Cisco)

[https://en.wikipedia.org/wiki/VP9#Successor:_from_VP10_to_AV...](https://en.wikipedia.org/wiki/VP9#Successor:_from_VP10_to_AV1)
(Google)

Updated: to clarify that AV1 is not only VP10 but also Daala and Thor, credit
to iskin.

~~~
iskin
Not only. It is also based on Xiph's/Mozilla's Daala and Cisco's Thor.

~~~
ElijahLynn
Thanks, I updated my comment.

------
lousken
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...](https://old.reddit.com/r/AV1/comments/a1038a/av11_is_launching_soon_and_will_include_breaking/?limit=500)

~~~
iskin
Nope, you can use AV1 without waiting for AV1.1.

AV1.1 players will support AV1.

~~~
lousken
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?

~~~
twotwotwo
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.

------
weugek
Wow this font is too large for my screen and it doesn't change if I zoom out,
great!

------
adamnemecek
Here’s a Rust AV1 mplementatuon by xiph
[https://github.com/xiph/rav1e](https://github.com/xiph/rav1e)

~~~
iskin
Yeap. Technically, it is encoder (a thing which generates AV1 files).

However, next-gen fast AV1 decoder (a thing which will play video), dav1d is
not Rust-based.

