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

iron2000

24th July 2006, 10:37

XXL:
Minimum CPU requirement: MMX
InnoSetup with CPU detection:
MMX, SSE & SSE2.
libavcodec.dll & libmplayer.dll are GCC 4.0.3 (mmx, sse & sse2)
http://rapidshare.de/files/26603725/FFdshow-20060722-rev2546.exe.html
http://ffdshow.faireal.net/mirror/Misc%20(not%20by%20celtic_druid)/FFdshow-20060722-rev2546.exe

I'm using this build now.
I experienced a DirectShow crash while trying to watch a video([gg]_Coyote_Ragtime_Show_03_[A3AEEC9E].mkv).

On using GSpot the crash is credited to libavcodec.
Does it mean the ffdshow is faulty?

thuan

24th July 2006, 12:44

Try clsid build his is the most stable IMHO, no crash here with that file.

Maybe because drevel use ICL (ffdshow.ax compiled by ICL crash with specific x264 encode)

clsid:
Minimum CPU requirement: MMX
Compilers used:
- MSVC71 (ffdshow.ax, etc)
- GCC 3.4.5 (libavcodec.dll, kerneldeint.dll, TomsMoComp_ff.dll)
- GCC 4.0.3 (mplayer.dll)
rev2543:
http://rapidshare.de/files/26625385/...60722.exe.html
rev2546:
http://rapidshare.de/files/26625534/...60722.exe.html

Egh

24th July 2006, 16:30

videomixer9

24th July 2006, 17:25

Bleh, that's handcrafting as milan has quite many changes in the code. Wonder if I'll find time to do that especially considering I never use the resizer and also haruhiko wildly changed stuff :P

haruhiko_yamagata

25th July 2006, 00:20

Wow, it seems that horizontal lines bug was corrected :) Indeed it was vertical mmx scaler :)

New mplayer has slower but moar accurate "-vf scale=...:arnd=1" scaling method. Will it be possible to import it into ffdshow?

Interesting to note that lines were causes by +/- 1 rounding errors :O
Thank you very much, Michael Niedermayer.

The newest patch looks like modifing MMX code of swscaler, but in fact no. I just undid all my MMX modifications and updated to Michael's newest. So it should be easy to import:) .

Chainmax

25th July 2006, 04:51

Since my computer now refuses to run some of the WMVs I have (it only displays pink, green and blue colors), I decided to completely update the codecs in my machine. Could someone summarize for me the different builds available and their strengths?

thuan

25th July 2006, 06:36

