Open-source solution for Intel Quicksync?

[Elecam]

The title really says it all...

I'm looking for a functional open-source/freeware transcoding solution that is compatible with Intel Quicksync. I am starting a BD collection and would like to start moving them over to my media server along with my older DVDs.

I've tried mediacoder because it cliamed to be IQS enabled, but it would crash every time I turned on the GPU (Quicksync) option. The other solutions that I know work, such a mediaespresso aren't free and are very basic.

Any help would be greatly appreciated

[pandy]

Quicksync is speed not quality oriented.

[Elecam]

Perhaps that is so, but it would be nice to test it for myself. Besides, I am no videophile and the speed advantage may outweigh the cost in quality. I'd like to make that determination if it's possible.

[deadrats]

Quicksync is speed not quality oriented.

i wish they would make and enfoce a rule on this board that said if you don't know WTF you're talking about you have to have a nice big cup of STFU.

seriously, it's annoying as hell.

[deadrats]

Elecam,

you need to make sure that you're setup supports QS, namely you have to be using a sandy bridge processor (which i'm assuming you have) with a QS supporting chipset (H61, H67 or P68, not P67) and you must have the integrated gpu as the only installed gpu.

so far no one has coded an open source implementation of the intel media sdk encoder (this is the encoder that runs on the QS dedicated hardware).

you can download demos of the following software that supports QS:

TMPG's latest encoder (i forget the convoluted name they gave it)

Cyberlink's Power Director and Espresso

Movavi's software, as well as AVS Editor

i also believe that Ulead's Video Studio Pro supports QS as well as Roxio's Creator

try these pieces of software and if you get it working properly i would appreciate it if you ran a number of in depth tests.

thanks.

edit: intel engineers have released source code, free to use as anyone wishes, for various portions of their accelerated encoder but thus far it doesn't seem anyone has jumped on the code and made any extensive use of it.

[pandy]

Quicksync is speed not quality oriented.

i wish they would make and enfoce a rule on this board that said if you don't know WTF you're talking about you have to have a nice big cup of STFU.

seriously, it's annoying as hell.

I would say: annoying like hell is mixing closed software with open source.
Intel SDK is closed - due of this there is no open source Quicksync - maybe some OS GUI can be written - seems that someone working on this.
And Quicksync IS SPEED oriented NOT QUALITY - there is wide area to make discussion about what is quality and what is not quality. So if You accept quality of Quicksync it is OK for me - but everyone should judge video compression quality by own eyes - for me Quicksync have lower quality than x264 with same bitrate.

So deadrats please accept DEMOCRACY - this forum is PUBLIC and OPEN to express VARIOUS OPINIONS - if You disagree with my opinion express You opinion but not try to prevent/forbid others from expressing their opinions in future.
Please respect others and their rights to express own opinions.

[deadrats]

I would say: annoying like hell is mixing closed software with open source.
Intel SDK is closed - due of this there is no open source Quicksync - maybe some OS GUI can be written - seems that someone working on this.
And Quicksync IS SPEED oriented NOT QUALITY - there is wide area to make discussion about what is quality and what is not quality. So if You accept quality of Quicksync it is OK for me - but everyone should judge video compression quality by own eyes - for me Quicksync have lower quality than x264 with same bitrate.

So deadrats please accept DEMOCRACY - this forum is PUBLIC and OPEN to express VARIOUS OPINIONS - if You disagree with my opinion express You opinion but not try to prevent/forbid others from expressing their opinions in future.
Please respect others and their rights to express own opinions.

there's opinion and there's fact and you expressed your misinformed opinion as fact.

intel sdk is not closed source, there is no source code to it.

QS is set of fixed function and fully programmable hardware built into sandy bridge. intel sdk is the development kit for creating an accelerated encoder, it includes specs, sample code and high level api documentation.

now intel did release an ipp encoder years ago that was a software based encoder and it's pretty good, you can test it by downloading gom encoder.

