AV1 codec ecosystem update

https://www.singhkays.com/blog/av1-ecosystem-update-may-2019/

by singhkays • 7 years ago

160 66 7 years ago

singhkays.com

slimscsi• 7 years ago

From Visionular website, Auorara claims to improve encoding speed by 32.2% against x265 veryslow

This is extremely unlikely. But a game changer if true.

motbob6• 7 years ago

Company, which has every reason to exaggerate, claims it can improve encoding speed by 32.2% against x265 veryslow

"It’ll be interesting to see if we find out more info and are able to test this encoder in the coming months."

BBC, which has no skin in the game, claims AV1 is less efficient than HEVC

"I would call this test flawed as AV1 has consistently shown to perform better than HEVC."

Every article on AV1 that I have read is like this, except for https://codecs.multimedia.cx/2018/12/why-i-am-sceptical-abou... -- they are always blatantly cheerleading new advancements, like only being 5x slower to decode than VP9 or 10x slower to encode than x265 or whatever. But the advancements are not phrased like that, of course--you are never reminded that the competition continues to clobber AV1 in every aspect but filesize/quality efficiency.

Causality1• 7 years ago

Yeah. I can see HEVC and AV1 coexisting for a very long time. I don't see AV1 getting adopted for game streaming purposes, for instance. It'll make an excellent media archive format, but personally I'm still migrating my content from h.264 to HEVC and I don't really see myself bothering to do it all again for AV1.

clouddrover3• 7 years ago

I don't see AV1 getting adopted for game streaming purposes

Twitch will be doing exactly that. They're using VP9 now:

https://blog.twitch.tv/how-does-vp9-deliver-value-for-twitch...

They will be moving to AV1 in the future. They've contributed features to AV1 specifically for the low latency live streaming use case:

https://www.youtube.com/watch?v=o5sJX6VA34o

clouddrover3• 7 years ago

the competition continues to clobber AV1 in every aspect

Which competitor beats AV1 in licensing? VP9 matches it in licensing. No other codec beats it. Even Leonardo Chiariglione (founder and chairman of MPEG) says AV1's licensing has MPEG beat:

http://blog.chiariglione.org/a-crisis-the-causes-and-a-solut...

icelancer• 7 years ago

Right. AV1 is technically poor but the licensing is so egregious elsewhere that we should really be rooting on VP9/AV1 over the alternatives.

zbobet20122• 7 years ago

The BBC article _is_ extremely flawed. Namely BBC bench-marked using this methodology^:

The parameter “--end-usage=q” was set to force fixed QP encoding according to the QPs in Table 1 and “--threads=1” was used to run the encoder in single-thread mode. The parameters “--passes=1” and “--lag-in-frames=0” were set to run AV1 in single pass mode without the possibility of looking ahead in the video sequence before encoding. Finally, the internal bit depth of the codec was set to 12 as typically used during the AV1 development. Finally, for all encoding technologies, each sequence was split into chunks of one Intra period (approximately 1 second, as defined in the RA configuration for HM and JEM), which allowed each chunk to be independently encoded in parallel. This coding configuration was adopted to reduce the overall time needed to encode with AV1, intead of encoding each 10 second sequence sequentially.

The BBC essentially forced the GOP size to 1s for libaom. In every benchmark I've run where HM and libaom are _not_ run in ridiculous modes, libaom has been about 30% better bdrate. This is consistent with many, broadly reported, independent analysis such as MSU, Facebook, etc. The second BBC evaluation which at least enabled two pass (the configuration AOM was developed in) shows much larger gains^^. They still did not address the inequity in gop length. Even old codecs like h264 can see a 10 to 20% gain on sequences from longer GOPs.

AV1 is far from perfect, as some of it's features are very computationally complex to implement today, while HEVC and VVC have "better known" complexity for their features. But the BBC benchmark analysis is simply not accurate.

^ https://zenodo.org/record/1494930#.XP7hdFVKgQ8

