DVRMSToolbox has had QS support for a long time (since SNB). I don't OSS the filters, but the surrounding DirectShow code is FOSS (http://babgvant.svn.sourceforge.net/viewvc/babgvan... and of course the whole thing is free as in beer :).
they didn't support it in x264 iirc as intel didn't give access to any low level stuff. made it pointless for the devs in that case as they had no control. if that's been fixed now then sweet!
Most of my transcoding is disc to archive, so quality is more important than speed. It would have been nice if there was more granularity to the fixed function encoder so the parts that matched x264 could have been utilized by it. The x264 people have generally said they can match QuickSync / GPU speed if you drop the quality down to comparable levels.
When I upgrade to Haswell, I'll still use the software encoder, especially if x264 makes as good as use of AVX2 as it sounds.
The x264 clowns are full of it. They went out of their way to hamper bringing Quicksync to the masses, and they did it for petty reasons of personal politics. I've read the forum posts where Intel came to them and said, "hey, this is what we're working on, what do you think?" They acted like jerks, and their performance claims are hogwash. Quicksync is fast. Seriously fast.
There is no way that x264 can compare to QuickSync in raw performance (not in quality) as, with full 4X 1080i59.94 HD Transcoding, Sandy Bridge Mobile CPUs only use 10%-25% of the CPU to feed the QuickSync engine while x264 would need more of the CPU to execute the same video transcoding task not leaving CPU performance for Audio Transcoding.
"There is no way that x264 can compare to QuickSync in raw performance"
Let's fine-tune that statement. The folks at Compression.ru do a yearly compression study and release free + paid reports. The appendix from their 2012 study, which includes IVB QS2 results, found that on performance desktop IVB, x264 is both faster AND provides a higher qual:perf ratio.
On mobile hardware, with a mid-end quad core IVB, QS takes the lead in performance and quality per performance.
I don't expect anyone with high end or overclocked CPUs to benefit from Quicksync, unless they're planning on doing some strenuous multitasking during the encode period.
There are a huge number of people that stream their gaming live. Quicksync could allow people with 2 core CPUs to stream without impacting game performance, and would allow people with 4 core CPUs to stream at a much higher quality.
The big thing is no one uses x264 on superfast presets because people using x264 usually care about quality. The result is few people are aware of how fast it can be in raw fps numbers once it backs off the quality benchmark it is known for.
I will grant you that while x264 veryfast may be around Quicksync speeds, it will definitely be using more CPU power to do it.
I've read that discussion in the past (first in early 2011 - when deciding whether to buy into P65 or wait for Z77). That's not really a correct interpretation of what the state of affairs were:
Firstly, the x264 dev's overriding interest is in maintaining the quality of the encode. If QuickSync was fast, that was irrelevant if it couldn't be used to replicate the quality of x264's CPU h.264 encode. We hhad all seen nVidia's efforts in this area to that time and they were pretty awful. So of course there was skepticism.
Then there was a problem with what information was actually forthcoming from Intel. The information provided seem to come from one engineer's private outreach. All the claims were vague (maybe he wasn't a native English speaker?). Requests for further information took a long time and still weren't sufficient.
Effectively, there seemed to be cross purposes. The x264 project would have been more than willing look at using specific elements of QuickSync, to the extent it was possible. The Intel engineer was thinking x264 should be just a QuickSync frontend (obviously not going to happen). Intel itself had no official involvement in the discussion at all.
So here we are two years down the track at approximately where we should have been a tad over 2 years ago!
Well, you should reread the discussions again. Love QuickSync and all the juicy part Anand told you about? They are not available unless you paid for an application. The decoder to OS software player didn't came long time later. And Intel couldn't be bother to work with the community as far as i could tell. ( Although not necessarily the engineers fault. )
So we basically have a piece of Hardware in our CPU that is being greatly advertised but cant be used at all.
It is actually not quite true. You DO have free (as in beer) software taping QuickSync since early/mid 2012, when Intel made it available in their dev kit. Mediacoder http://www.mediacoderhq.com/ is one of them and works quite well (on my SB 2500k).
QS is a black box with very limited options though, so in the end I used x264 for flexibility (still with MediaCoder btw).
So, it is usable, but intel is lifting the veil one corner at a time...
This may have been true in the past because they found (collectively) AMD and NVidia solutions did not offer substantial gains in transcoding time. Now QS is the game changer and so reflect the attitudes of said "clowns".
I read about that too... the Handbrake people are jerks... Maybe because they are French ?...
I've read tons of forums and articles about people wanting GPU power to HandBrake - and everytime the HandBrake/x264 people shoot it down (with good reasons sometimes)
I'm pretty sure that nothing will happen, that Handbrake and x264 will continue to be CPU only.
I do enjoy QuickSync, as I specifically wanted the HD 3000 i3 for this very task. I was disappointed I could not use QS on Ubuntu and that Intel offered no support. My guess is that Intel wants full exposure of QS so that their SDP chips have the most market penetration possible. QS on Android perhaps?
If QuickSync is still not available to anybody using a discrete graphics card, few desktop users will be able to access it.
I'll wind up in the bizarre situation where my IvyBridge MacBook Air will be able to transcode video much faster than my desktop i7 3770k system with a GeForce GTX 670.
Last time I tried to enable both the iGPU and discrete GPU in the BIOS, my system decided to stop sending video signals to any output (on either the iGPU or discrete card), requiring a CMOS reset to get the thing booting again.
Most desktop motherboards come with Lucid Virtu MVP these days, so desktop users with discrete cards can access QuickSync through d-Mode. However that's only for self-built systems; I can't recall ever seeing Virtu with an OEM system, which is what most customers are buying.
Well Intel should have done this when Sandy Bridge was released, but I am glad that they are doing it now. Makes me happier that I just upgraded to Ivy Bridge!
But already a year ago tablets have reached a point where they can decode 1080p in hardware.
In addition, the model I have has 32GB built in, a micro SD card slot supporting 32GB cards and I also have a 64GB USB stick that I can put in its dock.
Transcoding for mobile hardware is a fad that will go away soon enough - I never bothered with it.
Well if you're in android world, apple isn't there yet.
My 1080p movie files tend to be 10-15 gigabytes a pop. It's pretty easy to fill up your tablet's memory at that rate; 64GB of storage won't even get you through a flight from Toronto to Tokyo.
Most of my movies start at 4GB, I transcode them to less than a gig so I can fit about 25 films when I travel two weeks at a time. Also decoding a 1080p for a tablet uses more battery than 480p. I dont think transcoding is going away anytime soon.
I use transcoding on the fly with servio and ps3ms in my house for all my dlna devices, but hopefully those apps with start to take advantage of Quicksync as well
I hadn't bothered with it when I had my SGS2 with 16GB NAND and a 32GB mSDHC card. But when I switched to a Galaxy Nexus, space became a premium commodity. Now I reencode my 1080p stuff to 720p (reducing the size to ~1/3 or 1/4 of the original), so that I can cramp more stuff onto the phone. Though I wouldn't look at upgrading to a new setup (from my i7 860) just for QS.
AFAIR, the problem between Quick Sync and x264 were not because mediating library was closed source, but because main encoding process was closed and x264 had no way of affecting the quality. If I remember correctly (and I'm sure the messages can still be found in x264 forums): *) x264 folks were interested in accelerating the encoding, if x264 has access to all key steps and can affect the quality of the output (I have forgot the actual terms used). *) Quick Sync works as a fast black box: you feed some data and get back final results without being able to affect anything. *) Quick Sync produced quick results, but the quality wasn't good enough and offered no way to change that. *) Intel guys offered x264 folks to use Quick Sync, but because of above mentioned reasons it was rejected. *) Some x264 devs tried to play Torvalds and be an a$$hole. But they had actually very little reason to do so and in addition they overdid it. But it's not every day you get to opportunity to say "f**k off" to Intel from high horse, must have been very tempting, I'm sure.
The main argument of x264 against using Quick Sync was: it doesn't matter if it is fast, if it produces inferior results and doesn't provide any means to improve quality. In that sense Quick Sync doesn't differ from other fast libraries, for example Cyberlink. And x264 is not interested in being merely a caller of inferior external black boxes, no matter fast these are.
Many encoders trade quality for speed. x264 offers ability to trade speed to higher quality and x264 is not interested giving it up, even if some fast library is hardware accelerated and has "Intel inside" on it.
Yeah, even still I don't think this makes sense and don't see how it really gets supported by the programs we all actually use.
If I were on one of these teams, I'd be looking at whether OpenCL can do anything for me, given it's...open, and will probably be supported better than anything else, etc.
I continue to be pissed that Intel is blowing all these transistors on video and encoding. I do not want it. I want more cores, bigger cores, etc. Not some proprietary fixed function video encoder...
Yeah, as I understand it this doesn't actually fix x264's problem at all.
And it wasn't just x264 that was unimpressed with QuickSync's image quality; recall that Apple refused to enable it Sandy Bridge on the grounds that the output looked like crap. I assume that's why Intel concentrated more on quality for IVB. It now meets Apple's specs, but you still wouldn't want to use it for non-realtime transcoding (e.g. DVD ripping with Handbrake or whatever).
Also, I must protest being an a$$hole as "playing Torvalds". Linux's success is due in equal parts to Linus' pragmatism and his generally well-founded stubbornness. I'm genuinely afraid of what'll happen if he gets hit by the proverbial bus and the FSF faction takes over the kernel. Google would probably have to fork to continue Android, among other things.
FSF has 0 say in the kernel and would not be able to change anything: the kernel is licensed under GPL v2 PERIOD. No "or later" or anything like that, so it is stuck to it (it would be *impossible* to get consent from the hundreds if not thousand of contributors to re-license it, as each contributor has kept their copyright).
If anyone wants a kernel under a different license, they are welcome to write their own.
So what if it's GPL v2? The FSF could take over as the maintainers/stewards of the mainline kernel, leave it at GPL v2, and still accept patches into mainline that Linus would otherwise reject and/or reject patches that Linus would otherwise accept.
Quick Sync PR again? All people who really care about video encoding know that Quick Sync was pure marketing buzz from the beginning and has zero practical usage.
First you show the x264-level application benefiting from it – only then I'll believe you. Oh, and I want Hi10P h264 btw.
Without basic features like high profile and multipass it's totally useless.
It's not even worth for nand-based portable devices where you are limited by the amount of storage: double the file size for WAY too low video quality.
This asic\simd based features may be worth something for 480p phones....
Multi pass is a huge waste of space, unless you're doing something silly like trying to burn movies to 700MB CD-Rs. Believe it or not, x264 knows better than you how many bits it needs to achieve a particular quality level with a particular video.
People that argue that people using x264 only care about quality have very little imagination. There's a lot of uses i can think off where you need speed for x264. It's the codec that xsplit uses, and it's also used by plex and other applications like it.
on both xsplit and plex i'd much rather have the speed than the quality.
For xsplit the ability to stream with little to no performance hit would be very useful. Because assuming it doesn't slow your game down it would be just as good as having a dedicated encoding computer for streaming or a capture card that does hardware encoding. This would allow people to use hardware they already have instead of having to shell out 300 dollars or more on a hardware solution.
Plex would also have huge benefits from this. My whole family uses plex trough roku boxes and iOS clients. For me that means that my entire library has to be transcoded. Having plex use quicksync would probably allow for multiple transcodes with out breaking a sweat. Something that isn't possible right now; since a few 1080p transcodes will choke my server more often than not.
I never understood why intel would invest so much on a piece of technology if they were going to make it so useless... Well, at least they are trying to fix that now. But now we have to see if developers of desirable software jump on board.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
45 Comments
Back to Article
heymrdj - Monday, January 14, 2013 - link
Can't wait to see HB support this!babgvant - Monday, January 14, 2013 - link
DVRMSToolbox has had QS support for a long time (since SNB). I don't OSS the filters, but the surrounding DirectShow code is FOSS (http://babgvant.svn.sourceforge.net/viewvc/babgvan... and of course the whole thing is free as in beer :).tommo123 - Tuesday, January 15, 2013 - link
they didn't support it in x264 iirc as intel didn't give access to any low level stuff. made it pointless for the devs in that case as they had no control. if that's been fixed now then sweet!dmytty - Friday, January 18, 2013 - link
Is it possible to get the motion compensation data from Intel Quick Sync while encoding?icrf - Monday, January 14, 2013 - link
Most of my transcoding is disc to archive, so quality is more important than speed. It would have been nice if there was more granularity to the fixed function encoder so the parts that matched x264 could have been utilized by it. The x264 people have generally said they can match QuickSync / GPU speed if you drop the quality down to comparable levels.When I upgrade to Haswell, I'll still use the software encoder, especially if x264 makes as good as use of AVX2 as it sounds.
TerdFerguson - Monday, January 14, 2013 - link
The x264 clowns are full of it. They went out of their way to hamper bringing Quicksync to the masses, and they did it for petty reasons of personal politics. I've read the forum posts where Intel came to them and said, "hey, this is what we're working on, what do you think?" They acted like jerks, and their performance claims are hogwash. Quicksync is fast. Seriously fast.raulizahi - Monday, January 14, 2013 - link
There is no way that x264 can compare to QuickSync in raw performance (not in quality) as, with full 4X 1080i59.94 HD Transcoding, Sandy Bridge Mobile CPUs only use 10%-25% of the CPU to feed the QuickSync engine while x264 would need more of the CPU to execute the same video transcoding task not leaving CPU performance for Audio Transcoding.mavere - Monday, January 14, 2013 - link
"There is no way that x264 can compare to QuickSync in raw performance"Let's fine-tune that statement. The folks at Compression.ru do a yearly compression study and release free + paid reports. The appendix from their 2012 study, which includes IVB QS2 results, found that on performance desktop IVB, x264 is both faster AND provides a higher qual:perf ratio.
Here's a shot of the graph summarizing the results on desktop IVB: http://i.imgur.com/0ccUC.png
On mobile hardware, with a mid-end quad core IVB, QS takes the lead in performance and quality per performance.
I don't expect anyone with high end or overclocked CPUs to benefit from Quicksync, unless they're planning on doing some strenuous multitasking during the encode period.
heffeque - Tuesday, January 15, 2013 - link
Nice to see an informed comment. They aren't easy to find here on the intarwebz.Soulwager - Tuesday, January 22, 2013 - link
There are a huge number of people that stream their gaming live. Quicksync could allow people with 2 core CPUs to stream without impacting game performance, and would allow people with 4 core CPUs to stream at a much higher quality.icrf - Tuesday, January 15, 2013 - link
The big thing is no one uses x264 on superfast presets because people using x264 usually care about quality. The result is few people are aware of how fast it can be in raw fps numbers once it backs off the quality benchmark it is known for.I will grant you that while x264 veryfast may be around Quicksync speeds, it will definitely be using more CPU power to do it.
hornetfig - Monday, January 14, 2013 - link
I've read that discussion in the past (first in early 2011 - when deciding whether to buy into P65 or wait for Z77). That's not really a correct interpretation of what the state of affairs were:Firstly, the x264 dev's overriding interest is in maintaining the quality of the encode. If QuickSync was fast, that was irrelevant if it couldn't be used to replicate the quality of x264's CPU h.264 encode. We hhad all seen nVidia's efforts in this area to that time and they were pretty awful. So of course there was skepticism.
Then there was a problem with what information was actually forthcoming from Intel. The information provided seem to come from one engineer's private outreach. All the claims were vague (maybe he wasn't a native English speaker?). Requests for further information took a long time and still weren't sufficient.
Effectively, there seemed to be cross purposes. The x264 project would have been more than willing look at using specific elements of QuickSync, to the extent it was possible. The Intel engineer was thinking x264 should be just a QuickSync frontend (obviously not going to happen). Intel itself had no official involvement in the discussion at all.
So here we are two years down the track at approximately where we should have been a tad over 2 years ago!
icrf - Tuesday, January 15, 2013 - link
Yeah, I had read that thread, too, and I think that sums it up nicely.For anyone else interested in the details, this is the original discussion from October 2010: http://doom10.org/index.php?topic=717.0
iwod - Monday, January 14, 2013 - link
Well, you should reread the discussions again. Love QuickSync and all the juicy part Anand told you about? They are not available unless you paid for an application. The decoder to OS software player didn't came long time later. And Intel couldn't be bother to work with the community as far as i could tell. ( Although not necessarily the engineers fault. )So we basically have a piece of Hardware in our CPU that is being greatly advertised but cant be used at all.
frenchy_2001 - Tuesday, January 15, 2013 - link
It is actually not quite true. You DO have free (as in beer) software taping QuickSync since early/mid 2012, when Intel made it available in their dev kit.Mediacoder http://www.mediacoderhq.com/ is one of them and works quite well (on my SB 2500k).
QS is a black box with very limited options though, so in the end I used x264 for flexibility (still with MediaCoder btw).
So, it is usable, but intel is lifting the veil one corner at a time...
tdtran1025 - Thursday, January 17, 2013 - link
This may have been true in the past because they found (collectively) AMD and NVidia solutions did not offer substantial gains in transcoding time. Now QS is the game changer and so reflect the attitudes of said "clowns".Montago - Thursday, March 7, 2013 - link
I read about that too... the Handbrake people are jerks... Maybe because they are French ?...I've read tons of forums and articles about people wanting GPU power to HandBrake - and everytime the HandBrake/x264 people shoot it down (with good reasons sometimes)
I'm pretty sure that nothing will happen, that Handbrake and x264 will continue to be CPU only.
MonkeyPaw - Monday, January 14, 2013 - link
I do enjoy QuickSync, as I specifically wanted the HD 3000 i3 for this very task. I was disappointed I could not use QS on Ubuntu and that Intel offered no support. My guess is that Intel wants full exposure of QS so that their SDP chips have the most market penetration possible. QS on Android perhaps?Guspaz - Monday, January 14, 2013 - link
If QuickSync is still not available to anybody using a discrete graphics card, few desktop users will be able to access it.I'll wind up in the bizarre situation where my IvyBridge MacBook Air will be able to transcode video much faster than my desktop i7 3770k system with a GeForce GTX 670.
babgvant - Monday, January 14, 2013 - link
DX11 supporting GPUs don't need a connected display to enumerate, so it will work headless (or disconnected).Guspaz - Tuesday, January 15, 2013 - link
Last time I tried to enable both the iGPU and discrete GPU in the BIOS, my system decided to stop sending video signals to any output (on either the iGPU or discrete card), requiring a CMOS reset to get the thing booting again.Ryan Smith - Monday, January 14, 2013 - link
Most desktop motherboards come with Lucid Virtu MVP these days, so desktop users with discrete cards can access QuickSync through d-Mode. However that's only for self-built systems; I can't recall ever seeing Virtu with an OEM system, which is what most customers are buying.Guspaz - Tuesday, January 15, 2013 - link
My Z77 mobo didn't come with a Virtu license.danjw - Monday, January 14, 2013 - link
Well Intel should have done this when Sandy Bridge was released, but I am glad that they are doing it now. Makes me happier that I just upgraded to Ivy Bridge!edlee - Monday, January 14, 2013 - link
I love quicksync, I use it all the time to make smaller size video file for my android tablet when I am traveling .I upgraded to ivy bridge from sandy bridge to get the speed boost for transcoding. Nothing comes close right now.
Spoelie - Tuesday, January 15, 2013 - link
But already a year ago tablets have reached a point where they can decode 1080p in hardware.In addition, the model I have has 32GB built in, a micro SD card slot supporting 32GB cards and I also have a 64GB USB stick that I can put in its dock.
Transcoding for mobile hardware is a fad that will go away soon enough - I never bothered with it.
Well if you're in android world, apple isn't there yet.
Guspaz - Tuesday, January 15, 2013 - link
My 1080p movie files tend to be 10-15 gigabytes a pop. It's pretty easy to fill up your tablet's memory at that rate; 64GB of storage won't even get you through a flight from Toronto to Tokyo.edlee - Tuesday, January 15, 2013 - link
Most of my movies start at 4GB, I transcode them to less than a gig so I can fit about 25 films when I travel two weeks at a time. Also decoding a 1080p for a tablet uses more battery than 480p. I dont think transcoding is going away anytime soon.I use transcoding on the fly with servio and ps3ms in my house for all my dlna devices, but hopefully those apps with start to take advantage of Quicksync as well
Death666Angel - Thursday, January 17, 2013 - link
I hadn't bothered with it when I had my SGS2 with 16GB NAND and a 32GB mSDHC card. But when I switched to a Galaxy Nexus, space became a premium commodity. Now I reencode my 1080p stuff to 720p (reducing the size to ~1/3 or 1/4 of the original), so that I can cramp more stuff onto the phone.Though I wouldn't look at upgrading to a new setup (from my i7 860) just for QS.
vps - Tuesday, January 15, 2013 - link
AFAIR, the problem between Quick Sync and x264 were not because mediating library was closed source, but because main encoding process was closed and x264 had no way of affecting the quality. If I remember correctly (and I'm sure the messages can still be found in x264 forums):*) x264 folks were interested in accelerating the encoding, if x264 has access to all key steps and can affect the quality of the output (I have forgot the actual terms used).
*) Quick Sync works as a fast black box: you feed some data and get back final results without being able to affect anything.
*) Quick Sync produced quick results, but the quality wasn't good enough and offered no way to change that.
*) Intel guys offered x264 folks to use Quick Sync, but because of above mentioned reasons it was rejected.
*) Some x264 devs tried to play Torvalds and be an a$$hole. But they had actually very little reason to do so and in addition they overdid it. But it's not every day you get to opportunity to say "f**k off" to Intel from high horse, must have been very tempting, I'm sure.
The main argument of x264 against using Quick Sync was: it doesn't matter if it is fast, if it produces inferior results and doesn't provide any means to improve quality. In that sense Quick Sync doesn't differ from other fast libraries, for example Cyberlink. And x264 is not interested in being merely a caller of inferior external black boxes, no matter fast these are.
Many encoders trade quality for speed. x264 offers ability to trade speed to higher quality and x264 is not interested giving it up, even if some fast library is hardware accelerated and has "Intel inside" on it.
Wolfpup - Tuesday, January 15, 2013 - link
Yeah, even still I don't think this makes sense and don't see how it really gets supported by the programs we all actually use.If I were on one of these teams, I'd be looking at whether OpenCL can do anything for me, given it's...open, and will probably be supported better than anything else, etc.
I continue to be pissed that Intel is blowing all these transistors on video and encoding. I do not want it. I want more cores, bigger cores, etc. Not some proprietary fixed function video encoder...
Arbee - Tuesday, January 15, 2013 - link
Yeah, as I understand it this doesn't actually fix x264's problem at all.And it wasn't just x264 that was unimpressed with QuickSync's image quality; recall that Apple refused to enable it Sandy Bridge on the grounds that the output looked like crap. I assume that's why Intel concentrated more on quality for IVB. It now meets Apple's specs, but you still wouldn't want to use it for non-realtime transcoding (e.g. DVD ripping with Handbrake or whatever).
Also, I must protest being an a$$hole as "playing Torvalds". Linux's success is due in equal parts to Linus' pragmatism and his generally well-founded stubbornness. I'm genuinely afraid of what'll happen if he gets hit by the proverbial bus and the FSF faction takes over the kernel. Google would probably have to fork to continue Android, among other things.
frenchy_2001 - Tuesday, January 15, 2013 - link
FSF has 0 say in the kernel and would not be able to change anything: the kernel is licensed under GPL v2 PERIOD. No "or later" or anything like that, so it is stuck to it (it would be *impossible* to get consent from the hundreds if not thousand of contributors to re-license it, as each contributor has kept their copyright).If anyone wants a kernel under a different license, they are welcome to write their own.
Gigaplex - Wednesday, January 16, 2013 - link
So what if it's GPL v2? The FSF could take over as the maintainers/stewards of the mainline kernel, leave it at GPL v2, and still accept patches into mainline that Linus would otherwise reject and/or reject patches that Linus would otherwise accept.Goty - Tuesday, January 15, 2013 - link
Oh boy, now we can all have horrendously transcoded video no matter our platform of choice! Joy!Spoelie - Tuesday, January 15, 2013 - link
Once I read this comparison (and saw the comparison shots):http://www.behardware.com/articles/828-1/h-264-enc...
I simply ignored quicksync - however that was with HD3000, has the quality situation improved?
etamin - Tuesday, January 15, 2013 - link
when will GPU acceleration finally come to handbrake??Senti - Thursday, January 17, 2013 - link
Quick Sync PR again? All people who really care about video encoding know that Quick Sync was pure marketing buzz from the beginning and has zero practical usage.First you show the x264-level application benefiting from it – only then I'll believe you. Oh, and I want Hi10P h264 btw.
Marburg U - Friday, January 18, 2013 - link
Without basic features like high profile and multipass it's totally useless.It's not even worth for nand-based portable devices where you are limited by the amount of storage: double the file size for WAY too low video quality.
This asic\simd based features may be worth something for 480p phones....
vegemeister - Thursday, March 21, 2013 - link
Multi pass is a huge waste of space, unless you're doing something silly like trying to burn movies to 700MB CD-Rs. Believe it or not, x264 knows better than you how many bits it needs to achieve a particular quality level with a particular video.Kamus - Wednesday, January 23, 2013 - link
People that argue that people using x264 only care about quality have very little imagination.There's a lot of uses i can think off where you need speed for x264.
It's the codec that xsplit uses, and it's also used by plex and other applications like it.
on both xsplit and plex i'd much rather have the speed than the quality.
For xsplit the ability to stream with little to no performance hit would be very useful. Because assuming it doesn't slow your game down it would be just as good as having a dedicated encoding computer for streaming or a capture card that does hardware encoding.
This would allow people to use hardware they already have instead of having to shell out 300 dollars or more on a hardware solution.
Plex would also have huge benefits from this. My whole family uses plex trough roku boxes and iOS clients. For me that means that my entire library has to be transcoded. Having plex use quicksync would probably allow for multiple transcodes with out breaking a sweat. Something that isn't possible right now; since a few 1080p transcodes will choke my server more often than not.
I never understood why intel would invest so much on a piece of technology if they were going to make it so useless...
Well, at least they are trying to fix that now. But now we have to see if developers of desirable software jump on board.