New ffdshow build (?) [Archive] - Page 4

SeeMoreDigital

6th October 2005, 20:40

"Matroska" is not a person... Haali is and develops this splitter. So it's Haali's media splitter.Yep.... I'm aware of that. However, this does not explain why, on Matroska's web site, we see this: -

http://img123.imageshack.us/img123/9891/haali3gy.png

....This sort of thing has got to be confusing to newbies?

Cheers

clsid

6th October 2005, 22:09

At first it was only a splitter for Matroska. Now it also supports AVI and MP4.

But I agree that it is confusing.

Selur

6th October 2005, 23:29

1st I thought that it seemed like ffdshow had sometimes a problem selecting the right idct if it is set to 'auto' and the video stream (original Xvid) is muxed into a mp4 shell, but after changing the idct I had to release that all the options besides auto decode the file fine.

avi:
http://forum.gleitz.info/attachment.php?attachmentid=76070
mp4:
http://forum.gleitz.info/attachment.php?attachmentid=76072

screenshot:
http://forum.gleitz.info/attachment.php?attachmentid=76079 (3ivx)
http://forum.gleitz.info/attachment.php?attachmentid=76080 (libav 'auto')
http://forum.gleitz.info/attachment.php?attachmentid=76081 (libav 'xvid mmx')
http://forum.gleitz.info/attachment.php?attachmentid=76082 (nero)

=> What does happen if one selects 'auto'? (I thought it would automaticly decide if to choose e.g. Xvid MMX, integer or ..., but it seems like it does something else.)

Would be cool if someone could clear this up. :)

Thx

Cu Selur

tedgo

7th October 2005, 01:45

This "IDCT-problem" in ffdshow only happens with xvid encoded with a cqm or mpeg-matrix in mp4, not with h263-quantization or xvid cqm/mpeg in avi.
Is xvid cqm/mpeg-matrix in mp4 currently not "really" supported in ffdshow?

hpn

7th October 2005, 03:20

"Matroska" is not a person
(Sorry for the OT) Actually it is. It's an wooden figure usually representing a peasant Russian girl in traditional dress. The correct name is Matryoshka (or Matrioshka), but the original developer renamed it to "matroska" to make it sound better for the English speaking world. Here is more
http://en.wikipedia.org/wiki/Matryoshka

stephanV

7th October 2005, 08:59

Actually it is.
Yes i know where the name originates from, but I wouldn't call a type of doll a person. Certainly in this context, where the name "Matroska's Haali media splitter" was proposed the term Matroska can't be related to any person. There is not someone called "Matroska" in the Matroska team. The name is used for the container and I doubt a container format has ever developed any software for itself. :)

Inventive Software

7th October 2005, 11:21

....This sort of thing has got to be confusing to newbies?

Yup, I was confused as well. No thanks to my Aspergers!

ExtraEye

7th October 2005, 12:34

any feedback about the new ffdshow?

clsid

7th October 2005, 16:28

The configuration windows don't work.

rundll32 ffdshow.ax,configure
rundll32 ffdshow.ax,configureAudio
etc.

SeeMoreDigital

7th October 2005, 20:17

According to Matroska's web site "A Matroska Muxer is now included in the package (ie: the 05/10/2005 "test" version)....... But I'm unable to see where this installation contains anything new?

New 05/10/2005 "Test" version: -

http://img31.imageshack.us/img31/121/matroskatest7in.png

Previous 28/09/2005 version: -

http://img85.imageshack.us/img85/5535/haalifilter5kx.png

Cheers

MarkCoolio

7th October 2005, 20:29

The splitter.ax has increased in size (~ twice as big).. so the muxer is included there.

SeeMoreDigital

7th October 2005, 20:41

The splitter.ax has increased in size (~ twice as big).. so the muxer is included there.Is that common practice... Why are they not separate?

Cheers

CruNcher

7th October 2005, 22:57

i think its a cool idea if you have decoder multiplexers splitters from different companies it can really get alot and you lose overview bringing more stuff into 1 big .dll can reduce this chaos alot especialy multiplexers or other special filters as they only get used when needed most times by a special application and when you want to use it for a special purpose like muxing you just open the config dialog and click on mux mode i think a perfect idea more should do it this way :)

vidhead

8th October 2005, 02:49

