Handbrake: Please incorporate open source SVT encoders for VP9, AV1, X265 and X264.

[ZaphodX77]

The SVT encoders gave a 3X frame rate increase on VP9 and X265. There is a patch for ffmpeg noted in the videohelp article. Thank you.

https://forum.videohelp.com/threads/392544-Intel-SVT-HEVC-encoder-test
https://x265.readthedocs.io/en/default/svthevc.html
https://www.phoronix.com/scan.php?page=news_item&px=Intel-SVT-VP9-3x-AVX2-Boost

HandBrake 1.2.2

Windows 10 Creators Update)

[ZaphodX77]

https://github.com/OpenVisualCloud/SVT-HEVC

[Nomis101]

https://github.com/OpenVisualCloud/SVT-HEVC

x265 has support for open source HEVC encoder SVT-HEVC, see:
https://x265.readthedocs.io/en/default/svthevc.html

[ZaphodX77]

But it's not incorporated into Handbrake. I used the --svt switch and got a not supported response.

[jstebbins]

Last time I looked SVT-AV1 isn't yet ready for integration. I tried to help them by submitting a couple of PRs to fix some of the problems (static library are mingw support). But they were very slow to review. static library was finally merged but I gave up on the mingw PR. I went through too many rounds of gnarly conflict resolution with pretty much no review.

Last I checked SVT-AV1 and SVT-HEVC couldn't be linked in the same binary due to overlapping name space. They essentially copied the code from one and converted it to the other so they share many function and data structure names. I don't know if SVT-VP9 suffers from the same problem, I haven't looked.

When core development work stabilizes and they have the time to pay attention to build and integration issues, maybe I'll try again.

[sr55]

@ZaphodX77 what kind of hardware are you running?

[ZaphodX77]

AMD 3800X 8 core/16 threads.

[EwoutH]

SVT-AV1 already delivers very usable performance in it's fastest speed preset, which still delivers quite good quality.

| CPU | FPS |
|----------------|------:|
| Core i7-8550U | 9,50 |
| Core i3 8100 | 13,08 |
| Core i7 8700K | 23,39 |
| Ryzen 5 3600X | 23.99 |
| Core i7-8086K | 25,82 |
| Core i7-7900X | 34,27 |
| Core i9-7980XE | 43,98 |

Source: OpenBenchmarking.org

[jstebbins]

@EwoutH, thanks for you comments in the SVT-AV! issue. I wish I could have followed through with that patch, but I just don't have enough spare time to keep doing large conflict resolutions.

What is current memory usage of SVT-AV1? Has that come down at all? If it's still up at the astronomical levels that it once was, we would have to add a spacial check for amount of available memory before allowing use of AV1 to at least alert the user to the possibility that their encode would not complete. We cater to a diverse crowd many of which have older machines with inadequate memory.

Also, is the duplicate symbol problem between SVT-AV1 and SVT-HEVC still an issue? HandBrake statically links libs, so such duplicate symbols would be a blocker for us.

[EwoutH]

@jstebbins You're very welcome! Memory consumption was a big issue indeed, and still is, but has improved. I ran some test with consumer level parameters, measuring maximum memory usage with /usr/bin/time -v:

| Max memory (kB) | 8 threads | 12 threads | 16 threads |
|-----------------|-----------:|-----------:|-----------:|
| 1080p 8b / s8 | 2.050.680 | 2.300.080 | 2.747.580 |
| 1080p 8b / s1 | 2.740.032 | 3.031.072 | 3.578.772 |
| 2160p 10b / s8 | 11.709.504 | 12.453.388 | 15.345.332 |
| 2160p 10b / s1 | 14.454.488 | 15.279.532 | 18.647.016 |

1080p encoding should be possible on most systems with 4 GB memory, and 2160p 10-bit with 16 GB on lower speed presets of 24 GB on higher speed presets. Of course there are edge cases where more is needed (extra long lookaheads for example), but these values should hold up in general usage.

[galad87]

Is quality comparable to x264/x265 at the same encoding speed and file size or better/worse?

[EwoutH]

