Live data from Hacker News

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

phoronix.com

91–100 of 186 posts

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

#91
post #62

So does this mean that FFMPEG will be able to use multiple cores with all the included codecs? I'm using FFMPEG to encode MP3 with LAME for an audio hosting service and it would be great to improve encode times for long files.

Doubtful. Many codecs like MP3 aren't well suited to efficient multi-threaded encoding.

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

#92
post #45

Earlier quoted context omitted.

Why on earth would you possibly think that?

I'm quite confused by the answers I got from this thread. Haven't you tried refactoring with gpt-4 yet?

> 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 for fun and self-improvement, and a big part of both is thinking hard about problems. Why would I want to wreck that with asking a model to do it for me?

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

#93
post #60

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.

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. with imperative code).

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

#94
post #17

Earlier quoted context omitted.

Like what do you do?

I've used it for video and audio concatenation of laserdisc game segments, transcoding audio clips for gamedev, programmatically generating GIFs of automatically generated video clips from tests in a CI pipeline, ripping songs and audio clips from YouTube videos to ogg/mp3, creating GIFs from burst-shot and time-lapse photography (and decimating them), excerpting clips from a video without re-encoding, and compressin…

Sounds like you already have a process for most of this, but I found https://github.com/mifi/editly to be incredibly helpful to run ffmpeg and make my little time lapse video. Could be useful for others

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

#95
post #69

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…

There's already software that does this: https://github.com/master-of-zen/Av1an Encoding this way should indeed improve quality slightly. Whether that is actually noticeable/measurable... I'm not sure.

ffmpeg and x265 allow you to do this too. frame-threads=1 will use 1 thread per frame addressing the issue OP mentioned, without big perf penalty, in contrary to 'pools' switch which sets the threads to be used for encoding.

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

#97

Earlier quoted context omitted.

not gonna define FEAT, then? ok.

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

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

#98
I don't know anything about ffmpeg codebase, but I just wonder... how would I go about doing this _slowly_ without completely doing a giant commit that changes everything?

The presentation says it's 700 commits. Was that a separate branch? Or was it slowly merged back to the project?

Well I can look at github I guess

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

#99

I don't know anything about ffmpeg codebase, but I just wonder... how would I go about doing this _slowly_ without completely doing a giant commit that changes everything? The presentation says it's 700 commits. Was that a separate branch? Or was it slowly merged back to the project? Well I can look at github I guess

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.

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

#100
post #45

Earlier quoted context omitted.

I'm quite confused by the answers I got from this thread. Haven't you tried refactoring with gpt-4 yet?

> 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, I understand.

What if you have an idea and you tell the computer to implement it and then thoroughly check the code?

About the self-improvement part, I suppose you don't operate your graphics card yourself, but delegate it to your driver.

The LLM is just another tool.

Post reply on HN