there is also a reference intel sdk media encoder and that is closed source but intel engineers have released under a liberal license a fully functional QS accelerated decoder (vc-1, mpeg-2, h264) as well as encoder (h264,mpeg-2) and pre-processing filters and they are part of libVA, so we may see an accelerated encoder as part of ffmpeg.

there is nothing stopping anyone that so desires from coding a gpl'd version of the encoder that is accelerated via QS.

as far quality, the currently accelerated encoders offer quality comparable to x264 at ultra fast preset.

so again, if you don't know wtf you're talking about then stfu.

capice?

[pandy]

there's opinion and there's fact and you expressed your misinformed opinion as fact.

You just expressing opinion not fact and this is Your right but still it will not make it fact.

intel sdk is not closed source, there is no source code to it.

QS is set of fixed function and fully programmable hardware built into sandy bridge. intel sdk is the development kit for creating an accelerated encoder, it includes specs, sample code and high level api documentation.

Intel Media SDK is closed - there is no open specification for hardware thus SDK itself is a Closed Source - You can't build own encoder based on encoder form Intel SDK. You can use some primitives that can help to build own encoder but still You are not able to use hardware (fully programmable as You already mentioned) to build own encoder - this give us one result - always You have same results from SDK because it is self sufficient encoder.

now intel did release an ipp encoder years ago that was a software based encoder and it's pretty good, you can test it by downloading gom encoder.

Your opinion not a fact.

there is also a reference intel sdk media encoder and that is closed source but intel engineers have released under a liberal license a fully functional QS accelerated decoder (vc-1, mpeg-2, h264) as well as encoder (h264,mpeg-2) and pre-processing filters and they are part of libVA, so we may see an accelerated encoder as part of ffmpeg.

No - You can see Intel encoder in action - so any program appears like GUI that using primitives (eg H.264 encoder) - so we can have 2000 different GUI's and with same settings same results due identical encoding engine.

there is nothing stopping anyone that so desires from coding a gpl'd version of the encoder that is accelerated via QS.

oh - please tell me how without Intel NDA i can use HARDWARE - i can use only primitives from Intel SDK but nothing else.

as far quality, the currently accelerated encoders offer quality comparable to x264 at ultra fast preset.

And what is the speed difference for x264 with Ultrafast preset? vs QS (Intel Media SDK) - or maybe You comparing melons with apples like x264 with veryslow preset vs QS?

so again, if you don't know wtf you're talking about then stfu.
capice?

seems that You not able to use own advices but its clear that You also not able to understand difference between open and closed software also seems that You are confused what means "write encoder" and "use encoder".

Hint for You: NDA means NOT OPEN.

PS
swearing will not make You more important...

[Selur]

my two cents:
My guess is that there will be free tools that use the intel sdk as soon as a critical mass of programmers switch to QuickSync compatible hardware.
Writing a small command line tool that uses the cuda encoder library from the CUDA SDK was fairly easy and I guess writing a small cli for the intel sdk encoder shouldn't be so hard either. In my point of view it's mainly a question of waiting for interested programmers to update their hardware. (I myself will probably look at QuickSync in around one or two years, when my current i7 875k will 'feel' too old)

If you really wait for an encoder that isn't mainly just a fronted for the library you will probably have to wait 3+ years,.. look how long it took till a CUDA based encoder that's not just a frontend for NVIDAs library appeared,.. (afaik the only encoder that fulfills this criteria is the encoder from mainconcept)

Cu Selur

Ps.: btw. not aiming for quality is only a problem if you need to hit a specific bitrate range if you aim for speed and need you cpu for filtering&co it's nice to have the gpu do the encoding,.. (+ normally the worst&fastest H.264 settings produce still better results than MPEG-4 ASP )

[deadrats]

