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

141–150 of 186 posts

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

#141

Post by MightyBuzzard »

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…

It's not the codecs that were multithreaded in this release. Pretty much all modern codecs are already multithreaded. What they decided to parallelize is ffmpeg itself. You know, the filter graphs and such. They didn't do anything to the codecs themselves.

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

#142

Post by dataangel »

mrintegrity wrote: post #21
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.

Parent post is getting down voted to oblivion but it seems a reasonable belief for someone who is not highly engaged with AI. I have only the vaguest understanding of how it works (and it's probably wrong) and to my layman mind it also seems like a totally fair assumption, based on experience as a user and the constant flood of news. Please explain why the suggestion that a future AI / sufficiently advanced LLM could…

AI is not very good at single threaded code which is widely regarded as much easier. The breathless demos don't generalize well when you truly test on data not in the training set, it's just that most people don't come up with good tests because they take something from the internet, which is the training set. But the code most people need to write is to do tasks that are bespoke to individual businesses/science-experiments/etc not popular CS problems that there are 1000 tutorials online for. When you get into those areas it becomes apparent really quickly that the AI only gets the "vibes" of what code should look like, it doesn't have any mechanistic understanding.

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

#143

Post by dataangel »

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…

If you ask GPT to refactor a single threaded program much smaller than the context window that is truly out of sample into a multithreaded program, its often going to fail. GPT has trouble understanding bit masks in single threaded code, let alone multiple threads.

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

#144

Post by dataangel »

nolist_policy wrote: post #136
rocqua wrote: post #52

Earlier quoted context omitted.

Refactoring is really rather well defined. It's " just transformations that are invariant w.r.t. the outcome". The reason they are hard to automate is that 'invariant w.r.t. the outcome' is a lot more lenient than most semantic models van handle. But this kind of well-defined task with a slight amount of nuance (and decently checkable) seems pretty well-suited to an LLM.

At least for the linux kernel, qemu and other large c projects, this is a solved problem with coccinelle[1]. Compared to AI, it has the added benefit of not doing incorrect changes and/or hallucinating stuff or promt injections or ... I guess you could use AI to help create a coccinelle semantic patch. [1] https://en.wikipedia.org/wiki/Coccinelle_(software)

The part coccinelle does is the part GPT is good at, the problem is neither of them actually reason about the code

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

#145

Post by _joel »

asylteltine wrote: post #113
shp0ngle wrote: post #99

Earlier quoted context omitted.

It seems ffmpeg uses the mailing list patch way of doing "PRs", which is... well it is what it is. It doesn't help me understand the process unless I just go through all the mailing list archives, I guess.

Ugh why? That is so old school

Like the linux kernel?

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

#146

Post by dbrueck »

Hello71 wrote: post #56
kevincox wrote: post #46

I've always wondered if better multi-core performance can come from processing different keyframe segments separately. IIUC all current encoders that support parallelism work by multiple threads working on the same frame at the same time. Often times the frame is split into regions and each thread focuses on a specific region of the frame. This approach can have a (usually small) quality/efficiency cost and requires…

your idea also doesn't work with live streaming, and may also not work with inter-frame filters (depending on implementation). nonetheless, this exists already with those limitations: av1an and I believe vapoursynth work more or less the way you describe, except you don't actually need to load every chunk into memory, only the current frames. as I understand, this isn't a major priority for mainstream encoding pipeli…

Actually, not only does it work with live streaming, it's not an uncommon approach in a number of live streaming implementations*. To be clear, I'm not talking about low latency stuff like interactive chat, but e.g. live sports.

It's one of several reasons why live streams of this type are often 10-30 seconds behind live.

* Of course it also depends on where in the pipeline they hook in - some take the feed directly, in which case every frame is essentially a key frame.

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

#147

Post by bigbillheck »

smabie wrote: post #109
bigbillheck wrote: post #92

Earlier quoted context omitted.

> Haven't you tried refactoring with gpt-4 yet? I most certainly have not. At work, I do greenfield development in a specialized problem domain, and I would not trust a model (or, for that matter, a junior developer) to do any kind of refactor in an acceptable manner. (That aside, there's no way I'm goingto expose company code to any sort of outside party without the approval of upper management). At home, I program…

Oh yea your work is far too sophisticated for a llm, got it

Some of us do actual creative work, yes.

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

#148

Post by Const-me »

Intel Core Duo CPU was released in 2006. By then it was obvious computationally intensive programs need multithreading, these Unix-style processes are no longer adequate.

I wonder why did it took so long for FFmpeg?

BTW, MS Media foundation is a functional equivalent of FFmpeg. It was released as a part of Windows Vista in 2006, and is heavily multithreaded by design.

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

#150

Post by nerpderp82 »

ElijahLynn wrote: post #106
nerpderp82 wrote: post #34

Earlier quoted context omitted.

https://www.youtube.com/watch?v=9kaIXkImCAM

That was one of the funniest things I've seen in a while!!!! I had to stop drinking my decaf for fear of spitting it all over my computer I was laughing out loud so much! (ps: and no, it's not Rick Astley/Never Gonna Give You Up)

The artfully inserted, corrupted predicted frames was :chefskiss:
Post reply on HN