Hacker News Reader

Comment by wyattblue | Hacker News Reader

This may eventually be better for people working in the cloud. Shame there's no apple silicon support.

(See also Cisco's openh264, which supports decoding)

Don't all Apple Silicon devices have extremely good (in both speed and feature coverage) H.264 hardware decoders already?

Yes. If there's a hole in macOS's VideoToolbox support it's the middling quality of their hardware-accelerated encoder, so people who want high quality encodes will generally use x264/x265 for that.

Yes, H.264 is in hardware on Apple Silicon.

But as a software decoder which is specifically made to not use hardware APIs for decoding, I am not sure why they skipped ARM64 on non-linux platforms.

But why go through the trouble of building and shipping a software decoder for a platform you know has no devices which need such a thing? On the other hand it's not too hard to find ARM64 Linux devices which need an efficient software decoder (either because there isn't a hardware one at all, there one that is there is limited in feature support, or the one that is there is hybrid but written so poorly a good software decoder is more efficient).

What if there were some intelligence to test-for and auto-switch to support extensions when available? If you specify it manually it already supports x64-specific instructions via the ${VARIANTS} env var.

https://github.com/tvlabs/edge264/blob/5a3c19fc0ccacb03f9841...

Out of curiosity, what does “in hardware” actually mean in this context? Is it pure vhdl? Microcode that leverages special primitives? Something else?

In the case of Apple AVD, it's a multi-stage system with a bunch of special primitives, orchestrated by a Cortex-M3 with firmware. Codec-specific frontends emit IR which a less specialized backend can execute.

https://github.com/eiln/avd

This really heavily depends on the device, though. There are all sorts of "hardware" video decoders ranging from fairly generic vector coprocessors running firmware to "pure" HDL/VLSI level implementations. Usually on more modern or advanced hardware you'll see more and more become more general purpose, since a lot of the later stages can be shared across codecs, saving area vs. a pure hardware implementation.

Do we have hardware H.265 or other more current codec support in hardware on anything?

Yes, almost everything out there supports at least H.265, H.264, VP9, and AV1 in hardware.

I don't see why this would support Linux arm64 but not macOS.

Anyway, you can just use libavcodec, which is faster (because of frame based multithreading) and doesn't operate on the mistaken belief that it's a good idea to use SIMD intrinsics.

Care to ellaborate? Not shitting on libavcodec here, I would also guess it just beats a new project on raw performance.

But according to the repo, this project also uses both slice and frame multi-threading (as does ffmpeg, with all the tradeoffs).

And SIMD usage is basically table-stakes, and libavcodec uses SIMD all over the place?

> But according to the repo, this project also uses both slice and frame multi-threading (as does ffmpeg, with all the tradeoffs).

Oh, I missed that since it doesn't have a separate file. In that case they're likely very similar performance-wise. H.264 wasn't well-designed for CPUs because the arithmetic coding could've been done better, but it's not that challenging these days.

> And SIMD usage is basically table-stakes, and libavcodec uses SIMD all over the place?

SIMD _intrinsics_. libavcodec doesn't write DSP functions in assembly for historical reasons - it's because it's just better! It's faster, just as maintainable, at least as easy to read and write, and not any less portable (since it already isn't portable…). They're basically a poor way to generate the code you want, interfere with other optimizations like autovectorization, and you might as well write your own code generator instead.

The downsides are it's harder to debug and analyzers like ASan don't work.

That's a good catch. I did not notice there weren't using any assembly at all. I assumed they wanted to add NEON before advertising Apple Silicon but I guess not.

Also, hi FFmpeg twitter.

I had no issues getting this to build, pass tests, and render a video on ARM64 Mac OS X.

Reply on news.ycombinator.com