Intel Media SDK is closed - there is no open specification for hardware thus SDK itself is a Closed Source - You can't build own encoder based on encoder form Intel SDK. You can use some primitives that can help to build own encoder but still You are not able to use hardware (fully programmable as You already mentioned) to build own encoder - this give us one result - always You have same results from SDK because it is self sufficient encoder.

let me guess, you got this from that retarded x264 developer (jason), right?

No - You can see Intel encoder in action - so any program appears like GUI that using primitives (eg H.264 encoder) - so we can have 2000 different GUI's and with same settings same results due identical encoding engine.

you're being stupid, stop it, really. google libVA, look for the sample source code i talked about, it doesn't use the high level api, it doesn't use the win api nor does it use d3d surfaces.

oh - please tell me how without Intel NDA i can use HARDWARE - i can use only primitives from Intel SDK but nothing else.

http://cgit.freedesktop.org/libva/tree/test/encode

as i said, intel has shared tons of code on how to use the QS engine, you just have to open your eyes and read.

And what is the speed difference for x264 with Ultrafast preset? vs QS (Intel Media SDK) - or maybe You comparing melons with apples like x264 with veryslow preset vs QS?

actually a well respected member of this forum, jagabo, bought a i5 2500k and ran a few quick tests (he hasn't had a chance to run extensive tests yet) and he tested QS with espresso and he compared against an encode done using x264cli on ultra fast, the quality was comparable and QS in that test proved to be faster but not by as big a margin as he was expecting.

[deadrats]

If you really wait for an encoder that isn't mainly just a fronted for the library you will probably have to wait 3+ years,.. look how long it took till a CUDA based encoder that's not just a frontend for NVIDAs library appeared,.. (afaik the only encoder that fulfills this criteria is the encoder from mainconcept)

the elemental people also have a cuda encoder that doesn't use nvidia's reference encoder (they are the people behind badaboom and adobe's mercury engine).

[Selur]

@deadrats: Good to know, do you know of a quality and option comparison between the two encoders?
Tested badaboom 1.0 when it was new and back then the encoder wasn't better than the one from the sdk and had a lot less options. (+ no cli, which was it's downfall for me )

[deadrats]

@deadrats: Good to know, do you know of a quality and option comparison between the two encoders?
Tested badaboom 1.0 when it was new and back then the encoder wasn't better than the one from the sdk and had a lot less options. (+ no cli, which was it's downfall for me )

i have tested all of them, if you can name a gpu powered encoder and if it's available i have run it through the wringer, the best one available is main concept's cuda encoder, the mc reference application is very expensive but since divx bought main concept and roxio has bought both sonic and divx, you can get a complete implementation (the most complete) with either magix movie edit pro hd 17 or roxio's creator 2011/2012 (also implements main concept's QS sdk); microsoft's expression encoder pro sp1 also features the mc cuda encoder (but it's expensive).

it should be noted that microsoft gives some pointers for putting together a system for cuda and that includes matching video card performance with cpu performance; they advise against using a high end video card with a low end cpu or vice versa so as to maximize performance, they say not to use too little bit rate with the cuda encoder because the cuda encoder doesn't blur images as much as software encoder do, thus at low bit rates the cuda encoder tends to block more than the software encoders and a few other pointers.

edit: the newest badaboom also supports QS.

[Selur]

In your experience is the current Badaboom encoder any better than the cuda sdk encoder?

[deadrats]

In your experience is the current Badaboom encoder any better than the cuda sdk encoder?

than the reference cuda encoder that nvidia included as part of their sdk? absolutely, it's basically a slimmed down version of the cuda encoder they created for adobe which eventually became integrated into the mercury engine.

but as i said, the best is main concept's cuda powered encoder (they also have an OCL encoder for ati cards), and if you buy either roxio's creator or magix editor, both of which are reasonably priced, you get the complete main concept software and hardware accelerated encoders with all the granular control available from the sdk, it's actually quite good, mate it with a nice potent video card and you got yourself a serious setup as far as prosumer range setups go.

[Selur]

Thanks for you assessment.

