ffdshow tryouts project: Discussion & Development [Archive] - Page 229

Keiyakusha

20th April 2010, 01:45

With respect, I disagree strongly to clsid, MPC-HC has a place as an all in one that works REALLY well when lots of other things don't, especially for users who don't know enough to mess with filter priority and stuff, that can be pretty evil.

Especially once machines have had codec packs loaded on them and stuff no longer works, MPC-HC is like old faithful.

I'm sorry but I think this is not something where you can disagree with clsid with only these arguments. This discussion started from proposition to make something, so maintaining internal filters and bug fixing will be easier and not because someone just wants to change something for no reason. And it was said that mpc-hc team have no plans to work on codecs.
Also even with replacing internal filters by ffdshow it is possible to have no admin rights requirement and playability on old systems "where all codecs messed up". However yes, it will require some amount of work.

madshi

20th April 2010, 08:25

Except without the conflicts, crashes and ancient ACM/VCM libraries that codec packs have. (also the hundreds of tray icons)
I'm not saying that the well known big codec packs out there would be any good. But that doesn't mean that it wouldn't be possible to create a good codec pack.

In my opinion the setup is fine. It's the right mix between standalone player and mplayer/vlc type app with support for hundreds of codecs and dozens of various options. Though there is some cruft like RealMedia and Quicktime support that's a bit dated.
MPC HC is currently my main media player, and I really like it. I don't find the internal filter logic (preferring most internal filters over external filters, without considering the filter quality) right, though.

Also internal DXVA is better than anything else for 1080p50 material.
Why is ffdshow slower? Probably because it wants to enable post processing and subtitles, right? I think it would be possible to solve that problem. E.g. post processing could be disabled to avoid that GPU <-> RAM copy stuff. Subtitles could be sent to the video renderer directly, I'd guess. If all else fails, the MPC HC video renderers could expose some new interfaces to make ffdshow DXVA subtitle rendering possible in a fast way. Not sure how much work that would be. But I'm quite sure it would be possible to implement DXVA in ffdshow without speed penalty, as long as the user doesn't require post processing.

With respect, I disagree strongly to clsid, MPC-HC has a place as an all in one that works REALLY well when lots of other things don't, especially for users who don't know enough to mess with filter priority and stuff, that can be pretty evil.

Especially once machines have had codec packs loaded on them and stuff no longer works, MPC-HC is like old faithful.
There's no doubt that bad codec packs will mess up anyone's PC. But that's not the point. clsid was talking about a *good* codec pack. E.g. imagine a codec pack only consisting of MPC HC and ffdshow, where all those MPC HC's internal filters which are duplicates to ffdshow are removed, and where MPC HC automatically "preferred" ffdshow instead. That would be a pretty good start for a "good" codec pack. It would still have all the positive properties you mentioned, plus it would fix a couple of bugs. There may be a few more freeware filters which would be worth being part of such a codec pack, but that's a whole different topic.

Please understand that we're not trying to bully the MPC HC folks into distributing ffdshow with MPC HC. It's just that according to tetsuo55, MPC HC's aim is to provide an all-in-one solution. And if I, personally, were trying to create a really good all-in-one solution, I would find no way around including some selected external DirectShow filters.

tetsuo55

20th April 2010, 08:39

What kierank means with DXVA is that the implementation in ffdshow needs to do a very slow system memory > gpu memory copy operation.

about 3rd party codecs, almost every codec that we can legally include is equal to or worse than ffmpeg.
I would gladly hear about cases where another open source codec is better than ffmpeg.

madshi

20th April 2010, 08:58

What kierank means with DXVA is that the implementation in ffdshow needs to do a very slow system memory > gpu memory copy operation.
Yes, and what I mean is that there would probably be ways to avoid that under specific circumstances (e.g. with disabled post processing and subtitles, see previous post).

about 3rd party codecs, almost every codec that we can legally include is equal to or worse than ffmpeg.
I would gladly hear about cases where another open source codec is better than ffmpeg.
Why limiting things to open source? I was talking about *freeware* 3rd party codecs, which you could include in the MPC HC distribution to create an even better all-in-one solution. Examples would be ffdshow, Haali Media Splitter, madFlac, ... It's quite possible that Haali's license wouldn't allow you to redistribute it, though. Again: I'm not trying to bullying you into include the mentioned filters. I'm just saying that if a great all-in-one solution is your aim, it might make sense to include a few selected external filters. Or at least, if you detect that some specific external filters are installed, you could disable some internal filters by default and prefer known good external filters instead. Just a suggestion, though. Any way in which MPC HC could be improved to automatically work better with good external filters, without having to tweak MPC HC settings, would be nice.

