Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
15th January 2013, 15:31 | #1 | Link |
Registered User
Join Date: Oct 2012
Location: Akron, OH
Posts: 491
|
Intel QuickSync now open source
http://www.anandtech.com/show/6665/intels-quick-sync-coming-soon-to-your-favorite-open-source-transcoding-applications-
The x264 developers most likely had advance knowledge of this. Any official statements yet? |
15th January 2013, 16:00 | #2 | Link | |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
Dunno about advance knowledge, but this is pretty much the same high-level API as they presented before. It was pointed at yesterday on the #x264 channel.
Quote:
__________________
[I'm human, no debug]
|
|
15th January 2013, 22:58 | #4 | Link |
Registered User
Join Date: Oct 2008
Posts: 114
|
The "source code" is a very simple and small shim that can be "legally" linked in with GPL code. It dynamically looks up and loads the non-gpl MSDK lib and passes through calls to it. No new functionality or access to lower level features. IMO, it's flirting with the boundaries of gpl.
|
16th January 2013, 01:48 | #5 | Link | |
Registered User
Join Date: Oct 2012
Location: Akron, OH
Posts: 491
|
Quote:
The Intel FAQ did say, though, that devs could write their own libs, give them the same name as the Intel libs, and drop them right in. Last edited by jkauff; 16th January 2013 at 01:53. |
|
16th January 2013, 01:51 | #6 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Last I saw, on a typical desktop i5/i7 chip, x264 on superfast was roughly the same speed as QuickSync's encoder. So if you just want a quick transcode, preset ultrafast in x264 is probably still quite a bit faster than Quicksync.
|
16th January 2013, 15:17 | #7 | Link |
Registered User
Join Date: Oct 2012
Location: Akron, OH
Posts: 491
|
In my tests, superfast x264 is not as fast as QuickSync. I have an i5 3570K overclocked to 4.5. Using a 24GB .mkv file as the test source, and .mp4/.m4v as the target, x264 takes ten minutes longer to produce the same size file (using vbr). Quality difference is undetectable on my iPhone. CPU usage is considerably less than half. Ultrafast produces larger files.
|
16th January 2013, 22:51 | #11 | Link | |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
Quote:
|
|
17th January 2013, 15:30 | #12 | Link |
Registered User
Join Date: Jan 2002
Posts: 332
|
I think CPU usage is less than half with quicksync .
Last time I try x264 superfast vs quicksync on my I2600k : ~350 fps (90% cpu usage) for x264 and ~500 fps ( 25% cpu usage for decoding and 10% for encoding ) for quicksync x264 superfast quality was better for the same bitrate . quicksync is quicker and probably use lesser power than x264 nothing is perfect. |
17th January 2013, 15:46 | #13 | Link | |
Registered User
Join Date: Oct 2012
Location: Akron, OH
Posts: 491
|
Quote:
If I can set up the job before I go to bed, I prefer software-only transcoding. I'd just like to use one tool (in this case Handbrake) with the option to use hw or sw transcoding. |
|
|
|