Live data from Hacker News

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

phoronix.com

181–186 of 186 posts

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

#181

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.

Okaaay, and if I'm not operating a cloud service like Netflix, and I'm not running thousands of ffmpeg processes? In other words, it's not already a multi-core job?

This kind of multithreaded code introduces great complexity. So who wants to pay the cost for that tradeoff? Since most performance sensitive ffmpeg uses are cloud services, I don't see the benefit.

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

#182

Earlier quoted context omitted.

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…

> Indeed it was a major point of pride among Go enthusiasts that computers could not play it well

It's typical for enthusiast of anything to believe their area is special. To be able to judge how feasible besting humans is a question for computer scientists / engineers anyway. You need some knowledge of Go for sure, but don't actually have to be a master Go player.

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

Maybe it was a surprise for you, but I was familiar with the pre-AlphaGo state of the art, and it was always clear it's just a technical problem. There's no fundamental difference between a game like Go and Chess, it's only the parameters which differ, where Go's space is exponentially larger.

> Others, like the inherent difficulty in constructing an evaluation function, seemed intractable

The branching factor is what makes the evaluation function difficult in Go and is therefore again a technical problem.

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

This is a non-argument, betting markets are not rational.

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

#183
post #20

When I stream 4k from my laptop ffmpeg gets very intense about cpu usage to the point fans are constantly at high speed and it's distracting. I hope this helps in some way. I have a fairly decent specces mid-tier laptop.

I believe ffmpeg can be compiled to support the GPU, if your laptop has one. It works at least for CUDA-enabled GPUs ( https://docs.nvidia.com/video-technologies/video-codec-sdk/1... ) Talk with ChatGPT about it and see if you can do it.

My comment got quite downvoted. I blame ChatGPT for teaching me about whatever I said that was wrong.

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

#185

Earlier quoted context omitted.

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.

Thanks Capt Obvious

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

#186

Earlier quoted context omitted.

Hardware threads are not the same as software threads.

Thanks Capt Obvious

I don't understand your comment then. I'm not trying to be sarcastic or anything.

Using either processes or threads should bear no difference in terms of die space. In a die there are cores, each core with dual streams of computation, that are interleaved to compensate for memory latency, so while one waits the other computes and vice versa. It doesn't have anything to do with processes or (virtual) threads, which are software constructs.

Post reply on HN