lisamelton / other_video_transcoding

Other tools to transcode videos.
MIT License
544 stars 25 forks source link

Apple M1 #86

Open weaverm opened 3 years ago

weaverm commented 3 years ago

Do folks here have any thoughts or experience transcoding with the M1? I see that Handbrake has a Universal Binary beta (HandBrake 1.4.0-beta.1). I have no idea where ffmpeg is on the Universal Binary spectrum. I also am not aware of what, if any, changes have been made to the Apple VideoToolBox in Big Sur and on the M1.

samhutchins commented 3 years ago

There's no technical reason things wouldn't work, all the stuff required for other-transcode can be compiled for ARM (I've been running it on a Raspberry Pi recently)

Not sure what HomeBrew's plans for M1 are, but once that's serving ARM binaries (Universal or otherwise), everything should work.

I'd expect VideoToolbox to be similar to T2 macs, but I'm honestly not sure what changes have been made to the encoding block since T2. I doubt it's any worse.

I'd expect all the software encoders to work, and probably faster than most other macs

lambdan commented 3 years ago

I got the M1 Air (8/8 cores, 8 ram, 512 ssd) and I ran The Godfather (1080p bluray) through it using the VideoToolbox HEVC encoder (all default settings otherwise, just used the --hevc switch):

 > ask-ffmpeg-log The\ Godfather_t00.mkv.log 
 > 191 fps 00:22:14 The Godfather_t00.mkv

Pretty good I think? Especially since this thing doesn't even have a damn fan in it.

Video quality wise I think its fine? I can't see any obvious flaws in it.

As you can see in this screenshot, ffmpeg runs through Rosetta (Architecture = Intel) but VTEncoderXPCService has the Apple architecture.

Screenshot 2020-11-28 at 14 50 21

lisamelton commented 3 years ago

@lambdan Thanks for testing and sharing these numbers!

One of our HiveMind™ members is seeing similar performance on her new M1 MacBook Pro with a still-Intel ffmpeg binary for HEVC and AVC/H.264 output.

mushbuddygoose commented 3 years ago

I am seeing same thing. I found a static FFmpeg compiled for Apple Silicon but doesn't seem to make a difference. Using the VideoToolBox, 1080P BR > H265 at CB of 8K yields 200 FPS on my Mac mini M1. When I drop it down to x265 at medium and CF 20 I am seeing 14/15 FPS!

lisamelton commented 3 years ago

@mushbuddygoose Thanks for sharing those numbers!

weaverm commented 3 years ago

Can anyone comment on if VideoToolBox on M1 can produce 10-bit HEVC output from an 8-bit input?

lisamelton commented 3 years ago

@weaverm The HiveMind™ has been doing some testing on this and it appears that current M1-equipped Macs cannot produce 10-bit HEVC output using VideoToolbox. However, we don't know if this is a limit in the hardware, in system software or in ffmpeg. If it's a software issue then hopefully it can be fixed in the future.

RusselProuse34 commented 3 years ago

I also hope this is something that can be fixed because the M1 Mac mini seems like the ultimate machine to run a media server on - cool, silent, low power, and incredibly fast.

lisamelton commented 3 years ago

@RusselProuse34 This is exactly why the nerds of the HiveMind™ are interested in it. :)

weaverm commented 3 years ago

I got an M1 Air a couple days ago. Homebrew installed arm64_big_sur versions of everything for FFmpeg and MKVToolNix. When I run other-transcode on it, ffmpeg shows up as Apple architecture in Activity Monitor. The --vt encoder works as expected (still only 8-bit hevc from 8-bit source). The --x265 encoder will make 10-bit output, but it is slow. Roughly 4 fps with a 1080p blu-ray rip and a --target 4000 encode.

Transcoding...
x265 [info]: HEVC encoder version 0.0
x265 [info]: build info [Mac OS X][clang 12.0.0][32 bit][noasm] 10bit
x265 [info]: using cpu capabilities: none!
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads

I did find it humorous that the cpu capabilities line with --x265 ends with an exclamation point.