clsid

20th April 2010, 10:44

Postprocessing is disabled by default in ffdshow. The small speed difference might be due to colorspace conversion and some sanity checks that MPC does not perform. Btw, MPC does not have any multi-threaded decoding, so on a multicore CPU ffdshow will be much faster with decoding H.264 in software mode.

It always makes me laugh when people say that codec packs are evil and break your system. While that may be true for ancient stuff such as Nimo and ACE, it is just blatantly untrue for any modern codec pack such as CCCP or K-Lite. In fact, for example K-Lite is equipped with special functionality to fix things. This includes detection (and removal) of several known bad codecs that cause crashes, memory leaks and other stability issues. It includes detection (and removal) of incorrect codec references in the registry (left-over stuff). It includes detection of some known audio and DirectShow issues. It includes a proper uninstaller. It adjusts what it installs based on what is already installed. Everything can be customized. Etc. Etc.

Btw, the update that I did yesterday has made software H264 decoding in MPC significantly faster. Your welcome ;)

tetsuo55

20th April 2010, 11:35

It is possible to make a more complicated dshow fallback system than we currently have in MPC-HC and i can see how this improves the experience for some.

We believe that software should be open source, that is the main reason for not including closed source filters.
I think k-lite/cccp solve the problem quite nicely as their codec choices favor open source and free codecs replacing them only with others when they are truly better.

The problem with ffdshow's DXVA implementation has nothing to do with the postprocessing its a design flaw in DXVA2 (mpc-hc uses DXVA1 which doesn't suffer from this issue but has other problems).

Shankster

20th April 2010, 12:05

How about FFdshow guys help MPC guys with what they want and the MPC guys fix ffdshow's vobsub implementation. :eek:

/crawling back under my rock

tetsuo55

20th April 2010, 12:13

kieranrk

20th April 2010, 12:37

It always makes me laugh when people say that codec packs are evil and break your system. While that may be true for ancient stuff such as Nimo and ACE, it is just blatantly untrue for any modern codec pack such as CCCP or K-Lite. In fact, for example K-Lite is equipped with special functionality to fix things. This includes detection (and removal) of several known bad codecs that cause crashes, memory leaks and other stability issues. It includes detection (and removal) of incorrect codec references in the registry (left-over stuff). It includes detection of some known audio and DirectShow issues. It includes a proper uninstaller. It adjusts what it installs based on what is already installed. Everything can be customized. Etc. Etc.

One could go on for pages and pages as to why K-lite has major problems...I'm not going to do it because it will turn this thread into a flamefest. CCCP is ffdshow and mpc-hc so is not comparable.

madshi

20th April 2010, 13:55

We believe that software should be open source, that is the main reason for not including closed source filters.
So, you make your decisions based on politics, instead of quality?

clsid

20th April 2010, 14:15

One could go on for pages and pages as to why K-lite has major problems...I'm not going to do it because it will turn this thread into a flamefest. CCCP is ffdshow and mpc-hc so is not comparable.
Your last comment just proves how little you know about this. K-Lite has different variants, of which the Standard one is very comparable to CCCP in terms of contents.
I love to hear about those so-called problems, but since you don't actually use the pack, I doubt you will be able to come up with much valid stuff.

ikarad

20th April 2010, 15:43

The idea is to create a new subtitle renderer and with that a new subtitle format.
This new renderer should be a drop in replacement for the current stuff in ffdshow/mpc-hc
the lead dev for that project is looking for help though, he needs help with brainstorming and coding. (PM me if you are willing and able to help out)

Why don't you include subtitle renderer from ffdshow in mpc-hc because your subtitle renderer is very buggued with a bad blu-ray subs support (with ffdshow it is nearly perfect under vista and seven (even if it doesn't work under xp) thanks to the amazing work of Albain)?

tetsuo55

20th April 2010, 16:01

So, you make your decisions based on politics, instead of quality?As you might have noticed there is a ton of politics in both these programs.
I hope everyone will move to a new scientifically best best model instead, but it will remain based on open-source.
being/using open source is one of mpc-hc's core ideoligies and one of our unique selling points as a dshow based player.