So remind me. What exactly do I need to compile ffdshow, bearing in mind all I have at the minute is MSYS, MinGW 3.4.2 (i'm working on updating this to 4.0.1), and NASM 0.98.39.

Also, is there any specific instructions that I need to take account of. Usually with most packages, I just do "configure", "make all", and if necessary, "make install".

try here:

http://sourceforge.net/tracker/?group_id=53761&atid=471490&func=detail&aid=1277820

i did. unsuccessful with specified mingw/msys. :(

any ideas?

edit: http://72.14.203.104/search?q=cache:LSGdNPwSoqEJ:www.zszoi.glog.pl/Home/KazubskiJ/help/compilation.html+ffdshow+compile+mingw+msys&hl=en

google cached copy looks possible but atm don't've all the tools.

clsid

8th October 2005, 13:12

You don't need MSYS. That's a unix emulator. Since ffdshow will be build for Windows, you only need MingW.

Also, not all files will compile with GCC. For example ffdshow.ax won't. So don't use the main Makefile. Just go to the directory of each library and run "Make clean" and then "Make CC=gcc".

You need to compile ffdshow.ax (and some other files) with Visual Studio 2003.

-----

Does anyone know how I can run a Visual Studio 2005 compilation of ffdshow.ax on Windows XP? I have put the correct version of msvcr80.dll and Microsoft.VC80.CRT.manifest in the same folder as ffdshow.ax (to act as private assembly), but registering ffdshow.ax always gives an error.

Egh

8th October 2005, 22:53

BTW, for those who doesn't know yet: 20051006 build (hosted by x264 and already on free-codecs.com) suffers from same playback slowdown problem as [unfixed] celtics's 20050920.

Compling comrades, please do pay more attention to libmplayer.dll builds!!! :P

1006 is better build than 1002 due to lots of changes in ffdshow source, so I use 1006 but put into ffdshow folder that dll from movax's 20051002.

movax

9th October 2005, 04:42

Does anyone know how I can run a Visual Studio 2005 compilation of ffdshow.ax on Windows XP? I have put the correct version of msvcr80.dll and Microsoft.VC80.CRT.manifest in the same folder as ffdshow.ax (to act as private assembly), but registering ffdshow.ax always gives an error.

Everytime I've compiled the VS2005 project, I get a .ax that will never display video, so basically a null .ax. Don't bother with that project.

I've been busy lately, but I'm still working on the mutant mongrel build of it with the latest cvs of each lib/component.

clsid

9th October 2005, 12:15

bob0r

9th October 2005, 15:25

Exactly. For mplayer.dll and libavcodec.dll the GCC builds should be used. The MSVC71 builds are too slow.

Affirmative.

I compiled libavcodec.dll with gcc (because msvc does not work)
But i guess libmplayer.dll is causing slow playback?
On slow CPU? on certain samples (any online?)?

libavcodec.dll + libmplayer.dll gcc 3.4.2
(compile ff_vfw.dll with gcc = crash in virtual dub)

Any more files should be compiled with gcc?

Egh

10th October 2005, 01:55

Affirmative.

But i guess libmplayer.dll is causing slow playback?
On slow CPU? on certain samples (any online?)?

Not if you consider 1800+ XP slow CPU for playback.

I can't get smooth playback with that faulty dll of any avc stream. And i play the same stream on proper dll with software _bicubic_ resizer on.

As a test i always use TheFluffy's Hellsing Ultimate OVA trailer. That one was encoded w/o [de]blocking in-loop filter, btw. And I always have "skip deblocking always" enabled in ffdshow. So if i get slowed and certainly nonsmooth playback of that video [VMR9, RGB output] (without resizing enabled, with resizing it's more like quick slideshow and causes audio/video desync) == fault.

That behaviour was originally discovered by me, btw. See entry on ffdshow tracker: http://sourceforge.net/tracker/index.php?func=detail&aid=1296582&group_id=53761&atid=471489

Also, if you're sure that compiling ff_vfw.dll with gcc causes crash, then probably better report there: http://sourceforge.net/tracker/index.php?func=detail&aid=1310982&group_id=53761&atid=471489

But, iirc movax 1002 build was gcc and i didn't have any problems with vfw crashes there.

Edit: BTW, checked 1009 build -- no that problem like in 1006. Though i somehow feel (though that could be only my imagination, since i didn't measure actuall performance with anything specific) that full gcc build (1002) was the smoothest one in terms of playback speed (and also mpc reaction time to user actions). But that's only an impression, there could be many factors contributing there on comparison.

movax

10th October 2005, 03:40

Some of them shouldn't be compiled with GCC, like a52 for sure. libavcodec and libmplayer should both be always compiled with GCC for sure.

Making a chart of the DLL combos and their results would be very useful. Using GCC for things like libdts allows you to do things like "make NOINTRIN=1", therefore allowing it to function normally on a non-SSE2 system.

bob0r

10th October 2005, 04:29

@Egh

Anyway i can get my hands on that video?

I have AMD XP 1800+ too, with 1024MB ram.
The only slow videos i have are HD 1280x720, but only a stutter now and then, never a slide show.

As for the 2 dll files i compiled with gcc, i just did make clean and make, no extra optimizing flags, if any exist, gcc version 3.4.2

celtic_druid

10th October 2005, 06:03

Was there ever a verdict on the speed of libavcodec compiled by icl/gcc vs. a pure gcc build?

Revgen

10th October 2005, 07:36

Was there ever a verdict on the speed of libavcodec compiled by icl/gcc vs. a pure gcc build?

I haven't noticed a difference at all as far as performance.

SPP deblocking performance is about the same as the last one. At least to my eyes.

Then again I have an AMD X2 4600+. Even though you removed Intel's CPU detection parameters out of the ICL build, it's improvements most likely benefit Intel processors than AMD.

Hopefully Milan could release a mutithreaded version in the near future.

marcellus

10th October 2005, 09:46

Hi,
I have an Athlon XP 2600+ and I use ffdshow to record live from my TV tuner in DVD PAL format (Mpeg2, 720x576, 25fps). The only image processing I enable is KernelDeinterlacing.
The latest build I can use is celticdruid's 20050930 (not msvc71 one). 20051006 and 20051009 are slower enough to make the capture program (whitch, BTW, it's using DirectShow interface, not VFW) to constantly drop frames getting the CPU at 100% usage. 20051009 is a little faster than 20051006 but not by much (not enough to stay below 100% permanently). With 20050930 the CPU usage stays at 82-88%, I recorded even 5 hours without a dropped frame.

bob0r

10th October 2005, 14:51

@marcellus
Interesting, that build 0930 is made with ICL, guess ill have to look into that aswell :) :(

@celtic_druid
whats the difference between icl/gcc and "pure" gcc?

celtic_druid

10th October 2005, 15:59

Well in one case all files are compiled via gcc, in the other those that can are compiled with ICL, the rest are compiled with gcc. Have a look at the libavcodec dsp file.

clsid

10th October 2005, 16:55

Could you give some more detailed instructions on how to create such a mixed build?

Egh

10th October 2005, 19:39

@Egh

Anyway i can get my hands on that video?

I have AMD XP 1800+ too, with 1024MB ram.
The only slow videos i have are HD 1280x720, but only a stutter now and then, never a slide show.

Are those videos AVC? Cause really noticable slowdown (not percents, but more like dozens of percents on 1800+, 512MB ram).

For testing, download trailer from bt.animeasy.net (the fluffy one, though no objections to getting anything else:). That trailer was encoded with Nero AVC, no deblocking inloop used.

I use: (not only for testing, for casual watching too:)
MPC (last celtic's build), ffdshow.
In mpc -- VMR9 is used, in ffdshow -- RGB output and "high-quality conversion" enabled. "Skip deblocking always" used.

Try two modes: playing w/o any resizer (including mpc one) and then going to ffdshow Resizers, enabling bicubic/lanczos for let's say 1024*768 resolution. [damn, when milan cutka finally makes normal resizer interface in ffdshow????!!!!! I keep bugging him for months :)].

In my case, some playback slowdown [mostly in complex scenes] and very slow reaction to user actions [like right-click menu appearance] is present in first mode. In second mode, it's not exactly slideshow, but real FPS (according to OSD meter) are usually below <16 [in complex scenes] and audio/video desync is caused.

Also ffdshow OSD's cpu meter is recommended. With "fault" libmplayer.dll you see CPU usage higher on average than on gcc dll. In fact now i see faulty dll practically at once on playback seeing CPU meter in ffdshow osd. In normal library CPU meter jumps a lot, but with nongcc dll it almost always @ 100%.

Egh

10th October 2005, 20:00

The latest build I can use is celticdruid's 20050930 (not msvc71 one). 20051006 and 20051009 are slower enough to make the capture program (whitch, BTW, it's using DirectShow interface, not VFW) to constantly drop frames getting the CPU at 100% usage. 20051009 is a little faster than 20051006 but not by much (not enough to stay below 100% permanently). With 20050930 the CPU usage stays at 82-88%, I recorded even 5 hours without a dropped frame.

I'd suggest you to try movax 1002 build (the one which is in \gcc folder in .rar archive). Can you confirm that that's the fastest for Athlon systems amongst last builds?

@Movax:
Can you please build yours? Would be interesting to compare it with 1009.

movax

10th October 2005, 20:09

Yep, school is letting up, so I'll work on making a MSVC/GCC bin of files for people to mix and combine (and hopefully not crash. :) ).

Revgen

10th October 2005, 21:57

@CelticDruid

The september 20th fixed build has issues when capturing with Huffyuv. The captured video starts to deteriorate into colored blocks right when the capture starts.

Is this being caused by ICL or Milan's new code?

I'll stick with the Sep. 9th build for now.

Egh

11th October 2005, 01:05

Yep, school is letting up, so I'll work on making a MSVC/GCC bin of files for people to mix and combine (and hopefully not crash. :) ).

Please do same build as in \gcc folder in 20051002 archive :) Was it really fully gcc compiled then?

