Intel® Media SDK 2014 for Clients

[gmb]

TU1 is nonsense, better use TU4. I have seen worse quality with TU1 in some cases and in general quality is practically the same in screenshot direct comparisons. It's not worth it since TU1 is much much slower. Trellis can help in some videos but here as well I have seen quality regression in some cases. ICQ_LA has a bigger advantage is dark videos, sometimes it's not better than ICQ but in darker video scenes the difference can be huge.

[gmb]

gop-ref-dist=4:target-usage=4:extbrc=0:mbbrc=0:gop-pic-size=0:num-ref-frame=0:lookahead=1


ref-dist 4 doesn't work with the above command line, Handbrake still using ref-dist 3. Also extbrc doesn't work but not sure about the cause, could be a driver thing as well.


Driver related, extbrc doesn't work in QSTranscode. Looks like there is a bug in Intels driver.

[Deleted User 11865]

gop-ref-dist=4:target-usage=4:extbrc=0:mbbrc=0:gop-pic-size=0:num-ref-frame=0:lookahead=1


ref-dist 4 doesn't work with the above command line, Handbrake still using ref-dist 3.

We insert keyframes at chapter marker points in a way that's was not really intended by the Media SDK team, and this causes all sorts of issues with B-pyramid. So we force-disable B-pyramid when chapter markers are enabled (until I can implement a proper fix). That means modifying either of GopRefDist or GopPicSize, and when we don't know GopPicSize (here, it's 0), we modify GopRefDist instead.

Also extbrc doesn't work but not sure about the cause, could be a driver thing as well.

Please define "doesn't work".

[gmb]

Doesn't work means no effect, it is VBR without extbr or mbbrc.

[Rezal]

TU1 is nonsense, better use TU4. I have seen worse quality with TU1 in some cases and in general quality is practically the same in screenshot direct comparisons.

I have done multiple subjective and objective comparisons, and so far TU1 and trellis3 has always won slightly. This probably depends a lot on the input material, too. Should speed ever become a concern again I will go TU4 for sure, but for now I can still encode at more than 120 fps. While doubling that is nice, it is diminishing returns, as most of my files are only about 20 minutes long.

Also, has anybody been able to actually use adaptive I/B? Turning them on or off always produced identical output so far.

[gmb]

Slightly better for a more than twice as slow encoding speed in comparison to TU4, that's a horrendous efficiency. And to make it even worse it can be worse in quality. TU4 is much more stable and much faster as well. The gopsize has a big effect, hence why it's just unreal that Handbrake is using such a poor size on default based on a Intel recommendation. People often moan about Quicksync quality but it's no surprise when even Handbrake doesn't utilize Quicksync in the best possible way. Aanandtech's Haswell review is a good example, these peoples use Handbrake QS how it is in default state. They don't change the goppicsize to make it more comparable to x264.

[gmb]

Here a good example, in occasional frames TU1-TU2 is far off. With TU4 I never saw such a huge loss.


TU4 204 fps
http://s1.directupload.net/images/140317/zvliftli.png

TU1 trellis 93 fps
http://s14.directupload.net/images/140317/kasiuin3.png

TU1 trellis 3 84 fps
http://s7.directupload.net/images/140317/tavyzgku.png

[Rezal]

This is what I'm dealiing with:
http://imgur.com/a/9Wr7L
TU1 with IPB trellis is first.

While TU4 is slightly better sometimes, it can also be much worse in other scenes for my material. Encoding speed still around 130 fps, TU4 would not even save me 5 minutes for 20 minute video at 60 fps.

[gmb]

Latest beta switched to final: https://downloadcenter.intel.com/Detail ... ldID=23714

[Rezal]

Will upgrade soon, maybe adaptive I/B will work with these...

Edit: Still the same output.

[Rezal]

With the final out for well over two weeks now, has anybody had success in getting adaptive I and B frames to work?

[Deleted User 11865]

If you haven't noticed a difference, maybe it's still not implemented.

[Rezal]

Yeah, that is what I suspect now...

[Deleted User 11865]

It does look like it has no effect for now. I'm going to (finally) update the wiki page today, but will leave them out as there's little point in documenting not-yet-implemented options.

[Deleted User 11865]

https://trac.handbrake.fr/wiki/QuickSyncOptions

There (basically just updated the wording a bit, reordered some options, and added force-cqp). I left both adaptive I/B and lookahead downsampling out as the former isn't yet implemented, and the latter may not be either.

But if you care about compression efficiency, the default values we set (for these options, that is) should hopefully give the better results, and if you prefer speed, you will probably want to disable the lookahead or use a higher target usage than simply downsample the lookahead or simplify the GOP structure.

[gmb]

How can I enable adaptive I/B? I would like to try it out if there is a difference.

[Deleted User 11865]

It doesn't to be implemented yet (or at least the option isn't).

