Intel QuickSync now open source

[jkauff]

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?

[JEEB]

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.

<mduell> is http://anandtech.feedsportal.com/c/34653/f/635203/s/2784af4b/l/0L0Sanandtech0N0Cshow0C66650Cintels0Equick0Esync0Ecoming0Esoon0Eto0Eyour0Efavorite0Eopen0Esource0Etranscoding0Eapplications0E/story01.htm correct to the extent that the new SDK will make quicksync usable by x264? or will it still be high-level access only?
<mduell> in other words are they only fixing the licensing issue for an app like HB to implment another encoder in a gpl program, or are they providing the low level access needed to make QS useful for x264?
<s55> no low level access
<s55> just MSDK which is the high level encoder

[jkauff]

Originally Posted by JEEB

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.

Reading the announcement on the Intel site, I got the impression that source code for the SDK was now available for download. I would think that allows for low-level access, but maybe not.

[JohnAStebbins]

Originally Posted by jkauff

Reading the announcement on the Intel site, I got the impression that source code for the SDK was now available for download. I would think that allows for low-level access, but maybe not.

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.

[jkauff]

Originally Posted by JohnAStebbins

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.

Disappointing. I'd still like to see it offered as an option in Handbrake, though, when I just want to do a quick transcode for an iPhone video and don't care about top quality. I use MediaCoder for that now, and the result is perfectly acceptable for my purposes.

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.

[Dark Shikari]

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.

[jkauff]

Originally Posted by Dark Shikari

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.

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.

[sneaker_ger]

Originally Posted by jkauff

Ultrafast produces larger files.

That does not make any sense, as bitrate can be arbitrarily chosen (within certain limits) through the --crf or --bitrate parameters.

[jkauff]

Originally Posted by sneaker_ger

That does not make any sense, as bitrate can be arbitrarily chosen (within certain limits) through the --crf or --bitrate parameters.

Using Constant Quality of 20 in Handbrake, Ultrafast produces bigger files for me. YMMV.

[sneaker_ger]

Yes, but you can increase the CRF to get the same filesize. So implying that you don't use that preset instead of QuickSync because "it produces larger files" is nonsensical.

[Dark Shikari]

Originally Posted by jkauff

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.

If the CPU usage is less than half, x264 isn't the reason it's going slowly. Most likely you have a decoder bottleneck preventing either from going any faster.

[easyfab]

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.

[jkauff]

Originally Posted by Dark Shikari

If the CPU usage is less than half, x264 isn't the reason it's going slowly. Most likely you have a decoder bottleneck preventing either from going any faster.

I know I'm not comparing apples to apples here. All I'm saying is that I get a usable and reasonably good looking video for my phone using MediaCoder and QuickSync, and any one of the four cores seldom goes past 50%. Using Handbrake with the x264 superfast preset and an equivalent bitrate (or high Constant Quality setting) uses all four cores at 100% and takes longer. For a quick and dirty transcode in the morning before I leave for work, MediaCoder w/QS gets the job done faster and I can do some other work at the same time.

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.