Plans for Quicksync on Mac?

[abrax5]

Hi Handbrakers,

I am looking at the Quicksync on Mac patches on github
https://github.com/galad87/HandBrake-Qu ... 55739d5945

What's the plan with this branch? Is this going to be merged into a release or beta version at any time soon?
Are there binaries available for this branch? What's the current maturity level?

And I am curious abot: Where did you get the exact parameter settings from to require/enable hardware encoding support? [1] I am working on the gstreamer applemedia plugin and it would be good to know more details about the configurable parameters, if you can share such.

[1] https://github.com/galad87/HandBrake-Qu ... 39e7a0bR83

Thanks,

Abrax5

[s55]

A second implementation for the same encoder is not desirable. I'd much rather wait and see what Intel can come up with on that side so from this perspective it's not likely to make it into our code.

I believe it was just an experiment to see what it was capable off and last I heard, it's more limited compared to the official SDK

[Ritsuka]

It was more of an exercise with VideToolbox. The most useful part was the video decoder acceleration, but the libav architecture is a bit flawed and so it wouldn't work for .ts and .m2ts (my intention was to use it to accelerate my blu-ray encoding).

I think it is as good as it can get, the parameter to enable QuickSync on 10.8 were reversers engineered (but you should look at 10.9 docs). But the configuration options are in Apple style (meaning few options or no options at all), there are one or two parameters left to implement, but nothing big. The only documentation of VideoToolbox is in the header files.

Eventually I saw I could get better quality with x264 at the same fps, so I lost the little interest I had left.

[abrax5]

Thanks for your replies, I understand the background of the experiment.

A second implementation for the same encoder is not desirable. I'd much rather wait and see what Intel can come up with on that side so from this perspective it's not likely to make it into our code.

You could see the VT based encoding as a separate encoder, right? At the hardware level, they probably resemble each other, however, the software stacks around the hardware are likely very different. I would be much in favor of adding VT support as another encoder option.

If I compare x264 (at medium speed/quality tradeoff) and VT with HW acceleration, I get much better frame rates for VT. Wouldn't this be useful for many users?

Running two gstreamer pipelines on a 20 minutes 640 x 352 video one with VT, one with x264, on a mid 2011 mac mini (SandyBridge, afaik), and using VT with baseline profile, I get:

HW accelerated VT: 4m11.191s
Software x264: 25m15.651s

These are wall clock times, CPU times for software x264 were ~98 minutes and ~1m41.992s for VT in this case.
So, in addition to being roughly 6 times faster, the fan isn't even spinning.

[s55]

So you used Fast settings on one encoder, and slow on another and wondered why there was a difference?

Ultrafast is more comparable, especially on sandybridge. That difference will shrink substantially.


If/when we implement QuickSync on Mac, it'll be through the official SDK.

[abrax5]

Okay, I tested with ultrafast and superfast - quite impressive. And I admit I didn't expect this kind of speed.
The point I was aiming to make is that the GPU acceleration is likely superior to anything you do on the CPU - but these higher settings on x264 are impressive. Do you know how they achieve these, OpenCL, aggressive SIMD?

I hear you re VT support. Let's see whether there'll be such an SDK.

[s55]

x264 is heavily optimized (The Various flavors of SSE, AVX, AVX2 and numerous others).


As always, it's a game of tradeoffs. Speed, Quality, Fieszie. Pick 2

You'll find x264 gives you an extreme amount of control that can result in speeds of 0.1 fps to over 2000fps on the same system (assuming your running on good hardware). Your sacrificing or gaining quality and lower filesizes depending on what end of the spectrum you go for.
QuickSync also has a range of options that can take it from extremely fast to rather slow but it doesn't have the same degree of features and control that x264 does. While it can't match quality, it can be faster in many cases, especially on slower CPUs and it's lower power consumption but ofcourse, it comes back to trade offs.

Basically, find something that works for you and go with it. HandBrake optimises towards quality and fileszie with x264 by default.

Either way, we want it supported in the Mac builds too, just done in the right way.

[mduell]

The point I was aiming to make is that the GPU acceleration is likely superior to anything you do on the CPU

Not for video encoding. The GPUs are one trick ponies (speed speed speed) for video encoding, the CPU encoders are quite flexible, and just as fast.

[gmb]

Ultrafast isn't comparable because it's extremely pixelated and extremely bad in motion. For x264 super fast is the fastest usable preset.

[s55]

He's running on SandyBridge. There is a large difference in quality Sandy -> Haswell, (or even IvyBridge).

SandyBridge encodes look really bad.

[gmb]

Quicksync output isn't pixelated not matter which generation. Ivy Bridge better than Sandy Bridge regarding quality? What is different?

[collegeitdept]

Any updates for Quick Sync on the Mac? It doesn't look very likely that Intel will release an official port of Media Kit SDK on the Mac. So maybe a reversed engineered port that people were working on would suffice. Any improvements from partial use of Quick Sync on the Mac would be a tremendous benefit to Mac users (even if it's not as fast or as good as the Windows version).

Thanks.

[Deleted User 11865]

Not as much as you'd think, especially for HD where decoding will bottleneck, so encoding won't be as fast as one could expect, and CPU usage will be very high since decoding will still run on the CPU.

[s55]

look very likely that Intel will release an official port of Media Kit SDK on the Mac

Intel are typically quiet until they announce it publically. We don't do NDA's so we don't know any more than you at this point.

Just a waiting game I'm afraid.