Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

phoronix.com

Post reply on HN
Print view View original

171–180 of 186 posts

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#171

Post by account42 »

astrange wrote: post #102
cudder wrote: post #58

Earlier quoted context omitted.

I know next to nothing about video encoders, and in my naive mind I absolutely thought that parallelism would work just like you suggested it should. It sounds absolutely wild to me that they're splitting single frames into multiple segments. Merging work from different threads for every single frame sounds wasteful somehow. But I guess it works, if that's how everybody does it. TIL!

Most people concerned about encoding performance are doing livestreaming and so they can't accept any additional latency. Splitting a frame into independent segments (called "slices") doesn't add latency / can even reduce it, and it recovers from data corruption a bit better, so that's usually done at the cost of some compression efficiency.

> Most people concerned about encoding performance are doing livestreaming

What make you think that? I very much care about encoding performance (for a fixed quality level) for offline use.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#172

Post by account42 »

keehun wrote: post #61
seeknotfind wrote: post #59

Earlier quoted context omitted.

Video codecs often encode the delta from the previous frame, and because this delta is often small, it's efficient to do it this way. If each thread needed to process the frame separately, you would need to make significant changes to the codec, and I hypothesize it would cause the video stream to be bigger in size.

The parent comment referred to "keyframes" instead of just "frames". Keyframes—unlike normal frames—encode the full image. That is done in case the "delta" you mentioned could be dropped in a stream ending up with strange artifacts in the resulting video output. Keyframes are where the codec gets to press "reset".

> That is done in case the "delta" you mentioned could be dropped in a stream ending up with strange artifacts in the resulting video output.

Also to be able to seek anywhere in the steam without decoding all previous frames.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#173

Post by tetris11 »

naikrovek wrote: post #97
tetris11 wrote: post #77

Earlier quoted context omitted.

...in this case, multi-threading. In other cases; AI workflows that others commercialize, a new type system in a language that already exists in another, a new sampling algorithm that has already existed by another name for decades, a permaculture innovation that farmers have been using for aeons, the list goes on...

just say "feature". language is for communicating. don't impede that communication by using unnecessary terms.

I was trying to generalise a concept so I used a placeholder word. I feel that most people got that.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#174

Post by LtdJorge »

chrismsimpson wrote: post #160
bane wrote: post #132

A theory about this that may also affect other older solid software: the assumptions made on where to optimally "split" a problem for multi-threading/processing has likely changed over time. It wasn't that long ago that reading, processing, and rendering the contents of a single image took a noticeable amount of time. But both hardware and software techniques have gotten significantly faster. What may have made sense…

I assume 1 process with 2 threads takes up less space on the die than 2 processes, both single threaded. If this is true, a threaded solution will always have the edge on performance, even as everything scales ad infinitum.

Hardware threads are not the same as software threads.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#175

Post by bigbillheck »

ctoth wrote: post #23
motoboi wrote: post #3

It’s nuts to think that in the near future LLM will be able to do that refactoring in seconds. All we need is enough context window.

I see that you got some responses from people who may have not even used gpt-4 as a coding assistant, but I absolutely agree with you. A larger context window, a framework like Aider, and slightly-better tooling so the AI can do renames and other high-level actions without having to provide the entire changeset as patches, and tests. Lots of tests. Then you can just run the migration 15 times, pick from the one which…

> so the AI can do renames

I do renames in a big window with my IDE.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#176

Post by bigbillheck »

ctoth wrote: post #73
kcbanner wrote: post #55

Earlier quoted context omitted.

> Because refactoring requires understanding, which LLMs completely lack. It's obvious from context here that the refactoring that was mentioned was specifically around concurrency, not simply cleaning up code.

So if I show you an LLM implementing concurrency, will you concede the point? Is this your true objection? https://chat.openai.com/share/7c41f59a-c21c-4abd-876c-c95647...

Did you learn anything from that exercise? Are you a better programmer now for having seen that solution? Because if not, this seems like a great way for getting the fabled "one year of experience, twenty times"

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#177

Post by Shish2k »

kuba-orlik wrote: post #169

I routinely use ffmpeg CLI and I see in top that multiple cores are engaged in the processing. Hadn't it been multi-threaded for years? What exactly is changing?

My interested-lay-person understanding: Previously it would read a chunk of file, then decode it, then apply filters, then run multi-threaded encoding, then write a chunk of file.

Now it can read the next chunk of file while decoding a chunk while applying filters while running multi-threaded encoding while writing the previous chunk.

I expect this will be a big help for complicated setups (applying multiple filters, rendering to multiple outputs with different codecs), but probably not much change for a simple 1-input 1-output transcode.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#178

Post by apetresc »

The_Colonel wrote: post #93
atrus wrote: post #60

Earlier quoted context omitted.

Chess requires understanding, which computers lack. Go requires understanding, which computers lack. X requires Y which AI technology today lacks. AI is a constantly moving goalpost it seems.

It was always clear that games like chess or go can be played by computers well, even with simple algorithms, because they were completely formalized. The only issue was with performance / finding more efficient algorithms. That's very different from code which (perhaps surprisingly) isn't well formalized. The goals are often vague and it's difficult to figure out what is intentional and what incidental behavior (esp…

> It was always clear that games like chess or go can be played by computers well

As someone who was deeply involved in the Go scene since the early 2000s let me emphatically assure you it was not at all clear. Indeed it was a major point of pride among Go enthusiasts that computers could not play it well, for various reasons (some, like the branching factor, one could potentially grant that advances in hardware and software could solve for eventually. Others, like the inherent difficulty in constructing an evaluation function, seemed intractable).

Betting markets at the time of the AlphaGo match still had favorable odds for Sedol, even with the knowledge that Google was super-confident baked in.

It is extreme hindsight-bias of exactly the type the grandparent was talking about to suggest that obviously everybody knew all along that Go was very beatable by "non-real AI".

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#179

Post by arp242 »

atrus wrote: post #60
not_the_fda wrote: post #33

Earlier quoted context omitted.

Because refactoring requires understanding, which LLMs completely lack.

Chess requires understanding, which computers lack. Go requires understanding, which computers lack. X requires Y which AI technology today lacks. AI is a constantly moving goalpost it seems.

> Chess requires understanding

Actually it doesn't, as demonstrated by the fact that people have made fairly decent chess implementations in 1K lines of code and things like that. Chess is comparatively easy because it has well-defined rules and well-defined concepts of "good" and "bad". Refactoring something to be multi-threaded is incomparably more complex and any comparison to this is just pointless.

Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades

#180

Post by arp242 »

ctoth wrote: post #73
kcbanner wrote: post #55

Earlier quoted context omitted.

> Because refactoring requires understanding, which LLMs completely lack. It's obvious from context here that the refactoring that was mentioned was specifically around concurrency, not simply cleaning up code.

So if I show you an LLM implementing concurrency, will you concede the point? Is this your true objection? https://chat.openai.com/share/7c41f59a-c21c-4abd-876c-c95647...

That ... didn't even refactor the code. It just returned some generic Python concurrency methods which vaguely fit the posted code.
Post reply on HN