Intel QuickSync Decoder - HW accelerated FFDShow decoder with video processing

[ajp_anton]

Westmere was weird. At least on desktop, don't know about mobile. i5 existed only as overpriced dual-cores with no real advantage over i3, and i7 only existed as the hex-core on LGA1366 (no iGPU).

[CruNcher]

@ Egur

https://forum.doom9.org/showpost.php?p=1557962&postcount=9048

is this correct FFdshow Quicksync and Lav Video Quicksync both doesn't reach yet Intels own Reference implementation Efficiency ?
which according to these benchmarks is ~2 higher then Mainconcepts Decoder Core running on the CPU alone and lowering the CPU utilization @ the same time by over 50% or does the Intel Decoder switch between DXVA and Quicksync depending where it renders to (that would be actually very smart) ?

ILK is IronLake - the code name for Westmere's chipset (or integrated north bridge, don't remember),
The difference between the various Media SDK DLLs is the API they support. The newer the API, more features are supported.
I use MSDK API 1.1 which correlates to SNB. I don't have a Westmere (32nm i3/5/7 Core Processor) so I'm not sure what API it supports - probably API 1.0.
IvyBridge's driver has a similar DLL (libmfxhw32-i2.dll). It supports API version 1.3 (same as the latest MSDK 2012 version). The latter DLL does not work with SNB.

This opens another question general improvements done in newer APIs (non really hardware dependent, bugfixes, quality improvements,performance improvements) will be backported between the Driver or stay new API exclusive so you not going the same way as Nvidia i guess with their UDA ?
As you say Ivy Bridge will have it's own Driver Mfx components not backward compatible with SNB ?

[egur]

@ Egur

https://forum.doom9.org/showpost.php?p=1557962&postcount=9048

is this correct FFdshow Quicksync and Lav Video Quicksync both doesn't reach yet Intels own Reference implementation Efficiency ?

I use similar code as the the Media SDK sample. The performance differences are that the sample will work in pure DXVA and my code (within ffdshow or LAV) will cause the frames to copied at least twice: GPU->CPU, CPU->Renderer's sample. In high bitrates I can achieve similar performance.

v0.27 performance will be much better on high bitrate clips BTW. It seems I can't optimize for both low and high bitrates and the latter are more important.
Who cares if a clip plays at 1000fps or 1100 fps when a high bitrate clip can play at 270fps instead of 160 (real numbers BTW)?

This opens another question general improvements done in newer APIs (non really hardware dependent, bugfixes, quality improvements,performance improvements) will be backported between the Driver or stay new API exclusive so you not going the same way as Nvidia i guess with their UDA ?
As you say Ivy Bridge will have it's own Driver Mfx components not backward compatible with SNB ?
The same DLL is able to support several API levels. e.g. SandyBridge's HW DLL can support MSDK API 1.1 and 1.0.
An API is basically a collection of functions, types and constants. An API may change during alpha/beta stage but doesn't after it's released.
The actual implementation of an API can change over and over as long as the documented functionality of the API stays the same.

IvyBridge driver (API 1.3) should run all code built with API 1.1 and 1.0. If it doesn't, then it's a bug.
Actual usage is quite simple. During initialization, my decoder asks the MSDK for a minimum API level. The MSDK searches for the HW DLL and returns success if the API is the same or higher than what I requested.
When I'll add features specific to IvyBridge (or future products), these features will be enabled/disabled at runtime depending on the API level.

[CruNcher]

@Egur

the Mpeg-2 result differences (Performance) i (hopefully) carefully benched seem pretty huge

Lav Video Quicksync:

http://img221.imageshack.us/img221/1778/lavvideoquicksync1.png

FFdshow Quicksync:

http://img513.imageshack.us/img513/2123/ffdshowquicksync1.png

Lav Video DXVA2

http://img826.imageshack.us/img826/6760/lavvideodxva2.png

Intel SDK Decoder Quicksync ? (pretty impressive)

http://img836.imageshack.us/img836/8784/intelmpeg2.png

