rbultje

That sounds nice in theory, but it seems obvious to me there is a major discrepancy between who is burdened with this responsibility, and who benefits from the result. Given many of these contributors are unpaid volunteers, maybe the infrastructure provider needs to secure FFmpeg in another way, for example by restricting codecs or by running it in a container?

> Lets see AI take the AV2 spec and Dav1d code and try to make a working high performance AV2 decoder.

That sounds like one of these high-risk, high-reward things that are great for people / projects / companies who have nothing to lose, but is not a great baseline strategy for an established market player. AV2 is here with support from aomedia and its members. AV2 will be used, and we need a production-grade decoder regardless of where AI is at, so it makes much more conservative business sense to use established approaches (language: c/asm, devteam: ffmpeg/dav1d) as a starting point. While that's happening, we can dabble in AI and other risky stuff and see if it helps. If so, great, and if not, nothing lost.

dav2d author here - the 5x number is just where we currently are, it's not the theoretical limit. We're hopeful that a significant amount of the increase we observe in dav2d relative to dav1d is in math code, which should be easier to optimize using hand-written assembly or other algorithmic optimizations. If that holds true, the practical slowdown once everything has been optimized may be substantially less, possibly 2x.

I try but it feels like whack-a-mole to me.

> Can't they be deducted the same way as accountants or other functions?

No.

It didn't become law (no 60 votes in senate), after Schumer sat on it for 6 (!) months. And there were earlier attempts to fix this, for example at the end of 2022 using budget/reconciliation - like what the Reps are doing here; but that was blocked by progressives because of "bad optics".

If the issue is with general tax compliance of large multinationals, then congress should have done something about that. This tax rule has hit small software businesses particularly badly, so much so that it'll practically strengthen the quasi-monopoly of established players.

LLCs pay 37%, not 21%. Plus state plus local. This can reach 50% in high-tax areas like CA or NY.

One of the reasons small businesses have been hit so hard with this is because for then (when incorporated as LLCs), their tax rate is 37% + state + local. I live in NYC and my LLC has a combined tax rate of 50%.

The opposite of what you're saying is "perfection is the enemy of progress", so let's move past them. I'm asking for more than "this is not the way". What is the way? How will we do this? This is critical, and we've failed to do anything since early 2022. Democrats are clearly not at all interested. My (Dem) congressman responded directly to my enquiry with "fixing section174 just wouldn't be good optics". I agree republicans can't be taken very seriously either if OB3 is the highest of highs. But we all want this fixed. So: how?

> We'll correct the ills of the 2017 administration in time

How? We have - at times - had democrats in charge since 2017 and they did nothing to resolve this either. We appear to be waiting for flying pigs.

> This isn't changing if it is taxed or not.

This is untrue. The rule is not about taxation, but deductions/expenses. If your expenses cover most revenue, you owe little in taxes. With this rule, a particular type of expense (software engineering salaries) is no longer deductible from revenue to calculate taxable income over which taxes are owed. So you might previously owe no taxes, but now you do. The deduction might carry over to the next few years and eventually (after 6 years) you will reach the same point - assuming your salaries don't go up and your business doesn't grow. The remainder in deductions will be returned after the business stops employing software engineers. I'm not sure why anyone would want the tax code to incentivize a business outcome that all of us would consider failure.

You're confusing corporate vs personal taxes. The salaries businesses pay are meant to be deductible business expenses. The business only pays taxes over the profit after these expenses are deducted from their revenue. The person receiving the salary still owes personal taxes over the income.

We don't talk about this enough. International R&D is not offshoring of call-centers to India. International R&D is the IP for the next generation of global communication standards being owned by US-based or foreign corporations, because international (e.g. Canadian, European) standards experts/developers become un-affordable for US-based corporations and are forced to work for our "adversaries" instead. Crazy.

The way this is "fixed" right now, every five years we need another round of republican government to make things great again. If only enough democrats cared to fix this.

Large companies always find a way to not pay taxes. It's the little guys that end up paying (a lot!) more, to the extend that it cripples and kills them. But transformative innovation happens with the little guys. As a result, this tax change cements monopolies for megacorps. They will be fine and still pay nothing.

That part is not so weird, you didn't pay all salaries on January 1st. But amortizing salaries in general is ridiculous.