ffdshow is the farthest thing from wmv decoding if you don't enable ffdshow wmv decoding (the wmv1/2 decoder have no problem IIRC). Have you updated driver recently, do you use ATI card (the infamous hardware accelerated WMV decoding)? If so maybe it's the problem here (http://www.cccp-project.net/wiki/index.php?title=Issues:WMV_Playback_Problems).
About which ffdshow is best for you, you should test it out for yourself. drevel sum it up pretty well here (http://forum.doom9.org/showthread.php?p=854832#post854832) just missing the newest nosee build from vm9 which is here (http://ffdshow.da.cx/). Personally I use clsid's build it's the most stable IMHO. Also judging from the size of drevel build I think he uses ICL (haven't tried it) because of that it will crash with certain encode with specific x264 revision as someone reported a few posts back.

Chainmax

25th July 2006, 07:01

I did update drivers recently, having upgraded from a Radeon 7200 to a 9600Pro. The suggestion in that CCCP wiki page you linked me to solved tthe issue, so thanks for the heads-up :). What's weird is that the update was a couple of weeks ago and I only started experiencing this problem today.

As for the ffdshow question, I like stability more than anything so I'll go with clsid's compile. Thanks for clearing that up as well http://smilies.vidahost.com/otn/wink/thumb.gif.

_xxl

25th July 2006, 09:34

I'm using this build now.
I experienced a DirectShow crash while trying to watch a video([gg]_Coyote_Ragtime_Show_03_[A3AEEC9E].mkv).

On using GSpot the crash is credited to libavcodec.
Does it mean the ffdshow is faulty?

What version of libavcodec.dll (mmx,sse,sse2),media player, mkv splitter are you using?Haali Media Splitter?

foxyshadis

25th July 2006, 10:41

Okay, I got lavc to update, it wasn't so hard. I just copied the whole i386 folder over, and then the files for all the codecs that I figured I might want - anything related to h26*, xvid, x264, mpeg, svq*, indeo, etc, along with whatever support files I needed. A couple that will cause the build to fail if updated are:
avcodec.h, golomb.c, golomb.h
I'll look into merging them and porting everything over; if successful I'll make a patch. Just copy a few at a time and recompile until the builds fail! Too bad AVC decoding doesn't seem to have any performance increases yet (no multithreading ;_; ).

I won't even try replacing ffdshow's buggy wmv9 with lavc's new vc-1 decoder, though. Someone more versed in ffdshow would have to tackle that.

videomixer9

25th July 2006, 10:57

The revision MBAFF was added there was even a funny remark about regular h264 becoming 1-2% slower due to it.

_xxl

25th July 2006, 11:45

Try clsid build his is the most stable IMHO, no crash here with that file.

Maybe because drevel use ICL (ffdshow.ax compiled by ICL crash with specific x264 encode)

ffdshow.ax is compiled by MSVC2003,
libavcodec.dll & libmplayer.dll are GCC 4.0.3 (mmx,sse,sse2)
and the rest are by ICL9.

foxyshadis

25th July 2006, 13:57

Hey, vm9, I'm curious. In my VC8 builds, it seems lavc is compiled right into ffdshow.ax, I think, whereas in yours and most others it's separate somehow, and almost twice the size when added to ffdshow.ax. (And testing proved it wasn't extraneous.) Is it something to do with using GCC/ICL? Or am I doing something wrong? It seems to work correctly...

videomixer9

25th July 2006, 14:06

libavcodec incl. into the .ax file? heh. I'm pretty sure that wouldn't work as it's loaded by Tdll class. I bet you just mixed up some stuff and have the dll in a directory and can be found. There are no real direct references either in the code so statically linking wouldn't really work either. Other than that you prolly use the Debug Config that outputs larger code :P

foxyshadis

25th July 2006, 14:39

Oh, I see, it was picking up libavcodec in the old ffdshow install folder. Geez, it's not in the path or anything, that's totally unexpected. I guess I was wrong about it then, back to the drawing board. I hate building monstrocities like this. >.>

haruhiko_yamagata

26th July 2006, 00:01

Okay, I got lavc to update, it wasn't so hard. I just copied the whole i386 folder over, and then the files for all the codecs that I figured I might want - anything related to h26*, xvid, x264, mpeg, svq*, indeo, etc, along with whatever support files I needed. A couple that will cause the build to fail if updated are:
avcodec.h, golomb.c, golomb.h
I'll look into merging them and porting everything over; if successful I'll make a patch. Just copy a few at a time and recompile until the builds fail!
Oh yes, it's a good news.
Too bad AVC decoding doesn't seem to have any performance increases yet (no multithreading ;_; ).
I was wrong about it. There's no multithreading. Mplayer have multithreading to play AVC file, but it seems not to be the decoder.

iron2000

28th July 2006, 13:49

What version of libavcodec.dll (mmx,sse,sse2),media player, mkv splitter are you using?Haali Media Splitter?

Here are the details:

libavcodec.dll(mmx,sse,sse2) : 51.9.0
media player : BSplayer 1.37 and MPC 6.4.9.0
mkv splitter : Haali Media Splitter 1.6.162.22

videomixer9

28th July 2006, 17:09

Wow, kurosu even added the new WMV3/VC-1 decoder to his builds, well it's not that great yet and mostly interesting for ffmpeg rather than ffdshow as it is interesting to not depend on the MS dlls on other platforms.

Whatever, sadly kurosu refused to send me any patches to changes he made so I guess I have to wait to get these changes merged into the real one.

In his mail he was rather pissed and I'd recommend not to bother him about anything like that, probably he's kind of annoyed by milans sleepiness :P

akapuma

28th July 2006, 18:04

Audio-normalizing don't works with kurosu's build 20060727-00H07 at my PC. Same problem like 7th July 2006, I posted this here.

Best regards

akapuma

Egh

28th July 2006, 22:52

videomixer9

28th July 2006, 23:43

I'm not really eager to do it and imo that's wasted time currently too as it is slower than the MS codec too. I got like zero WMV3 except for useless trailers. It seems WMV3 is popular with japanese only, some friend has a tons of japanese tv stuff as wmv3 in total oversize. Prolly it's not hard to do, but I don't see a point in it currently.

More interesting would be a some other codecs ... kurosu wouldn't give out the a patch to it after my impression, even though it kind of violates GPL :P

Also since people asked this often enough, here a package of the current sourcetree I'm using incl. the ICL projects etc. here (http://www-users.rwth-aachen.de/Jens.Daumann/ffdshow.7z)

Egh

29th July 2006, 01:14

BTW, what Debanding filter ffdshow uses?

Is that filter available as a standalone avs plugin?

foxyshadis

29th July 2006, 02:18

(the somewhat buggy) gradfun2db.

haruhiko_yamagata

29th July 2006, 06:39

Quality control
(1)Which do you give preference to image quality or frame rate?
(2)Which do you choose droping frame or to losing synchronization of audio and video?

as for (1), it is supported only in H.264. By default, it is set to skip loop filter/deblocking on delay > 350ms. When the video catches up audio, the quality is back. Though the quality drops, I think it's better than no new frame for seconds.
as for (2), on delay > 1500ms, ffdshow give up decoding for a while. If the file is H.264, you may have no new frame for seconds.

Both (1) and (2) have configuration at "decoder options/quality control" in the dialog.
Resize
Update to libswscale rev 19211. It fixed the holizontal line problem. It may be slower and if it is matter for you, uncheck "Resize & aspect/Settings/Accurate rounding".

An old bug fix: While playing resized HD movie, when one try to enter new holizontal size the the application sometimes crashes. I set minimum holizontal size 64 instead of 8 to fix this.
[Patch] (http://sourceforge.net/tracker/index.php?func=detail&aid=1472926&group_id=53761&atid=471491) ffdshow_multithread_060730.patch is PATCH to PATCH.
To rev2546 + ...060517 + ...060601 + ...060604 + ...060625 + ...060709 + ...060721.patch

haruhiko_yamagata

29th July 2006, 08:06

ffdshow-20060730-Q.exe
Needs SSE
http://www.mytempdir.com/833254

libmplayer.dll, libavcodec.dll and libmpeg2.dll are by GCC 4.0.3.
The rest are by MSVC8(VS2005).

applied patches
ffdshow_vorbis6ch.patch
inttypes.diff
ffdshow_accuracy.diff
dts.patch
ffdshow_multithread_060730.patch
TsampleFormat.patch

Liisachan

29th July 2006, 08:30

to save some clicks
ffdshow-20060730-Q.exe (http://space34.at.infoseek.co.jp/ffdshow-20060730-Q.exe)
lazy is beautiful

videomixer9

29th July 2006, 11:29

btw. that patch is bollox, it contains full pathes. Had to fix it up to get it applied.

haruhiko_yamagata

29th July 2006, 12:02

btw. that patch is bollox, it contains full pathes. Had to fix it up to get it applied.
Excuse me. I replaced the patch.

videomixer9

29th July 2006, 12:17

So my version is done too, as always on the website or directly here (http://www-users.rwth-aachen.de/jens.daumann/ffdshow-20060730-rev2546.exe) (hotlinking from random locations allowed). Almost exactly one week after the last one? :P

haruhiko_yamagata

29th July 2006, 14:28

It's just my working copy.
My local SVN rev 33.
size= 13.1MB

applied patches
ffdshow_vorbis6ch.patch
inttypes.diff
ffdshow_accuracy.diff
dts.patch
ffdshow_multithread_060730.patch
TsampleFormat.patch
http://www.mytempdir.com/833815

videomixer9

29th July 2006, 14:51

Btw. does anyone have MBAFF h264 video material, just wanna test if my patching worked?

MatMaul

29th July 2006, 15:01

http://www.giusberto.ch/hdtv/

videomixer9

29th July 2006, 15:09

thx, I could confirm with this that MBAFF works, however Haali TS Splitter may crash on this so when trying use Gabest one or others. I updated my build silently with a new libavcodec that supports MBAFF.

MBAFF patch: here (http://www-users.rwth-aachen.de/Jens.Daumann/ffdshow_mbaff.patch)
all patches used: here (http://www-users.rwth-aachen.de/Jens.Daumann/ffdshow_patches.7z)

I also tried adding VC-1 support as inserting other codecs shouldn't be hard but the vc-1 files threw an error like these:
libavcodec/vc1acdata.h:7: error: expected '=', ',', ';', 'asm' or '__attribute_' before 'vc1_ac_tables'
libavcodec/vc1acdata.h:233: error: expected '=', ',', ';', 'asm' or '__attribut__' before 'vc1_index_decode_table'
libavcodec/vc1acdata.h:402: error: expected '=', ',', ';', 'asm' or '__attribut__' before 'vc1_delta_level_table'

but to me the tables looked fine so I'm stuck.

Egh

29th July 2006, 23:49

foxyshadis

30th July 2006, 00:27

vm9, ICL has issues with uint8_t (and 16/32), it isn't defined by default so it thinks that's the symbol you're trying to define. Including common.h should fix it but apparently doesn't in this case, maybe you could include <inttypes.h> at the top of the header.

I understand why lavc was so rarely updated after spending the last week on it, it's a real pain to keep it gcc & mcvc compatible, especially when common headers are shuffled significantly, and if you don't have something encoded by each codec to test against.

conando

30th July 2006, 13:10

@videomixer.. thx so much for the regular builds and all the work.. but: makeavis.exe seems to be broken in your builds.. crashes immediately...

LoRd_MuldeR

30th July 2006, 16:41

@videomixer.. thx so much for the regular builds and all the work.. but: makeavis.exe seems to be broken in your builds.. crashes immediately...

I can reproduce this error:

http://img153.imageshack.us/img153/1948/makeavisyc8.th.gif (http://img153.imageshack.us/my.php?image=makeavisyc8.gif)

And yes, I have installed the vcredist_x86.exe :D

foxyshadis

31st July 2006, 06:53

Question for you guys as I'm finishing up the lavc reimport patch: To include various random formats use in video game movies, or no? This includes: mdec, mmvideo, roqvideo, rpza, vqavideo, xan, xl, along with other random stuff like 4xm and rtjpeg. None of them are remotely difficult to port, but nor is there a very compelling reason to keep them. (Most are in proprietary containers that only lavf can read anyway.)

Man, I wish I hadn't wasted time on chasing down one nasty h264 bug caused by not commenting one merged line out. ^^;; Ah well.

After this I'll fixup ffdshow to use the new vc-1 and avs decoders, and release a patch for that separately.

This reminds me of something else, later down the line I'll see if I can get msvc to cleanly link with gcc object files, so gcc can do the at&t asm while either of the others does the former, as an attemp to obtain maximum optimization. (I can dream, non?) It'll probably just take some reconfiguring of the projects.

conando

31st July 2006, 07:19

btw how is it currently compiled to get "best" performance? i just started looking into the ffdshow sources and yesterday did my first build to do the vfw preset fix thing... at the moment i'm building everything using vc2003... on playback with some filter if gut 34% cpu usage whereas a build by videomixer9 shows 6% :D .. after compiling libavcodec, libmplayer etc. with mingw i'm down to 12%.. fine but still double of what the other builds use.. i looked at the build options but seem to miss the magic speedup setting or something :(

conando

31st July 2006, 08:43

ok forget it.. silly me used different filter settings/presets ;) the difference is just 1-2% and i can live with that right now... but seems there's a better way to build libavcodec, libmplayer than just using mingw with the supplied makefiles.. guess i've got to tune that.. didn't find the msvc solution/project file anywhere thats mentioned in the docs that should use an icl/gcc combination for libavcodec..

haruhiko_yamagata

31st July 2006, 09:42

haruhiko_yamagata

31st July 2006, 09:46

// EDIT after writing this I saw your second post...

Egh

1st August 2006, 12:03

@ haruhiko_yamagata:

I've noticed a interesting thing in the newest builds on this system. It's always reproducible here.

If "queue samples" is on, then if I pause a video, I see a black screen (instead of a still frame). If I switch off queuing, then all is as it should be. So, the question is: is it bug or feature? :)

It happens even if ffdshow is only used as a passthru, not doing any actual decoding (like receiving data from WMV decoder DMO)

Liisachan

1st August 2006, 12:46

I think you are talking about this (http://forum.doom9.org/showthread.php?p=837296#post837296)?

If "Queue output samples" is unchecked, you'll get a static picture (video frame) when you pause the video (which is normal).

If "Queue output samples" is ticked, you'll get nothing (blackness) when the video is paused, which is not too nice. If so, you can read the following discussion first, to make the report more specific.

Egh

1st August 2006, 12:56

I think you are talking about this (http://forum.doom9.org/showthread.php?p=837296#post837296)?

If so, you can read the following discussion first, to make the report more specific.

Well I recall there was such problem reported earlier, and I thought it was fixed and this bug is actually a regression.

Maybe then it wasn't fixed at all :)

Sometimes you can actually see all is paused OK, still frame is shown and after that frame becomes blank :)

videomixer9

3rd August 2006, 12:00

I got a fork project on SourceForge approved and already added some of the people here for access to it and SVN repository to commit changes. I think this is a good base for all the changes proposed by various people and I can add more developers flexibly without making any harm to the original project and everyone can check out things incl. the patches. Also people can upload their builds there which could end all this hosting on dozens of freehosters that are full of ads and waiting delays.

Also the development on the patches by many people might be more transparent and you can easily created patches via the webinterface to propose them as changes to the original ffdshow.

Project:
https://sourceforge.net/projects/ffdshow-tryout/

if someone wants access to commit changes on svn just ask me or the other admins I just added without telling them ;P

MatMaul

3rd August 2006, 12:43

Thanks videomixer9 !

I don't know if it is possible, but I think a good improvement is to update ffdshow to can use directly the dlls produced by the ffmpeg project.

videomixer9

3rd August 2006, 12:54

I think that is just a thing of modifying the entry points in the dlls from ffmpeg. I wondered about this for a while, maybe it's time again to seriously try it. Question is if that really works so easily as the question is which additional parts of the 3 dlls ffdshow really needs. But the original reason for stripping down was probably cause the original dlls are significantly larger than the ffdshow version.

As said everyone with some sense is welcome to participate in the fork.

MatMaul

3rd August 2006, 13:17

at this time, I have still some problems to compile the ffmpeg dlls.
this dlls do not compile with a "configure make", some hacks are needed.
I think the size of the dll is not a problem : users generally download codecs packs and the size of codecs packs generally exceeds 20 or 30 mo...

EDIT : I can now compile ffmpeg dlls !

Tuto to build ffmpeg dlls :

read this tuto (particulary the parts "Fixing "msys.bat"" and "Building FFmpeg SVN dlls" if you have mingw installed) : http://ml20rc.msnfanatic.com/ffmpeg/msysguide.html

use gcc 3.4.5, gcc 4.0.3 doesn't work

./configure --enable-memalign-hack --enable-shared --disable-static

then open the file config.mak, and add "-Wl,-rpath-link,$(BUILD_ROOT)/libavutil -Wl,--output-def,$(@:.dll=.def)" at the end of the LDFLAGS line.

then make