Which Open Source Video Apps Use SMP Effectively?

ydrol writes "After building my new Core 2 Quad Q6600 PC, I was ready to unleash video conversion activity the likes of which I had not seen before. However, I was disappointed to discover that a lot of the conversion tools either don't use SMP at all, or don't balance the workload evenly across processors, or require ugly hacks to use SMP (e.g. invoking distributed encoding options). I get the impression that open source projects are a bit slow on the uptake here? Which open source video conversion apps take full native advantage of SMP? (And before you ask, no, I don't want to pick up the code and add SMP support myself, thanks.)"

Comments

ffmpeg

[bconway]

Use the -threads switch.

Re:ffmpeg

[morgan_greywolf]

Similarly, mencoder supports threads=# where # is something between 1 and 8.

Re:ffmpeg

[mweather]

Apple computers ARE PCs. They coined the damn term.

Re:ffmpeg

[Tanktalus]

That sounds like a lot of work... I just used make:

%.mpg: %.avi
tovid -ntsc -dvd -noask -ffmpeg -in "$<" -out "$(basename $@)"

all: $(subst .avi,.mpg,$(wildcard */*.avi))

Then I just ran "make -j4". All four processors working like mad, with a minimal of effort.

(You may need to change the wildcard for your own scenario.)

Re:ffmpeg

[maglor_83]

On a single core system this would result in not being able to run anything!

Re:ffmpeg

[hedwards]

Apple has spent a lot of time and money convincing everybody that they don't sell PCs, they sell Macs. I'm not sure what the point of arguing with both the general public as well as Apple is.

At this point, the term PC does not include Apple computers. It's a change to the definition which happens when the vast majority of people decide amongst themselves that the definition should change.

In terms of the topic at hand, most video apps really should be capable of using multiple cores, tasks of this sort are quite easy to finish in parallel. Either by doing ever n frames or subdividing the image into a number of regions which can be completed separately and joined at the end before writing the frame to disk.

Re:ffmpeg

[3vi1]

No - HP did (for their calculators), way before there "was" an Apple.

Also, I don't even think Apple marketing would agree with you - or they wouldn't have "I'm a Mac... and I'm a PC" adverts.

Re:ffmpeg

[ksheff]

That's the point. If the xvid encoder is single threaded, then to keep all the cores busy, one must run multiple instances of ffmpeg with each one encoding a different file. For the given Makefile, that is what make will do when the -j switch is used.

transcode, of course!

[morgan_greywolf]

transocde uses separate processes for everything.

Handbrake

[vfs]

Handbrake has always used both of the cores on my system for transcoding.

F(next) = F(current) + Delta(F(current:next))

[Lumenary7204]

The problem with MPEG encoding and decoding is that the data itself is not well suited to multi-threaded analysis.

Multi-threading is most efficient when it is applied to discrete data sets that have little or no dependency on each other.

For example, suppose I have a table with four columns -- three holding input values (A, B, and C) and one holding an output value (X). If the data in a given row of the table has nothing to do with the data in any other row, multi-threading works efficiently, because none of the threads are waiting for data from any of the other threads. If I want to process multiple rows at once, I simply spawn additional threads.

On the other hand, for data such as MPEG video, the composition of the next frame is equal to the composition of the current frame, plus some delta transformation - the changed pixels.

This introduces a dependency which precludes efficient multi-threaded processing, because each succeeding frame depends on the output of the calculations used to generate the prior frame. Even if more than one core is dedicated to processing the video stream, one core would wind up waiting on another, because the output from the first core would be used as the input to the second.

Re:Simple...

[j00r0m4nc3r]

Running multiple instances of the same code concurrently in multiple threads is simple. Even running mutually exclusive parts of the same code concurrently in separate threads is easy. Converting complex serial algorithms to effectively utilize multiple cores is generally not simple. And writing code that can scale and balance across n number of cores/threads is extremely hard. There are all sorts of synchronization issues to deal with, scheduling issues, data transport issues, etc.. and it becomes increasingly hard to debug code the more cores/threads you throw in. I think the stigma is justified.

keyframes

[Anonymous Coward]

Actually, the MPEG stream resets itself every n frames or so (n is often a number like 8, but can vary depending on the video content). These are called keyframes (K) and the delta frames (called P and I frames) are generated against them. Because of this, it is really easy to apply parallel processing to video encoding.

avidemux

[Unit3]

I've noticed a lot of talk about commandline options, but not the nice guis that use them. Avidemux is open source, cross-platform, gives you a decent interface, and uses multithreaded libraries like ffmpeg and x264 on the backend to do the encoding, so it generally makes optimal use of your multicore system.