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

21–30 of 186 posts

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

#21

Post by mrintegrity »

motoboi wrote: post #3

It’s nuts to think that in the near future LLM will be able to do that refactoring in seconds. All we need is enough context window.

Parent post is getting down voted to oblivion but it seems a reasonable belief for someone who is not highly engaged with AI. I have only the vaguest understanding of how it works (and it's probably wrong) and to my layman mind it also seems like a totally fair assumption, based on experience as a user and the constant flood of news. Please explain why the suggestion that a future AI / sufficiently advanced LLM could refactor a complex codebase is so preposterous.

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

#22

Post by The_Colonel »

bsdpufferfish wrote: post #16
The_Colonel wrote: post #13

Earlier quoted context omitted.

I guess it's irrelevant for Netflix then*. But it sounds great for the remaining 99.99%. * I would be very surprised if Netflix even uses vanilla ffmpeg

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

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

#23

Post by ctoth »

motoboi wrote: post #3

It’s nuts to think that in the near future LLM will be able to do that refactoring in seconds. All we need is enough context window.

I see that you got some responses from people who may have not even used gpt-4 as a coding assistant, but I absolutely agree with you. A larger context window, a framework like Aider, and slightly-better tooling so the AI can do renames and other high-level actions without having to provide the entire changeset as patches, and tests. Lots of tests. Then you can just run the migration 15 times, pick from the one which passes all the tests... run another integration pass to merge ideas from the other runs, rinse and repeat. Of course the outer loops will themselves be automated.

The trick to this is continuous iteration and feedback. It's remarkable how far I've gotten with GPT using these simple primitives and I know I'm not the only one.

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

#25

Post by j1elo »

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.

Interesting! I'm among today's lucky 10,000 in learning for the first time about VapourSynth.

How come it only has 4 measly entries in HN, and none got any traction. I've posted a new entry, just for the curiosity of others.

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

#26

Post by andoma »

m3kw9 wrote: post #17
dylan604 wrote: post #15

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.

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 -

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

#27

Post by polonbike »

m3kw9 wrote: post #17
dylan604 wrote: post #15

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.

Like what do you do?

Beside video conversion/compression ? Sound extraction or processing, image processing, video casting or streaming, anything related to image/multimedia format, basically

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

#28

Post by DonHopkins »

andoma wrote: post #26
m3kw9 wrote: 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 -

Good thing it's now multi-threaded so it can process all those command line arguments in parallel!

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

#29

Post by sanitycheck »

The_Colonel wrote: post #19
sanitycheck wrote: post #11

Earlier quoted context omitted.

Curious, what would that many ffmpeg processes be doing at Netflix? I assume new VOD content gets encoded once per format, and the amount of new content added per day is not gigantic. Agree with the general premise, of course, if I've got 10 different videos encoding at once then I don't need additional efficiency because the CPU's already maxed out.

I assume they re-compress for each resolution / format, quite possibly they also have different bitrate levels per resolution. Potentially even variants tweaked for certain classes of device (in cases this is not already covered by combination of format/resolution/bitrate). I would also assume they re-compress with new advances in video processing (things like HDR, improved compression). Also, their devs likely want…

They'll be doing VBR encodes to DASH, HLS & (I guess still) MSS which covers the resolutions & formats... DRM will be what prevents high res content from working on some "less-trusted" platforms so the same encodes should work.

(Plus a couple more "legacy" encodes with PIFF instead of CENC for ancient devices, probably.)

New tech advances, sure, they probably do re-encode everything sometimes - even knocking a few MB off the size of a movie saves a measurable amount of $$ at that scale. But are there frequent enough tech advances to do that more than a couple of times a year..? The amount of difficult testing (every TV model group from the past 10 years, or something) required for an encode change is horrible. I'm sure they have better automation than anyone else, but I'm guessing it's still somewhat of a nightmare.

Youtube, OTOH, I really can imagine having thousands of concurrent ffmpeg processes.

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

#30

Post by ctoth »

bigbillheck wrote: post #12
motoboi wrote: post #3

It’s nuts to think that in the near future LLM will be able to do that refactoring in seconds. All we need is enough context window.

Why on earth would you possibly think that?

Just as your human intelligence lead to you writing the same darn comment as another human above you, AI can often write the same code as a human would, without having to even bring creativity into it! For those of us who write code, this can be useful!
Post reply on HN