Mainconcept CPU (Slices)

http://img198.imageshack.us/img198/7311/mainconceptmpeg2.png

Mainconcept CPU (Frames)

http://img819.imageshack.us/img819/7028/mainconceptmpeg2smpfram.png

[egur]

@Egur

the Mpeg-2 result differences i (hopefully) carefully benched seem pretty huge
...

You should wait with the compares until I release v0.27. I already reported a performance issue which I've already fixed. Just a few days... :)

[CruNcher]

You should wait with the compares until I release v0.27. I already reported a performance issue which I've already fixed. Just a few days... :)

Ok the ffdshow,lav video quicksync/dxva2 Kernel Peaking though looks strange compared to the Reference Decoder :)

[egur]

Version 0.27 beta is out with the following changes:
* Optimized code path to high performance on high bitrate clips.
* FFDShow rev4322

Downloads
* For the latest cutting edge FFDShow builds download my builds Intel QuickSync Decoder SourceForge home page (http://sourceforge.net/projects/qsdecoder/)
* FFDShow-tryout site (http://ffdshow-tryout.sourceforge.net/download.php)
* LAV Splitter builds (http://forum.doom9.org/showthread.php?t=156191)

[CruNcher]

@ Egur

this doesn't look good it looks even more bad then before now :(

now:

http://img7.imageshack.us/img7/8203/ffdshowquicksync027kern.png

before:

http://img513.imageshack.us/img513/2123/ffdshowquicksync1.png

intel reference:

http://img836.imageshack.us/img836/8784/intelmpeg2.png

[egur]

Do you mean the low CPU utilization, right?

Strange, doesn't reproduce on my machine on other clips. Also tried a high bitrate m2ts file. Splitter is LAV 0.46 in my case.
A CPU usage of 13% (e.g. 1 core at 100%) is a little low. Should be 23-30% on an 8 thread machine.

Can you share the clip?
Do you have similar issues with other clips?

[CruNcher]

Do you mean the low CPU utilization, right?

Strange, doesn't reproduce on my machine on other clips. Also tried a high bitrate m2ts file. Splitter is LAV 0.46 in my case.
A CPU usage of 13% (e.g. 1 core at 100%) is a little low. Should be 23-30% on an 8 thread machine.

Can you share the clip?
Do you have similar issues with other clips?

I mean the overall Performance of the Reference Quicksync Decoder cant be compared with ffdshow-quicksync @ least for Mpeg-2 in General it already fall into my eye when comparing vs DXVA and power consumption now i looked deeper and saw this Kernel Explosion of ffdshow-quicksync and Generally in Performance that's not a good Sign.

According to the data both use Quicksync i could have understood the difference with Interlaced due to the ffdshow overhead maybe (but even then this is pretty heavy, it remembers me of some heavy firefox problems with kernel Explosions) but this is progressive :(

I didn't looked deeper yet in the H.264 performance differences and overhead

http://img684.imageshack.us/img684/9558/performanceefficiencyin.png

[nevcairiel]

You cannot compare the reference decoder to Erics QuickSync, because the reference does not copy the data back from the GPU.
Also, MPEG-2 isn't a good format to benchmark, its decoding is too simple. Use H.264.

The memory copy from the GPU to the CPU is simply a kernel operation.

I do however agree that Eric seems to be "over optimizing" the thing. Find a state that works well and stop touching it, its fast enough. :P
I haven't tested 0.27 yet, so i cannot comment how well it works.

[CruNcher]

ah so it's Quicksync without copy back but not DXVA that explains a lot

http://img828.imageshack.us/img828/5999/intelmediacheckerquicks.png

i just used it to manipulate the surface on the EVr renderer in realtime with ffdshow as NV12 input and it works without any copy back fully accelerated

though for what specific reason we do use copy back again for Playback wasn't it initially subtitles or overlays in General this seems pretty outdated doesn't it (since Nt 6) ?

And i really wonder who uses Lav Video or ffdshow-quicksync for encoding ?

[egur]

Nev is right.
I'd like to further explain.
My decoder copies the frame from the GPU. ffdshow copies the frame again to the buffer supplied by the renderer.
This is because ffdshow performs various video processing algorithms on the first copy and converts it to the colorspace/format of the renderer on the second copy.
LAV decoder might do something similar.

The MSDK filter is very basic, it doesn't perform any video processing or format conversions so it's operation is much simpler. It's a simple example on how to use the MSDK within a DirectShow environment. Making it complex would render it less effective for developers...
Since it's a DirectShow filter, it can negotiate with the renderer so it will allocate the frame buffers instead of the renderer. For DXVA this is a must. I don't remember if it's done when it's not connected to a non-DXVA renderer.

The various MSDK decoder filters should have similar performance to a pure DXVA decoders.

In my opinion, working in a restrictive SW architecture like DXVA cripples and significantly complicates everything. This is one of the main reasons I started this project - abstract the HW and simplify things so everyone can use the HW acceleration. This comes at a small performance price as you've noticed. You can't have the cake and eat it ;)

[nevcairiel]

though for what specific reason we do use copy back again for Playback wasn't it initially subtitles or overlays in General this seems pretty outdated doesn't it (since Nt 6) ?

Why would i want to limit myself with silly DXVA restrictions when current QuickSync decoder still does 300+ fps in copy back mode?

After all, the important part is playback (at least for me), and if i can benchmark it at 300 fps, doing 24 fps in playback (or even 60 fps) is done at nearly no load at all.

[CruNcher]

Yes sure but even if you compare it to Lav Video DXVA2 Copy Back there are pretty big differences

and you doesn't push the kernel or cpu too that extreme and still reach better FPS and this is automatically also visible in load and Power Consumption comparing both side by side also if taken Lav Video Quicksync it looks the same.

Lav Video DXVA2 Copy Back

http://img826.imageshack.us/img826/6760/lavvideodxva2.png

FFdshow Quicksync Copy Back

http://img513.imageshack.us/img513/2123/ffdshowquicksync1.png

Lav Video Quicksync Copy Back

http://img221.imageshack.us/img221/1778/lavvideoquicksync1.png

and the only real DXVA problem are Reference Frames and if people dont accept the rule H.264 Profile setting i dunno to blame Microsoft for it i never experienced a problem with it in the wild except when Anime guys Encode stuff ;)

[egur]

Setup:
* GraphStudioNext, 10 passes, NULL renderer.
* 10 clips from http://forum.doom9.org/showthread.php?t=163110
* FFDShow rev4322 (QS 0.27) 32 bit.
* Windows 7 Ultimate 64 bit, Aero on.
* Intel driver: v2622.
* Lucid Virtu: not installed.
* CPU: i7-2600 (3.4GHz), power management on. HD 2000 (GT1) iGPU.
* DDR3 @1333MHz (nothing fancy)
* Score are lowest/avg/highest frame rates for the entire clip.
* Note - the min score is due to graph contruction time which affects short clip benchmarks. The most interesting results are the highest FPS as the median score is very close to them.
1.Twinpeaks1080p30fpsRef2-27Mbps.mov
279/323/340

2.Samsung.Demo.Oceanic.Life-1080p30fpsRef16-40Mbps.mkv
268/273/278

3.Basketball-1088p60fpsRef8-10Mbps.mkv
349/361/368

4.Girls.YoonYoon-1080p60fpsRef5-21Mbps.mkv
338/343/348

5.Birds_1080p60fpsReF2-30Mbps.mp4
316/324/332

6.Cat-1080p60fpsRef4-25Mbps.m2ts
324/323/332

7.Vortexx_1088p24fpsRef3-109Mpbs.mp4
114/129/131

8.Birds_1080p24fpsRef4-112Mbps.mkv
122/134/137

9.Ducks.Take.Off.1080p30fpsRef5-108Mbps.mkv
138/148/154

10.Crowd.Run.1080p25Ref4-116Mbps.mkv
109/121/125

[egur]

Yes sure but even if you compare it to Lav Video DXVA2 Copy Back there are pretty big differences

and you doesn't push the kernel or cpu too that extreme and still reach better FPS and this is automatically also visible in load and Power Consumption comparing both side by side also if taken Lav Video Quicksync it looks the same.

...
and the only real DXVA problem are Reference Frames and if people dont accept the rule H.264 Profile setting i dunno to blame Microsoft for it i never experienced a problem with it in the wild except when Anime guys Encode stuff ;)
With DXVA copy back you only do 1 copy not 2.

If both I and Nev change our code (not trivial on both sides and will dirty both our SW designs) we can cut down the extra copy or even work in pure DXVA (no copy). I think it's NOT worth the effort. If someone wants the pure DXVA route there are several alternatives.
Since memory bandwidth and HW decode performance is guaranteed to increase, the current solution is scalable to very high bit rate/ frame rate video.

[NikosD]

Setup:
* GraphStudioNext, 10 passes, NULL renderer.
* 10 clips from http://forum.doom9.org/showthread.php?t=163110
* FFDShow rev4322 (QS 0.27) 32 bit.
* Windows 7 Ultimate 64 bit, Aero on.
* Intel driver: v2622.
...
...
...
...

1.Twinpeaks1080p30fpsRef2-27Mbps.mov
279/323/340

2.Samsung.Demo.Oceanic.Life-1080p30fpsRef16-40Mbps.mkv
268/273/278

...
...
...

10.Crowd.Run.1080p25Ref4-116Mbps.mkv
109/121/125

Huge performance difference from my results, back then (http://forum.doom9.org/showthread.php?t=163110)

The benchmark tool is different and the QS HW works in different frequencies for Core i5-2400 vs Core i7-2600, but the advantage is more than clear.

Well done!

I do hope to see current generation QS HW (SandyBridge), to become capable in HW acceleration of 4K files, with the help of new drivers.

It's a pity to waste so fast and efficient resources to just 1080p.

I don't believe this is going to happen before IvyBridge.

But I do hope that such a large company as Intel, will not afraid of loosing sales of new products (Ivy) by upgrading the old ones (Sandy).

I believe the Intel's drivers team will give us an Easter egg when 4K capable Ivy's drivers will be released, supporting SNB as well for that feature.

:thanks: in advance

[CruNcher]

Did you looked into the new DXVA Checker
there are now 2 VLD ClearVideo Device entries for VC1 ?

ModeVC1_VLD_2_ClearVideo: DXVA2, 720x480 / 1280x720 / 1920x1080
ModeVC1_VLD_ClearVideo: DXVA2, 720x480 / 1280x720 / 1920x1080

also you can create your own Device with resolution now (not sure if you can workaround driver limitations that way but im currently trying if it has any effect) ;)

http://img208.imageshack.us/img208/922/devicecreationfailed.png

[egur]

Huge performance difference from my results, back then (http://forum.doom9.org/showthread.php?t=163110)

The benchmark tool is different and the QS HW works in different frequencies for Core i5-2400 vs Core i7-2600, but the advantage is more than clear.

Well done!

10x

...
But I do hope that such a large company as Intel, will not afraid of loosing sales of new products (Ivy) by upgrading the old ones (Sandy).
In my opinion, if people buy Sandybridge now and not wait for IvyBridge, Intel will probably make more money in the long run as that SandyBridge will become outdated faster than IvyBridge and that user will buy the next PC sooner.

[CruNcher]

@ Egur
hmm i just realized ffdshow-pp doesn't work with the Quicksync Decoder ?

it works with the Intel Reference Decoder + ffdshow (though their seems to be a bug somewhere pading line)

http://img46.imageshack.us/img46/9536/pprealtimesppintelrefer.png

[clsid]

PP only works for certain formats. It is simply skipped for H.264.

[CruNcher]

thats Mpeg-2, with Quicksync as Decoder i dont get SPP to work to pressure 1/4 of the consumption of cores completely :)
activating ffdshow-warpsharp also crashes though also on the surface with another decoder awarpsharp works
High Quality aWarpsharp crashes with Quicksync as Decoder works with another

[nevcairiel]

I did my own peformance series, and i'm kind of pleased that my results are higher then Erics. :D

* GraphStudioNext, 5 passes, NULL renderer, first result not used.
* 10 clips from http://forum.doom9.org/showthread.php?t=163110
* Windows 7 Professional 64 bit, Aero on.
* Intel driver: v2622, no Lucid Virtu
* CPU: i7-2600k (3.4GHz), power management on. HD 3000 (GT2) iGPU.
* DDR3 @1600Mhz
* All Scores are averages

https://docs.google.com/spreadsheet/ccc?key=0Ajo8vvjNtaZ5dC1abjBSeVlmcnZXSjYwampfamk3ZWc

Note that at these speeds any little activity on the PC can alter the scores, so difference of 1-2 FPS are negligible.
I'm happy to report that the speed has increased basically across the board with QS 0.27 (and the changes i did for yet unreleased LAV 0.47)

I'm still a bit confused by that Samsung clip, why does it behave to special.

[CruNcher]

People shouldn't concentrate on x264 bitstreams alone if im not wrong all of those 10 clips are x264 bitstreams ;)

@Nev
could you please post those results outside of Google Docs ;)