[Rezal]

The commands are adaptive-i=<boolean> and adaptive-b=<boolean>, but as it has been said, it seems to be not yet implemented. If you find a way to generate different output, let us know.

[Rezal]

New drivers have been released, no changes in my test.

[gmb]

[05:46:49] CPU: Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz
[05:46:49] - Intel microarchitecture Haswell
[05:46:49] - logical processor count: 4
[05:46:49] OpenCL device #1: Intel(R) Corporation Intel(R) HD Graphics 4600
[05:46:49] - OpenCL version: 1.2
[05:46:49] - driver version: 10.18.10.3621
[05:46:49] - device type: GPU
[05:46:49] - supported: YES
[05:46:49] Intel Quick Sync Video support: yes
[05:46:49] - Intel Media SDK hardware: API 1.10 (minimum: 1.3)
[05:46:49] - Intel Media SDK software: API 1.8 (minimum: 1.3)

API 1.10 instead 1.8? Is this a bug or valid? Driver is from here: http://downloadmirror.intel.com/23886/a ... 0.3621.zip

[gmb]

Just noticed that Media SDK 2014 R2 is available.

Intel® Media SDK 2014 R2 introduces API version 1.9. This version is backwards compatible with the previous API version 1.8.

But 1.10 makes no sense, next step should be 1.9 according to this.

[Deleted User 11865]

Intriguing. Though it may take longer than usual for this to be supported, I'm busy enough plus also several bugfixes and miscellaneous code path validations have been delayed forever and take some precedence over new features.

[gmb]

I don't see new interesting encoding related things in the changelog. QSTranscode reports API 1.10 with this driver as well so it could be a mistake from Intel.

[zaphodx77]

Adaptive I & B frames is working with API 1.10. This partial log is from Vidcoder-Beta using libhb_svn6190_x64.

[19:09:29] hb_init: starting libhb thread
[19:09:29] CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
[19:09:29] - Intel microarchitecture Ivy Bridge
[19:09:29] - logical processor count: 8
[19:09:29] OpenCL device #1: Intel(R) Corporation Intel(R) HD Graphics 4000
[19:09:29] - OpenCL version: 1.2
[19:09:29] - driver version: 10.18.10.3621
[19:09:29] - device type: GPU
[19:09:29] - supported: no
[19:09:29] Intel Quick Sync Video support: yes
[19:09:29] - Intel Media SDK hardware: API 1.10 (minimum: 1.3)
[19:09:29] - H.264 encoder: yes
[19:09:29] - preferred implementation: hardware (any)
[19:09:29] - H.265 encoder: no

[19:09:29] + encoder: H.264 (Intel Media SDK)
[19:09:29] + options: tu=1:ref=0:gop-ref-dist=0:gop-pic-size=0:vbv-bufsize=78125:vbv-maxrate=62500:extbrc=1
[19:09:29] + quality: 28.00 (QP)

[19:09:29] encqsvInit: using encode-only path
[19:09:29] encqsvInit: TargetUsage 1 AsyncDepth 4
[19:09:29] encqsvInit: GopRefDist 3 GopPicSize 256 NumRefFrame 2
[19:09:29] encqsvInit: BFrames on
[19:09:29] encqsvInit: AdaptiveI on AdaptiveB on
[19:09:29] encqsvInit: RateControlMethod CQP with QPI 28 QPP 30 QPB 32
[19:09:29] encqsvInit: CAVLC off
[19:09:29] encqsvInit: H.264 profile High @ level 3.0
[19:09:29] qsv_enc_init: using 'hardware (1)' implementation, API: 1.10

[Deleted User 11865]

How do ou know it's working (i.e. have you compared the output with it enabled vs. disabled, e.g. via the byte count in the mux: section at the end of the log)?