^^ https://www.bbc.co.uk/rd/blog/2019-05-av1-codec-streaming-pr...

Comparisons: http://www.compression.ru/video/codec_comparison/hevc_2018/ https://code.fb.com/video-engineering/facebook-video-adds-av... https://www.elecard.com/page/aom_av1_vs_hevc http://iphome.hhi.de/marpe/download/spie-2017.pdf https://bitmovin.com/av1-multi-codec-dash-dataset/

Edit: PS. The BBC evaluation is good for what they where benchmarking. Will AV1 today beat HM for live streaming? And the answer is, no. The Intel SVT encoder may change that soon. Libaom was not configured, or tested for that. But this is an odd benchmark to put forward as explicitly mentioned, speed is not what _either_ code base was built for.

motbob6• 7 years ago

1) Good post, but there is no "inequity" in GOP length, is there? The paper says "for all encoding technologies, each sequence was split into chunks of one Intra period."

2) I also don't really see why this would inherently disadvantage AV1, though obviously it would dampen any efficiency gain. (Why would it dampen it? Because it's not like one encoder is going to draw keyframes way more efficiently than another encoder, and as you lower GOP size, way more of the filesize gets taken up by keyframes, proportionally).

3) One-second GOPs are pretty out there, but we do live in a world where two-second GOPs aren't that unusual, so it's not that crazy.

jupp0r• 7 years ago

you are never reminded that the competition continues to clobber AV1 in every aspect but filesize/quality efficiency

You could have made that statement for all previous codec generations as well. We always buy comparatively small improvements with much higher computational costs. And Moore's law makes it always worth it. In the end filesize/efficiency is why we are doing this stuff in the first place.

ZeroGravitas3• 7 years ago

It's slightly obscure, but I think the BBC concluded that AV1 was better than x265.

They ran a similar comparison before and published more details. In that one, AV1 lost a little bit to x265 on objective PSNR but beat it on subjective evaluation.

In this latest result, they don't give as much info, but AV1 is closer in PSNR (ahead for 4k) while also being 25x faster than it was the last time, so presumably it would still win on subjective quality.

microcolonel4• 7 years ago

BBC, which has no skin in the game, claims AV1 is less efficient than HEVC

The BBC does have skin in the game. They have many people in house who have invested in HEVC, and put their names behind that decision; furthermore, maybe you'll remember when the BBC spent a huge amount of money on Dirac, which seems to have continued to be extremely impractical in the medium to long term. Maybe the BBC doesn't have a spectacular track record for picking the winners in the video codec game. ;- )

Added: The BBC's comparison also seems to be between professionally-configured and tuned HEVC/VVC encoders, supported by their vendors; and what seems to be a default-configured libaom, with no consultation with the vendor.

derf_• 7 years ago

To be fair, BBC's sole reason for investing in Dirac (to my understanding) was to fit HD quality video into the pipes for an SD production system. As far as I know, it satisfied that purpose for them, so the project can be considered a success from that standpoint.

xvilka• 7 years ago

The whole patent system for audio and video storage is flawed. These "competitors" should be abolished completely.

unlord• 7 years ago

It’ll be interesting to see if we find out more info and are able to test this encoder in the coming months.

You won't have to wait long, more information will be coming out later this month. I manage the codec engineering team at Mozilla and we are co-hosting the Big Apple Video 2019 conference with Vimeo at their space on June 26th:

https://bigapple.video

https://twitter.com/bigapplevideo

Have a look at our speaker list. Zoe Liu, the Co-Founder and President of Visionular, will be presenting the Aurora AV1 encoder, but this is just one of many talks that will look at the state-of-the-art in video technology. Hassene Tmar of Intel will give an overview of SVT-AV1.

The conference is free to attend, but please register. We will be live streaming the event with remote participation for those who can't make it.

ksec2• 7 years ago