[nevcairiel]

People shouldn't concentrate on x264 bitstreams alone if im not wrong all of those 10 clips are x264 bitstreams ;)
H264 is the most complicated format of the three to decode, everything else is irrelevant and will most likely just run faster.
Its also the most popular format.

Also, no-one really came up with a good set of test samples for VC-1. :p


@Nev
could you please post those results outside of Google Docs ;)
Nope. :)

[wanezhiling]

A new driver 8.15.10.2626 (http://www.necacom.net/index.php?option=com_content&view=article&id=5931:intel-hd-graphics-i357-gen23-drivers-version-815102626&catid=56:intel&Itemid=82)

IVB seems to be supported.:p
http://i.imgur.com/cVxmd.png

[CruNcher]

ui a leak with a official release date in the readme ? :) ?

[wanezhiling]

:pI think so.

Good night for me.

[CruNcher]

could be no bootkit virus indeed ;)
http://server.zdnet.com.cn/server/2012/0214/2078751.shtml

http://www.station-drivers.com/page/intel%20graphics.htm ( i don't trust this other site ;))

[egur]

A new driver 8.15.10.2626 (http://www.necacom.net/index.php?option=com_content&view=article&id=5931:intel-hd-graphics-i357-gen23-drivers-version-815102626&catid=56:intel&Itemid=82)

IVB seems to be supported.:p
http://i.imgur.com/cVxmd.png

It's probably a leaked IVB driver. Will work on SNB. I personally tested with 2639 which is a little newer (also IVB driver).
Strange enough, the 2622 driver (SNB) which was available on Intel's website is not available anymore. Newest one is 2509. The 2559 driver which was available till recently is also gone.

[nevcairiel]

It's probably a leaked IVB driver. Will work on SNB. I personally tested with 2639 which is a little newer (also IVB driver).
Strange enough, the 2622 driver (SNB) which was available on Intel's website is not available anymore. Newest one is 2509. The 2559 driver which was available till recently is also gone.

The 2559 is still available when you look at one of their 6 series desktop boards.

Their driver policy is weird..

[CruNcher]

Yeah intels Driver releasing is weird again drivers gone that where official the 2nd time now, though that with the boards could be understandable in tested drivers for their specific bios (optimized the best way possible) :P

[egur]

The 2559 is still available when you look at one of their 6 series desktop boards.

Their driver policy is weird..

I looked at the main download center and couldn't find it.
The 2622 driver (and others) can be found here (http://drivers.softpedia.com/progDownload/Intel-HD-Graphics-Display-Driver-152254642622-for-Vista64-Windows-7-x64-Download-149821.html)
I downloaded it and it was identical to my copy.

[CruNcher]

i mean even if intel forgot some restriction or did put some in the newer driver concerning their PVP or a bug it would be pretty dumb to believe after a official driver release the driver is out of history (and do like it never existed) ;)
Such silent delete operations only make some people more suspicious whats going on Nvidia @ least learned to explain why they remove drivers (if the reasons are the truth or not isn't really important, just tell them something and don't just remove and forget official released driver) ;)

