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

Re:ffmpeg

[fm6]

So why is threading off by default? In a CPU-intensive application like this, multithreading always makes sense, even on a single-core system.

Also consider this.

[SignOfZeta]

If you do a lot of H.264 conversion, look into picking up a hardware encoder. There's the Turbo.264; it's Mac-only, but I'm fairly sure it's a rebranded PC device. Plug into a USB port, and it speeds up H.264 encoding -- even on single-core systems. Imagine that with your quad-core. It's not a free solution, but if you find yourself doing a *lot* of encodes, it may be worth your money.

Re:ffmpeg

[civilizedINTENSITY]

strange that quoting history correctly and in context gets you modded flamebait...

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

[Fred_A]

Is creating a copy of my DVD for my Cowon D2 piracy now ?

Legally it probably is in many places since I'm probably not even allowed to read them on my PC (Linux), but still...

Re:Max CPU?

[Barny]

With video conversion faster storage (not low latency) is the big winner, with huge cache being a close second.

If you want the fastest video encodes with no care to cost, get an 8-way pci-e raid card and 8 laptop sata HDD, small and very very fast in a stripe raid.

Re:ffmpeg

[Anonymous Coward]

I don't think you're actually trolling, so I'll bite.

Jahshaka has quite a good GUI - it needs a bit of stability and a few extra features, but it's free so who am I to complain?

Re:ffmpeg

[QuoteMstr]

Yes, you can use threads well. But with less effort (taking into account synchronization and debugging), you can make the asynchronous tasks independent programs instead of threads. Your video and sound processing threads sound like perfect candidates for being made into independent programs.

A task being an independent program affords several advantages. For example, it's easier to test an independent program, especially in a test harness. An independent program can be run by itself. And it's very clear what an independent program's data dependencies are. There is no risk of accidentally racing in memory access, assuming the programs don't share memory. Don't do that.

Performance simply is not a problem. Any modern operating system will have IPC primitives that are more than good enough.

For something like a video processing application, all three programs sharing file descriptors open to a video buffer sounds ideal. And before you complain that "disk access" is slow: on modern operating systems, main memory is just a cache for the disk anyway. With a modern page cache, using a disk file well be just as efficient as pretending you can keep arbitrarily large data structures in memory. See Varnish's architecture [linpro.no].

Even if you must use threads, you should always program them as if they were independent programs, use message-passing, sockets, and so on for communication, and treat the shared address space more as a dangerous misfeature than a communication medium.