Why don't you include subtitle renderer from ffdshow in mpc-hc because your subtitle renderer is very buggued with a bad blu-ray subs support (with ffdshow it is nearly perfect under vista and seven (even if it doesn't work under xp) thanks to the amazing work of Albain)?they are incompatible unfortunately, we need devs that want to work on this type of changes.

ikarad

20th April 2010, 16:04

@Albain,
there is a bug with blu-ray sub support with xp sp3 (under vista it works very well).

The subs are divide in two parts and are not completed
http://nsa14.casimages.com/img/2010/04/20/mini_100420050119368677.jpg (http://www.casimages.com/img.php?i=100420050119368677.jpg)

I try with YUY2 or RGB 32 and there is the same problem.
I try with all versions of ffdshow (3350 to 3368) where it works under vista and there is the same problem udner xp sp3.

I notice some crashs but I think that crashs come from this problem .

same example that I give you before
example
part 1
http://www.zshare.net/info.html?7219...12ca4e70f4959e
part2
http://www.zshare.net/info.html?7222...cb0c45e37239c1
part3
http://www.zshare.net/info.html?7222...fa215e89fcfdf2

part 4
http://www.zshare.net/info.html?7287...1fac7d6620cda5

part 5
http://www.zshare.net/info.html?7289...835142beff854c
part 6
http://www.zshare.net/info.html?7290...3fe6974fb1237c

partie 7
http://www.zshare.net/info.html?7215...a94c0fc61987f5

kieranrk

20th April 2010, 16:13

Your last comment just proves how little you know about this. K-Lite has different variants, of which the Standard one is very comparable to CCCP in terms of contents.
I love to hear about those so-called problems, but since you don't actually use the pack, I doubt you will be able to come up with much valid stuff.

No I would never pollute my PC with K-lite. Why do you think Microsoft started putting native codecs in Windows 7? Because normal people, many of whom I know have installed codec packs such as K-lite which lead to crashes and conflicts beyond belief.

For a start in K-lite Basic/Standard you include:

Haali Video Renderer [version 1.10.120.15]
Hasn't been updated for ages. Is it that fundamental to watching videos that it deserves to be in the Basic pack?

In Standard:

MPEG-2 (Cyberlink) [version 8.4.0.1014]
And whats wrong with ffdshow's mpeg-2 decoder?

And to summarise what would be pages and pages for the other variants:

You take the Adobe Acrobat Reader approach to codecs. Include as much obscure stuff in the codec pack as possible just like Adobe includes all sorts of obscure plugins. Add so much bloat so that the 0.00001% of occasions when such a thing is needed it's there. There is also ridiculous amounts of duplication for no reason at all: ACM codecs, VFW codecs and even more obscure formats. How many AAC/AC3/MPEG-2 etc decoders do we really need according to you?

Midzuki

20th April 2010, 16:30

And whats wrong with ffdshow's mpeg-2 decoder?

http://forum.doom9.org/showthread.php?t=148056

for example. :)

kieranrk

20th April 2010, 16:36

http://forum.doom9.org/showthread.php?t=148056

for example. :)

That's a subtitling issue though, not an mpeg-2 issue.

STaRGaZeR

20th April 2010, 16:56

I'm sure all of you have your own opinions about codec packs but this thread is about ffdshow :rolleyes:

Did anyone review this (http://forum.doom9.org/showthread.php?p=1392884#post1392884) patch/build?

Midzuki

20th April 2010, 17:20

That's a subtitling issue though, not an mpeg-2 issue.

Well, the stupidly-resized subtitles are produced by the mpeg-2 decoder from ffdshow, whenever it is allowed to connect to the DVD-Navigator.

And yes, the non-independent "raw video filter" has the same issue.

clsid

20th April 2010, 18:43

No I would never pollute my PC with K-lite. Why do you think Microsoft started putting native codecs in Windows 7? Because normal people, many of whom I know have installed codec packs such as K-lite which lead to crashes and conflicts beyond belief.Windows 7 includes more codecs primarily to give users a better out-of-box experience. For example, the H.264 support was essential for Media Center, since H.264 is now also used in digital TV broadcasts.
Btw, K-Lite is on the official compatible application list of Windows 7, added on the initiative of Microsoft themselves!
Crashes are just nonsense. Pretty much all crash reports I deal with end up being caused by faulty drivers. The component in the pack that is the least stable is actually MPC-HC.
For a start in K-lite Basic/Standard you include:
Haali Video Renderer [version 1.10.120.15]
Hasn't been updated for ages. Is it that fundamental to watching videos that it deserves to be in the Basic pack?
It's not fundamental. It is normally bundled with Haali splitter, which is also included, so it is included to keep things similar to standalone installers. It is very small compressed and has no ill effects when not used.
In Standard:
MPEG-2 (Cyberlink) [version 8.4.0.1014]
And whats wrong with ffdshow's mpeg-2 decoder?Lots of things unfortunately.
You take the Adobe Acrobat Reader approach to codecs. Include as much obscure stuff in the codec pack as possible just like Adobe includes all sorts of obscure plugins. Add so much bloat so that the 0.00001% of occasions when such a thing is needed it's there. There is also ridiculous amounts of duplication for no reason at all: ACM codecs, VFW codecs and even more obscure formats. How many AAC/AC3/MPEG-2 etc decoders do we really need according to you?Things are included based on the needs of the users, which are millions of very satisfied ones btw. You just looked at the contents lists, not at the actual installers themselves. Then you would have noticed that not everything actually gets installed. Choices must be made between redundant items. Redundance in contents is there when there are good reasons for it, like known limitations in items, or significant groups of users that prefer specific alternative items. Items that the average user does not need are disabled by default.
Native codecs and popular third party codecs (like CoreAVC) are automatically detected so that the installer can adapt itself. So by default no MPEG-2 decoder will be installed on Vista Home Premium because that already contains a good decoder.
The fact that you don't need many things does not mean that the same applies to others. That is why the installers are fully customizable and there are different sized packs. What you call bloat is what others call essential functionality.
Even when a user decides to install more than he/she actually needs, then there is no harm other than a few MB of wasted space.

kieranrk

20th April 2010, 18:54

That is why the installers are fully customizable and there are different sized packs. What you call bloat is what others call essential functionality.

I did look at the installers and they still allow duplicates in terms of VFW, ACM and the likes. Xvid/ffdshow too. It's clearly bloat under the misguided attempt to second guess what people want or you feel that implementations are incomplete based on conjecture and not real evidence.

You haven't revealed specifically what is wrong with ffmpeg's mpeg-2 decoder or any of the other open source decoders and tetsuo55 has also said that you have a "secret collection of bugreports" whatever that means. You do not choose to share these bugreports so it's pretty clear that you have no idea what you are doing or think people are psychic.

You are doing a disservice to people by offering so much unnecessary cruft in the codec-pack then using the installer to patch over any potential conflicts. This is a poor way of offering software to end-users.

Even when a user decides to install more than he/she actually needs, then there is no harm other than a few MB of wasted space.

Security holes, longer time for directshow to connect to pins.

Anyway the overall point is that neither mpc-hc nor ffdshow should end up like k-lite because it's a terrible example to follow.

clsid

20th April 2010, 19:52

I did look at the installers and they still allow duplicates in terms of VFW, ACM and the likes. Xvid/ffdshow too. It's clearly bloat under the misguided attempt to second guess what people want or you feel that implementations are incomplete based on conjecture and not real evidence.You need to be more specific about what you think are duplicates. VFW/ACM codecs are primarily for applications that do not use DirectShow. DirectShow apps can use them as fallback, but that is obviously not their main purpose.
I don't second guess what people want or need, it is based on years of experience and actually talking to people. That is why I am also engaging in this discussion with you. Your opinion is also valued like everyone elses, even when I may disagree on certain points.
You haven't revealed specifically what is wrong with ffmpeg's mpeg-2 decoder or any of the other open source decoders and tetsuo55 has also said that you have a "secret collection of bugreports" whatever that means. You do not choose to share these bugreports so it's pretty clear that you have no idea what you are doing or think people are psychic.There is no secret list of bug reports. There is just lots of info in my head gathered from forums like this. I actually do forward important info to the appropriate developers. So you are really really out of line here.
As for specific mpeg-2 related issues, I suggest you search this topic and have a look at the ffdshow forum and bugtracker. For example a video corruption issue can be found a few pages back.
Security holes, longer time for directshow to connect to pins.Which holes? Please mention specific ones, instead of hypothetical ones. Did you know some holes in MPC were fixed long ago partly due to my efforts? I guess not.
The number of filters installed by the average pack is just a fraction of what is already part of Windows. Filter enumeration pin connection in done in the order of milliseconds.

clsid

20th April 2010, 20:47

I should add that the philosophy is of course to install as little as possible. That is why the smaller variants are the ones that are recommend for the average user. But the reality is that most want maximum functionality and do not care about a bit of bloat. They only care about working playback, which is what the pack provides.

Mixer73

21st April 2010, 01:31

While I have no problem with codec packs for the less expert user, I personally have found that they lead to less stable machines over time. So I choose to install applications or codecs specifically and very carefully.

I also have seen machines recently that were totally unable to play videos in WMP and even PowerDVD, but MPC-HC worked 100%. Its able to play even when system codecs are borked, and if we strip internal filters, this will no longer be the case.

YMMV, and yes, clsid's criticism that I do not use the packs means that my comment could well be out of date; but if I can install 2-3 things I specifically need, then I don't see a need to have a pack.

Hell, I won't even install Haali Splitter on my machines, its got far too many bugs that seem to affect me. I remux everything back to MP4 because that works perfectly!

Maybe I'm strange.

_xxl

21st April 2010, 06:42

n Standard:
MPEG-2 (Cyberlink) [version 8.4.0.1014]
And whats wrong with ffdshow's mpeg-2 decoder?
ffdshow's libavcodec decoder crashes with some mpeg2 samples, for example.

lych_necross

21st April 2010, 07:36

Maybe I'm strange.
No you're not strange. Discussing codec packs in a ffdshow thread is strange, off topic, and counter productive. :readrule:

tetsuo55

21st April 2010, 07:38

ffdshow is itself a kind of open source codecpack

Mr VacBob

21st April 2010, 08:29

ffdshow's libavcodec decoder crashes with some mpeg2 samples, for example.

Where are these?

starla

21st April 2010, 12:09

How about opening a separate thread for the code packs are evil discussion and keeping this thread in technical details of ffdshow?

br,
tourettes / MediaPortal

ps. I wont even say aloud my opinion on codec packs (I have seen enough damage different codec packs have done. Like unregistering filters that they think aren't needed...)

clsid

21st April 2010, 13:54

Like unregistering filters that they think aren't neededSuch as?

dann23

21st April 2010, 17:43

I also don't like codec packs. So can we keep this thread clean?

namaiki

21st April 2010, 18:03

Just curious, but what is the minimum amount of keys that will tell ffdshow video to output only RGB formats with dithering?

I tried the following, but it seems to only enable dithering.

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Software\GNU\ffdshow]

[HKEY_CURRENT_USER\Software\GNU\ffdshow\default]
"dithering"=dword:00000001
"outYV12"=dword:00000000
"outYUY2"=dword:00000000
"outYVYU"=dword:00000000
"outUYVY"=dword:00000000

adam777

21st April 2010, 19:30

Hello all,
Revision 3368 breaks Hebrew subtitles - words are not displayed in correct order, letters inside words display correctly.

albain

21st April 2010, 20:24

Hi all,

very intense dicussions :-)