This is a weird take. Employees are supposed to be business expenses, that's the core idea of running a business: profit = revenue - expenses, where expenses are personnel / materials, and pay taxes over profit. Since the R&D change, businesses can't fully expense employees and need to pay (business) taxes over their salaries. Employees - of course - still pay personal taxes also (as was always the case).

Maybe related - I noticed that hotel room prices in New York dropped, they used to start at $350/night just a few months ago, now you can get them for $150/night.

There's also section-174, which big corporations don't care about but kills smaller businesses left and right.

> I sure hope a broader exploration precedes micro-optimizing register allocation and calling conventions.

It should be obvious that both are pursued independently whenever it makes sense. The idea that one should precede the other or is more important than the other is simply untrue.

Binary size was a concern, so excessive inlining was undesirable.

And don't forget that any asm-optimized variant always has a C fallback for generic platforms lacking a hand-optimized variant which is also used to verify the asm-optimized variant using checkasm. This might not be linked into your binary/library (the linker eliminated it because it's never used), but the code exists nonetheless.

> If it's so heavy in assembly, the fact that ffmpeg works on my Mac seems like a miracle. Is it ported by hand?

Not ported, but rather re-implemented. So: yes.

A bit more detail: during build, on x86, the FFmpeg binary would include hand-written AVX2 (and SSSE3, and AVX512, etc.) implementations of CPU-intensive functions, and on Arm, the FFmpeg binary would include hand-written Neon implementations (and a bunch of extensions; e.g. dotprod) instead.

At runtime (when you start the FFmpeg binary), FFmpeg "asks" the CPU what instruction sets it supports. Each component (decoder, encoder, etc.) - when used - will then set function pointers (for CPU-intensive tasks) which are initialized to a C version, and these are updated to the Neon or AVX2 version depending on what's included in the build and supported by this specific device.

So in practice, all CPU-intensive tasks for components in use will run hand-written Neon code for you, and hand-written AVX2 for me. For people on obscure devices, it will run the regular C fallback.

Sadly no mention of Section-174, which is a contributing factor. As a reminder, TCJA (2017) amended Section-174 (with a 5-year deferral) to require amortization over 5 (domestic) or 15 (foreign) years of all R&E expenses, and included all software development under R&E. This went into effect in 2022. This causes unexpected employer tax bills over money that has been spent on employee salaries and over which these employees are also taxed.

There have been repeated promises by congress to fix it but these efforts have failed so far. The latest attempt, HR7024, received overwhelming support in the house but stalled in the senate over objections by Idaho senator Mike Crapo and was later voted down (mostly by senate Rs, but also notable by a handful of progressive Ds).

It still surprises me every day that industry insiders discuss our current-era tech downturn and attribute it to a poor investment environment due to increased interest rates, yet nobody discusses the devastating impact of Section-174.

People don't appreciate how expensive health insurance in the US is. A high-quality PPO plan for a whole family on the open market can cost $4k/month.

For me, the critical take-home message is:

"the issues around tens of thousands of unpaid developers writing the core of the world’s most critical infrastructure nowadays."

We need to take opensource software sustainability much more seriously.

Blog author (and dav1d/ffmpeg dev) here. My talk at VDD 2023 (https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=9290s) did a comparison like the ones asked above. I compared an intrinsics implementation of the AV1 inverse transform with the hand-written assembly one found in dav1d. I analyzed the compiler-generated version (from intrinsics) versus the hand-written one in terms of instruction count (and cycle runtime, too) for different types of things a compiler does (data loads, stack spills, constant loading, actual multiply/add math, addition of result to predictor, etc.). Conclusion: modern compilers still can't do what we can do by hand, the difference is up to 2x - this is a huge difference. It's partially because compilers are not as clever as everyone likes to think, but also because humans are more clever and can choose to violate ABI rules if it's helpful, which a compiler cannot do. Is this hard? Yes. But at some scale, this is worth it. dav1d/FFmpeg are examples of such scale.

> Who does this benefit in a zero-sum competition scenario, assuming that everybody is affected.

Foreign-run software companies not affected by this law, big companies with deep pockets that don't need to fear upstart competition, and other industries that are not R&E but can enjoy the lower tax rates from TCJA that were paid for with this revenue.

What if a court interprets fair use as a human-only right, just like it did for copyright?