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

ffmpeg

[bconway]

Use the -threads switch.

transcode, of course!

[morgan_greywolf]

transocde [transcoding.org]uses separate processes for everything.

Re:ffmpeg

[morgan_greywolf]

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

VisualHub...

[e4g4]

...makes excellent use of multiple cores. It is however Mac-only. Interestingly, what it does is split a file into chunks and spawns multiple ffmpeg processes to do the conversion. Which is to say, perhaps you can do some (relatively simple) scripting with ffmpeg that will do the job.

x264 and avisynth

[PhrostyMcByte]

x264 and avisynth can make pretty decent use of threads. check out meGUI.

Beat me to it!

[BLKMGK]

x264 via meGUI from Doom9 is what I use to compress HD-DVD and BD movies - also on a quad core. I have some tutorials posted out and about on how I'm doing it. Near as I can tell you cannot dupe the process on Linux due to the crypto - Slysoft's AnyDVD-HD is needed.

Playback - I use XBMC for Linux. It is also SMP enabled using the ffmpeg cabac patch. the developers of this project have been VERY aggressive at taking cutting edge improvements to the likes of ffmpeg and incorporating them into the code. Since Linux has no video acceleration of H.264 SMP really helps on high bitrate video!

Re:Which part of Open Source didn't you get?

[phuul]

So is ffmpeg not open source? It uses the LGPL license and from their license FAQ:

"FFmpeg is licensed under the GNU Lesser General Public License (LGPL). However, FFmpeg incorporates several optional modules that are covered by the GNU General Public License (GPL), notably libpostproc and libswscale. If those parts get used the GPL applies to all of FFmpeg. Read the license texts to learn how this affects programs built on top of FFmpeg or reusing FFmpeg. You may also wish to have a look at the GPL FAQ. "

Since his suggestion was to do some scripting that does essentially what VisualHub does using ffmpeg I'm not sure I see how he missed the Open Source requirement.

Handbrake

[vfs]

Handbrake [handbrake.fr] has always used both of the cores on my system for transcoding.

Re:ffmpeg

[sp332]

And it may or may not be useful to actually rune more than one thread per kernel. It depends on the encoder and application how many threads you shall run, so the best is to test with 1, 2 and 4 threads per kernel.

Isn't that per-core, not per-kernel?

Re:Which part of Open Source didn't you get?

[pushing-robot]

OP is asking for open source tools. You cited a commercial one that doesn't provide source.

VisualHub (the front-end app) may be closed, but ffmpeg is LGPL.

And the GP was suggesting using ffmpeg, not VisualHub.

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.

Re:ffmpeg

[mweather]

Apple computers ARE PCs. They coined the damn term.

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

[Lumenary7204]

Note that the above example is about the video component only of a single MPEG audio/video stream.

There is no reason that an encoder/decoder can't process audio in one thread and video in another, thereby using more than one core (which has already been discussed in other posts relating to this article).

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.

Re:Handbrake

[Anonymous Coward]

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

... and is only good for transcoding DVDs. Sure it's nice and simple for that one thing, but I assume the submitter wants more than that.

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

[Zygfryd]

http://en.wikipedia.org/wiki/Group_of_pictures [wikipedia.org]

You can encode GOPs independently. I think the only dependency between GOP encoding processes is bit allocation, which probably works well enough if you simply assign each process an equal share of the total bit budget.

Windows? VirtualDub 1.8.x + ffdshow-tryouts

[tdelaney]

You don't say if you're running on Windows or Linux or something else. If you are running on Windows, the latest versions of VirtualDub have made big improvements to SMT/SMP encoding.

VirtualDub home [virtualdub.org]
VirtualDub 1.8.1 announcement [virtualdub.org]
VirtualDub downloads [sourceforge.net]

Make sure you grab 1.8.3 - 1.8.1 was pretty good, but had a few teething problems. 1.8.2 has a major regression which is fixed in 1.8.3. The comments in the 1.8.1 announcement contain a few important tips for using the new features (some of which I posted BTW).

The two major new features that would be of interest to you are:

1. You can run all VirtualDub processing in one thread, and the codec in another. This works very well in conjunction with a multi-threaded codec - this one change improved my CPU utilitisation from approx 75% to 95% on my dual-core machines - with an equivalent increase in encoding performance.

2. VD now has simple support for distributed encoding. You can use a shared queue across either multiple instances of VD on a single machine, or across multiple machines (must use UNC paths for multiple machines). Each instance of VD will pick the next job in the queue when it finishes its current job. Instances can be started in slave mode (in which case they will automatically start processing the queue).

I use 3 machines for encoding (all dual-core). With VD 1.8.x I start VD on two of the machines in slave mode, and one in master mode. I add jobs to the queue on the master instance, and the other two instances immediately pick up the new jobs and start encoding. When I've added all the jobs, I then start the master instance working on the job queue.

