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.
FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades
81–90 of 186 posts
Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades
#82Earlier quoted context omitted.
I'm dying.
https://www.youtube.com/watch?v=9kaIXkImCAM
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
#83Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades
#84If 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.
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
#85Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades
#86Meanwhile, 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.
Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades
#87Meanwhile, 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…
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
#88Meanwhile, 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.
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
#89Earlier 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.
Re: FFmpeg lands CLI multi-threading as its "most complex refactoring" in decades
#90If 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.
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.