[pandy]

let me guess, you got this from that retarded x264 developer (jason), right?

I have (or i have's) installed on my computer all 3 versions Intel Media SDK - read carefully license then show me documentation how to fully access "fully programmable hardware" - for developer only primitives exposed by Intel are available - how this is implemented and how to implement new, unsupported by Intel functionality?
And once again - insulting people doesn't make You more important.

you're being stupid, stop it, really. google libVA, look for the sample source code i talked about, it doesn't use the high level api, it doesn't use the win api nor does it use d3d surfaces.

i never says win api or dx or something else - and still - trying insulting me make You only more hilarious not serious.

http://cgit.freedesktop.org/libva/tree/test/encode

http://git.videolan.org/?p=x264.git;a=blob;f=encoder/encoder.c;h=26672138133288bf3db9b...5ceb94;hb=HEAD

this is encoder source - apples to apples or apples to melons?

as i said, intel has shared tons of code on how to use the QS engine, you just have to open your eyes and read.

yep - this is true - Intel have tons of code how to use Intel encoder and some less complex than encoder primitives but there is no hardware documentation available without NDA - there is magical programmable hardware but You can use this hardware only by calling Intel primitives - or maybe i'm wrong and maybe i can use this hardware directly to implement functionality not available in current SDK?

actually a well respected member of this forum, jagabo, bought a i5 2500k and ran a few quick tests (he hasn't had a chance to run extensive tests yet) and he tested QS with espresso and he compared against an encode done using x264cli on ultra fast, the quality was comparable and QS in that test proved to be faster but not by as big a margin as he was expecting.

apples to apples and melons to melons - believe me - i have nothing against Intel, QS, hardware acceleration - to be honest i dream about decent quality encoder that make 1920x1080 50 fps and will consume not more that 1 - 2W (this type hardware is available on market) - if this will be implemented on fully programmable hardware is even better - You can use hardware to accelerate different algorithms (like reconfigurable FPGA hardware coprocessor) - but still this is not case of Intel QS, Intel Media SDK so maybe some day in future but not now...

I see no point to discuss more - we are to far from question that start this topic.

[deadrats]

fine, you wish to get back to the topic at hand? the topic was "open source solution for intel quick sync" and the answer still is that despite the fact that no such solution yet exists (it's only been on the market for 9 months, developers are slow to adopt new technology) there is nothing preventing you or anyone else from coding a custom solution are releasing the source code as gpl.

i would also say that QS has the potential to be the highest quality encode at any particular speed; the hardware supports sum of absolute hadamard differences, mate SAHD with large search ranges (say a value of 64), something that brings software encoders to their knees and you will have crisp encodes at much higher frame rates than is possible via software encoders.

add to the fact that ivy bridge is rumored to offer better quality encodes and the QS engine is rumored to be twice as fast and one has to be nuts to encode using any software based solution.

[jagabo]

jagabo, bought a i5 2500k and ran a few quick tests (he hasn't had a chance to run extensive tests yet) and he tested QS with espresso and he compared against an encode done using x264cli on ultra fast, the quality was comparable and QS in that test proved to be faster but not by as big a margin as he was expecting.

Actually what I said was (I still have the PM):

In the mean time I tried out MediaEspresso but it had too few configuration options to be useful (unless there are some hidden options?). I did a quick comparison using its AppleTV preset (1280x720 8000 kbps?) and x264 CRF 18 at "very fast". On quick inspection the quality looked similar but the x264 file was 1/3 the size. Encoding time wasn't too different though I didn't time either one.

Emphasis added. I haven't had a lot of time to work with it but I'm still having trouble getting Mediacoder working with QS.

[poisondeathray]

haha selective ommision of pertient facts = agenda

[deadrats]

haha selective ommision of pertient facts = agenda

no, it equals lots of painkillers playing tricks with my memory.

[deadrats]

Actually what I said was (I still have the PM):

In the mean time I tried out MediaEspresso but it had too few configuration options to be useful (unless there are some hidden options?). I did a quick comparison using its AppleTV preset (1280x720 8000 kbps?) and x264 CRF 18 at "very fast". On quick inspection the quality looked similar but the x264 file was 1/3 the size. Encoding time wasn't too different though I didn't time either one.

Emphasis added. I haven't had a lot of time to work with it but I'm still having trouble getting Mediacoder working with QS.

i stand corrected; since you're having so much trouble with media coder, are you averse to downloading the demo for the latest tmpg and running off a test or two? or perhaps teh demo for power director as it also supports QS.

edit: if the x264 encode is 1/3 the size that means it's using less than 2700 kb/s? for 720p video? are you sure the entire clip was encoded?

[jagabo]

edit: if the x264 encode is 1/3 the size that means it's using less than 2700 kb/s? for 720p video? are you sure the entire clip was encoded?

I was using that old "get out the vote" video we were experimenting with a year or two ago. The source resolution was 960x544. I don't remember if MediaEspresso upscaled to 1280x720 and if I upscaled for x264 too. I just encoded that video with x264 CLI at 960x544 and CRF 18 and the final bitrate turned out around 1900 kbps.

are you averse to downloading the demo for the latest tmpg and running off a test or two?

I just downloaded and installed TMPG Video Mastering Works 5 Trial 5.0.6.38. I did a quick x264 and QS encodes at 3000 kbps CBR. Something is wrong with the QS encode. It seems to have only every 4th frame and each frame is repeated 4 times. Ie, instead of frames 12345678 it has 11115555. And it took several times longer to encode. I'll keep experimenting. Maybe it doesn't like Lagarith sources? But the x264 encode worked fine.

[deadrats]

I was using that old "get out the vote" video we were experimenting with a year or two ago. The source resolution was 960x544. I don't remember if MediaEspresso upscaled to 1280x720 and if I upscaled for x264 too. I just encoded that video with x264 CLI at 960x544 and CRF 18 and the final bitrate turned out around 1900 kbps.

well that explains it; espresso upscaled it to 720p and and likewise upped the bit rate to an appropriate level. don't use a 960x544 source, use a 1080p source and test using the same bit rate; i know you only use crf for your encodes but for an apples to apples comparison you really need to use a bit rate based target encode.

I just downloaded and installed TMPG Video Mastering Works 5 Trial 5.0.6.38. I did a quick x264 and QS encodes at 3000 kbps CBR. Something is wrong with the QS encode. It seems to have only every 4th frame and each frame is repeated 4 times. Ie, instead of frames 12345678 it has 11115555. And it took several times longer to encode. I'll keep experimenting. Maybe it doesn't like Lagarith sources? But the x264 encode worked fine.

i've used the intel sdk encoder in software mode in that app and have never seen a problem like you describe, not that it should make a difference but i'm assuming you did remember to pick hardware acceleration from the settings menu, no?

[jagabo]

I was using that old "get out the vote" video we were experimenting with a year or two ago. The source resolution was 960x544. I don't remember if MediaEspresso upscaled to 1280x720 and if I upscaled for x264 too. I just encoded that video with x264 CLI at 960x544 and CRF 18 and the final bitrate turned out around 1900 kbps.

well that explains it; espresso upscaled it to 720p and and likewise upped the bit rate to an appropriate level.

Not really. Even if I upscael the x264 encode the bitrate only goes up to 3000 or so. Well less than half the bitrate with similar quality.

I just downloaded and installed TMPG Video Mastering Works 5 Trial 5.0.6.38. I did a quick x264 and QS encodes at 3000 kbps CBR. Something is wrong with the QS encode. It seems to have only every 4th frame and each frame is repeated 4 times. Ie, instead of frames 12345678 it has 11115555. And it took several times longer to encode. I'll keep experimenting. Maybe it doesn't like Lagarith sources? But the x264 encode worked fine.

i've used the intel sdk encoder in software mode in that app and have never seen a problem like you describe, not that it should make a difference but i'm assuming you did remember to pick hardware acceleration from the settings menu, no?

Where's this "settings" menu. I see a pulldown where I can select x264 or Intel Media SDK Software. That must mean the software encoder (it looks like a single threaded encoder, I see 25 percent CPU usage when using that option, one of four cores running at 100 perent). Options -> Preferences has a CPU/GPU section but it only shows Multithread and NVIDIA CUDA options. Maybe the free trial version doesn't include the QS encoder?

I ran another pair test encodes with a VOB source. The x264 encode worked fine. The Intel SDK encode again had only 1 of every 4 frames repeated 4 times.

[deadrats]

in the preferences tab go to mpeg decoder settings, check to see if you have the intel hardware sdk decoder picked; also i realize this might be a silly question but you are using the integrated gpu with a supporting chipset (H61/67 or P68) no? if you're using either a discrete graphics solution or the P67 chipset you can't use QS, you are aware of this right?

edit: i just tried a test encode using tmpg vmw5 using the intel sdk encoder in software mode, 4 b frames, 4 reference frames, gop length of 250, deinterlace with a vob source and it encodes just fine (albeit slow), i don't see any evidence of the weird frame pattern you describe, something is wrong with your setup. does the cuda encoder have a similar output?

[jagabo]

in the preferences tab go to mpeg decoder settings, check to see if you have the intel hardware sdk decoder picked;

The only choice I have there is "Standard decoder". For MPEG-4 AVC decoder there are two choices: "Standard decoder" and "Intel Media SDK Software".

also i realize this might be a silly question but you are using the integrated gpu with a supporting chipset (H61/67 or P68) no? if you're using either a discrete graphics solution or the P67 chipset you can't use QS, you are aware of this right?

I have a Core i5 2500K and a Z68 based motherboard (ASRock Z68 Pro3-M). I'm using the Intel HD 3000 graphics, no add-in cards. Win7 Home Premium 64 bit.

edit: i just tried a test encode using tmpg vmw5 using the intel sdk encoder in software mode, 4 b frames, 4 reference frames, gop length of 250, deinterlace with a vob source and it encodes just fine (albeit slow), i don't see any evidence of the weird frame pattern you describe, something is wrong with your setup. does the cuda encoder have a similar output?

No CUDA options. No NVIDIA card.

[pandy]

fine, you wish to get back to the topic at hand? the topic was "open source solution for intel quick sync" and the answer still is that despite the fact that no such solution yet exists (it's only been on the market for 9 months, developers are slow to adopt new technology) there is nothing preventing you or anyone else from coding a custom solution are releasing the source code as gpl.

IMHO to use encoder You can simply use one of the examples from Intel - seems that for average skilled developer making this type of software should be not a problem but still - this will be like GUI not encoder per se.

i would also say that QS has the potential to be the highest quality encode at any particular speed; the hardware supports sum of absolute hadamard differences, mate SAHD with large search ranges (say a value of 64), something that brings software encoders to their knees and you will have crisp encodes at much higher frame rates than is possible via software encoders.

And? did You ever tried to compare quality of both functions? Or we still talking about dreams, opinions, hoaxes, rumors? I have nothing against QS but still seems that for developers who are involved in developing Open Source encoders this is not very attractive - why?

add to the fact that ivy bridge is rumored to offer better quality encodes and the QS engine is rumored to be twice as fast and one has to be nuts to encode using any software based solution.

Rumors, speculations, opinions, hopes, dreams, expectations - i hope to but today QS situation is quite obvious - x264 offer more at cost of time and there still room to improve and what is more important - it works on all CPU's not only on SB, works on various environments (not only in Win7/partially Vista). More flexible and real OS. I choose x264.


Deadrats seems that this one can be interesting for You:
http://forum.doom9.org/showthread.php?t=162442