To achieve a similar effect on your quad-code, start two instances of VD on the same machine - one slave, the other master.

It's not perfect (if you've only got one job, you won't use your maximum capacity) but it has greatly simplified my transcoding tasks, and reduced the time to transcode large numbers of files.

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.

Re:ffmpeg

[m0rph3us0]

No it doesn't the only time you want to use multi-threading in a single CPU environment is because asynchronous methods for IO are unavailable or the code would be too difficult to re-architect to use asynchronous IO. If the application is seriously IO bound threads can even make the situation worse by causing random IO patterns.

Ideally, the number of threads a program uses should be no more than the number of processors available. Otherwise, you are wasting time context switching instead of processing.

Do more jobs rather than one job more quickly

[myz24]

As posted elsewhere, it is difficult to divide a project up that is really pretty linear. Instead, you should try to do more jobs at once. Encode four videos at once.

Re:ffmpeg

[i.r.id10t]

Yup, with separate disks to work on to remove (mostly) the disk i/o contention, just let each process run happily away.

Re:Handbrake

[catmistake]

that's because Handbrake uses ffmpeg

Re:Simple...

[sexconker]

How the hell is this modded interesting (as opposed to informative)?

Do people really not know this stuff (thus making it interesting to them)?

For the gp and the others who still don't get it.

Multi-threaded programming (getting your shit to run in separate threads) is easy, now.
Multi-threaded / distributed algorithms (getting your shit to do some coherent, useful shit while scaling well) are not easy at all.

Re:keyframes

[DigitAl56K]

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

That is not true for MPEG-4 unless you have specifically constrained the I/IDR interval to an extremely short interval, and doing so severely impacts the efficiency of the encoder because I-frames are extremely expensive compared to other types.

Keyframes are usually inserted when temporal prediction fails for some percentage of blocks, or using some RD evaluation based on the cost of encoding the frame. Therefore unless the encoder has reached the maximum key interval the I frame position requires that motion estimation is performed, and thus you can't know in advance where to start a new GOP.

In H.264 due to multiple references you would certainly have issues to contend with since long references might cross I-frame boundaries, which is why there is the distinction of "IDR" frames, and this would certainly not be possible threading at keyframe level.

Granted, for MPEG1&2 encoders threading at keyframes is a possibility, although still not one I'd personally favor.

Re:ffmpeg

[ydrol]

Darn, I forgot a minor detail in my question. I was really asking about the various front-end apps (dvd::rip, k9copy, acidrip etc), I got the impression that none seem to notice they are running on an SMP platform and pass the necessary switches by default to the backend.

Some may argue this is a good thing, but for the time being SMP is the way forward for faster processing as MHz has maxed out, in consumer PCS. So when they start buying octo-core CPUs they dont expect it to run at 1/8th speed by default.

I was also being a bit lazy. I could have checked up on each app in turn, but I asked /. instead.

Re:Handbrake

[crmarvin42]

It's good for Video_TS folders in general. In fact, a handful of DVD's can't be ripped directly from the disk using handbrake and need to be copied to HD via something like MacTheRipper before being transcoded by Handbrake. I don't know what format the guy is trying to transcode from, but most people only need to transcode DVD's.

Re:ffmpeg

[Anonymous Coward]

If thread 1 is doing work while thread 2 is blocked (io, semaphores, etc), then multithreading will be faster.

Re:ffmpeg

[sexconker]

If you're making another copy of it to play on another device (format shifting or whatever bullshit term they used), yeah, you can probably get sued for it if some asshat wants to target you.

Illegal? No.
Wrong? Hell no.

My point is that encoding apps often exist separately from editing apps (such as FCP). This is due in large part to piracy, especially when talking about free/open encoders and sites like doom9.
Pirates are not concerned with editing/creating, they're concerned with copying and converting/compressing. Likewise, the writers of such tools/interfaces are concerned with pleasing a certain crowd of people...

I was calling FCP trash in terms of a converter/encoder. It's much more geared toward editing. Thus, I think the ACs mention of FCP in this conext is not very pertinent.

Re:ffmpeg

[VGPowerlord]

True, but in most contexts, "PC" is the shortened form of IBM-compatible PC (which is really outdated), and is usually just stands for Windows these days.

Re:keyframes

[TwinkieStix]

