Log in

View Full Version : New ffdshow build (?)


Pages : 1 2 3 4 [5] 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72

bob0r
14th October 2005, 17:08
Everything but the .ax compiles with GCC. Making SSE compatible builds with GCC is another story.

Wrong, but compiling ffdshow.ax with gcc is quite useless:

Quote Milan Cutka:

And FYI: I used gcc 4.0.2 build from
http://oss.netfarm.it/mplayer-win32.php.

But even if you'd be finally able to build ffdshow using gcc too,
don't expect too much. I was able to run configuration dialog,
but the playback crashed at the beginning.

bob0r
14th October 2005, 17:09
https://sourceforge.net/tracker/index.php?func=detail&aid=1326921&group_id=53761&atid=471489

I found out some more details when ff_vfw.dll crashes:

After some more testing i have found out:
Compiling all files with gcc is no ff_vfw.dll crash.
Compiling ffdshow.ax with msvc 7.1 and ff_vfw.dll with
gcc, ff_vfw.dll crashes in virtualdub.

movax
14th October 2005, 18:28
After some more testing i have found out:
Compiling all files with gcc is no ff_vfw.dll crash.
Compiling ffdshow.ax with msvc 7.1 and ff_vfw.dll with
gcc, ff_vfw.dll crashes in virtualdub.

Your compiles are either borked then, or your computer configuration is.

bob0r
14th October 2005, 18:37
Your compiles are either borked then, or your computer configuration is.

Then so are celtic_druid's, Sharktooth's and a lot of other people's!

Kinda stupid unmotivated answer.... please leave those to me :sly:

Egh
14th October 2005, 19:14
https://sourceforge.net/tracker/index.php?func=detail&aid=1326921&group_id=53761&atid=471489


Good, maybe it will be fixed then ;)

Now more about libmplayer.dll, different builds and speed.

I installed last CD's build, works fine. Although the size of libmplayer.dll grow up to 570kb (but there were some changes to it recently).

(@Celtic: what compiler was used in this build?)

As for speed, i didn't notice much difference with 20051013 build working with new dll or the one from movax 1010 build.

Also, since b0b0r didn't like previously suggested video (are you sure you didn't get v1 of that trailer instead of v2?), i made more interesting test.

http://bt.animeasy.net/ [air creditless OP, first entry in the list]. It's from progressive source and thus 29.97fps all the way, so it is *quite* CPU hungry. In fact on my system (cpu same as b0b0r ;)) it is very close to maximum i can play w/o frame drops (of course using VMR9, and inloop filter disabled). So those who have Athlon XP (i.e. SSE only, no SSE2 system) might try and see if they can get smooth playback using various builds of ffdshow.

bob0r
14th October 2005, 19:49
@Egh:
ok :cool:

Edit:
That build you installed from c_d must be ICL, because of the bigger file sizes.
If you were talking about [PSNR]Air.Creditless.OP.[avc][vorbis].mkv, i ran it twice, simultaneous, both played perfect without dropping frames :D
Do note, i have disabled all visual effects in WindowsXP, even thought i do run a lot of programs, the file plays just fine.


@Celtic_Druid:

I installed ICL 9.0 and integrated it with MSVC7.1.

When i had converted all ffdshow.sln to ICL, i build all 22 projects, the only files that appear in ffdshow\bin are:
ff_acm.acm, ff_realaac.dll, ff_vfw.dll, FLT_ffdshow.dll and verinc.exe

You have any tips how to compile ffdshow using ICL 9.0?
And if you already know, let us know which files can and which files cannot be compiled with ICL 9.0.

Egh
14th October 2005, 20:25
@Egh:
If you were talking about [PSNR]Air.Creditless.OP.[avc][vorbis].mkv, i ran it twice, simultaneous, both played perfect without dropping frames :D
Do note, i have disabled all visual effects in WindowsXP, even thought i do run a lot of programs, the file plays just fine.


That is strange. PPL reported 50% cpu usage on Athlon64 3200+ on ffdshow playing this file. So CPU usage 50% on athlon 1800+ would be kind of miracle. Please tell us your settings :) Or is it due to some good hardware acceleration?