lisamelton commented 3 years ago

@weaverm Thanks for testing! 👍

Yes, using --x265 will always be the slowest option. 🤷‍♂️

Thor263 commented 3 years ago

I'm getting an M1 mini next week, so I've been following this with some interest too. It appears that x265 hasn't been optimized for M1 yet -- see issue #578 at x265_git. However, looking at that issue, it appears that Handbrake has implemented much more complete x265 optimizations, so hopefully that will be coming back to main x265 soon.

clunkclunk commented 3 years ago

I just did a transcode with other-transcode on my M1 Mac Mini, and it went well. Installed ffmpeg and mkvtoolnix via homebrew (which is recently installed, and mostly working for ARM/M1). mpv wouldn't install because it's not ready for arm, but I didn't bother to dig in further.

Used --hevc and it appears to be leveraging the VTEncoder, though I only have 8 bit files to test, rather than 10 bit. Speeds seem to be around 200-225fps for a 1080p x264 source.

Oh and these M1 Macs are amazing. This is a base model, and I'm also simultaneously using Slack, Mail, Chrome and a Google Meet in Chrome with zero feelings of lag or stuttering, and no fan noise.

Skywalka1976 commented 3 years ago

You can use Homebrew's x86 version by using

arch -x86_64

As a prefix before all commands to make everything work. And yes the transcode speeds are amazing on the M1.

Botts85 commented 3 years ago

I've been playing with the M1 and Handbrake / ff-works quite a bit. It's lightning fast, it crushes my i9 iMac at x265 hardware encodes at 1080p and 4K.

It looks like the M1's videotoolbox support was tuned for SSIM. Irrespective of bitrate, it beat x265 slow and 9th gen QuickSync based VTB on SSIM.

However, it loses in VMAF against both QuickSync based VTB and X265 slow.

Please ignore the color explosion. Teal is M1 hardware. Green is i9 iMac hardware encoding.

Source data is here: https://docs.google.com/spreadsheets/d/1-lq8mA1z5srjBLJysdiUEN90HaCkuW7g_FPyyCJVenQ/edit?usp=sharing

This is the Extended Scenes from Thor: Dark World blu-ray. (18mbps):

Screen Shot 2021-02-14 at 3 56 20 PM

This is the Captain America - Winter Soldier trailer from blu-ray (18mbps). Note that the M1 crushed it at SSIM despite losing VMAF.

Screen Shot 2021-02-14 at 3 59 21 PM
lisamelton commented 3 years ago

@Botts85 Interesting. Thanks for posting these numbers.

Personally, I don't put much stock in PSNR, SSIM or VMAF being any kind of absolute measure of quality, objective or not. Those metrics are, of course, useful, but nothing beats a pair of Mark I™ eyeballs for assessing quality. 😄

Especially when similar target bitrates can produce significant differences between encoders. And things can get very different once you mix in presets.

So my question is, which one looks better to you?

Botts85 commented 3 years ago

The Mark 1 eyeball agrees with VMAF in this case. X265 slow still wins to my eyes. Then Quick Sync VideoToolbox, then M1's VideoToolbox.

It was a sad day when I tested M1 hoping it'd bring Apple's "magic" to my encode life and noticed it was worse than my Intel Mac for quality.

I haven't tested M1's CQ H265 encoding too much yet, but it doesn't seem massively better.

For "production" work, I'd still use software. For streaming though, M1's VTB is insanely fast. The challenge I'm looking at is when backing up my bluray library, is it worth the time of X265 slow, or do I just throw extra bitrate at it and use VTB.

I'm actually trying to figure out a way to test if the M1's video quality impacts Final Cut Pro's workflow in any notable way versus a Mac with Quick Sync, or just CPU encoding.

lisamelton commented 3 years ago

@Botts85 As far as backing up your Blu-ray library goes, a remux (not a transcoding) or your original rip is your best bet. Transcoding is really for making things smaller and more portable. But when you have enough storage space, decent bandwidth and a Plex server, then viewing your originals is preferred.