PS: I did several load tests now and i have to say Microsofts Mpeg-2 Decoder rocks in latency it seems heavily optimized for threaded frameworks :) intels reference decoder latency under pressure looks odd against it, though pretty much no other ISV can cope with it is so damn stable (despite the missing 4:2:2 support, and not so great benchmark results). Pressuring the cores and getting such low latency without any heavy render brake ups is just amazing http://img59.imageshack.us/img59/3185/microsoftmpeg2latency.png http://www.mediafire.com/?gbk85ypx7alv2bu (yup you don't imagine it it's still sync, and yep there are different low latency timers running simultaneously, not forgetting the capture task) though no Haiku http://vimeo.com/33197748 here ;)

@Egur

Only Intels Reference Decoder shows this issue with ffdshow (green line right into the content)

http://img46.imageshack.us/img46/9536/pprealtimesppintelrefer.png

Only Possible with Microsofts Decoder (Playback Performance) :(

http://www.mediafire.com/?nm948sww3lyhwt7

ahh no wait that is a surprise MPC-HCs Internal Mpeg-2 Decoder is also capable of those low latencies and performs even better with this presure and core distribution is also more sane :)

http://www.mediafire.com/?ipik22iyiumpyg5 (perfect)

[RBG]

CruNcher

I am just curious, why are you paying so much attention to mpeg-2, isn't it an outdated format?