Are you sure you play them with all options enabled in MPC? Especially the subtitles (first subtrack, not second).

Update: Some more test results from that special came in.
System: 2200+ XP, cccp 0923. Usage close to 100% in mpc + ffdshow (and that's in overlay mode, in vmr9 it lags and drop frames :P). Though less in zp + ffdshow + vsfilter, but with karaoke effect >90% cpu usage reported.

clsid
14th October 2005, 23:20
You have any tips how to compile ffdshow using ICL 9.0?
And if you already know, let us know which files can and which files cannot be compiled with ICL 9.0.
Everything except libavcodec compiles with ICL9 :D

You need to add to linker input: libircmt.lib libmmt.lib svml_dispmt.lib
C/C++ command line: /QaxKWNPB (=optimize for all processors)
C/C++ general: warning level = 0 (otherwise VS might crash)

Don't forget to patch libircmt.lib ;)

http://www.swallowtail.org/naughty-intel.html

movax
15th October 2005, 01:15
You can tell GCC compiles by running the dependeny walker on them like I mentioned earlier. MSVCRT.DLL = GCC, MSVCR71 = MSVC. Not sure about ICL, I'd assume you can differentiate that from the others through filesize.

bob0r
15th October 2005, 01:18
@clsid

I did run intel_check_executable_patch.pl libircmt.lib, that seems to work :)

If i run intel_check_patch.pl
File 'libirc.a' not found! This file is nowhere on my system, please let me know what to do! Or is it not important?


Edit:
Ah never mind, i got it working, i needed to linker/input and edit all projects seperately, probably a way to fix them all together, but i have no idea how to :)

celtic_druid
15th October 2005, 03:39
I use MSVC6 with ICL9, so no msvcr71. libmplayer was the only thing that I didn't compile with ICL9. It was compiled with gcc, although as mentioned earlier, parts of libavcodec are compiled with gcc to.

bob0r
15th October 2005, 05:19
ffdshow-20051015

gcc = gcc 4.0.2
icl = icl 9.0
msvc = msvc 7.1

http://mirror05.x264.nl/public/ffdshow/ffdshow-20051015.exe (all files gcc, except ffdshow.ax and ff_vfw.dll are msvc) (recommended and online version)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051015-gcc.exe (all files gcc, playback will 99% crash ffdshow)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051015-icl.exe (all files icl, except libavcodec.dll is gcc)
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051015-msvc.exe (all files msvc, but playback can be very slow)

[ Note x264 has server (nameserver) problems, working on backup nameserver so you can keep accessing the mirrors ]

Happy testing!

canuckerfan
15th October 2005, 06:14
what's the difference between celtic_druid's builds and bob0r's builds?

celtic_druid
15th October 2005, 07:30
((always_inline)) -> ((__always_inline__))
SPP deblocking doesn't depend on libavcodec
can be compiled using GCC 4.0.2
fast SPP imported
use image filters in VFW decoding

videomixer9
15th October 2005, 13:55
if there are nameserver problems why don't you just add the IP address of the mirror in the link instead of using it's DNS name. That way anything should work fine, not like you cannot link to the IP addresses, you can always change it back later ...

bob0r
15th October 2005, 14:27
The mirrors are all apache virtual hosts, but ill past you the full paths:

http://69.61.23.138/~x264/public/ffdshow/ffdshow-20051015.exe (all files gcc, except ffdshow.ax and ff_vfw.dll are msvc) (recommended and online version)
http://69.61.23.138/~x264/public/ffdshow/ffdshow-20051015-gcc.exe (all files gcc, playback will 99% crash ffdshow)
http://69.61.23.138/~x264/public/ffdshow/ffdshow-20051015-icl.exe (all files icl, except libavcodec.dll is gcc)
http://69.61.23.138/~x264/public/ffdshow/ffdshow-20051015-msvc.exe (all files msvc, but playback can be very slow)

Enjoy

videomixer9
15th October 2005, 14:30
thanks, works fine!