Seriously, investing in more storage will be cheaper in the long run than waiting for x265 to deliver you the "perfect" transcode.

And if you don't have enough storage to leverage that strategy, then I would just use a hardware transcoder, even the M1's VT technology, to get smaller and portable versions of your videos. They'll be "good enough," especially if you can get 10-bit HEVC output.

My two cents. 😄

Botts85 commented 3 years ago

Totally fair point on that. I think I've got 72TB of storage in my rack right now, but was hoping to avoid too much expansion.

I'd been running Jellyfin for on the fly transcode when over WAN. So far, I've liked it more than Plex and it's free, but you'd need to set up your own VPN or reverse proxy for it.

I can always re-rip, so good point with just using the M1 for now, then later on when storage permits go either to remux'd versions, or maybe rip to AV1 if we ever get a faster encoder for it.

RusselProuse34 commented 3 years ago

As per this comment from the MacRumors forums, it appears that someone was able to get 4K content encoded in 10-bit using VT in Compressor back in December. I'm not an expert by any means, but if Compressor can do it is it possible that ffmpeg could also add this functionality?

lisamelton commented 3 years ago

@RusselProuse34 It's unclear since Compressor is Apple's proprietary software. Which means they have access to APIs and mechanisms that FFmpeg might not.

Botts85 commented 3 years ago

@RusselProuse34 Handbrake's newest nightly will do 10-bit H265 (non-HDR IIRC) VideoToolbox encoding.

VideoToolbox lists the following support for color primaries: ITU_R_709_2 EBU_3213 SMPTE_C ITU_R_2020 P3_D65

And the following profiles: HEVC_Main_AutoLevel HEVC_Main10_AutoLevel HEVC_MainStill_AutoLevel HEVC_Main444_AutoLevel HEVC_Main44410_AutoLevel HEVC_Main42210_AutoLevel HEVC_Monochrome12_AutoLevel HEVC_Monochrome_AutoLevel

lisamelton commented 3 years ago

@Botts85 Thanks for the information. 👍

Botts85 commented 2 years ago

I got a chance to play with an M1 Pro today. It's definitely fast with VideoToolbox, but sadly, the encoder for H265 looks identical to the M1.

Aka, it is eclipsed by 9th gen QuickSync and NVENC.

I need to do some more testing, but it seems like the "CQ" setting that Handbrake has for M1 VTB is just a slider for a set of different CBRs. Take a sample video file in 4K, encode one copy at 4K CQ38, then encode a second copy at 1080P CQ38 and it'll likely wind up exactly the same bit rate. That's unfortunate.

lisamelton commented 2 years ago

@Botts85 Thanks for the update! That is... disappointing but predictable, I suppose.

tylercheung commented 2 years ago

I would agree with your eyeballs. Maybe placebo but I am noticing more pixelation especially on older films with out-of-focus lens bokeh and shadows with videotoolbox on an M1 and an M1 max… i’ve re-transcoded on my linux box w nvenc and a 1080 for now. I haven’t figured out how to set things up on my windows box yet, was going to try chocolatey to install ffmpeg next

lisamelton commented 2 years ago

@tylercheung Rather than use Chocolately to install FFmpeg, try this:

https://github.com/donmelton/other_video_transcoding/wiki/Windows

tylercheung commented 2 years ago

@tylercheung Rather than use Chocolately to install FFmpeg, try this:

https://github.com/donmelton/other_video_transcoding/wiki/Windows

Ah...kind of a tangent but in troubleshooting my windows install, perusing my windows path, I discovered a third party video conferencing app ("Intouch Health/Teladoc") used for work) had its own conflicting ffmpeg install tucked away somewhere...go figure!

sammoth commented 1 year ago

You can use the constant quality mode of videotoolbox encoders (HEVC and h264) on Apple Silicon from ffmpeg using -q:v and I do not find that it just translates to a target bitrate - encoding the same clip at 4k and 2k with the same q value produces completely different filesizes.

lisamelton commented 1 year ago

@sammoth Yep. I would expect a constant quality mode to do just that, i.e. produce variable-sized output.