@jstebbins MinGW support in SVT-AV1 is merged (https://github.com/OpenVisualCloud/SVT-AV1/pull/558). Thanks for your previous contributions!

[EwoutH]

SVT-AV1 v0.7.0 just got released. A lot of bugs got squashed in the past week, It should be pretty stable now.

Encoding quality on the fastest mode (EncMode 8) is objectively as good or better than x265 veryslow and libvpx s0, while being faster on multi-core machines. Subjective quality (VMAF) is still a bit behind due to not fully tuned yet. On a 6-core Ryzen 5 3600X it reaches 25fps while encoding 8-bit 1080p content.

Using EncMode 4, around 2,6 fps is reached on a 3600X, while delivering hugely better quality than both x265 veryslow and libvpx s0. Expect a 8% to 20% reduction in bitrate to enable the same quality.

At this point I would recommend EncMode 7 for quick encoding (15 fps on 3600X, quality on AWCY) and EncMode 5 for high quality encoding (6 fps on 3600X, quality on AWCY). Those two modes deliver an excellent quality/performance ratio.

[EwoutH]

I just published a short blog on SVT-AV1 performance, some of you might find it interesting

• AV1 is ready for prime time: SVT-AV1 beats x265 and libvpx in quality, bitrate and speed

[ZaphodX77]

@jstebbins Thank you for SVT-HEVC Safe string functions refactor (#422). I recognize that this is a much more popular codec than the others, and will therefore be more appreciated by Handbrake users.

[bradleysepos]

@ZaphodX77 Are you sure you linked the correct issue?

[1480c1]

I think he means https://github.com/OpenVisualCloud/SVT-AV1/pull/67
which also led to https://github.com/OpenVisualCloud/SVT-HEVC/pull/422

[ZaphodX77]

OpenVisualCloud/SVT-HEVC#422.
Sorry, I haven't commented so specifically and left out the majority of the address!!

[Zingam]

Does this mean there will be

1. SVT-AV1 encode/decode
2. rav1d/dav1d/ encode/decode #1864

[EwoutH]

@sr55, @bradleysepos and everyone else interested: Wednesday January 8th from 8:30 to 9:30 am PST (16:30 to 17:30 UTC) there is an open conference call for all users and developers interested in SVT-AV1. If you have any questions or suggestions for the Intel/Netflix team please name them there.

See https://github.com/OpenVisualCloud/SVT-AV1/issues/932 for more information and to put things on the agenda.

[crunchtime-ali]

Since https://github.com/HandBrake/HandBrake/issues/457 is limited to contributors I will write here.
ffmpeg gained av1 encoding support in 4.3 https://github.com/FFmpeg/FFmpeg/blob/3cf2f515e392ab22594f34966e93e75931cfc7e2/Changelog#L28

[Zingam]

Does anybody has any idea if AV1 encoding is feasible on home computers yet?

[1480c1]

I know multiple people who have done av1 encodes on their home computers, although they often used tools like av1an and neav1e to do chunking of their video and encoding to speed up the process

[master-of-zen]

Talking about AV1, I am a developer of a small framework for AV1 encoding.
Av1an

• Almost linear scaling for parallelization of AV1 encoding. From 2 cores to 32/64 core threadrippers and beyond, scalability only limited by video source and system resources. Parallelization can be done with or without loss of encoding efficiency.
• Real-world example of using 32 core Threadripper 3970X for AV1 encoding. Threadripper showcase notes
  TLDR: +10 fps for 1080p encoding at efficiency better than x265 placebo. (Screenshot really old:) )
  Screenshot

• AV1 encoding can be both faster and better than x265 at placebo/very slow/slower even on mainstream 6 core CPU (R5 1600). Reddit Post
  Graphs

[kellerkindt]

@master-of-zen I am currently giving your tool a try, and it just eats through the video (ryzen 3950x at 8-12fps), amazing! Would be really neat to have this or a similar strategy implemented in handbrake :)

[master-of-zen]

@kellerkindt :+1:

[bradleysepos]

We'll be revisiting AV1 encoders soon. No hard plans, but speed increases are encouraging. Also worth noting AOM is now at version 2.0.0 and significantly faster as well. Thanks for the interest and good work, everyone!

[EwoutH]

@bradleysepos Also maybe interesting: rav1e is included in the latest stable release of FFmpeg, version 4.3. Could be useful for testing or even integration.

[bradleysepos]

Indeed, rav1e in 4:3 😀 is something we've discussed internally as well. All good things.

I should note that while hunked/scene-split AV1 encoding will likely not become part of HandBrake (would be a bit invasive change), even 3 fps 1080p encoding on modern hardware is much improved. Parallel encoding (multiple simultaneous encodes) is also now available in the HandBrake nightly builds for Mac and Windows (10 only), which should help.

[lostinlodos]

With BOrAM I got Apx 40fps using a 2017 iMac I7 quad core and 64GB ram. 1080p 60 in 720p 60 out at 900kbs video and 86k he-aac.
Ram usage rarely moved past 20%
AND I could still use non-intensive apps like word, text pad, etc. Never passing 50% memory usage.
Given 16GB and 32GB are Mac options from Apple I think AV1 is ready for a handbrake rollout.
It saddens me I had to try a different app first. I like handbrake far better but BORAM got the job done.
I currently use HEVC 720P matched frame video at 980k and HEAAC at 86k for output. AV1 looks better at the same bitrate, a bit lower actually.
My next try is dropping the V rate down to 800 and see how it looks.
AV1 has amazing potential!