the builds are actually quite funny, the first build has high peak CPU usage for me than the full ICL build. If suddenly on h264 video high motion scenes kick in, the peak uses goes upto 67% on my tested encode, ICL peaks at 54% for those scenes, on regular motion scenes GCC is also a bit more CPU consuming, however on low motion it has much lower CPU usage down to 23%.

Quite amusing ... especially as libav is both GCC compiled ...

Egh
15th October 2005, 14:54
I tried first and third builds on that heavy cpu load video. First one seems to be a bit better than ICL compiled, but that i already noticed with movax builds (iirc there .ax is compiled with msvc and the rest with gcc).

@b0b0r: it seems that the CR/LF pairs in the "about" section of your ffdshow builds are b0rked. Other builds have proper line breakes in that text. I noticed it earlier but forgot to report :)

Liisachan
15th October 2005, 15:59
Thank you for your hard work :D
Tested with x264-video-only.mp4 on P4 3.4GHz,
In this test -msvc was significantly slow, the other 3 were about the same.
-gcc didn't crash.

http://subforge.net/image/2005/20051015mp4.png

Edit:
Same clip in SNOW. It doesn't play with -msvc. [ "This graph can't play. Unspecified error (Return code: 0x80004005)" ]
The other 3 are about the same again.

http://subforge.net/image/2005/20051015snow.png

Edit2:
CPU load-wise, I don't see any real differences between celtic_druid's 20051013 and this 20051015, tho the former may be slightly more optimized for my CPU.
http://subforge.net/image/2005/20051015c.png

midiboy
15th October 2005, 17:40
Hi Guys,

I hope you donīt keep ignoring me ... I am getting crashes with ALL versions since the ffdshow-20050920.exe. That was the last one that worked for me. All the versions since that one crash with my TV recordings I make with MediaPortal, no matter which compiler is being used. Since I am not using ffdshow for the MPEG2 video decoding it must be the ffdshow audio part that is crashing.



Hereīs the result with with the versions released on the 15th:

ffdshow-20051015.exe:
http://members.chello.at/afmusic2/ffdshow-20051015.JPG

ffdshow-20051015-gcc.exe
http://members.chello.at/afmusic2/ffdshow-20051015-gcc.JPG

ffdshow-20051015-icl.exe
http://members.chello.at/afmusic2/ffdshow-20051015-icl.JPG

ffdshow-20051015-msvc.exe
http://members.chello.at/afmusic2/ffdshow-20051015-msvc.JPG

I am using Zoom player 4.51, customized media mode, VMR9 windowless, ffdshow for the MPEG2 Audio profile (using the NVIDIA Audio decoder also fixes the crashing)

The ffdshow audio decoder (20050920 version) reports this:
http://members.chello.at/afmusic2/Screen05.JPG


I have uploaded a small recording here (http://members.chello.at/afmusic3/rec.dvr-ms) so you can see for yourself !

Could you please fix this for the next versions, thanks !! :cool:


Bye,
Alex

clsid
15th October 2005, 18:06
Try libmad instead of mp3lib.

bob0r
15th October 2005, 18:09
@midiboy

I suggest you submit this bug to http://sourceforge.net/tracker/?group_id=53761&atid=471489

I get the crash with Windows Media Player 10 too, however when i try to play the file with Media Player Classic 6.4.8.4, it says it cannot find a connectable filter. (funny when i start the video with WMP10, then at the same time with MPC6.4.8.4, it does play the audio (only the video is lighter, brightness wise, as usual :)))

Disabled mp1/mp2 via start/programs/ffdshow/Audio decoder configuration/Codecs > set MP1/MP2 disabled, will play the audio part for me, WMP10 says its InterVideo Audio Decode.

So submit the bug and let the ffdshow developers know!

bob0r
15th October 2005, 18:10
Try libmad instead of mp3lib.

Same problem, WMP10 crashing, MPC6.4.8.4 saying it cannot find a connectable filter

