19 ms·
FFmpeg Assembly Language Lessons
- cr125rider 1y agoI can’t imagine the scale that FFMPEG operates at. A small improvement has to be thousands and thousands of hours of compute saved. Insanely useful project.
- zahlman 1y agoIt'd be nice, though, to have a proper API (in the traditional sense, not SaaS) instead of having to figure out these command lines in what's practically its own programming language....
- codys 1y agoFFMpeg does have an API. It ships a few libraries (libavcodec, libavformat, and others) which expose a C api that is used in the ffmpeg command line tool. They publish doxygen generated documentation for the APIs, available here: https://ffmpeg.org/doxygen/trunk/ https://ffmpeg.org/doxygen/trunk/
- zahlman 1y agoDon't know how I overlooked that, thanks. Maybe because the one Python wrapper I know about is generating command lines and making subprocess calls.
- Wowfunhappy 1y agoThey're relatively low level APIs. Great if you're a C developer, but for most things you'd do in python just calling the command line probably does make more sense.
- f1shy 1y agoIt could even make sense in C. In some circumstances, I wouldn’t feel bad for cutting that corner.
- 1718627440 1y agoYes, that's what I did some time ago. I already want concurrency and isolation, so why not let the OS do that. Also I don't need to manage resources, when ffmpeg already does that.
- kaladin-jasnah 1y agoAs someone that used these APIs in C, they were not very well-documented nor intuitive, and oftentimes segfaulted when you messed up, instead of returning errors—I suppose the validation checks sacrifice performance for correctness, which is undesirable. Either way, dealing with this is not fun. Such is the life of a C developer, I suppose....
- javier2 1y agoIf you are processing user data, the subprocess approach makes it easier to handle bogus or corrupt data. If something is off, you can just kill the subprocess. If something is wrong with the linked C api, it can be harder to handle predictably.
- astrange 1y agoAlso because you can apply stricter sandboxing/jail/containerization to the process.
- ansk 1y agoFor future reference, if you want proper python bindings for ffmpeg* you should use pyav. * To be more precise, these are bindings for the libav* libraries that underlie ffmpeg
- xxpor 1y agoI get why the CLI is so complicated, but I will say AI has been great at figuring out what I need to run given an English language input. It's been one of the highest value uses of AI for me.
- emseetech 1y agoTheir commitment to performance is a beautiful thing. Imagine all projects were similarly committed.
- byteknight 1y agoSeems so easy! You only need the entire world even tangentially related to video to rely solely on your project for a task and you too can have all the developers you need to work on performance!
- ackfoobar 1y agoI seem to recall that they lamented on twitter the low amount of (monetary or code) contribution they got, despite how heavily they are used.
- lo_zamoyski 1y agoNo one is forcing them to produce code for free. There is something toxic about giving things away for free with the ulterior motive of getting money for it.
- imchillyb 1y agoIt’s market manipulation, with the understanding that free beats every other metric. Once the competition fails, the value extraction process can begin. This is where the toxicity of our city begins to manifest. Once there is no competition remaining we can begin eating seeds as a pastime activity. The toxicity of our city; our city. How do you own the world? Disorder. Disorder…
- godelski 1y agoThey have some fire tweets, especially when people say they write things from scratch or boast about how much money they make with ffmpeg wrappers https://x.com/FFmpeg/status/1775178803129602500 https://x.com/FFmpeg/status/1775178803129602500 https://x.com/FFmpeg/status/1856078171017281691 https://x.com/FFmpeg/status/1856078171017281691 https://x.com/FFmpeg/status/1950227075576823817 https://x.com/FFmpeg/status/1950227075576823817 Oh, and here's one making fun of HN comments. Hi ffmpeg :) https://x.com/FFmpeg/status/1947076489880486131 https://x.com/FFmpeg/status/1947076489880486131
- dlcarrier 1y agoWeb browsers and Electron far more than make up for it, in wasted resources.
- harry8 1y agoThey run on machines that are designed to have unused computer capacity. Desktops, laptops, tablets, phones. Responsiveness is the key. Ffmpeg runs on a load of server farms for all your favourite streaming services and the bajillion more you’ve never heard of. Saving compute there saves machines and power. Your point is well taken but there is a distinction that matters some.
- kasabali 1y agoSaving compute in consumer facing devices saves machines and power, too.
- harry8 1y agoYeah power. But less so. My phone or laptop battery lasts shorter between charges. I’m not buying more phones or laptops to take up the slack. Powering the screen dominates battery usage between charges. It isn’t nothing, sure. I’m in no way defending electron. It’s just not taking back the power and machines saved by ffmpeg. Which is a happy accident that’s nice. Restart your electron hate all you want.
- kasabali 1y ago> I’m not buying more phones or laptops to take up the slack I don't know about you, but everyone else sure does. Minimum requirements (even though not told explicitly anymore) has been constantly increasing.
- harry8 1y agoNo way. Apple stopping support for security upgrades is the issue requiring a phone to stop being used, by you or the 2nd hand recipient. Same issue for the various android vendors. That sure won't change if your phone uses a little less battery decoding movies and your battery use will still be dominated by screen use.
- KwanEsq 1y agoPrior discussion 2025-02-22, 222 comments: https://news.ycombinator.com/item?id=43140614 https://news.ycombinator.com/item?id=43140614
- sylware 1y agoThere is serious abuse of nasm macro-preprocessor. Going to be tough to move away to another assembler.
- oguz-ismail 1y agoWhere? There's very little code in those lessons
- pveierland 1y agoThe lessons reference `cglobal` in `x86inc.asm`: https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/x86inc.asm#L820 https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/x86/x...
- loeg 1y agoWhy move away?
- saagarjha 1y agoNot everyone wants to use nasm. Sometimes all you have is the clang integrated assembler :(
- sylware 1y agoYou could use GAS, FASM2, or write an ffmpeg specific one: writting a real-life assembler is orders of magnitude simpler than writting a real-life compiler... Usually that implementation complexity is very dependent on the macro pre-precessor one. This is a matter of exit cost: for instance look at linux bitkeeper->git exit.
- sylware 1y agoYep, look at nasm SDK, horrible, with tons of perl generators, etc, etc. From the worst.
- loeg 1y ago> Not everyone wants to use nasm. Yeah, but I'd really only be concerned with what the ffmpeg developers want here.
- ngcc_hk 1y agoMore interesting than I thought it could be. A domain specific tutorial is so much better.
- Alifatisk 1y agoHow do they make these assembly instructions portable across different cpus?
- KeplerBoy 1y agoThey don't. It's just x86-64.
- ahartmetz 1y agoThe lessons yes, but the repo contains assembly for the 5-6 architectures in wide use in consumer hardware today. Separate files of course. https://github.com/FFmpeg/FFmpeg/tree/master/libavcodec https://github.com/FFmpeg/FFmpeg/tree/master/libavcodec
- KeplerBoy 1y agoYeah, sure. I was specifically referring to the tutorials. Ffmpeg needs to run everywhere, although I believe they are more concerned about data center hardware than consumer hardware. So probably also stuff like power pc.
- duskwuff 1y agoTo a first approximation, the only architectures where people really care about ffmpeg performance (anymore) are x86_64 and arm64. Everything else is of minimal importance - the few assembly routines for other architectures were probably written more for fun than for practical reasons.
- CannotCarrot 1y agoI think there's a generic C fallback, which can also serve as a baseline. But for the big (targeted) architectures, there one handwritten assembly version per arch.
- faluzure 1y ago
- NullCascade 1y agoWhat is the actual process of identifying hotspots caused suboptimal compiler generated assembly? Would it ever make sense to write handwritten compiler intermediate representation like LLVM IR instead of architecture-specific assembly?
- deleted 1y ago[deleted]
- duped 1y agoNormally you spin up a tool like vtune or uprof to analyze your benchmark hotspots at the ISA level. No idea about tools like that for ARM. > Would it ever make sense to write handwritten compiler intermediate representation like LLVM IR instead of architecture-specific assembly? IME, not really. I've done a fair bit of hand-written assembly and it exclusively comes up when dealing with architecture-specific problems - for everything else you can just write C (unless you hit one of the edge cases where C semantics don't allow you to express something in C, but those are rare). For example: C and C++ compilers are really, really good at writing optimized code in general. Where they tend to be worse are things like vectorized code which requires you to redesign algorithms such that they can use fast vector instructions, and even then, you'll have to resort to compiler intrinsics to use the instructions at all, and even then, compiler intrinsics can lead to some bad codegen. So your code winds up being non-portable, looks like assembly, and has some overhead just because of what the compiler emits (and can't optimize). So you wind up just writing it in asm anyway, and get smarter about things the compiler worries about like register allocation and out-of-order instructions. But the real problem once you get into this domain is that you simply cannot tell at a glance whether hand written assembly is "better" (insert your metric for "better here) than what the compiler emits. You must measure and benchmark, and those benchmarks have to be meaningful.
- Sesse__ 1y ago> Normally you spin up a tool like vtune or uprof to analyze your benchmark hotspots at the ISA level. No idea about tools like that for ARM. perf is included with the Linux kernel, and works with a fair amount of architectures (including Arm).
- nisten 1y ago[flagged]
- abhisek 1y agoLove it. Thanks for taking the time to write this. Hope it will encourage more folks to contribute.
- commandlinefan 1y agoShame this doesn't start with a quick introduction to running the examples with an actual assembler like NASM.
- SilentM68 1y agoWhy not include the required or targeted math lessons needed for the FFmpeg Assembly Lessons in the GitHub repository? It'd be easier for people to get started if everything was in one place :)
- snickerbockers 1y agoNTA but if the assumption is that the reader has only a basic understanding of C programming and wants to contribute to a video codec there is a lot of ground that needs to be covered just to get to how the cooley/tukey algorithm works and even that's just the basic fundamentals.
- byryan 1y agoI read the repo more as "go through this if you want to have a greater understanding of how things work on a lower level inside your computer". In other words, presumably it's not only intended for people who want to contribute to a video codec/other parts of ffmpeg. But I'm also NTA, so could be wrong.
- WhitneyLand 1y agoI was expecting to read pearls of wisdom gleaned from all the hard work done on the project, but I’m not really getting how this relates to ffmpeg. The few chapters I saw seemed to be pretty generic intro to assembly language type stuff.
- saagarjha 1y agoIt's intended to get people up to speed on assembly so they can contribute to FFmpeg.
- Validark 1y agoI would be interested in more examples where "assembly is faster than intrinsics". I.e., when the compiler screws up. I generally write Zig code with the expectation of a specific sequence of instructions being emitted, and I usually get it via the high level wrappers in std.simd + a few llvm intrinsics. If those fail I'll use inline assembly to force a particular instruction. On extremely rare occasions I'll rely on auto-vectorization, if it's good and I want it to fall back on scalar on less sophisticated CPU targets (although sometimes it's the compiler that lacks sophistication). Aside from the glaring holes in the VPTERNLOG finder, I feel that instruction selection is generally good enough that I can get whatever I want. The bigger issue is instruction ordering and register allocation. On code where the compiler effectively has to lower serially-dependent small snippets independently, I think the compiler does a great job. However, when it comes to massive amounts of open code I'm shocked at how silly the decisions are that the compiler makes. I see super trivial optimizations available at a glance. Things like spilling x and y to memory, just so it can read them both in to do an AND, and spill it again. Constant re-use is unfortunately super easy to break: Often just changing the type in the IR makes it look different to the compiler. It also seems unable to merge partially poisoned (undefined) constants with other constants that are the same in all the defined portions. Even when you write the code in such a way where you use the same constant twice to get around the issue, it will give you two separate constants instead. I hope we can fix these sorts of things in compilers. This is just my experience. Let me know if I left anything out.
- ykonstant 1y ago>There are two flavours of x86 assembly syntax that you’ll see online: AT&T and Intel. AT&T Syntax is older and harder to read compared to Intel syntax. So we will use Intel syntax. God bless you, ffmpeg.
- rob44 1y ago[flagged]