Thanks for the link. For some reason my RSS reader ( likely in the Google Reader transition ) lost Kostya's feed. He used to be the one implementing all these obscure video codec.

And the article summarise nicely everything I loathe about AV1 and Baidu. I could only wish VVC or EVC fix what problem we have, or if not let hope they do better with AV2.

P.S - I am still not convinced Apple is fully on board with Open Media Alliance.

chubs2• 7 years ago

Any ideas how this Intel encoder compares to rav1e and why they chose to roll their own?

ComputerGuru3• 7 years ago

Auorara claims to improve encoding speed by 32.2% against x265 veryslow

I'll have to see it to believe it, because av1 has a long way to go to become even remotely comparable to x265 in encode times, let alone superior.

With ffmpeg built from git, I can encode a 1920x1080 video file to x265 (with a boatload of parameters and options, via a custom threadpool I've written that can saturate all the cores regardless of input stream complexity or size) at 9.2fps on a 16-core 1950X with sufficient RAM.

The same harness powering ffmpeg's av1 encoder (not the fastest, they haven't switched to rav1e yet) does not manage 2fps (I'm letting it run to see what it ends up with, but it'll be a while for this short 3:13 video).

FullyFunctional• 7 years ago

First, this is still the dawn of AV1 and the encoder you should be watching is SVT-AV1. You cannot conclude anything about the ultimate of AV1 encoding speed from experiences with a current version of ffmpeg.

As long as AV1 encoding (at useful compression etc) is within a small factor of HVEC, it will not be a factor in its success. License, quality, compression, and decoding speed are the things that matter.

shmerl• 7 years ago

And how is rav1e doing? The description claims it to be "the fastest and safest AV1 encoder."

ezoe• 7 years ago

2 fps isn't that bad considering the fact I believed that AV1 encoder's encoding speed should rather be measured by fph(frames per hour), or fpd(frames per day)

ComputerGuru3• 7 years ago

To be more clear: without my custom thread pool harness, av1 gets 0.2 fps on this same machine (under 700 frames per hour).

aidenn02• 7 years ago

What settings/cflags/&c. are you using? I get about 0.6 FPS on x265 1080p video on a Ryzen 7 2700. That's 10% the framerate on half the cores, with similar clockspeeds.

The only video options I'm using are:

    -preset:v veryslow -crf:v 18

ernst_klim• 7 years ago

I've just tested both `intel-svt-hevc` and `intel-svt-av1` from AUR on my 8-core i7-4790. Here are the results:

    Initial file:
    sintel.y4m  1280x544  21G
 
    HEVC:
    FPS: 140.65, File size: 114M

    AV1:
    FPS: 34.891, File size: 39M

Default profiles, since I'm not very familiar with AV1. HEVC is only 4 times faster here, but the AV1's output is 3 times more concise.

So AV1 looks very promising considering it's in its infancy yet.

phkahler• 7 years ago

So the Intel encoder handles 128x128 blocks. Isn't AV1 limited to 64x64 blocks?

sp332• 7 years ago

"superblocks... can either be of size 128×128 or 64×64 pixels" https://en.wikipedia.org/wiki/AV1#Partitioning Unfortunately I don't know of a more authoritative source.

cesarb• 7 years ago

Unfortunately I don't know of a more authoritative source.

https://aomediacodec.github.io/av1-spec/av1-spec.pdf is the most authoritative source.

"All superblocks within a frame are the same size and are square. The superblocks may be 128x128 luma samples or 64x64 luma samples. A superblock may contain 1 or 2 or 4 mode info blocks, or may be bisected in each direction to create 4 sub-blocks, which may themselves be further subpartitioned, forming the block quadtree."

"use_128x128_superblock, when equal to 1, indicates that superblocks contain 128x128 luma samples. When equal to 0, it indicates that superblocks contain 64x64 luma samples. (The number of contained chroma samples depends on subsampling_x and subsampling_y.)"

AV1 codec ecosystem update

Related Stories