Sandy Bridge

General questions or discussion about HandBrake, Video and/or audio transcoding, trends etc.
Post Reply
Gorloth
Posts: 25
Joined: Sun Dec 28, 2008 5:04 am

Sandy Bridge

Post by Gorloth »

I have some questions regarding Sandy Bridge. Do you know anything about the ability of Quick Sync in the Sandy Bridge CPU's. Supossidly there is suppose to be a dedicated area in the die for processing video .264 etc ... I heard Intel dropped this in the mobile CPU's but that it should be in the i7 and/or i5 or further down the road in the Xeon SB chips. Or is the Quick Sync only for SB CPU's w/onboard graphics. I'm googled out and couldn't find any thing about it. Same goes for the SB support i/o BD82Z68 chip that's in the new 2011 iMac. Can you shed any light on this ?

User avatar
s55
HandBrake Team
Posts: 9785
Joined: Sun Dec 24, 2006 1:05 pm

Re: Sandy Bridge

Post by s55 »

HandBrake doesn't use quicksync so it's not something to worry about. I believe it's any sandybrige with the HD graphics GPU that has it. Any without it won't have it. (Also, if you use discrete graphics, then the HD graphics is disabled anyway making it rather useless)

Intel has only released a high-level API for their own encoder (which isn't any use to HandBrake. There are licensing issues, and it doesn't look like it can match x264's quality or featureset. ).
They haven't released a low-level API which would be needed for x264 to take advantage of any of the hardware in there. There hasn't been any indication that they will release one

So really disappointing news all round :(.

Here's hoping they do release a low-level api some day as it has possible potential in giving x264 a bit of a speedup.

musicvid
Veteran User
Posts: 3604
Joined: Sat Jun 27, 2009 1:19 am

Re: Sandy Bridge

Post by musicvid »

'Ya know,
Handbrake with CQ x264 is already so much faster (>=25%) than any other VBR solution, I just wouldn't worry about it for the time being.
Just my 2c.

GregiBoy
Veteran User
Posts: 908
Joined: Sat Feb 12, 2011 9:23 pm

Re: Sandy Bridge

Post by GregiBoy »

Just have a read on other encoder forums about the problems with CUDA & DXVA and you will soon realize that GPU processing is not all that it is cracked up to be.

I totally agree with HB that they do not support this kind of processing. It is fraught with problems because of the reliance of the drivers/implementation of the manufactures and opens up huge support issues!!

thompson
Bright Spark User
Posts: 356
Joined: Sat Dec 12, 2009 8:04 pm

Re: Sandy Bridge

Post by thompson »

GregiBoy wrote:Just have a read on other encoder forums about the problems with CUDA & DXVA and you will soon realize that GPU processing is not all that it is cracked up to be.

I totally agree with HB that they do not support this kind of processing. It is fraught with problems because of the reliance of the drivers/implementation of the manufactures and opens up huge support issues!!
Thank you. Seriously, thank you. For taking the time to research the issue and try to understand why it wouldn't work. You have no idea how many people complain about handbrake's lack of CUDA/etc support and that zomg it's like just as good as x264 so why can't handbrake use it?!?

It's cool in theory, and might be great down the road, but GPU accelerated encoding needs a lot more time to bake before it'll be of great use.

Motley
Posts: 1
Joined: Sat Jun 04, 2011 6:00 pm

Re: Sandy Bridge

Post by Motley »

Well except when you have been spoiled by 400+ FPS encoders, it's hard to go back.

User avatar
s55
HandBrake Team
Posts: 9785
Joined: Sun Dec 24, 2006 1:05 pm

Re: Sandy Bridge

Post by s55 »

If you want faster encoding, use faster settings. HandBrake is optimized to use settings that prefer quality/filesize over speed. These tools that use hardware encoding are optimized towards speed, not quality or filesize.

justinmiller621
Posts: 1
Joined: Wed Aug 10, 2011 1:25 pm

Re: Sandy Bridge

Post by justinmiller621 »

I'm sure you guys have seen this article: http://www.anandtech.com/show/4083/the- ... 0-tested/9

It presents a pretty glowing review of Sandy Bridge's Quick Sync for both performance and quality. They claim there are minute differences in quality that are more than made up for in the performance.

What are your thoughts on this?

User avatar
s55
HandBrake Team
Posts: 9785
Joined: Sun Dec 24, 2006 1:05 pm

Re: Sandy Bridge

Post by s55 »

I'm just going to quote myself...
Intel has only released a high-level API for their own encoder (which isn't any use to HandBrake. There are licensing issues, and it doesn't look like it can match x264's quality or featureset. ).
They haven't released a low-level API which would be needed for x264 to take advantage of any of the hardware in there. There hasn't been any indication that they will release one

User avatar
JohnAStebbins
HandBrake Team
Posts: 5581
Joined: Sat Feb 09, 2008 7:21 pm

Re: Sandy Bridge

Post by JohnAStebbins »

A much more thorough analysis was done by MSU. There is a free pdf download of their comprehensive codec comparison is here:
http://compression.ru/video/codec_comparison/h264_2011/

Comparisons with hardware based encoders are in appendix 1. It includes comparisons to other GPU based encoders.

It shows that x264 and quick sync run neck-and-neck on speed vs. quality benchmarks. It also shows that the other GPU based encoders are pretty awful. Basically, if you use x264's "Superfast" preset, you get output that is similar to quick sync in quality and speed of encoding.

Note that the "Superfast" preset is the second to bottom of x264's presets. It is fast, but produces inferior quality for a given bitrate to all but one other x264 preset. Quick sync appears to have no higher quality "presets".

So in addition to the licensing issues and the unavailability of the necessary documentation, there is almost no advantage to using quick sync. The only valid reason for using quick sync would be so you can use the CPU for some other compute intensive task while encoding. Gaming is out because quick sync uses GPU resources (and intel GPUs suck at gaming anyway). I'm not sure what else you would want those CPU cycles for, but it would have to be pretty niche.

Post Reply