Slashdot Mirror
Facts and Fiction of GPU-Based H.264 Encoding
notthatwillsmith writes "We've all heard a lot of big promises about how general-purpose GPU computing can greatly accelerate common tasks that are slow on the CPU — like H.264 video encoding. Maximum PC compared the GPU-accelerated Badaboom app to Handbrake, a popular CPU-based encoder. After testing a variety of workloads ranging from archival-quality DVD rips to transcodes suitable for play on the iPhone, Maximum PC found that while Badaboom is significantly faster than X264-powered Handbrake in a few tests that require video resizing, it simply can't compare to the X264-powered Handbrake for archival-quality DVD backups."
So if you had tried Handbrake before posting you would see you don't need to first rip the dvd's. You wouldn't have to buy slysoft. You furthermore would be able to choose ipod, psp, etc as a setting for output.
There's no simple answer here. As the FSF say in the answer you link to "This is a legal question, which ultimately judges will decide." And you missed the rest of the answer following your quote "But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program." It could certainly be argued in a court that distributing an application that performs video encoding by transferring commands and data frames across an IPC link constitutes a derivative work, especially if there's no way for the encoding application to work if the GPL component were removed (as would be the case here). The mere aggregation clause was meant to apply more to clear cut cases like distributing a Linux distribution, where differently licensed unconnected software like, say, emacs and skype, could be incorporated on the same CD.
Wait, what?
If the CPU were running at 100%, then it would be CPU bound. Perhaps you meant to say it's GPU bound?