As clsid said we on ffdshow team don't have the time and the manpower to work on MPC filters and MPC in general

Tetsuo, you are the one who proposed this idea to import ffdshow inside MPC HC a while ago. After all it may be better to design interfaces or improve existing ones in ffdshow to make a better integration

As a media center user, I am not a MPC user so I still think that the codec efforts should be unified into one place.
Besides, directshow support will be dropped in the future (the question is not if but when) and we have to focus on migrating to media foundation (or rather bring support for the 2 media engines). So a lot of work is needed on our side too
Without forgetting support for new ffmpeg codecs (wma pro, ...)

About DXVA, I don't understand the posts before : we have the same implementation as MPC HC : DXVA 1 & 2 are supported
I don't understand why ffdshow would be slower, unless you enable postprocessing filters
Also, DXVA2 brings some postprocessing features (DXVA HD) that may be interesting.

But once again, I don't like DXVA : the picture is blurry compared to software decoding, and with multithreaded decoding AND postprocessing, you have the best results even if you don't have a (very) recent CPU on HD content

@adam777 : this has to be my fault, I replaced the SRT parser by the SSA parser which brings of course more features but there was a bug that seems still to be not fixed

clsid

21st April 2010, 20:33

Restructuring the code of ffdshow is something I would fully support. It should become more modular/layered with nice interfaces between parts. The code that interfaces with the various external libraries could also use some good cleaning/rewrite.

SamuriHL

21st April 2010, 20:37

And allow it all to build in VS 2010? :D

adam777

21st April 2010, 23:08

@adam777 : this has to be my fault, I replaced the SRT parser by the SSA parser which brings of course more features but there was a bug that seems still to be not fixed

