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 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.