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

161–170 of 186 posts

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

#161

Post by mappu »

aidenn0 wrote: post #44
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'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…

20 years ago, the best feature of avisynth was running random plugin dlls downloaded from doom9, none with source code and all running on an XP Administrator account.

The frameserver is one thing, but an ecosystem of (trustable! open source!) plugins is harder to replicate.

At least we don't need deinterlacers so badly any more, though.

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

#163

Post by brucethemoose2 »

Thaxll wrote: post #89
brucethemoose2 wrote: post #86

Earlier quoted context omitted.

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?

It reads image sequences with imagemagick or ffmpeg, but in place repair is not its thing, no.

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

#164

Post by brucethemoose2 »

mappu wrote: post #161
aidenn0 wrote: post #44

Earlier quoted context omitted.

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…

20 years ago, the best feature of avisynth was running random plugin dlls downloaded from doom9, none with source code and all running on an XP Administrator account. The frameserver is one thing, but an ecosystem of (trustable! open source!) plugins is harder to replicate. At least we don't need deinterlacers so badly any more, though.

They have pretty much all been ported, and much more! VapourSynth can do a lot more than AviSynth can.

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

#165

Post by maxlin »

vore wrote: post #158
danudey wrote: post #82

Earlier quoted context omitted.

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

I thought this was a joke, but it really exists! https://ffmpeg.org/ffmpeg-filters.html#ocr

Lol what. I have a bot that processes ~50 videos a day, burning in translated whisper-generated subtitles. It also translates images using Tesseract, then overlaying texts in-place. I once thought of exporting frames as images to maybe do this for video too, I actually did not even start to think FFMPEG would have tesseract support on top of everything.

Later on though I've realized the quality of tesseract's OCR on arbitrary media is often quite bad. Google translates detection and replacement is so much ahead my current image system I'd think I would just somehow reutilize that for my app, either thru public API or browser emulation ...

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

#166

Post by astrange »

canucker2016 wrote: post #154
astrange wrote: post #153

Earlier quoted context omitted.

> You're letting the video codec make all the decisions for bitrate allocation. > Netflix tries to optimize the encoding parameters per shot/scene. That's the problem - if the encoding parameters need to be varied per scene, it means you've defined the wrong parameters. Using a fixed H264 QP is not on the rate-distortion frontier, so don't encode at constant QP then. That's why x264 has a different fixed quality sett…

What about VP9? And any of the other codecs that Netflix uses (I'll assume AV1 is one they currently use)?

It's not a codec-specific concept, so it should be portable to any encoder. x265 and AV1 should have similar things, not sure about VP9 as I think it's too old and On2 were, as I said, not that competent.

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

#167

Post by jaquesy »

qrush wrote: post #2

Is there a recording of this talk from VDD@Dublin? Can't easily find it on the author's site or here https://www.videolan.org/videolan/events/vdd23/ Update: Found here! https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221s

As someone who has only used ffmpeg for very trivial scenarios this was really interesting to listen to. It's nice knowing it's getting a proper refactor (not that I knew much of its internals until now)

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

#168

Post by bagels »

Thaxll wrote: post #90
kevincox wrote: post #37

Earlier quoted context omitted.

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.

Facebook does, and contributes to ffmpeg.

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

#170

Post by never_inline »

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…

Ok bro I am not the parent commenter who set the goalpost.

Let's see how your smooth talking LLM is going to do with things that are not web development or leetcode medium, for which so much stuff has been written. All the best.

Post reply on HN