Slashdot Mirror

← Back to Stories (view on slashdot.org)

Which Open Source Video Apps Use SMP Effectively?

Posted by kdawson on from the on-the-one-core-on-the-other-core dept.

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

9 of 262 comments (clear)

  1. ffmpeg by bconway · · Score: 5, Informative

    Use the -threads switch.

    --
    Interested in open source engine management for your Subaru?
    1. Re:ffmpeg by morgan_greywolf · · Score: 5, Informative

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

      --
      My blog
    2. Re:ffmpeg by mweather · · Score: 5, Informative

      Apple computers ARE PCs. They coined the damn term.

    3. Re:ffmpeg by ksheff · · Score: 5, Informative

      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.

      --
      the good ground has been paved over by suicidal maniacs
  2. transcode, of course! by morgan_greywolf · · Score: 5, Informative

    transocde uses separate processes for everything.

    --
    My blog
  3. Handbrake by vfs · · Score: 5, Informative

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

  4. Re:Simple... by j00r0m4nc3r · · Score: 5, Informative

    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.

  5. keyframes by Anonymous Coward · · Score: 5, Informative

    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.

  6. avidemux by Unit3 · · Score: 5, Informative

    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.

    --
    -- sudo.ca