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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th January 2013, 15:31   #1  |  Link
jkauff
Registered User
 
Join Date: Oct 2012
Location: Doylestown, PA in the U.S.A.
Posts: 341
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?
jkauff is offline   Reply With Quote
Old 15th January 2013, 16:00   #2  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
Join Date: Jan 2008
Location: Finland / Japan
Posts: 509
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:
<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
__________________
[I'm human, no debug | Unofficial x264 Builds]
JEEB is offline   Reply With Quote
Old 15th January 2013, 16:23   #3  |  Link
jkauff
Registered User
 
Join Date: Oct 2012
Location: Doylestown, PA in the U.S.A.
Posts: 341
Quote:
Originally Posted by JEEB View Post
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.
jkauff is offline   Reply With Quote
Old 15th January 2013, 22:58   #4  |  Link
JohnAStebbins
Registered User
 
Join Date: Oct 2008
Posts: 114
Quote:
Originally Posted by jkauff View Post
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.
JohnAStebbins is offline   Reply With Quote
Old 16th January 2013, 01:48   #5  |  Link
jkauff
Registered User
 
Join Date: Oct 2012
Location: Doylestown, PA in the U.S.A.
Posts: 341
Quote:
Originally Posted by JohnAStebbins View Post
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.

Last edited by jkauff; 16th January 2013 at 01:53.
jkauff is offline   Reply With Quote
Old 16th January 2013, 01:51   #6  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
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.
Dark Shikari is offline   Reply With Quote
Old 16th January 2013, 15:17   #7  |  Link
jkauff
Registered User
 
Join Date: Oct 2012
Location: Doylestown, PA in the U.S.A.
Posts: 341
Quote:
Originally Posted by Dark Shikari View Post
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.
jkauff is offline   Reply With Quote
Old 16th January 2013, 18:19   #8  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 4,570
Quote:
Originally Posted by jkauff View Post
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.
sneaker_ger is offline   Reply With Quote
Old 16th January 2013, 22:30   #9  |  Link
jkauff
Registered User
 
Join Date: Oct 2012
Location: Doylestown, PA in the U.S.A.
Posts: 341
Quote:
Originally Posted by sneaker_ger View Post
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.
jkauff is offline   Reply With Quote
Old 16th January 2013, 22:42   #10  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 4,570
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.
sneaker_ger is offline   Reply With Quote
Old 16th January 2013, 22:51   #11  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Quote:
Originally Posted by jkauff View Post
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.
Dark Shikari is offline   Reply With Quote
Old 17th January 2013, 15:30   #12  |  Link
easyfab
Registered User
 
Join Date: Jan 2002
Posts: 307
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.
easyfab is offline   Reply With Quote
Old 17th January 2013, 15:46   #13  |  Link
jkauff
Registered User
 
Join Date: Oct 2012
Location: Doylestown, PA in the U.S.A.
Posts: 341
Quote:
Originally Posted by Dark Shikari View Post
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.
jkauff is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:28.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.