That's why one of the most common ways of dealing with tech debt is allocating time for it within other sometimes completely irrelevant stories. For management you can just say "oh I take a bit of extra time for tech debt there", if they're known to take that well, and if not, you don't say anything at all. The ones who you should definitely tell all the details is your team lead / collegues. Like, "oh this is a mess I'll take some time for refactoring/optimizing this next planning", which often implies you allocate this time within other stories.

I was under the impression that libsvtav1 was still underdeveloped, but turns out the ffmpeg documentation for it was just lacking. Looks to be pretty good quality and even supports two-pass (which the documentation doesn't mention).

Thank you 🙏

As a more concrete example for people out there. C is an example of a "high level" programming language. In C you might write a statement like "int x = 3;".

"Assembly language" is a "human readable" representation of the instructions that are actually executed by your CPUs*. There is a different assembly language for each processor or processor family. Your desktop or laptop computer with an Intel or AMD chip, and in all likelihood execute the "x86_64" language. Meanwhile, your phone is probably on the "AArch64" language. An example of assembly language is "mov rax, #3", which loads register rax with the value 3. Notice that we have dispensed with the niceties of variable names.

Assembly language is "assembled" into the "machine language.". To do this, the "human readable" mnemonics like "mov" are replaced with numbers called opcodes. The sequence of opcodes and arguments, like the number 3, are called the "machine code", because the CPU silicon can read those numbers from memory and follow the instructions with no additional translation steps*.

*Microcode throws a wrench here. Folks like Intel realized they could run things more efficiently if they translated each machine language instruction into simpler microcode instructions onboard the chip.

Even if true, SIMD is doing the heavy lifting here. Probably followed by the fact that almost any rewrite of a code base will result in performance improvements due to the nature of being more familiar with the domain and where the bottle necks are. I would be surprised if the assembly was responsible for more then about 1% of the gains here. So why highlight the fact assembly was used here? It is just missleading. If you want to show how ASM is so much better you need a much better example then this. For all we know the use of ASM could have made things slower and harder to develop. There is just no details at all as to why ASM is beneficial here except some author seems to love it.