marcellus
15th October 2005, 18:53
Hi bob0r, thanx for your builds.
I tested 3 of the 4 builds for mpeg2 (25fps/720x576/2000 kbps) encoding speed on my athlon xp 2600+ (with Kernel Deinterlace as image processing enabled).
-The fastest by far the icl one, (85-95% cpu); is not as fast as celtic_druid's latest build but is very close, with a difference of about 4-6 percent.
-The regular (recomended) build is slow, it gets the cpu at 100% and it drops more frames than actually manages to capture.
-The pure gcc build crashes right away.

(I mentioned the bitrate in the mpeg2 capture specs because I noticed that the higher the bitrate - the more CPU it needs (for the same motion search parameters). For example I manage to capture safely in realtime with my CPU at about 2-3000 kbps, higher it's a gamble. I think this is true for libavcodec in general, not only for ffdshow).

multiblitz
15th October 2005, 19:28
Is there any version / developer out there which supports dual-cores ?

bob0r
15th October 2005, 19:28
http://cia.navi.cx/stats/project/ffdshow
http://cia.navi.cx/stats/project/ffdshow/.message/6044320
use __stdcall in internal VFW interface - not backward compatible change, but allows GCC<->MSVC interoperability

The gcc ff_vfw.dll and msvc ffdshow.ax crashing is fixed.

@marcellus
Yup ICL is faster, and celtic_druid probably uses some optimizations.
The GCC is not that much slower, and some of you people really manage to get frames dropped, where i can run some clips twice, maybe disable all XP visual stuff? :)

Thanks for the testing, but for now the default online build will be all files gcc + ffdshow.ax msvc.

clsid
15th October 2005, 20:03
Where can I find a (windows) binary of GCC 4.0.2 (for use with mingw)?

bob0r
15th October 2005, 20:12
Where can I find a (windows) binary of GCC 4.0.2 (for use with mingw)?

Extract
ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-4.0.2/gcc-core-4.0.2.tar.gz
and
ftp://ftp.nluug.nl/mirror/languages/gcc/releases/gcc-4.0.2/gcc-g++-4.0.2.tar.gz
(both will be gcc-4.0.2/) then:

1. cd gcc-4.0.2/
2. mkdir obj
3: cd obj
4: ../configure --prefix=/usr/local
5: make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
6: make install

As for step 4, that failed on me, so i copied:
C\msys\1.0\local\include dir to:
C\msys\1.0\ (seems it searches for /usr/include and its subdirs/files)

marcellus
15th October 2005, 21:35
The GCC is not that much slower, and some of you people really manage to get frames dropped, where i can run some clips twice, maybe disable all XP visual stuff? :)

My main interest in ffdshow is dvd compatible capturing (encoding) and not playing CPU demanding formats (as I like to watch what I capture on my standalone and TV set). Maybe in the encoding case the difference in speed between icl and gcc is more important. I'm just guessing, as I am a simple user.

midiboy
16th October 2005, 10:41
Hi Guys,

I have created a bug report as suggested. Thanks for your help !

Bye,
Alex

bob0r
16th October 2005, 16:28
http://cia.navi.cx/stats/project/ffdshow is currently down, i believe there are some more sites doing something similar to check for ffdshow updates, anyone has that/those site(s) URLs?

Liisachan
16th October 2005, 19:08
how about this?
http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/src/?sortby=date

Egh
16th October 2005, 20:25
http://cia.navi.cx/stats/project/ffdshow is currently down, i believe there are some more sites doing something similar to check for ffdshow updates, anyone has that/those site(s) URLs?

Nah, only site i know besides sf's CVS and CIA site (which is down atm) is changelog on http://m17n.cool.ne.jp/freeware/mpc/ But that's not regularily updated one :)


Heh, amongst very latest updates from cvs one quite interesting:

" possible to build ffdshow using GCC without requiring SSE2"

Seems that pure gcc builds might be more sensible now.

Seems that http://sourceforge.net/tracker/index.php?func=detail&aid=1326883&group_id=53761&atid=471489
and
http://sourceforge.net/tracker/index.php?func=detail&aid=1326921&group_id=53761&atid=471489
are fixed in source now.