[roytam1]

CruNcher

I am just curious, why are you paying so much attention to mpeg-2, isn't it an outdated format?

Don't you know MPEG-2 is used in digital video broadcasting standard?

[ryrynz]

A new driver 8.15.10.2626 (http://www.necacom.net/index.php?option=com_content&view=article&id=5931:intel-hd-graphics-i357-gen23-drivers-version-815102626&catid=56:intel&Itemid=82)
[/url]

Didn't work for me, my system does not meet the minimum requirements for whatever reason, also won't update manually, oh well.

[egur]

With the exception of testing purposes, I advise against installing unreleased drivers. Do this at your own risk.
They are aimed at ISVs and OEMs.

[CruNcher]

@Egur

It looks like Intels Mpeg-2 Reference Decoder is shifting chroma when connected to ffdshow-quicksync ?

[egur]

@Egur

It looks like Intels Mpeg-2 Reference Decoder is shifting chroma when connected to ffdshow-quicksync ?

Do you mean that ffdshow is shifting chroma? Then open a sighting in the ffdshow thread. If not, then I don't understand.

[CruNcher]

yes no it only happens with intels decoder though so far only for this stream, also this SPP restriction for Quicksync decoding is really odd :D

[egur]

yes no it only happens with intels decoder though so far only for this stream, also this SPP restriction for Quicksync decoding is really odd :D

Although my code started from the reference decoder, I used it for reference, I had to change things and add features to make it work like it works today.

Regarding ffdshow's lack of support for various video processing, it might be what clsid pointed out, that some algorithms do not support NV12 which is the native output of the QS decoder (or any other HW decoder for the matter).
I'll need to take a deeper look.

[RBG]

Don't you know MPEG-2 is used in digital video broadcasting standard?

H.264 is also used in DVB... It's not like I don't know the standards or asking a general question, it is just to sate my curiosity, since I myself see no reason in benchmarking MPEG-2, but that's just me, I wanted to know another point of view.;)

[TPoise]

As a mobile specific user, the lowest CPU usage (which should correspond to the lowest wattage/battery usage) is MOST important for me, as long as the decoder can do 1x realtime with no dropped frames. So if I had to decide between an LAV decoder that could do 13x at 50% cpu or a QuickSync-based decoder that could only do 12x at 13% CPU, then the choice is pretty clear for me.

So, why should the performance really matter when you're several magnitudes higher than realtime, other than just for optimization's sake? Transcoding? I haven't seen any transcoder out in the wild that uses QS for decoding.

[nevcairiel]

LAV has a QuickSync based decoder. :p
Optimizing the speed of course has advantages, if you can increase the top speed, you reduce resource usage on real-time speed, its just that simple.

Realtime playback of typical Blu-ray material is at around 2-3% CPU for me, and that includes audio decoding as well as all other components in playback. :) (that is with LAVs QuickSync, i bet ffdshow is the same)

