New ffdshow build (?)

[clsid]

from wikipedia
Differences between MMX and SSE2

SSE2 supports almost every integer operation that MMX supports. Therefore, it is possible to convert all existing MMX code to SSE2 equivalent. Since an XMM register are two times as long as an MMX register, loop counters and memory access may need to be changed to accommodate this.

Although one SSE2 instruction can operate on twice as much data as an MMX instruction, performance might not increase significantly. Two major reasons are: accessing SSE2 data in memory not aligned to a 16-byte boundary will incur significant penalty, and the throughput of SSE2 instructions in most x86 implementations is usually smaller than MMX instructions. Intel has recently addresses the first problem by adding an instruction in SSE3 to reduce the overhead of accessing unaligned data, and the last problem by widening the execution engine in their Core microarchitecture.

[videomixer9]

VC1 decoding still doesn't work for me for some reason and the new VMnc codec also won't run after I added, wonder what I oversaw ... tried various combinations so far already but both won't decode no matter what ...

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev146.exe?download

[_xxl]

AMD-XP:
http://s21.simpleupload.de/fa18a296e/ffdshow-tryouts-rev145-amd-xp.exe.html
AMD-K8
http://s21.simpleupload.de/fdb8eddb3/ffdshow-tryouts-rev145-k8.exe.html
INTEL-P4
http://s21.simpleupload.de/ffeef6e7a/ffdshow-tryouts-rev145-p4.exe.html

[videomixer9]

Lol bad day today, fucked up too often with that VMnc thing ... works now but it always crashes ... oh well, need to check if ffmpeg itself crashes too or if it's introduced through porting. Was so busy searching for the error that I oversaw the most obvious. It's early stage so I guess some errors are still in there and it hasn't hit mplayer either for now.

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev148.exe?download

[Amour]

... works now but it always crashes ...
crash ≠ working

By the way, is there a way to rotate or flip the image when watching (decoding) a video with ffdshow?

[Amour]

