Usually, yeah, it's noticeably worse than using individual loads and stores as it adds around a dozen cycles of latency. This is usually enough for the load to light up hot in a sampling profile. It's possible for that extra latency to be hidden, but then in that case the extra loads/stores wouldn't be an issue either.

+1

This seems like an area where LLMs would actually be extremely useful. You can manually mark comments as irrelevant. Why can't GitHub use AI to do it automatically? Or to highlight the "resolution" comment automatically? On very big issues it can take a non-trivial amount of time just to find out what the outcome was.

I mean yea, i just view rust as the quality-oriented spear of western development.

Rust is absolutely an improvement over C in every way.

Out of curiosity just clang or gcc as well?

    typedef struct { uint16_t a, b; } pair;

    int eq_copy(pair a, pair b) {
        return a.a == b.a && a.b == b.b;
    }
    int eq_ref(pair *a, pair *b) {
        return a->a == b->a && a->b == b->b;
    }

    eq_ref:
        movzx   edx, WORD PTR [rsi]
        xor     eax, eax
        cmp     WORD PTR [rdi], dx
        je      .L9
        ret
    .L9:
        movzx   eax, WORD PTR [rsi+2]
        cmp     WORD PTR [rdi+2], ax
        sete    al
        movzx   eax, al
        ret

This is so true. They got a following and like many who suddenly get some sort of niche fame, they reoriented to serve the audience and it hasn't improved anything. The greatest damage that popularity does to many is that they lose themselves in the desire to hold on to it.

I'm not saying that they don't do great work, but that twitter thread (https://x.com/ffmpeg/status/1924137645988356437) is pretty obnoxious and reads like they are upset they didn't get funding. It's entirely possible that they are just difficult to work with and funders _don't_ want to fund them.

"Because substantial amounts of human and financial resources go into these rust ports that are inferior to the originals. Orders of magnitude more resources than the originals which remain extremely understaffed/underfunded." -- https://x.com/FFmpeg/status/1924149949949775980

"... And we get this instead: <xz backdoor subtweet>" -- https://x.com/FFmpeg/status/1924153020352225790

"They [rust ports] are superior in the same way Esperanto is also superior to English." -- https://x.com/FFmpeg/status/1924154854051557494

It's kind of sad to see that snarky attitude. Clearly the corporate sponsors _want_ a more secure decoder. Maybe they should try and work _with_ the system instead of wasting energy on sarcasm on Twitter?

You’re right; this happens a lot.

The SQlite folks, half of Linux, and other maintainers have encountered the same kind of zealotry. Dealing with language supremacism is annoying and I don’t blame ffmpeg for venting.

In fact, I’d even say that twitter thread is informative, because it demonstrates out how big tech fund their own pet projects over the actual maintainers.

There is not much, unless you're working with AV1. rav1d is the alternative there but you've got to trade off some performance for security gains.

ffmpeg is a monopoly in the space which means that you either take the exact set of tradeoffs they offer, or... well, you have no alternatives, so take it.

Of course the alternatives are never going to be as good as the originals until they've had more effort put into them. It took _years_ until the Rust gzip/zip libraries surpassed the C ones while being more secure overall.

More than enough are exploitable for this to be a problem.

It varies. New public APIs or language features may take a long time, but changes to internals and missed optimizations can be fixed in days or weeks, in both LLVM and Rust.

If you are doing something like a GIF or an MJPEG, sure. If you are doing forwards and backwards keyframes with a variable amount of deltas in between, with motion estimation, with grain generation, you start having a very dynamic amount of state. Granted, encoders are more complex than decoders in some of this. But still you might need to decode between 1 and N frames to get the frame you want, and you don't know how much memory it will consume once it is decoded unless you decode it into bitmaps (at 4k that would be over 8MB per frame which very quickly runs out of memory for you if you want any sort of frame buffer present).

I suspect the future of video compression will also include frame generation, like what is currently being done for video games. Essentially you have let's say 12 fps video but your video card can fill in the intermediate frames via what is basically generative AI so you get 120 fps output with smooth motion. I imagine that will never be something that WUFFS is best suited for.

> codecs are basically designed to minimize the amount of 'work' being done from frame to frame

But to do that they have to keep state and do computations on that state. If you've got frame 47 being a P frame, that means you need frame 46 to decode it correctly. Or frame 47 might be a B frame in which case you need frame 46 and possibly also frame 48 - which means you're having to unpack frames "ahead" of yourself and then keep them around for the next decode.

I think that all counts as "dynamic state"?

Maybe you're not familiar with how long GOP encoding works with IPB frames? If all frames were I-frames, maybe what you're thinking might work. Everything you need is in the one frame to be able to describe every single pixel in that frame. Once you start using P-frames, you have to hold on to data from the I-frame to decode the P-frame. With B-frames, you might need data from frames not yet decoded as the are bi-direction references.

compression algorithms can get very clever in recursive ways

Hey maybe we can discuss why I'm being downvoted? This is a technical discussion and I'm contributing. If you disagree then say why. I'm not stating anything as fact that isn't fact. I am getting downvoted for asking a question.

Do your part: name your kids "ffmpeg" and "vp-IX"!

Thx for taking the time and glad to hear you enjoyed it. I keep being impressed by people like Cory Doctorow that can express nearly every sentence they write extremely succinctly and on the point. That's something I aspire to, so hopefully next time I'm a little better at it :)

Yes that sounds spot on.

I don't know instagram, but I would expect any provider to be handle almost any container/codec/resolution combination going (they likely use ffmpeg underneath) and generate their different output formats at different bitrates for different playback devices.

Either instagram won't accept av1 (seems unlikely) or they just haven't processed it yet as you infer.

I'd love to know why your commend is greyed out.

Isn't that expected? 4K Blurays only encode up to like 128Mbps, which is 16MB/s. 100MB/s seems like complete overkill.

VP9 works for live streaming/real time conferencing too.

AV1 is the outright winner in terms of compression efficiency (until you start comparing against VVC/H.266¹), with the advantage being even starker at high resolutions. The only current notable downside of AV1 is that client hardware support isn't yet universal.

¹ https://www.mdpi.com/2079-9292/13/5/953

Sponsored by FBI probably :p