[CruNcher]

As a mobile specific user, the lowest CPU usage (which should correspond to the lowest wattage/battery usage) is MOST important for me, as long as the decoder can do 1x realtime with no dropped frames. So if I had to decide between an LAV decoder that could do 13x at 50% cpu or a QuickSync-based decoder that could only do 12x at 13% CPU, then the choice is pretty clear for me.

So, why should the performance really matter when you're several magnitudes higher than realtime, other than just for optimization's sake? Transcoding? I haven't seen any transcoder out in the wild that uses QS for decoding.


Hehe the Chinese affiliate Devs aren't as fast as they where with Nvidia (Wondershare, Xilsoft and Co, there are far to many to list them all here and most are doughters of the big ones anyways and mostly all have ffmpeg violation in common) ;) for now you only have the top ISV products (Elemental,Cyberlink,Arcsoft,Corel,MainConcept SDK) :D or (semi)* top ISVs that support it (BIT,Movavi,Mirillis,CoreAVC) i guess new stuff like freemakes (Ellora Assets) DXVA copy back decoding will be pretty much the same way defunct as Nevs copy back decoder with Intel currently ;)
Hmm though i didn't tried the crash bitstream yet on freemake though i guess it will do like the others and crash and most H.264 bitstreams i guess will also most probably show heavy decoding issues ;)

