(See also Cisco's openh264, which supports decoding)
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.
https://github.com/tvlabs/edge264/blob/5a3c19fc0ccacb03f9841...
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.
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.
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?
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.
Also, hi FFmpeg twitter.
Access to left/top macroblock values is done with direct offsets in memory instead of copying their values to a buffer beforehand.
I made use of this technique too, so I think it's not particularly novel nor non-obvious. The performance-sensitivity of video decoding necessarily means avoiding any extraneous data movement whenever possible.
Also worth noting: H.264 patents have already expired in most of the world: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...
ebb_earl_co•4mo ago
CachyOS is a whole distro compiled with these flags, if possible, which is appealing.
[0] https://github.com/tvlabs/edge264#compiling-and-testing
kimixa•4mo ago
[0] https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning....
kg•4mo ago
kimixa•4mo ago
So it does have some limitations like not being inlined, same as any other external function.
eru•4mo ago
You have bigger binaries, but the logistics are simplified compared to shipping multiple binaries and you should get the same speed as multiple binaries with fully inlined code.
Since they don't seem to be doing that, my question is: what's the caveat I'm missing? (Or are the bigger binaries enough of a caveat by themselves?)
mikepurvis•4mo ago
astrange•4mo ago
It can be useful to duplicate the entire code for 8-bit vs 10-bit pixels because that does affect nearly everything.
amluto•4mo ago
A relocatable call within the same DSO can be a PC-relative relocation, which is not a relocation at all when you load the DSO and ends up as a plain PC-relative branch or call.
kimixa•4mo ago
Ideally you should just multiversion the topmost exported symbol, everything below that should either directly inlined, or, as the architecture variant is known statically by the compiler, variants and a direct call generated. I know at least GCC can do this variant generation for things like constant propagation over static function boundaries, so /assume/ it can do the same for other optimization variants like this, but admittedly haven't checked.
URScrewed13•4mo ago
pjmlp•4mo ago
nnevatie•4mo ago
Sesse__•4mo ago
nnevatie•4mo ago
Sesse__•4mo ago
nnevatie•4mo ago
error: inlining failed in call to 'always_inline' 'float _mm512_reduce_add_ps(__m512)': target specific option mismatch
Sesse__•4mo ago