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

51–60 of 186 posts

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

#51

Post by ctoth »

never_inline wrote: post #42
ctoth wrote: post #36

Earlier quoted context omitted.

> Because refactoring requires understanding, which LLMs completely lack. Interesting. Here's a sample question I just asked the AI: We are working on a React mapping application. I am going to give you two components from this application. Our goal is to extract functionality to deduplicate code We can make a single base component, extract code to hooks, or any other strategy which you think is appropriate Here is t…

Eliminating duplication and cleaning code is a different type of refactoring than supporting concurrency, which is much much harder. Cleaning up code also follows some well established patterns, performance work is much less pattern-y. Codebases like FFMPEG are one of the kind. I bet you need 10 or 100 times more understanding than the react thing you mentioned above. One day maybe AI can do it, but it probably won't…

Ah, we're having some classic goalpost moving!

> Because refactoring requires understanding, which LLMs completely lack.

> Cleaning up code also follows some well established patterns, performance work is much less pattern-y.

Just as writing shitty react apps follow patterns, low-level performance and concurrency work also follow patterns. See [0] for a sample.

> I bet you need 10 or 100 times more understanding

Okay, so a 10 or 100 times larger model? Sounds like something we'll have next year, and certainly within a decade.

> One day maybe AI can do it, but it probably won't be LLM. It would be something which can understand symbols and math.

You do understand that the reason some of the earlier GPTs had trouble with symbols and math was the tokenization scheme, completely separate from how they work in general, right?

[0]: C++ Concurrency in Action: Practical Multithreading 1st Edition https://www.amazon.com/C-Concurrency-Action-Practical-Multit...

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

#52

Post by rocqua »

thfuran wrote: post #9
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.

Yeah, it's nuts to think that.

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.

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

#53

Post by banana_giraffe »

sanitycheck wrote: post #11
bsdpufferfish wrote: post #5

If I'm operating a cloud service like Netflix, then I'm already running thousands of ffmpeg processes on each machine. In other words, it's already a multi-core job.

Curious, what would that many ffmpeg processes be doing at Netflix? I assume new VOD content gets encoded once per format, and the amount of new content added per day is not gigantic. Agree with the general premise, of course, if I've got 10 different videos encoding at once then I don't need additional efficiency because the CPU's already maxed out.

It's been reported in the past that Netflix encodes 120 different variants of each video they have [1] for different bitrates and different device's needs.

And that was years ago, I wouldn't be surprised to learn it's a bigger number now.

[1] https://news.ycombinator.com/item?id=4946275

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

#54

Post by dylan604 »

m3kw9 wrote: post #17
dylan604 wrote: post #15

Earlier quoted context omitted.

FFMPEG does so much more than just video encoding. I use ffmpeg all day every day, and only a fraction of the time do I actually make a video.

Like what do you do?

ffmpeg can produce an amazing amount of analysis

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

#55

Post by kcbanner »

ctoth wrote: post #51
never_inline wrote: post #42

Earlier quoted context omitted.

Eliminating duplication and cleaning code is a different type of refactoring than supporting concurrency, which is much much harder. Cleaning up code also follows some well established patterns, performance work is much less pattern-y. Codebases like FFMPEG are one of the kind. I bet you need 10 or 100 times more understanding than the react thing you mentioned above. One day maybe AI can do it, but it probably won't…

Ah, we're having some classic goalpost moving! > Because refactoring requires understanding, which LLMs completely lack. > Cleaning up code also follows some well established patterns, performance work is much less pattern-y. Just as writing shitty react apps follow patterns, low-level performance and concurrency work also follow patterns. See [0] for a sample. > I bet you need 10 or 100 times more understanding Okay…

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

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

#56

Post by Hello71 »

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 pipelines because gop/chunk threading isn't massively better than intra-frame threading.

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

#57

Post by naikrovek »

brucethemoose2 wrote: post #8

Meanwhile, I've been enjoying threaded filter processing in VapourSynth for nearly a decade. Not that this isn't great. Its fantastic. But TBH its not really going to change my workflow of VapourSynth preprocessing + av1an encoding for "quality" video encodes.

I don't understand why you would want to piggyback on this story to say this.

are people just itching for reasons to dive into show & tell or to wax poetic about how they have solved the problem for years? I really don't understand people at all, because I don't understand why people do this. and I'm sure I've done it, too.

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

#58

Post by cudder »

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…

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!

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

#59

Post by seeknotfind »

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…

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.

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

#60

Post by atrus »

not_the_fda wrote: post #33
mrintegrity wrote: post #21

Earlier quoted context omitted.

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…

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.
Post reply on HN