Egh
17th October 2005, 01:30
Interesting last fix:

(file) TffdshowDecAudio.cpp 1.159 6 hours milan_cutka fix encoder input colorspace forcing I remember that there were some problems with input colorspace, but i didn't know they are in audio decoder .... :P

Liisachan
17th October 2005, 06:11
cia.navi.cx is up again.
cvs changelog on ffdshow.faireal.net / m17n.cool.ne.jp / etc. is just manually copy-and-pasted from cia. so it doesn't work if cia. is down.

bob0r
17th October 2005, 07:02
Yeah thanks, indeed up again.

I do remember seeing some other cia.navi.cx like site with the same updates.

Via google or doom9, i dont remember anymore, just cant find them.

Anyways looks like we gonna test full gcc build + all updates :D

@celtic_druid:

... Interesting to note is that you get a cli version of makeavis.
http://cia.navi.cx/stats/project/ffdshow/.message/6056690
have a GUI built with makeAVIS when using GCC (patch by Kurosu)

Inventive Software
17th October 2005, 14:18
Hehe. :D I'm gonna have to get the sources at some point to actually try to build this thing next week. Trouble is, CVS doesn't like me. All the computers are getting Windows XP installed (I say good luck to the technicians!) and as such they're gonna be unusable from about Thursday (20/10/05) onwards until they get the bugs ironed out.

Can somebody be so kind as to provide a mirror for the sources for ffdshow please? Any build in October will be fine. I've tried numerous solutions for getting the sources and none have worked. It seems that the software I've tried has problems getting through the proxy server.

celtic_druid
17th October 2005, 15:08
http://mirror05.x264.nl/celtic_druid/force.php?file=./ffdshow.7z
Source current as of a few minutes ago. I compiled ffdshow with gcc earlier and it worked. No crashes.

bob0r
17th October 2005, 18:14
http://mirror05.x264.nl/celtic_druid/force.php?file=./ffdshow.7z
Source current as of a few minutes ago. I compiled ffdshow with gcc earlier and it worked. No crashes.

To compile ffdshow.ax without sse2 thus without crashing:

Quote Milan Cutka:

Yes, you have to edit src/makefile.inc and src/makefile_c.inc.
Search for -msse2 switch and remove it.

bob0r
17th October 2005, 21:32
Test Build ffdshow-20051017.exe:
http://mirror05.x264.nl/public/ffdshow/ffdshow-20051017.exe

Compiled only with gcc 4.0.2.

Manually edited:

ffdshow/src/makefile.inc
ffdshow/src/makefile_c.inc
(removed -msse2 from CFLAGS+=-mmmx -msse -msse2)
This so you can use ffdshow.ax on a CPU without SSE2 support, without crashing, may still not work on a CPU not supporting SSE.
based on:
possible to build ffdshow using GCC without requiring SSE2 > http://cia.navi.cx/stats/project/ffdshow/.message/6056513

ffdshow/dscaler/Makefile
added -I"/dx/Include" -L"/dx/MingLib" -ldx9 behind CFLAGS+= -I. -I../src

ffdshow/src/codecs/wmv9/Makefile
added -I"/dx/Include" -L"/dx/MingLib" -ldx9 behind CFLAGS+= -I. -I../.. -I../../cygwin -I../../baseclasses -Iinclude -DSUPPORT_INTERLACE

These are Direct X 9 header files, required to build these files.
(copied from C:\Program Files\Microsoft DirectX 9.0 SDK (Summer 2004), and based/convert on: http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6939)

Quick Test, with (from x264) using cpu capabilities MMX MMXEXT SSE 3DNow! (AMD XP 1800):
xvid/divx/x264
All files playback perfectly, even my x264.333.mp4 runs way smoother than before, when i skip the video, the Sync Offset (avg and dev) both remain 0ms.
So far no crashes, this may not be the fastest version one can build, but i hope it has the best ratio between speed and stability.
And since its fully gcc, i can easily built a new build on a weekly bases or on demand. (Run mingw > ffdshow_gcc.sh and done)

Please test this build!