This may be true for sending entire frames to threads, but in mpeg4, frames are broken up into chunks. Motion vectors are created that allow these chunks to move about the image from frame to frame. Other filters are used to remove blockiness, compress the image, do motion detection and macroblock detection, and do various other tasks. MPEG4, especially H.264, can be easily multi-threaded: http://ietisy.oxfordjournals.org/cgi/content/abstract/E88-D/7/1623 [oxfordjournals.org] http://adsabs.harvard.edu/abs/2004SPIE.5308..384L [harvard.edu] http://www.electronicsweekly.com/Articles/2007/05/02/41296/aspex-targets-parallel-processor-at-blu-ray-dvd.htm [electronicsweekly.com] When doing a two-pass encode, this is even easier because the keyframes are discovered on the first (faster) pass, so (if encoding already couldn't be threaded) it could by taking advantage of the known keyframe markers in at least the second pass. But, that's not necessary. I use handbrake to create H.264 videos under Linux all the time on my dual core machine, and both processors stay between 80%-90% utilization from start to finish regardless of the number of passes.

Re:ffmpeg

[elgaard]

I have not tried it. But e.g. k9copy uses mencoder.
So if you just put something like "x264ops=threads=auto" in you mencoder.conf file it might work also from k9copy.
k9copy also have a settings menu where you can tune options to mencoder for various codecs.

Re:ffmpeg

[SimonTheSoundMan]

Yeah, Compressor is pretty damn good. It doesn't just use all your cores, but it can also distribute the workload to other machines on a network. Whole render farms.

Logic Node is somewhat better, however it only does audio, we have two eight core Mac pro's and three Xserv machines in our studio. The Xserve machines will be binned when the new version of Logic Pro supporting GPU processing the audio is out.

heroinewarrior.com

[heroine]

The version of Cinelerra from heroinewarrior.com uses SMP. It's highly dependant on the supporting libraries & who implemented the feature. In the worst case, use renderfarm mode & nodes for each processor. Sometimes the libraries work in SMP mode & sometimes they don't. Sometimes the feature was intended for everyone to use on any number of processors & sometimes it was written for 1 person's cheap single processor.

Re:keyframes

[srw]

Slight correction: in MPEG, the keyframes are called I-Frames. The delta frames are B and P frames. Most MPEG2 encoders that I have used default to a 15 frame GOP.

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

[foxyshadis]

Several implementations of this exist: For x264, there's x264farm (which includes network encoding as well).

Re:ffmpeg

[networkBoy]

I hit I/O throttling when I do the following:
* rip 2 dvds (two DVDR Drives)
* transcoding previous DVD rips to XVID
* Moving completed rips to server over 1 Gbps Ethernet link.

At this point I can see CPU load start to drop as PCI bus I/O saturates.

At no point do I hit disk I/O or memory limits.
Disks are non-RAID non-striped, but rips are to separate disks (thus DVDA rips to HDA DVDB to HDB) and server upload pulls from whatever disk is not currently transcoding (transcode file on HDA, when done start transcode on HDB and move file from HDA).
-nB

Re:keyframes

[Anonymous Coward]

These are called keyframes (K) and the delta frames (called P and I frames) are generated against them.

This is essentially correct, but a little bit off in the terminology. The keyframes are called Intra-coded (I) frames. The delta frames are called Predictive-coded (P) or Bidirectionally-predictive-coded (B) frames depending on whether or not they depend on frames from the future.

AcidRip patches

[ydrol]

Cheers. I also found these Acidrip patches. [ubuntuforums.org] PS In case anyone missed it, I really meant to ask about the front end GUI/script tools rather than the engines. PPS I'm actually using Mandriva.

Re:ffmpeg

[MadnessASAP]

If I may offer a suggestion, I'm not too sure on what your setup is but on mine I have 2 DVD drives each on separate IDE buses and 2 SATA drives (also on separate buses) rip from the DVD to drive 1 and encode from drive 1 to 2. OF course it all depends on a variety of factors but using that certainly helped that.

Re:ffmpeg

[Nikker]

Running multiple cores with an ide interface is going to kill you regardless because you are only encoding in memory not really storing much there. Basically you have a cap of about 40MB/s for anything larger than about 40MB.

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.

Re:Use Mac OS X...

[Anonymous Coward]

But Mac users have been living with SMP since 2001

Just for reference:

UNIX System V R4-MP 1993
Windows NT 1993
OS/2 2.11 1993
Linux 2.0 1996

Re:ffmpeg

[QuoteMstr]

You're still missing the OP's point. Let me spell it out for you:

Say you have four videos to encode, and four cores.

1) You can either use one core at a time and encode one video at a time. Let's say that takes time T.
2) You can encode one video at a time, but use all four cores while doing it. Your total time is T/4.
3) You can encode four videos at a time, one on each core. Your total time is T/4.

The OP was advocating strategy #3. It's a fine approach.

Re:Handbrake

[Anonymous Coward]

Handbrake uses x264, though you can use ffmpeg if you want. And Handbrake can take as many cores as you want to throw at it...