this post was submitted on 12 Dec 2023
189 points (100.0% liked)

Programming

17695 readers
368 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
top 8 comments
sorted by: hot top controversial new old
[–] Juujian 25 points 1 year ago (2 children)

I'm not sure I understand. I've already been running ffmpeg from the command line and it's been using multiple cores but default. What's the difference, what's the new behavior?

[–] supercritical 65 points 1 year ago (1 children)

Maybe this?

Every instance of every such component was already running in a separate thread, but now they can actually run in parallel.

[–] [email protected] 16 points 1 year ago

Good old RTFM lol

[–] echo64 31 points 1 year ago (1 children)

before you could tell an encoder to run multiple threads, but everything outside of the encoder would run effectively single threaded.

now you (should) be able to have all the ffmpeg components, decoder, encoder, filters, audio, video, everything all run parallel

[–] owlboy 8 points 1 year ago

Oooo. Will it be automatic? Or do you need to pass a flag?

[–] [email protected] 5 points 1 year ago

This is the best summary I could come up with:


The long-in-development work for a fully-functional multi-threaded FFmpeg command line has been merged!

FFmpeg is widely-used throughout many industries for video transcoding and in today's many-core world this is a terrific improvement for this key open-source project.

The patches include adding the thread-aware transcode scheduling infrastructure, moving encoding to a separate thread, and various other low-level changes.

Change the main loop and every component (demuxers, decoders, filters, encoders, muxers) to use the previously added transcode scheduler.

There's a recent presentation on this work by developer Anton Khirnov.

It's terrific seeing this merged and will be interesting to see the performance impact in practice.


The original article contains 226 words, the summary contains 103 words. Saved 54%. I'm a bot and I'm open source!

[–] chocolatine 4 points 1 year ago (1 children)

I was using gnu parallel before with ffmpeg. Is this any different and better?

[–] grue 3 points 1 year ago

GNU Parallel allows multi-process, which generally tends to be less efficient than multi-threading. I can't speak to the specifics of your use vs. FFmpeg's refactoring, though.