ffdshow tryouts project: Discussion & Development

[haruhiko_yamagata]

This affect's all ffdshow versions as far as I know. I'm currently using: ffdshow_rev4150_20111215_clsid

I am trying to playback mpeg2 videos which switch between soft and hard telecine using ffdshow's internal mpeg2 decoder + avisynth IVTC/deinterlace.

The problem is that the internal “ffdshow_source” source filter that is used to get frames from ffdshow into AviSynth is not honoring soft pulldowns when fed to the avisynth IVTC plugin (TIVTC or Decomb). It needs to behave the same way as if the video was fed from DGDecode (or any avisynth mpeg2 decoder would).

Could someone PLEASE enhance the existing "ffdshow_source" source filter to honor soft pulldowns in the same fashion when DGDecode does? I'm hopeful this will be fixed in the next beta release.

Normally, I wouldn't make a big deal about this. However, this type of mix soft/hard telecine video is extremely common in America; as, it's the encoding format used by many cableTV content providers like HBO, Showtime, Cinemax, etc; played back by millions of people (mostly on STB cableboxes).

PS: I have "Detect soft telecine and average frame durations" disabled in ffdshow in order for the IVTC plugin in Avisynth to remove 3:2 pulldown correctly to 23.976fps.

If you want ffdshow to behave like DGIndex with "Honor Pulldown Flags" option enabled, use 3:2 Pulldown "Apply pulldown" option in ffdshow's dialog. It serves hard telecined frames if the input is soft telecined.

It works if "Detect soft telecine and average frame durations" is unchecked.

[kc7bfi]

We are having issues with H.264 video and ffdshow. Is there any options for paid support with ffdshow? David

[Liisachan]

To devs:
Even after the fix in 4240, I think ffdshow crashes while doing the high-quality conversion to RGB when dithering is disabled, if the source is 8-bit. (No crash if 10-bit).

[haruhiko_yamagata]

To devs:
Even after the fix in 4240, I think ffdshow crashes while doing the high-quality conversion to RGB when dithering is disabled, if the source is 8-bit. (No crash if 10-bit).
Hi, Liisachan. Nice to see you again.
It works for me. Maybe there are more conditions needed?

[Liisachan]

Thanks, haruhiko.
Perhaps this simply means my PC is too old. On my XP Pro SP3 (Pentium4/NVIDIA Quadro FX), the crash seems to occur for any input with ffdshow RGB32 output (i.e. uncheck YV12 etc., or select RGB32 as Primary output color space), if hq-conv is used without dithering. The crash happens with MPC, MPC-HC, mplayer2, or GraphEdit. Everything is okay, though, once dithering is enabled.

The problem is, I can't reproduce the crash myself on another old (but slightly less old) XP Home SP3 machine (Core2 Duo/NVIDIA GeForce), using the exact same settings (exported and imported as .reg). Testing 4281 on both. So apparently the problem more or less depends on HW, or, as you suspected, some subtle conditions. I hope someone can reproduce this problem.

PS
rev3925 (20110709) doesn't have the above problem.

[haruhiko_yamagata]

Thanks, Pentium 4 isn't too old.
I have Pentium　4-HT, I'll try on it on Monday.

[Liisachan]

I did some more tests:
*rev4106 (2011-12-03) and before = no problem
*rev4119 (2011-12-04) and after = crash for me, if hq-conv to rgb32 is used without dithering

[haruhiko_yamagata]

I found it was crashing on single CPU (m_thread_count == 1).
fixed at rev 4285. :thanks:

[Liisachan]

Fix confirmed; it's working again in 4285 (http://www.xvidvideo.ru/ffdshow-tryouts-project-x86-x64/ffdshow-tryouts-project-svn-4285-x86-x64.html). Thank you :)

[Reino]

haruhiko_yamagata, if you can find some time, can you please have a look at the following tickets?