[Zingam]

So basically AV1 isn't suitable for a quick encoding of a weekend filming session on a low low budget power laptop with the standard 8Gb RAM. Or like we used HB - make a quick shot with a handy reencode with HB and file a bug report.

Is it a software optimization or will it require a special hardware to encode AV1 in real time? Or maybe it will be only good for offline encoding and streaming for anlong time?

I know multiple people who have done av1 encodes on their home computers, although they often used tools like av1an and neav1e to do chunking of their video and encoding to speed up the process

Thank you for the reply. 16-32 cores are hardly a typical home PC. That maybe only feasible in a professional setting for now.

The chunking strategy is a very clever one if you are already an enthusiast level hardware user.

[1480c1]

Thank you for the reply. 16-32 cores are hardly a typical home PC. That maybe only feasible in a professional setting for now.

I am not talking about people who have 16-32 cores, I am talking about people who have 4 physical cores with 8 threads.

[lostinlodos]

I was referring to ram. 16gb is the norm, with 8 and 12GB as the low end. 32 as a pro solution.
I only have 4 (FOUR) cores.

[w-barath]

If SVT-AV1 is at a point where it can achieve the same performance (same visual quality @ same file size @ same encode time) then it would be preferable as an "open" streaming format. Drawbacks include poor consumer device support and hit-and-miss browser support, but those problems will go away over the next few years, whereas the problems with x265 will take another 15 years to go away.

If you've followed the rule of thumb for RAM that says for every core x base clock GHz you should have 1GB of RAM, then on a 4-core i7 you should have 16GB. On an 8-core i9 you should have 32GB. On a 16-core Ryzen you should have 64GB. On a 32-core Threadripper you should have 96GB. Minimum, or you should have bought a lower-spec CPU and spent more on RAM.

[lostinlodos]

@w-barath
There’s definitely not time parity on older equipment. It’s just about real time on my iMac.
However with today’s core and AMD offerings, I’m sure if my older i7 can do real-time, they are faster yet.
When I switched from x264 to 265... I was able to match quality dropping from 1400-1500kbs 720p30 down to 900-1000kbs 720p30
AV1 is showing a quality match bringing that down to 500-600kbs from source. That’s a substantial drop!
Half the data rate rate half the size.

[w-barath]

The reduced data rate is nice, but what more people will care about more is whether it can achieve a lower data rate at a higher encode rate than the older codec. x265 overtook x264 about 3 years ago. x265 on 'fast' encodes faster than x264 on 'slow' while achieving a smaller file size for the same perceptual quality. There's a claim further up this thread that SVT-AV1 has overtaken x265 in a similar way, so then it becomes detrimental to continue encoding with x265 because you use more disk space and take longer for the same archival quality. And with AV1 you get browser support, which x265 won't get for another 15 years.

[lostinlodos]

The reduced data rate is nice, but what more people will care about more is whether it can achieve a lower data rate at a higher encode rate

I doubt that will be reached on older tech. Now or ever. But technology keeps marching forward. We’re now 3? Generations on from my Mac.
It would be nice to see someone with a current generation chip, i7 or Rz 5 drop my numbers in and run an encode. Just to see what modern speed looks like. If 2017 is at real-time we may be close to your dividing mark.
Based on Reddit:
10-meg shrek is actually, somewhat, watchable. Lol.

[EwoutH]

A quick status update on SVT-AV1 since it's v0.8.5 release.

On a fairly low-end Core i5-4590, a quad-core CPU from 2014, I'm reaching around 3,4 fps on 1080p content at preset 8 and 7. Compared to x264 veryslow, SVT-AV1 preset 7 offers a 43% reduction in bitrate (MS SSIM). Compared to x265 veryslow it offers a 21% bitrate reduction and compared to libvpx cpu-used 0 the reduction is 12%.

On this low-end CPU an 45 minute series episode (24fps) would take 6 hours to encode. A 2 hour movie would take 17 hours. If you have a somewhat more modern CPU, like a Ryzen 5 3600 or i5-10600, you can easily half those times, makeing

i5-4590 | FPS
-- | --
Preset 8 | 3,392
Preset 7 | 3,398
Preset 6 | 2,774
Preset 5 | 1,475
Preset 4 | 0,937
Preset 3 | 0,348

SVT-AV1 is now also integrated into FFmpeg (pass --enable-libsvtav1 when building).

[zocker-160]

@lostinlodos

