Live data from Hacker News

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

phoronix.com

81–90 of 186 posts

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

#81

Earlier quoted context omitted.

> But it sounds great for the remaining 99.99%. I believe the vast majority of ffmpeg usages are web services, or one off encodings.

Well, this feature is awesome for one-off encoding by a home user. Subjectively, me compressing my holiday video is much more important than Netflix re-compressing a million of them.

I use ffmpeg all the time, so this change is much appreciated. Well not really that often, but when I do encode video/audio it's generally with ffmpeg.

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

#82

Earlier quoted context omitted.

I'm dying.

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

"Do you know ffmpeg supports OCR? I haven't found the command yet, but it does support it."

This is probably 80% of my experience with ffmpeg, to be honest, but the other 20% is invaluable enough anyway.

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

#83
post #26
post #17

Earlier quoted context omitted.

Like what do you do?

One can use it instead of cat to display text files. Easy syntax to remember. ffmpeg -v quiet -f data -i file.txt -map 0:0 -c text -f data -

Ah now I can replace all my useless uses of cat with ffmpeg

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

#84

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.

Latency is still valuable. For example YouTube (which IIRC uses ffmpeg) often takes hours to do transcodes. This is likely somewhat due to scheduling but assuming that they can get the same result doing 4x threads for 1/4 of the time they would prefer that as each job finishes faster. The only real question is at what efficiency cost the latency benefit stops being worth it.

I think that if you're operating at the scale of Google using a single-threaded ffmpeg will finish your jobs in less time.

If you have a queue of 100k videos to process and a cluster of 100 cores, assigning a video to each core as it becomes available is the most efficient way to process them, because your skipping the thread joining time.

Anytime there is a queue of jobs, assigning the next job in the queue to the next free core is always going to be faster than assigning the next job to multiple cores.

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

#86

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.

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.

Vapoursynth can be used for image processing too (albeit more clumsily with variable size input), and its also a great way to hook into PyTorch.

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

#87
post #44

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'm guessing from context that VapourSynth is a frame-server in the vein of avisynth? If so, does it run on Linux? Avisynth was the single biggest thing I missed when moving to Linux about 20 years ago. [edit] found the docs; it's available on Linux[1]. I'm definitely looking into it tonight because it can't be worse than writing ffmpeg CLI filtergraphs! 1: http://www.vapoursynth.com/doc/installation.html#linux-insta…

Yep, and its so much better than ffmpeg CLI that its not even funny.

This is a pretty good (but not comprehensive) db of the filters: https://vsdb.top/

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

#88

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.

Not gonna lie, I think VapourSynth has been flying under the radar for far too long, and is an awesome largely unused alternative to ffmpeg filter chains in certain cases. I don't see any harm in piggybacking on an ffmpeg story to bring it up, especially if readers find it useful.

It's been threaded since its inception, so it seems somewhat topical.

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

#89

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.

Vapoursynth can be used for image processing too (albeit more clumsily with variable size input), and its also a great way to hook into PyTorch.

Does it can fix broken files?

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

#90

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.

Latency is still valuable. For example YouTube (which IIRC uses ffmpeg) often takes hours to do transcodes. This is likely somewhat due to scheduling but assuming that they can get the same result doing 4x threads for 1/4 of the time they would prefer that as each job finishes faster. The only real question is at what efficiency cost the latency benefit stops being worth it.

YouTube does not use ffmpeg, at the scale at which they operate it would be too slow / expensive.

They use custom hardware just for encoding.

fyi they have to transcode over 500h of videos per minute. So multiple that by all the formats they support.

They operate at an insane scale, Netflix looks like a garage project for comparison.

Post reply on HN