movax

11th October 2005, 03:14

Got a little tired of the source combine, so here's a direct from CVS ffd build, separated again into gcc and msvc folders, plus the distrib folder in case you want to make a exe installer.

ffdshow 2005-10-10 (http://www.filefarmer.com/movax/s/ffdshow20051010.rar)

And yeah, those are all GCC compiled (should be anyways :P), and you can check with the dependency walker: a GCC build will depend on the OS file MSVCRT.dll, whereas a MSVC build will depend on the runtime dll msvcr71.dll.

And if I forgot any files, tell me so I can add them to the rar, please.

*EDIT* After some testing my a friend of mine on an old Win9x system, seems like compiling without "NOINTRIN=1" will break SSE/Win9x boxes.

marcellus

11th October 2005, 09:43

I'd suggest you to try movax 1002 build (the one which is in \gcc folder in .rar archive). Can you confirm that that's the fastest for Athlon systems amongst last builds?

I just tried latest movax's 20051010 (the files in gcc folder). It is faster than 20051006 and 1009, the CPU stays at about 90-95% so I can use it for live recording but it is definitely not faster than celtic_druid's 20050930 compile. And when I exit the VFW config panel it gives this error:
RUNDLL
<<An exception occured while trying to run "ff_vfw.dll,configureVFW">>

bob0r

11th October 2005, 19:59

@Egh

I play [VeryFluffy]_Hellsing_Ultimate_OVA_DVD-trailer_v2_(English_Subs)_[6E888601].mkv
just fine, this the file?

I just install ffdshow, only enabe h.264, x264 and vorbis/ac3/dts/aac , disable post processing and disable volume normalization.

I am also using MPC default settings.

Edit:
I have a NVIDIA GeForce FX 5200.
Also i must say, if i downloaded the correct sample, and this is indeed Nero AVC, its bloody hell ugly and blocky (yes filter disabled)

I set output to VMR9 (in MPC)

I dont use any resize stuff, never used it, never needed it.

Inventive Software

12th October 2005, 16:21

You don't need MSYS. That's a unix emulator. Since ffdshow will be build for Windows, you only need MingW.
Got it, thanks.
Also, not all files will compile with GCC. For example ffdshow.ax won't. So don't use the main Makefile. Just go to the directory of each library and run "Make clean" and then "Make CC=gcc".
OK, thanks for that!
You need to compile ffdshow.ax (and some other files) with Visual Studio 2003.
That's gonna be a bit difficult, bein's I use Windows 98, and will not fork out £100 for Visual C++. Even the VC Toolkit 2003 won't install on Windows 98.

movax

12th October 2005, 17:13

If you run Win98, you can definitely run Win2K. (hardware-wise, at least)

Inventive Software

13th October 2005, 12:21

Yeah, sure. It's just acquiring a legal version of Win2K. Microsoft tend to charge about £50 for a license.

esby

13th October 2005, 14:07

Microsoft tend to charge about £50 for a license.

Well that's ouf of this thread. I bet you are talking of an educational licence, here microsoft licences (oem, not market or enterprise negociated) are available for 150-200 euros, for windows 2000 or windows xp pro. ~~
Now the point is compiling ffdshow, and it can be done by using only gcc, like CelticDruid already did.
Now I don't know if microsoft compiler can give a better performance, that's not my problem,
anyway, buying a new os or buying vstudio to perform only that, while someone can do for you, is a waste of money.

esby

Liisachan

13th October 2005, 15:35

mirrored (http://ffdshow.faireal.net/) celtic_druid's 20051013 build :)

tedgo

13th October 2005, 18:29

Like Selur mentioned some posts before there is still a strange quality issue (i would call it a "ringing impact" and smearing on one-coloured backgrounds) with xvid created with mpeg/cq-matrix with or without qpel in mp4-container when ffdshow's iDCT detection is set to "auto". Choosing any other iDCT-option solves the problem, but shouldn't it be automatically set a proper option with "auto"?

This issue only happens with xvid mpeg/cqm in mp4, not in avi and not with nerodigital mpeg/cqm or divx in mp4. Is it a problem of ffdshow's iDCT detection or xvid? Has ffdshow problems when xvid in mp4 is detected as MP4V? As mentioned before, xvid in avi plays fine with iDCT "auto".

Btw. there are no problems with NeroDecoder, vlc or mplayer instead of ffdshow.

EDIT:
I made some tests tonight. Would anybody make it too to confirm, please?

Try the following:
- Create a xvid.avi with Jawor's 1CD-matrix (the described issues are best visible with).
- mux the xvid.avi into mp4
- set ffdshow's iDCT detection to "auto"
- DISABLE ALL POST-PROCESSING (to avoid errors caused by it)!
- play both files (xvid.avi and xvid.mp4) with your favourite directshow-player
- you'll see what i mean - the xvid.avi plays fine the xvid.mp4 is borked

This issue happens with all mpeg/custom-matrices but is best visible with jawor's 1cd-matrix but only when the xvid-file is muxed in mp4.
Setting ffdshow's iDCT detection to any other than "auto" solves the problem.
With nerovideodecoder, neroshowtime, vlc or mplayer the xvid.mp4-file plays fine.
Files created with nerodigital mpeg/custom-matrices plays also fine with ffdshow, so what's wrong?

bob0r

14th October 2005, 15:37

Compiling ffdshow with gcc 4.0.2
I managed to compile most files:

#compiling ffdshow with gcc 4.0.2
#ffdshow/ffacm/ff_acm.acm
#ffdshow/src/imgFilters/KernelDeint/ ff_kernelDeint.dll
#ffdshow/src/codecs/liba52/ ff_liba52.dll
#ffdshow/src/codecs/libdts/ ff_libdts.dll
#ffdshow/src/codecs/libmad/ ff_libmad.dll
#ffdshow/src/codecs/realaac/ ff_realaac.dll
#ffdshow/src/audioFilters/resample/libsamplerate/ ff_samplerate.dll
#ffdshow/src/codecs/theora/ ff_theora.dll
#ffdshow/src/codecs/tremor/ ff_tremor.dll
#ffdshow/unrar/ ff_unrar.dll
#ffdshow/ffvfw/ ff_vfw.dll, crashing in virtual dub (used msvc 7.1)
#ffdshow/src/codecs/wmv9/ ff_wmv9.dll (used msvc 7.1), compiling fixed with dx9 include/lib
#ffdshow/src/codecs/x264/ ff_x264.dll
#ffdshow/ffavisynth/ ffavisynth.dll
#crashing when playing videos ffdshow/src/ ffdshow.ax (used msvc 7.1), compiling fixed with dx9 include/lib
#ffdshow/ffvdub/src/ ffvdub.vdf
#ffdshow/dscaler/ FLT_ffdshow.dll (used msvc 7.1), compiling fixed with dx9 include/lib
#ffdshow/src/ffmpeg/ libavcodec.dll
#ffdshow/src/codecs/libmpeg2/ libmpeg2_ff.dll
#ffdshow/src/mplayer/ libmplayer.dll
#ffdshow/makeAVIS/ makeAVIS.exe
#ffdshow/src/imgFilters/TomsMoComp/ TomsMoComp_ff.dll
# can't compile (no Makefile): ffdshow/verinc/ verinc.exe (used msvc 7.1)

#compiling fixed with dx9 include/lib = edit ff_wmv9.dll/FLT_ffdshow.dll Makefile, ffdshow.ax makefile.inc and add -I"/dx/Include" -L"/dx/MingLib" -ldx9 to CFLAGS+=
#Based on: http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=6939

Anyway to compile ffdshow.ax and verinc.exe with gcc 4.0.2, or because there are no Makefiles for these, its just not possible?

(post regarding: http://cia.navi.cx/stats/project/ffdshow/.message/6032697 > can be compiled using GCC 4.0.2)