- Volume levels animation glitch on WavPack audio (http://sourceforge.net/tracker/?func=detail&aid=3458213&group_id=173941&atid=867360)
- Vorbis audio input bitrate incorrectly being reported (http://sourceforge.net/tracker/?func=detail&aid=3458218&group_id=173941&atid=867360)
- Feature Request: Output colorspace as-is (http://sourceforge.net/tracker/?func=detail&aid=3458249&group_id=173941&atid=867363)

[Midzuki]

haruhiko_yamagata, if you can find some time, can you please have a look at the following tickets?

- Volume levels animation glitch on WavPack audio (http://sourceforge.net/tracker/?func=detail&aid=3458213&group_id=173941&atid=867360)
- Vorbis audio input bitrate incorrectly being reported (http://sourceforge.net/tracker/?func=detail&aid=3458218&group_id=173941&atid=867360)
...

As he said some pages ago...

Sorry, I'm not interested in the audio part.

[haruhiko_yamagata]

- Feature Request: Output colorspace as-is (http://sourceforge.net/tracker/?func=detail&aid=3458249&group_id=173941&atid=867363)
I replied at SourceForge.
Sorry, my motivation for audio part has not been changed.

[haruhiko_yamagata]

I have found and reported (http://software.intel.com/en-us/forums/showthread.php?t=102671) a bug of ICL12.
I modified ffdshow slightly and x64 by ICL12 is now available.

[nevcairiel]

Everytime i read about ICL12 i can't help but wonder who really paid for it, and who just uses a pirated version....
You know, that thing isn't cheap (and the benefits of using it are questionable at best)

[alexins]

...(and the benefits of using it are questionable at best)
Here is a comparison of the performance of ffdshow msvc2010 and ffdshow icl12:

http://s018.radikal.ru/i500/1201/92/c31d359f1064t.jpg (http://radikal.ru/F/s018.radikal.ru/i500/1201/92/c31d359f1064.png.html)
http://s57.radikal.ru/i155/1201/b4/b1ac6ed35262t.jpg (http://radikal.ru/F/s57.radikal.ru/i155/1201/b4/b1ac6ed35262.png.html)

P.S
LAV Video Decoder 0.44 x86 MSVC2010/GCC4.63pre

http://s018.radikal.ru/i521/1201/2a/4f9361c846b9t.jpg (http://radikal.ru/F/s018.radikal.ru/i521/1201/2a/4f9361c846b9.png.html)

[nevcairiel]

So the average difference is 0.1-0.2%, in other words - worthless. :p

[_xxl]

Critical parts of the code are hand optimized.... so only some unoptimized and non-critical parts would benefit from compiler version.

[haruhiko_yamagata]

Formerly, icl9 was much better than MSVC2003(7.1).
Regarding performance, MSVC has been improved.
Old comparison (http://ffdshow-tryout.svn.sourceforge.net/viewvc/ffdshow-tryout/trunk/htmlhelp/html/en/images/benchmark.png?revision=1138&pathrev=2089).
Please try filters. Let's see how much MSVC improved.

[clsid]

It has been benched many times in the past. ICL is only faster for a few of the processing filters in ffdshow. For pure decoding it has no benefit.

@alexins
Part of the reason why LAV is faster in benchmark is because it uses more threads by default. 1.5x cores instead of 1.0x cores.

[amtm]

The only real benefits to buying the Intel compiler suite is if you like the performance tuning and static analysis tools that come with it. From having played with them in the trial version, they are kind of nice but definitely not something that can't be replaced and matched by cheaper tools. Intel's marketing only uses a single, synthetic benchmark to prove the "great" performance of their compiler, and even then they only show a 9% to 12% gain over GCC on Linux for example, so one should definitely take it with grand helpings of salt. Most likely their performance benefits are due to the synthetic benchmark doing computation that Intel can target lots of optimizations at rather than being a true accurate gauge of real world applications.

[oddball]

I am having issues with ffdshow (any build as far as I can tell) hanging when playing back MKV with AAC audio. Sometimes it plays fine and other times MPC-HC (Latest xvidvideo.ru builds) just hangs with the video and audio still playing but you cannot pause, stop or exit the player. I have to end it in task manager and it ends with the audio continuing for a second like it's a stuck CD going really fast on stuck sample. This only just started with recent builds and I don't know what to make of it other than to try rolling back MPC-HC, ffdshow and MadVR, I also use ReClock with WASAPI. But never had this issue until recently. I use a extrernal USB soundcard but never had issues with that until now either.

[haruhiko_yamagata]

I am having issues with ffdshow (any build as far as I can tell) hanging when playing back MKV with AAC audio. Sometimes it plays fine and other times MPC-HC (Latest xvidvideo.ru builds) just hangs with the video and audio still playing but you cannot pause, stop or exit the player. I have to end it in task manager and it ends with the audio continuing for a second like it's a stuck CD going really fast on stuck sample. This only just started with recent builds and I don't know what to make of it other than to try rolling back MPC-HC, ffdshow and MadVR, I also use ReClock with WASAPI. But never had this issue until recently. I use a extrernal USB soundcard but never had issues with that until now either.Thanks for report, but we need more information (http://forum.doom9.org/showthread.php?p=930663#post930663)to reproduce.

[oddball]

Nevermind it appears to be a switching but when going fullscreen on my HDTV. Going from 60Hz to 24Hz in conjunction with ReClock appears to be the culprit.

[ryrynz]

Haruhiko, I can reproduce another Rundll32 error. Simply rename any default preset and press enter, DO NOT click apply, then press ALT + F4.

[ipanema]

Some time between rev 3914 (Jun 29 2011) and rev (4291 Jan 31 2012) there seems to have been a bug introduced in the timestamps of the first decoded frame for the H.264/AVC decoder.

For example the older rev 3914 produces output frames with these start and end timestamps:
5575666 5575667
5909333 5909333
6243000 6243001
6576666 6576667

The difference is always correctly 333666, and the end timestamp is always 1 greater then the start timestamp.

But the newer rev 4291 gives these output timestamps:
0 399999
5909333 5909334
6243000 6243001
6576666 6576667

The timestamp of the first frame is way too low and much less than the input sample timestamps. Then there's a large jump to the timestamp values of the second frame which seems to be correct (as are all subsequent frames).

This causes a glitch or error when fed to downstream filters.

I don't know at what rev this problem first appeared, but at least rev 3914 works fine.

Is it possible to get this fixed ?

Thanks.


EDIT: I've just gone through all the previous versions of ffdshow-tryouts in

http://sourceforge.net/projects/ffdshow-tryout/files/SVN%20builds%20by%20clsid/generic%20builds/

and the problem seems to have been introduced at rev 4194. The previous rev 4174 seems to be OK (first frame has correct timestamps).

Hope that helps.

[kc7bfi]

I just installed ffdshow_rev4291_20120131_clsid_x64.exe and now, when trying to play a video I get a popup ffdshow error window saying it failed to load ffmpeg.dll. I am running Windows7 64-bit. Thanks, David

[clsid]

A fresh working x64 build will be available shortly.

[kc7bfi]

Here is a cell phone video (http://dl.dropbox.com/u/37804952/2012-02-01_16-17-41_209.3gp) taken of our attempt to play H.264 video from an Optelecom encoder. It appears that only I-frames are being decoded. Any thoughts what the problem might be? I am running Windows7 64-bit and ffdshow ffdshow_rev4293_20120201_clsid_x64. Thanks, David

[CruNcher]

you trying to playback the raw bitstream, what is the parser ?
though your chances arent high that it will work flawlessly as ffdshow isn't meant for this use case :)

[haruhiko_yamagata]

Haruhiko, I can reproduce another Rundll32 error. Simply rename any default preset and press enter, DO NOT click apply, then press ALT + F4.
I can reproduce the crash. Thanks.

[haruhiko_yamagata]

Some time between rev 3914 (Jun 29 2011) and rev (4291 Jan 31 2012) there seems to have been a bug introduced in the timestamps of the first decoded frame for the H.264/AVC decoder.

I think it's rev 4179.
Would you provide the sample?

[Pat357]

I 've just updated my FFDshow from rev3972 to rev4291.
When setting up FFDshow DXVA, I noticed that there is currently only support for H264 and VC1, no option to choose MPEG2 anymore !
What has happened to the MPEG2 HW acceleration ?
This is really a pitty because I used it often with my GTX 570 (full MPEG2 HW decoding support).
Do we we also loose the HW vector adaptive deinterlacing for all MPEG2 streams ? Like for TV recordings, DVD movies, ..?
I know we have Yadiff and other softw. based options but none comes even close to HW deinterlacing (quality wise),
not to mention the extra load on the CPU.:(
Can anyone please enlighten me ?
Will the option be back in the near future versions ?

[nevcairiel]

Deinterlacing through the renderer is not related to DXVA decoding, it should work equally well with software decoding as long as the decoder is setting the flags properly.

[ipanema]

I think it's rev 4179.
Would you provide the sample?

Do you mean the MTS file that produced the timestamps I quoted? If so where do I provide it?

[clsid]

I 've just updated my FFDshow from rev3972 to rev4291.
When setting up FFDshow DXVA, I noticed that there is currently only support for H264 and VC1, no option to choose MPEG2 anymore !
What has happened to the MPEG2 HW acceleration ?
This is really a pitty because I used it often with my GTX 570 (full MPEG2 HW decoding support).
Do we we also loose the HW vector adaptive deinterlacing for all MPEG2 streams ? Like for TV recordings, DVD movies, ..?
I know we have Yadiff and other softw. based options but none comes even close to HW deinterlacing (quality wise),
not to mention the extra load on the CPU.:(
Can anyone please enlighten me ?
Will the option be back in the near future versions ?
There never has been such an option. There are also no plans to add it.
You should use LAV Video instead. That provides CUVID HW acceleration with HW deinterlacing.

[clsid]

Do you mean the MTS file that produced the timestamps I quoted? If so where do I provide it?You can upload it to for example:
http://www.mediafire.com

If the file is very large and you want to cut a sample, then use DGSplit:
http://neuron2.net/dgsplit/dgsplit12.zip

[kc7bfi]

Here is a cell phone video (http://dl.dropbox.com/u/37804952/2012-02-01_16-17-41_209.3gp) taken of our attempt to play H.264 video from an Optelecom encoder. It appears that only I-frames are being decoded. Any thoughts what the problem might be? I am running Windows7 64-bit and ffdshow ffdshow_rev4293_20120201_clsid_x64. Thanks, David

I have confirmed that the problem with the Optelecom H.264 video was created somewhere between version 4174 and 4194. Version 4174 plays the video fine but 4194 seems to only be playing I-frames. Any ideas what may have changed in those versions? If there are any intermediate Windows 64 bit installs I can also test them to try and narrow down the exact revision that caused the problem. Just let me know if they are available. Any help in resolving this issue would be greatly appreciated. David

[clsid]

I am making preparations for a new official release that is planned for later this month, once remaining regressions have been fixed.

Everyone please review this changelog for omissions and mistakes:

(revision 3154 to 4296)

Bugfixes:
* Lots of updates for libavcodec that bring bug fixes, performance enhancements, and security fixes.
* Disable "Detect soft telecine and average frame durations" if 3:2 pulldown is being applied in AviSynth filter.
* IAMStreamSelect: fix duplicated subtitle list in case of multiple ffdshow instances
* If a matroska container had hidden leading chapter and Haali's splitter was used and tray icon was right-clicked, ffdshow crashed.
* Various fixes regarding input mediatype handling, strides, and pin re-connection.
* Various fixes regarding H.264 SPS parsing
* Fixed decoding of 96khz 32bit audio with libavcodec
* Fixed decoding of AAC audio with libavcodec when extradata is missing
* Better handling of non-mod4 resolutions
* Workaround for freeze in Powerpoint 2010
* AC3 encoder was producing improper bitstream when connected to file writer filter
* Various fixes for audio bitstreaming

New and improved features:
* Support for H.264 10-bit 4:2:0/4:2:2/4:4:4/RGB
* Support for H.264 8-bit 4:2:2/4:4:4/RGB, 4:2:0 was already supported
* Support for various 10-bit and 16-bit colorspaces
* Optimized YV12 to NV12 conversion
* Enabled high quality RGB32 conversion by default
* Added option to select a preferred output colorspace
* Added Intel QuickSync decoder. This provides hardware acceleration decoding of H.264, VC-1 and MPEG-2. Requires the integrated GPU of Intel Sandy Bridge processors.
* Added DXVA video filter for hardware accelerated decoding. Supports H.264 and VC-1 video. Also includes subtitle support.
* Various additions to the application blacklist and whitelist
* Added support for Blu-ray PGS subtitles
* Removed support for USF subtitles
* Various improvements for the handling of ASS/SSA subtitles. More tags are supported now, but not yet all of them.
* Various improvements for the rendering of text-based subtitles
* By default now only subtitle files are shown that match the video filename. This behavior can be adjusted through an
option on the "Try, dialog & Paths" page in ffdshow settings.
* Created new format option in ffdshow audio decoder for the QT PCM variants (such as TWOS). They were previously part if the Uncompressed audio option.
* ffmpeg-mt has been merged into libavcodec
* Multi-threaded decoding is now used by default for H.264, MPEG-1/2, FFV1, and DV video.
* Added decoding support for Indeo 4 and Indeo 5 video
* Floating point output for libavcodec AAC, AC3, E-AC3, DTS, Vorbis, and Nellymoser decoders.
* Added option to disable jitter correction for audio decoder
* Improved performance of Deband filter
* Removed some encoders for which the interface that ffdshow provided was outdated and unmaintained, such as Xvid and
H.264. You should use the official codecs instead.
* Removed some encoders that were considered obsolete or unstable.

Updates:
* Updated Boost library to v1.48
* Updated zlib library to v1.2.6
* Updated minilzo library to v2.06
* Updated unrar library to v4.10
* Updated libsamplerate to v0.1.8
* Removed mp3lib
* Removed xvidcore

[ipanema]

You can upload it to for example:
http://www.mediafire.com

If the file is very large and you want to cut a sample, then use DGSplit:
http://neuron2.net/dgsplit/dgsplit12.zip

Thanks. I have just been doing some more checks for 3 MTS files chosen at random and they all have similar output timestamp problems which were not present in the older revisions of ffdshow tryouts. And it isn't just the timestamp of the first frame. There are some very strange timestamp values jumping forward and then backward (this is the output remember), and the end timestamp value is sometimes strange aswell. In comparison, the older revisions always produce correct values with the end timestamp always 1 greater than the start.

Here are the start and end timestamps for the 3 files I tried. The input timestamps are shown, followed by the "correct" output timestamps from the older revision 4174, followed by the weird values produced by the newer revision.

File 1

Input Timestamps
5575666 5575667
4908333 4908334
5242000 5242001
6576666 6576666
5909333 5909334
6243000 6243001
7577666 7577667
6910333 6910334
7244000 7244001
8578666 8578667
7911333 7911334
8245000 8245001

Output Timestamps from revision 4174
5575666 5575667
6576666 6576667
6910333 6910334
7244000 7244001
7577666 7577667
7911333 7911334

Weird Output Timestamps from newer revision
0 399999
6576666 6576667
6910333 6910334
7244000 7244001
7644000 8043999
7911333 7911334


File 2

Input Timestamps
2918111 2918112
2118111 2118112
2518111 2518112
3718111 3718112
3318111 3318112
4518111 4518112
4118111 4118112
5318111 5318112
4918111 4918112
6118111 6118112
5718111 5718112
6918111 6918112
6518111 6518112

Output Timestamps from revision 4174
2118111 2118112
2518111 2518112
2918111 2918112
3318111 3318112
3718111 3718112
4118111 4118112
4518111 4518112
4918111 4918112
5318111 5318112
5718111 5718112
6118111 6118112

Weird Output Timestamps from newer revision
2118111 2118112
3718111 3718112
4118111 4518110
3318111 3318112
3718111 3718112
5318111 5318112
4518111 4518112
6118111 6118112
5318111 5318112
6918111 6918112
6118111 6118112


File 3

Input Timestamps
7770333 7770334
7103000 7103001
7436666 7436667
8771333 8771334
8104000 8104001
8437666 8437667
9772333 9772334
9105000 9105001
9438666 9438667
10773333 10773333
10106000 10106001
10439666 10439667
11774333 11774334
11107000 11107001
11440666 11440667
12775333 12775334
12108000 12108001
12441666 12441667
13776333 13776334
13109000 13109001
13442666 13442666

Output Timestamps from revision 4174
7770333 7770334
8771333 8771334
9105000 9105001
9438666 9438667
9772333 9772334
10106000 10106001
10439666 10439667
10773333 10773334
11107000 11107001
11440666 11440667
11774333 11774334
12108000 12108001
12441666 12441667
12775333 12775334
13109000 13109001

Weird Output Timestamps from newer revision
0 399999
8771333 8771334
9438666 9438667
10773333 10773334
11173333 11573332
10439666 10439667
10439666 10439667
10773333 10773334
11107000 11107001
12775333 12775334
13175333 13575332
12441666 12441667
12441666 12441667
12841666 13241665
13109000 13109001


Given that all 3 of the files I selected at random show the problem within the first few frames, I would think that you would be able to reproduce this quite easily using one of your own files (all 3 were from different AVCHD camcorders).

However, if you still think you need an example file, let me know and I will upload one for you.

[haruhiko_yamagata]

I am making preparations for a new official release that is planned for later this month, once remaining regressions have been fixed.

Everyone please review this changelog for omissions and mistakes:Good log.
One thing I want for the next release is fast "Accurate rounding" in resize filter. Actually it's a regression.

[haruhiko_yamagata]

Given that all 3 of the files I selected at random show the problem within the first few frames, I would think that you would be able to reproduce this quite easily using one of your own files (all 3 were from different AVCHD camcorders).

However, if you still think you need an example file, let me know and I will upload one for you.
Finally I found one, but it was hard...
With one file, in combination with Haali's splitter.

[haruhiko_yamagata]

ipanema, please upload the file anyway. The file I mentioned above has the same timestamp as the older build.
Which source/splitter filter do you use?

[haruhiko_yamagata]

Madagascar.avi 1280x720
Average of about 2760 frames (QueryPerformanceCounter, which is high resolution time. Smaller number is faster.).
Image filter only, not overall frame rate.

RGB conversion (HQ, dithering enabled)
MSVC x86: 5,415
ICL x86: 5,488
MCVC x64: 4,856
ICL x64: 4,961

Denoise 3D HQ
MSVC x86: 36,047
ICL x86: 31,716
MSVC x64: 419,569
ICL x64: 32,220

Denoise 3D Normal
MSVC x86: 25,618
ICL x86: 18,753
MSVC x64: 16,917
ICL x64: 18,715

As you can see, ICL is faster only in special cases.
ICL is faster by 36.6% for Denoise 3D normal x86. This filter is useless because it's quality is too low. Denoise 3D HQ should be used.
ICL is 13 times faster for Denoise 3D HQ x64. MSVC does not support MMX intrinsics for x64. ICL seems to be OK.

EDIT
Core2 Quad Q9550 2.83GHz
Windows 7 Professional sp1
GeForce 7900 GS
ffdshow rev 4298

[khagaroth]

I am making preparations for a new official release that is planned for later this month, once remaining regressions have been fixed.
Up to update the Czech translation I guess. What a pity it's such a pain to find changed/new strings, it would be great if the whole thing got gettextized. As probability of that ever happening is pretty low, it would be nice if this ticket (http://sourceforge.net/tracker/?func=detail&aid=3360019&group_id=173941&atid=867363) was followed.

[nevcairiel]

MSVC does not support MMX intrinsics for x64. ICL seems to be OK.

So rewrite them using SSE2, its really just the same commands with 128-bit instead 64... :)

[haruhiko_yamagata]

So rewrite them using SSE2, its really just the same commands with 128-bit instead 64... :)
That's a bother.:p
That's something compilers must do. MSVC is simply inferior to ICL in that regard.

[haruhiko_yamagata]

Up to update the Czech translation I guess. What a pity it's such a pain to find changed/new strings, it would be great if the whole thing got gettextized. As probability of that ever happening is pretty low, it would be nice if this ticket (http://sourceforge.net/tracker/?func=detail&aid=3360019&group_id=173941&atid=867363) was followed.
Tags such as <translate> in the svn log may help. I think it's a good idea.
As far as I can find,

Image buffer: in Subtitles::Text page
Primary output color space: in Output page

Both have tool-tip hint.

[ipanema]

ipanema, please upload the file anyway. The file I mentioned above has the same timestamp as the older build.
Which source/splitter filter do you use?

Sorry you've had some problems finding a file - it seemed to do this to all 3 files that I examined. Perhaps this does have something to do with the splitter. The splitter being used is the Microsoft MPEG-2 Demux that is part of Windows which works fine with all decoders I've tried, including ffdshow - but it's just the recent ffdshow revs that cause the problem. The Microsoft splitter produces fixed sized 8192 byte samples, where only the sample which STARTS a frame carries a start/end timestamp - all other samples have no timestamp. Also the sample at the end of a frame may be less than 8192 bytes in size.

Here's a sample file - it's pretty small but is enough to show the problem. It is the "File 3" in my previous message.

http://www.mediafire.com/?88db0kvuw83ubh5

[haruhiko_yamagata]

Thanks for the sample.
The splitter being used is the Microsoft MPEG-2 Demux that is part of Windows
Is it "MPEG-2 Demultiplexer" or "MPEG-2 Splitter"?
What is the OS?
"MPEG-2 Demux" isn't installed on my PC.

[egur]

@clsid
The QS check doesn't work on non-SandyBridge machines. It fails on my 9400T (Penryn) which is capable of QS. I'm afraid it will also fail on IvyBridge.
Please remove the existing check untill a new one is found.
If it makes sense to you, I can export a check function from my dll.

If these checks are too complicated or time consuming (from you), please remove them altogether or at least make them pass on all Intel processors.