Ah... OK. I'll keep an eye to see when things gets fixed. :thanks:

tal.aloni

22nd April 2010, 09:16

But once again, I don't like DXVA : the picture is blurry compared to software decoding

an internal post processing beta that I made allowed me to grab frames from the DXVA GPU Buffer, and compare them to software decoding. my Radeon 4550 output was identical to H.264 software decoding. (results may vary based on the GPU obviously)

p.s.
I agree that it's harder to tame DXVA: worse postprocessing, and it doesn't work well with overlay filter. (overlay filter is the best way for me to avoid tearing)

Sebastiii

22nd April 2010, 09:51

an internal post processing beta that I made allowed me to grab frames from the DXVA GPU Buffer, and compare them to software decoding. my Radeon 4550 output was identical to H.264 software decoding. (results may vary based on the GPU obviously)

p.s.
I agree that it's harder to tame DXVA: worse postprocessing, and it doesn't work well with overlay filter. (overlay filter is the best way for me to avoid tearing)

It's cool and good idea :)

tetsuo55

22nd April 2010, 09:52

_xxl

22nd April 2010, 11:14

Tested with ffdshow 3368, mkv 720p h.264 sample.
ffmpeg-mt compiled with -mmmx
User: 0s, kernel: 0s, total: 0s, real: 11s, fps: 2228.0, dfps: 149.2
ffmpeg-mt compiled with -mmmx -msse -mfpmath=sse
User: 0s, kernel: 0s, total: 0s, real: 11s, fps: 1782.4, dfps: 149.6
ffmpeg-mt compiled with -mmmx -msse -mfpmath=sse -msse2 -msse3 -mssse3
User: 0s, kernel: 0s, total: 0s, real: 11s, fps: 2228.0, dfps: 149.4

tetsuo55

22nd April 2010, 13:07

So it doesn't hurt, nice.

tetsuo55

22nd April 2010, 13:50

I did some more research, and it seems that every benchmark ever posted here seems to prove that the higher the sse version used, the higher the performance.

I also found 2 benchmarks that indicate msvc is actually faster than gcc/icc (all posted here on doom9)

http://forum.doom9.org/showthread.php?p=1363969#post1363969
http://forum.doom9.org/showthread.php?p=1335779&highlight=dfps#post1335779
http://forum.doom9.org/showthread.php?p=973342&highlight=dfps#post973342
http://forum.doom9.org/showthread.php?p=943149#post943149
http://forum.doom9.org/showthread.php?p=1217662#post1217662
http://forum.doom9.org/showthread.php?p=998532&highlight=dfps+msvc#post998532

Quick conclusion, it doesnt matter what you use to compile ffmpeg, the best way to get a tiny bump in performance to is to build it with all the optimisation switches your cpu supports.

clsid

22nd April 2010, 14:02

Those benchmarks were for MSVC/GCC builds of ffdshow.ax! For that we obviously prefer MSVC. What matters for decoding performance is libavcodec.dll and for that GCC is the best by a huge margin.

The numbers from _xxl's benchmark show that it is of little benefit to enable additional compiler optimizations for libavcodec. The difference is less than 1% and within the margin of error. Compatibility with older systems is much more important than an insignificant performance difference.

tetsuo55

22nd April 2010, 14:11

Those benchmarks all tests libavcodecs performance by running a h264 video with the internal decoder, they clearly specify when the whole project was built with gcc, icc or msvc. [i have been brainwashed to believe gcc/icc are always faster than msvc so i have a hard time believing these facts myself]

its true that the improvements fall within the margin of error scale, but over all the benchmarks posted its consistently faster by 0.1% to 2%.
I agree that the default stable builds should support the lowest os/cpu available. In the case of MPC-HC that means "SSE"

22nd April 2010, 14:20

Those benchmarks all tests libavcodecs performance by running a h264 video with the internal decoder, they clearly specify when the whole project was built with gcc, icc or msvc. [i have been brainwashed to believe gcc/icc are always faster than msvc so i have a hard time believing these facts myself]

its true that the improvements fall within the margin of error scale, but over all the benchmarks posted its consistently faster by 0.1% to 2%.
Hmm. Looking at your links, I only see one old benchmark (http://forum.doom9.org/showthread.php?p=998532#post998532) where MSVC is faster and two (this (http://forum.doom9.org/showthread.php?p=1363969#post1363969) and that (http://forum.doom9.org/showthread.php?p=1217662#post1217662)) where it's slower?