*PS: Some of the semi top ISVs are in some places better then the TOP ISVs imho, though BIT is controversial as of its ffmpeg issue same as Movavi (i forgot their company name strange russian one) ;)

http://www.intel.com/content/www/us/en/architecture-and-technology/quick-sync-video/quick-sync-video-general.html

Also a lot of other software recently got Intel HD Graphic updates it looks pretty good for Intel support wise, something that AMD also could have had so easily but no they sleeped it out and now running with fusion after it :)

[hoborg]

Hi.
Can somebody share latest "IntelQuickSyncDecoder.dll"?
Or is there a simple way how i can extract it by myself from FFDshow.exe installer?

BTW, it is possible to share IntelQuickSyncDecoder.dll between LAV video decoder and FFDshow? Both decoders are using exactly the same name for this dll.

[egur]

Hi.
Can somebody share latest "IntelQuickSyncDecoder.dll"?
Or is there a simple way how i can extract it by myself from FFDshow.exe installer?

BTW, it is possible to share IntelQuickSyncDecoder.dll between LAV video decoder and FFDshow? Both decoders are using exactly the same name for this dll.

They usually have the same dll (right click on the DLL for version number). Sometimes LAV or ffdshow use a newer version until the other picks up. Currently both use 0.27.
You said it didn't install because your iGPU is disabled? So why do you need it? You can always run the installer again when do enable the iGPU. It won't change your settings.

[amtm]

CruNcher

I am just curious, why are you paying so much attention to mpeg-2, isn't it an outdated format?

Because it's still used widely in TV broadcasting and for DVDs (you know those optical discs that still outsell Blu-Ray by quite a large margin)?

H.264 is also used in DVB... It's not like I don't know the standards or asking a general question, it is just to sate my curiosity, since I myself see no reason in benchmarking MPEG-2, but that's just me, I wanted to know another point of view.;)

You ask why people want to benchmark a format that is still widely used for video? Because they have lots of videos in that format possibly?