kierank

Then you and your security friends will create lots of FUD about FFmpeg being "insecure" with lots of red and the word "critical" everywhere.

FFmpeg is developed almost entirely by volunteers. We have no "customers".

We in FFmpeg need all the instructions and we often need to do register allocations by hand.

I have tried with Grok3 and Claude. They both seem to have an understanding of the algorithms and data patterns which is more than I expected but then just guess a solution that's often nonsensical.

I am the author of these lessons.

Ask me anything.

It's crazy that you have to use this custom "embedded" tooling when the vendor should be implementing support in vanilla Linux distros.

This is premature optimisation. The bus bandwidth and latency needed to get a few Mbps of compressed video to the PC is microscopic. It's completely unnecessary to lock yourself into NVIDIA just to create some UDP packets.

Because latency is a distribution and these photos are often selected at the best-case P0 end of all the encode/decode processes whereas actually what matters is the worst case P99.

A proper implementation will make sure the worst-case latency is accounted for and not cherry-pick the best case.

Backstage feeds go in uncompressed via HD-SDI and have a latency of lines (microseconds to single digit milliseconds). Totally different ballgame.

I wrote a blog post about how numbers like "30ms latency" are thrown around called "How to lie about latency": https://www.obe.tv/how-to-lie-about-latency/

It's left as an exercise to the reader which methods of lying are being used in this case.

I actually saw numerous issues with segments being one frame out of sync with the rest.

Imagine Ethernet was designed like this and you had to implement mandatory congestion control and other cruft. The layer of the stack that has knowledge of the content should be implementing the congestion control.

I'm sure SAP reads mastodon and will be right on it

The Firefox PDF reader is atrocious. Opening any non-trivial PDF causes it to crash even on an i9 with 32GB of RAM. I guess this is because it's rendering the pdf to HTML.

VVC is marked as experimental as fuzzing continues on it.

(author of the post on X)

We cannot tell volunteers to not do something (i.e help Microsoft) in the same way we cannot tell volunteers to do something.

(author of the post on X)

To clarify, Microsoft didn't offer a one-time payment to fix any bug. A volunteer explained for free that a command line option had changed between FFmpeg versions.

Microsoft offered a one-off payment instead of a support contract.

Hi, this is a high priority ticket and FFmpeg is used in highly visible products all over the world. We have developers working for free while trillion dollar corporations want urgent help from volunteers. Please help,

/s

v210_planar_pack_8_c: 2298.5

v210_planar_pack_8_ssse3: 402.5

v210_planar_pack_8_avx: 413.0

v210_planar_pack_8_avx2: 206.0

v210_planar_pack_8_avx512: 193.0

v210_planar_pack_8_avx512icl: 100.0

23x speedup. The compiler isn't going to come up with some of the trickery to make this function 23x faster.

800% is nothing.

x86inc.asm takes care of the different OS ABI differences for you.

FFmpeg code by definition is not "basic SIMD code". And it supports numerous other compilers other than LLVM.

That "20 minute patch" will need to be maintained for decades to come in FFmpeg, long after a standalone JPEG-XL library. Potentially centuries as archives like the Library of Congress are storing FFmpeg. So that's why it's done in assembly, so it's maintainable with the rest of the code.

This isn't a surprise from an organisation that opened a ticket on the FFmpeg tracker asking volunteers for free "high priority" support:

https://trac.ffmpeg.org/ticket/10341#comment:4

> It is impossible for the audio to drift ahead of or behind the video, regardless of the video framerate or audio samplerate.

How is this "impossible" if the video clock and audio clock are on different physical devices?

Exactly, just pretending to ignore the 80% of the market that isn't critical or safety of life and saying it's not true "embedded industry" (or True Scotsman) is just ignoring the reality.

Exactly as you see in this comment chain, engineers at startups get fed up of the embedded industry being stuck in the 1980s (long sales process with many meetings and salespeople, custom blobs galore, custom distros, long lead times, high prices etc).

You cannot iterate quickly based on the glacial embedded industry. I am amazed by the way we are quoted 3 month wait for a shipment (even pre-covid) without anyone batting an eyelid.

You're a bit like the satellite industry looking at Starlink and saying "well it's not true satellite, doesn't have X, Y and Z" and pointing to a few specialist applications where legacy satellite is highly suited and ignoring the masses of business applications that have moved to Starlink.

The incredible part is the RPi sucks less than all the other commercial embedded SBCs such that it's had huge industry uptake purely by being the least worst.

The state of the embedded industry continues to amaze me.

The tweet links to the mailing list which is the official source of the patchset (you can choose "Next in Thread" to continue).

Do you actually implement all permutations of vpternlogd?

The lightweight macro layer in ffmpeg takes care of v prefixes.

In FFmpeg, x264 and dav1d there are many different examples of code that couldn't be written in intrinsics or other abstraction layer.

https://twitter.com/FFmpeg/status/1705543447245988245?t=Ul9e...

The paper suggests FFmpeg uses intrinsics which is not correct.

There have been many SIMD abstraction layers created in the past but none of them will beat the raw speed of handwritten assembly. Try and implement something like vpternlogd in one of these abstraction layers.