clsid and videomixer9, can you please fill the Release Date field when adding files to SourceForge (I mean on this page (http://sourceforge.net/project/showfiles.php?group_id=173941))? Like that, the files would be listed according to release date, and the package date wouldn't be August 3, 2006 anymore. Or you could keep filenames with the same logic name, so it becomes easy to spot the latest release.

Thanks a lot!

[cc979]

tested using elephant dream_hd xvid/ac3 (8mbs stream mostly)
using 07-07-06 hali splitter

videomixer9
ffdshow-tryouts-rev148.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 81.4, dfps: 79.0
vmr9: User: 8s, kernel: 0s, total: 9s, real: 10s, fps: 68.4, dfps: 60.8
ovrl: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 77.2, dfps: 74.6

drevil_xxl
ffdshow-tryouts-rev145-amd-xp.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 79.3, dfps: 76.5
vmr9: User: 8s, kernel: 0s, total: 9s, real: 10s, fps: 67.1, dfps: 59.5
ovrl: User: 8s, kernel: 0s, total: 8s, real: 9s, fps: 74.9, dfps: 72.2
...
ffdshow-tryouts-rev145-k8.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 78.5, dfps: 75.7
vmr9: User: 8s, kernel: 1s, total: 9s, real: 10s, fps: 66.2, dfps: 59.9
ovrl: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 75.3, dfps: 72.8
...
ffdshow-tryouts-rev145-p4.exe
null: User: 8s, kernel: 0s, total: 8s, real: 8s, fps: 79.7, dfps: 76.8
vmr9: User: 8s, kernel: 1s, total: 9s, real: 10s, fps: 70.2, dfps: 59.9
ovrl: User: 8s, kernel: 0s, total: 8s, real: 9s, fps: 74.5, dfps: 72.7

@videomixer9 your rev148 looks a bit faster, what instruction set is it using?

@drevil_xxl and @clsid if you do a rev148 i'll check them too

:thanks: guys

[cc979]

@videomixer9: using your rev148 virtualdudmod stated it could'nt find msvcr80.dll so i copied the one from ffdshow directory into system32 and vdm shows this error

http://img100.imageshack.us/img100/9916/clipboard1og8.png (http://imageshack.us)

[Amour]

1.FFdshow-Tryouts-20060901-rev122-sse2 crashes on P4
when decoding MPEG-2 using libmpeg2?
2.Libavcodec works fine?
3.FFdshow-Tryouts-20060901-rev122-sse & mmx are working fine?
Don't know, but, here are my tests:

ffdshow-tryouts-rev100-sse2 = working
ffdshow-tryouts-rev111-sse2 = crash
ffdshow-tryouts-rev118-sse2 = crash
ffdshow-tryouts-rev122-sse2 = crash
ffdshow-tryouts-rev138-sse2 = crash
ffdshow-tryouts-rev145-p4 = crash

I made a thread about it on http://ffdshow-tryout.sourceforge.net/phpBB2/

[videomixer9]

@videomixer9: using your rev148 virtualdudmod stated it could'nt find msvcr80.dll so i copied the one from ffdshow directory into system32 and vdm shows this error

http://img100.imageshack.us/img100/9916/clipboard1og8.png (http://imageshack.us)

try copying it to where the vdub plugin is located only, there should be no copy of it in the windows system32 dir, also note even if you have to also copy the manifest file!

If you want the runtime working everywhere please install vcredist_x86.exe instead of copying the file, the redist doesn't copy the file to the system dir and also comes with the manifests.

I tested the plugin and it works fine as always :P


@videomixer9 your rev148 looks a bit faster, what instruction set is it using?


none really, it's a plain generic build with no single instructionset enforced. It should technically also work on CPUs without MMX. Maybe you should also do some tests with filters enabled. Then my build might be slower ...

[Amour]

more tests:

ffdshow-tryouts-rev122-sse = crash
ffdshow-tryouts-rev122-mmx = crash

drevil_xxl, I found where is the issue! If you uncheck Enable output queuing during the installation, it will work fine. So you might consider to disable this option by default, or fix the issue.

[_xxl]

drevil_xxl, I found where is the issue! If you uncheck Enable output queuing during the installation, it will work fine. So you might consider to disable this option by default, or fix the issue.
Output queuing is NOT working and it causes ffdshow to crash?

[Amour]

Ah, sorry, sorry...

Output queuing enabled + BSPlayer = crash
Output queuing enabled + Windows Media Player = working
Output queuing disabled + BSPlayer = working
Output queuing disabled + Windows Media Player = working

So the problem is a combination of Output queuing and BSPlayer.

Same problem with VM9 releases. clsid is ok because it doesn't have Output queuing by default.

[videomixer9]

BSPlayer is crap anyways, the free variant is just a spyware throwing cashmachine and the pro version just crap only without the spyware. I guess everyone knows what bs means too ;O No sense working around bsplayer, guess just adding it to the blacklist for output queuing is adequate.

[_xxl]

Stable version should work with BSPlayer.Adding it to the blacklist is NOT a good idea.

[haruhiko_yamagata]

I think blacklist is not a good idea. Bsplayer, Crystal player and WMP...

Btw, what is working fine with queue?
MPC mostly works, except for (VMR9 renderless+RGB32+specific video card+pause) = blackout problem.

List working application and check by default
Use queue only in "..."
looks better.

What should be included in the list? I would like to add MPC first.

[haruhiko_yamagata]

@videomixer9: using your rev148 virtualdudmod stated it could'nt find msvcr80.dll so i copied the one from ffdshow directory into system32 and vdm shows this error

http://img100.imageshack.us/img100/9916/clipboard1og8.png (http://imageshack.us)
To say good bye to the msvcr80.dll problem, the installer have to deal with it. I'm trying to include vcredist_x86.exe for NSIS installer. vcredist_x86.exe has to be executed by administrator though.

[haruhiko_yamagata]

none really, it's a plain generic build with no single instructionset enforced. It should technically also work on CPUs without MMX. Maybe you should also do some tests with filters enabled. Then my build might be slower ...
Which filter would be affected?
As for MSVC8, the compiler make autodetecting code, doesn't it? If I'm not wrong, MSVC8(for .ax) generic build is not slow on new CPUs and works on old CPUs (maybe wrong).

[videomixer9]

MSVC8 doesn't use any autodetection, per default it generates generic running code for any CPU (of course it can detect if certain instruction sets are available and integrate special assembly for that, but it won't generate code making full use of the instruction sets). There are many variants to compile into machine code and every compiler is differently good on this task. Also some add extra checks or produce check routines etc. MSVC is generally producing stable code that is still faster than most of GCCs often unstable code. Intel Compiler uses many advanced compiling technologies to the fullest even without auto vectorization it reaches decently faster speeds that way. However C/C++ is quite slow compared to real well hand written assembler code (you can see this when compiling the plain C code of libavcodec with the compilers). As a human you still know the best which things you can leave out that a compiler would generate like it does for everything even if it may not be really neccessary. The list of optimization techniques is nowadays quite endless, and even more endless the variations, e.g. simple things like loop unrolling, if improperly done it makes things slow (partly that may also fault of the coder and his code), if properly used it speeds things up (with libavcodec and GCC it's usually slower). Same goes for many things. MSVC is a compromise of stable and fast code. ICL is the speedmachine and GCC is mostly portable but not fast. ICLs vectorization that tries converting things automatically to SSE1-SSE4 doesn't know if the vectorizations it does make sense, so it vectorizes quite useless loops and blocks too which can lead to crashes or speed things down as SSE units get stuffed with things to handle while they could just use the regular instruction units.

So as said often, the decoding speed is thanks to hand written code and the rest of the code is better executed the regular way except for some filters maybe. But maybe someone can test that to see how it compares. I'd think though that full GCC builds end up worse than MSVC and ICL builds will prolly be another tick faster, on some filters maybe special SSE/SSE2/SSE3/SSE4 builds may be faster. I released a Core2 Duo version before that is still quite much up2date with the decoding stuff that is usually tested and filters didn't change much either. I'm still wonder if someone could compare the Core2Duo version with a generic build.

As for the filters I'm usually trying filter speed differences with the rather odd combination of xsharpen + Gradual Denoise + Denoise3D. So far ICL generic managed to be 10 fps ahead of MSVC generic there.

[haruhiko_yamagata]

So MCVC8 creates code for SSE and use it by autodetect, but not so fast. Thank you very much.

[videomixer9]

it only does generates SSE code if /arch:SSE is set. The .ax. file will crash on non-SSE CPUs then once a SSE instruction will be actually used. Only few things will be replaced with SSE instructions when this function is used though.

[haruhiko_yamagata]

Bug fix(? alpha test) : Raw video :
When Divx5=disabled and Raw video=all supported, the Divx5 video flips. The player is MPC.
Please see if it does not have any side effects.

[videomixer9]

Does that even have to really do sth. with ffdshow and not more like funny avi decompressor kicking in before or so? Not even asking which tard uses that kind of configuration ... :O

[haruhiko_yamagata]

it only does generates SSE code if /arch:SSE is set. The .ax. file will crash on non-SSE CPUs then once a SSE instruction will be actually used. Only few things will be replaced with SSE instructions when this function is used though.
In that case, ffdshow.ax should be autodetected rather than libavcodec. I'm talking about installer.

[videomixer9]

Only the Innosetup has an autodetection routine to deploy it with several special compiles ... that installer is done by drevil_xxl and clsid, I have no need for such detections as special versions are useless anyways imo. All important things are hand optimized.

Is this another of those brought to us by 2ch tardness questions you're asking cause the cowards over there aren't lazy enough to try ask themselves? They seem to be totally keen on this optimizations shit even if it's worthless. Just tell them there's a magic detection component build in that automagically makes use of anything available :P

http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev150.exe?download

[Mc Onyx]

I was just wondering what happened with the "special" H.264 GPU accelerated ffdshow that was mentioned few pages back?

[Egh]

I was just wondering what happened with the "special" H.264 GPU accelerated ffdshow that was mentioned few pages back?

looks like that project (along with x264gpu from same author) was born dead :) Not that I actually expected anything soon, especially that devaster mentioned 3rd September for the release :P

Might be that the dev just seriously underestimated the difficulties coding that (take a look at Haali renderer for instance).

[_xxl]

In that case, ffdshow.ax should be autodetected rather than libavcodec. I'm talking about installer.
FFdshow.ax is autodetected.All files are.
GCC 4.0.3 compiler can compile SSE and SSE2 versions of ffdshow.ax.

[clsid]

clsid and videomixer9, can you please fill the Release Date field when adding files to SourceForge (I mean on this page (http://sourceforge.net/project/showfiles.php?group_id=173941))? Like that, the files would be listed according to release date, and the package date wouldn't be August 3, 2006 anymore. Or you could keep filenames with the same logic name, so it becomes easy to spot the latest release.

Thanks a lot!The release date is filled in for each file. However, SF keeps listing them alphabetically.

[clsid]

Lol bad day today, fucked up too often with that VMnc thing ... works now but it always crashes ... oh well, need to check if ffmpeg itself crashes too or if it's introduced through porting. Was so busy searching for the error that I oversaw the most obvious. It's early stage so I guess some errors are still in there and it hasn't hit mplayer either for now.
I tried a nightly build of VLC yesterday and it could play both VC-1 and VMnc samples that I got from the mplayer sample site. VLC also uses code based on ffmpeg, right? So in theory it should work.

[videomixer9]

yeah ... now just need to find out why it doesn't work in ffdshow so far.

[clsid]

Sample file with FourCC "WMVA" crashes. I also got VC-1 sample files with FourCC "WMVP" and "WVP2". MPC reports no filters found for those. It also doesn't seem to want to use ffdshow for VMnc.

[bond]

Sample file with FourCC "WMVA" crashes. I also got VC-1 sample files with FourCC "WMVP" and "WVP2". MPC reports no filters found for those. It also doesn't seem to want to use ffdshow for VMnc."WMVA", "WMVP" and "WVP2" are not vc-1 compliant. therefore ffdshow of course doesnt handle them

[_xxl]

rev 152 crashes:
http://i3.tinypic.com/2mwfcsx.jpg
rev 151 works.

[affter333]

Hi,
What's the last version of ffdshow that
supports Win98se ? The newest version (20060828)
doesn't seem to support it anymore..

Thanks for your help..

[clsid]

My builds support Windows 98.


The info&debug page looks a bit messy since the addition of SSE3/SSE4. Also MMX2 should be named MMXext. MMX2 is incorrect and confusing.

[Anima123]

I have an old P3 core which does not support MMXext while ffdshow defaultly set MMXext optimization on. Is it a bug with cpu detection routine?

[clsid]

As far as I know MMXext is a subset of SSE. All P3 support SSE.

[videomixer9]

ffdshow-tryouts revision 154r2
Download: here (http://prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev154r2.exe?download)

compilers: ICL 9.1.030 and GCC 3.4.5
changes: igor1st audio normalization tweak

I scraped the new instruction set things for now. Still didn't find the reason for VC-1 and VMnc not properly working, would be great if someone could check those things for stuff I oversaw really :O edit: 5% faster :P

[Eragon4ever]

You mean r154 not 127?

[Egh]

You mean r154 not 127?
prdownloads.sourceforge.net/ffdshow-tryout/ffdshow-tryouts-rev154.exe?download

announced 127, link leads to 154 :)

[videomixer9]

ups copy & paste devil striked

[LoRd_MuldeR]

Found a bug: The "perspective correction" filter makes ffdshow crash when interpolation-mode is set to "cubic", while "linear" and "none" seems to work. Tested with ffdshow-tryouts-rev150-AMD-XP-K8 (drevil) and ffdshow-tryouts-rev154.exe (vm9). My CPU is Athlon-XP.

[videomixer9]

hm works just fine on my athlon xp

[LoRd_MuldeR]

hm works just fine on my athlon xp
hmmm, that's strange. I tested with MPC. But that filter isn't very important anyways...

[foxyshadis]

Probably has something to do with the source being fed into it. Dimensions probably.

[Egh]

Probably has something to do with the source being fed into it. Dimensions probably.

Exactly. Did quick testing with ffdshow resizer put prior the perspective correction in "Cubic interpolation" mode.

ffdshow crashes reproducibly here on Athlon XP if horizontal size (vertical was autodefined from 16:9 sauce AR) hits 768. In my tests, even 766 works, but just 2 pixels increment crashes ffdshow.

[videomixer9]

yeah it indeed does with resizer on

[affter333]

Hi:
There seems to be a huge memory leak When using
kernel deinterlacer on NTSC Mpeg2 (720x480i).
the free physical memory is dropping fast. (-2M/sec)
After playing for about 2 min, free memory down to zero.
But it does release all the used mem when closing player.
(Win98se,wmp 6.4 & 9.0)

My observation is that when there's more motion, it
consume more memory.

It doesn't seem to have the issue when playing
with PAL mpeg2 (720x576i) (or with other deinterlacers)

I'm using ffdshow-tryouts-rev150-INTEL-P4.exe
, don't know about other builds..

Thanks..

[_xxl]

I'm using ffdshow-tryouts-rev150-INTEL-P4.exe, don't know about other builds..
Thanks..
Please test other builds!
videomixer9 and clsid ffdshow builds.