

the M1 MacBook Pro before now.Įven though both laptops operate on the M1 processor that Apple launched in late 2020, the introduction of the new chip is a significant gain in performance and battery life to Apple's most portable laptops, leading a big step forward for the Mac.Ĭhoosing between the M1 MacBook Air and MacBook Pro can be pretty hard since they come in similar storage and memory configurations. X265: MMX2 SSE2Fast LZCNT SSSE3 SSE4.It's never been difficult to choose among the rivals of the M1 MacBook Air vs. X264: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 Hence, while SVT AV1 seems impressive, I'm not convinced an implementation for general use in Handbrake would be a good idea. The rav1e videos are (for me at least) not distinguishable from the original, but encoding speed obviously is pretty low. However, x265 still would be the better choice unless file size is critical. Still, I'd say the videos look very good, for me personally the quality would be ok. hairs are more washed out, even when compared to e.g. However, when comparing some of the frames in the videos you can clearly see that e.g. The speed of SVT AV1 is impressive, file sizes are, too. I used the file elephants_dream_1080p24.y4m, which is 46GB in size.ĬPU is an AMD Ryzen 9 5950X on Linux 5.10.12. Since I don't know which file zocker-160 used, I don't know if the results are comparable, possibly not. Out of curiosity I did a little bit of testing as well. Maybe only adding "slow" and "very slow" presets could help there a bit, but that could also rise requests to add "fast" presets, which however might not be available. Personally, I'm also interested in AV1 encoding, mainly since AV1 decoding is now getting implemented in recent consumer hardware and because it can offer better quality/size ratio, so it's a very good choice for archiving.īut I do get the argument here, that there will be complaints if the encoding speed is too slow. But for the pro, 10% of the size is worth a few hours of Coffee and Biscuits. And matched settings 264 can do it in, what?, 30 minutes? I think spending 2-4 hours for a 2hr video to come out 10% of the size is a good thing. You can’t use x264 to drop that unnoticed to 2-4GB.

What I tell people as being worth the rate. Yes there are gui options, randomly seeded around and he nets, none of them work right all the time.
Handbrake 1080p 60 fps mac software#
The issue isn’t AV1, it’s users who want everything now.Ĭurrently 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.

And far to many users want click click done.Īs 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. That’s the best ‘commercial’ response (no offence intended in the term) from any more popular development base on AV1!įar to many, even here, point to AV1 being too slow. We actually still get quite a lot of hate towards us for x264 being "too slow" :/Įither way, there are several viable options for us and it's defiantly trending in the right direction. 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. 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. 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.ĪV1 will probably be the release following after1.4 once it's had a bit more time to mature.

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. 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. 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. 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. In other words, it's actually not simple to do this kind of approach. Our engine isn't designed with split/combine encoding methods in mind. We have our own engine and while we use libavformat/libavcodec it's not quite as simple as job processing.