It would be nice to see someone with a current generation chip, i7 or Rz 5 drop my numbers in and run an encode. Just to see what modern speed looks like

Do you have a script or something like that (to make it comparable) available? I have a 3700X for testing.

[EwoutH]

@zocker-160

• Download the SvtAv1EncApp from the release page and unzip
• Download (or create) a raw .y4m video (from https://media.xiph.org/ for example)
• Run the SvtAv1EncApp in the command prompt (I use SvtAv1EncApp.exe -n 60 -enc-mode 7 -b NULL.ivf -i video.y4m)
• The SvtAv1EncApp will output data including fps

In the CLI you can use a for loop if you want to test multiple settings. For Windows with different presets:
FOR %i IN (8 7 6 5 4 3) DO SvtAv1EncApp.exe -n 60 --preset %i -b NULL.ivf -i video.y4m

[zocker-160]

thank you @EwoutH I compiled the latest version on my own and tested with the 1080p 24fps video, here are my results:
I have to say though, that not all 8 cores where fully used

(RUN1 and 2 with the same settings and all runs with the same video file)

| R7 3700X | FPS RUN1 | FPS RUN2 | FPS RUN3 | Bitrate (kbps) |
| :---: | :---: | :---: | :---: | :---: |
| Preset 8 | 17,075 | 18,192 | 16,535 | 301 |
| Preset 7 | 18,204 | 18,192 | 16,570 | 300 |
| Preset 6 | 13,086 | 13,196 | 11,523 | 289 |
| Preset 5 | 8,649 | 8,766 | 6,555 | 282 |
| Preset 4 | 4,221 | 4,268 | 3,117 | 274 |
| Preset 3 | 2,806 | 2,581 | 1,780 | 276 |

Here the log output:
convert.log

EDIT: added RUN3, which converts the whole video and not only the first 60 frames

[telephoton]

I'd love to see some of these AV1 multicore strategies implemented in Handbrake. If the ffmpeg supports AV1 encoding and there are multiple multicore strategies I'm sure a relatively painless synthesis between them could be acheived

[sr55]

@telephoton HandBrake is not an ffmpeg front-end. We have our own engine and while we use libavformat/libavcodec it's not quite as simple as job processing. There is a lot of complexity in there. Our engine isn't designed with split/combine encoding methods in mind. In other words, it's actually not simple to do this kind of approach.

Most AV1 encoders should be multi-threaded but it will take time for encoders to mature and become more efficient such that they can scale on higher core count CPUs.
That said, AV1 is complex to encode, so ultra fast encoding times are not something we are going to see for probably a few years. Even where encoders do split/combine to get past scaling problems on high core count CPU's, It's still pretty slow in comparison to what most users are used to with x264.

Regardless, with the next release 1.4, we will be supporting (on mac/windows to begin with) the ability to have multiple discrete jobs running. So assuming your encoding more than 1 file, you'll still be able to have a chance of fully utilising the CPU assuming DDR4 Memory bandwidth (and potentially quantity for some people) doesn't become an issue.

AV1 will probably be the release following after1.4 once it's had a bit more time to mature. Adding something that's hyped up to HandBrake, that's not going to run at an acceptable speed for 99% of the user base is only going to create a crap ton of hate/noise/drama that a tiny team like ours just doesn't have time to deal with. Chances are we'll have it as a compile time nightly option for a while for folks that are smart enough to understand what they are getting themselves into. We actually still get quite a lot of hate towards us for x264 being "too slow" :/

Either way, there are several viable options for us and it's defiantly trending in the right direction. Just a waiting game and patience.

[lostinlodos]

@sr55
THANK YOU!!
That’s the best ‘commercial’ response (no offence intended in the term) from any more popular development base on AV1!

Far to many, even here, point to AV1 being too slow. And far to many users want click click done.

As I and others pointed out over the last few months you can get near real-time on modern mid-to-high range equipment at lower end HD settings.

The issue isn’t AV1, it’s users who want everything now.
Currently there are two options for AV1 you can build your own and use dozens of switches in a terminal emu, or spend thousands of dollars on commercial software that happens to implement the free AV1 as a drop down option.

Yes there are gui options, randomly seeded around and he nets, none of them work right all the time.
What I tell people as being worth the rate.
A 2 hour SOD video at 720p avg 8GB
You can’t use x264 to drop that unnoticed to 2-4GB.
Or X265 to drop to 1-3
Or AV1 to drop it to 700sMBs!
I think spending 2-4 hours for a 2hr video to come out 10% of the size is a good thing.
Sure the 265 encode takes under 2 hours. And matched settings 264 can do it in, what?, 30 minutes?
The haters will always hate. But for the pro, 10% of the size is worth a few hours of Coffee and Biscuits.