movax
17th October 2005, 22:43
I'll expand on your idea a bit, and upload a RAR with gcc_sse and gcc_sse2 in a few minutes :) Nice work. I'm pretty sure NOINTRIN=1 does something similar to your makefile editing though.

clsid
17th October 2005, 22:49
I have finally updated gcc from 3.4.4 to 4.0.2

What I have noticed so far:

All compiled libs are a bit bigger in size, except for libavcodec which is a little bit smaller.

ff_kernelDeint.dll and TomsMoComp_ff.dll came out much bigger (1057 and 1279 KB) as before (656 and 660 KB). I also noticed both were much slower compared to my ICL9 builds, but also compared to my old gcc builds.

bob0r
18th October 2005, 00:54
All tests are ok, ffdshow-20051018.exe online! :cool:

vortex_hl
18th October 2005, 01:07
All tests are ok, ffdshow-20051018.exe online! :cool:
it's crashes when opening "version details" window.

NoX1911
18th October 2005, 01:36
crashes here as well... (AmdK7/XPSP2)

I tested some versions (not 18102005 yet) on AmdK6. None worked. Any chance to see a generic build in near future?

bob0r
18th October 2005, 02:08
it's crash when opening "version details" window.

Confirmed, bug submitted.
https://sourceforge.net/tracker/index.php?func=detail&aid=1329122&group_id=53761&atid=471489

crashes here as well... (AmdK7/XPSP2)

I tested some versions (not 18102005 yet) on AmdK6. None worked. Any chance to see a generic build in near future?

Are you only talking about the Version Details crashing?
This seems a bug and will probably be fixed any time soon then.

Most importantly is audio/video playback, if you come up with any crashes of those please report them.


My personal goal is to test as many as possible with GCC and forget about icl/msvc.

Thanks for testing and keep it up! (the testing :p)

NoX1911
18th October 2005, 02:25
Are you only talking about the Version Details crashing?
No, generally trying to get ffdshow running on a K6 cpu. Either it doesn't even install (cannot register ffdshow.ax - msvc version) or crashes on playback attempt (filtergraph initialisation - non-msvc version). Manually disabled all cpu extensions (mmx, sse,...) but doesn't help...
.NET(sp1) is installed (maybe some libs are useful) and all ms updates. GFX driver is a generic XPSP2 nVidia TNT though. Original DivX and XviD codecs are working without problems.

flanger216
18th October 2005, 02:37
I get a crash when I use Denoise3D in 'high-quality' mode, and even normal Denoise3D is much slower than HQ-mode used to be. Was Denoise3D optimized for SSE2...?

Chris

bob0r
18th October 2005, 03:05
No, generally trying to get ffdshow running on a K6 cpu. Either it doesn't even install (cannot register ffdshow.ax - msvc version) or crashes on playback attempt (filtergraph initialisation - non-msvc version). Manually disabled all cpu extensions (mmx, sse,...) but doesn't help...
.NET(sp1) is installed (maybe some libs are useful) and all ms updates. GFX driver is a generic XPSP2 nVidia TNT though. Original DivX and XviD codecs are working without problems.

Try to submit your finding as bug report to the ffdshow development team, because if its for all versions, i can't help you.
http://sourceforge.net/tracker/?group_id=53761&atid=471489

bob0r
18th October 2005, 03:15
I get a crash when I use Denoise3D in 'high-quality' mode, and even normal Denoise3D is much slower than HQ-mode used to be. Was Denoise3D optimized for SSE2...?

Chris

Crash confirmed!
---

http://forum.doom9.org/showthread.php?p=683104#post683104
and
http://forum.doom9.org/showthread.php?p=683246#post683246
Seems it is optimized for SSE2(which i removed to prevent crashing)

Edit:
For those who wondered, like i did:
start/programs/ffdshow/Video decoder configuration/Blur & NR > Denoise3D and enable HQ.

Crashes on ICL/GCC, MSVC seems to work.

bug submitted:
https://sourceforge.net/tracker/index.php?func=detail&aid=1329145&group_id=53761&atid=471489