New ffdshow build (?)

[DeathTheSheep]

Ah, yes, this one works like a charm!
Thank ye kindly!

[bob0r]

msvc 7.1:
http://files.x264.nl/ffdshow/ffdshow-20051124-msvc7.1-x264.nl.exe
msvc8.0
http://files.x264.nl/ffdshow/ffdshow-20051124-msvc8.0-x264.nl.exe
icl 9.0 (libavcodec.dll from Milan's ffdshow-20051124.exe build, assuming icl 8):
http://files.x264.nl/ffdshow/ffdshow-20051124-icl9.0-x264.nl.exe

For testing one more time, and none-SSE i guess :sly:

[DeathTheSheep]

MPEG4 quantizer noise shaping is broken...
And many codecs only encode at 25fps...

[bob0r]

MPEG4 quantizer noise shaping is broken...
And many codecs only encode at 25fps...

Give more details, and please report to http://sourceforge.net/tracker/?group_id=53761&atid=471489

(More info like, where to find MPEG4 quantizer noise shaping in the settings, as i have no clue)

[DeathTheSheep]

lol, sorry 'bout that :)

Actually, I submitted that post at exactly the same time you submitted the other builds, and it works with icl9.

It's in the VFW settings. Here's a screenshot:
http://www.myfilehut.com/userfiles/5120/ffdshow.PNG

However, the ICL9 is 2 times slower than the gcc4.0.2 build on my Intel Celeron D 2.93ghz (I just ran an ASP decoding test with mplayer deblocking).

So, the icl9 version's noise shaping works, but ffdshow in general is much, much slower for me.

Thanks 4 all the builds!

[bob0r]

@DeathTheSheep

How is it not working?

I tried 300 frames encoding with those settings, and its working, encode and decode.

[DeathTheSheep]

Oh? It consistently crashed VirtualDub with the GCC4.0.2 build, but it works fine with the ICL9.0 build (EDIT: and the msvc71 build is fine, too, but the slowest of the three)...? I'll try a reinstall.

By the way, I downloaded msvcr80.dll into my system and system32 and ffdshow directory, but the new msvc8 build gives this error message upon installation:
http://www.myfilehut.com/userfiles/5120/msvc8.PNG
Even when the system is restarted, and the old ffdshow is uninstalled, the message persists. Is there just something wrong with my computer?
Thanks for all the help :)

EDIT: Reinstall produces both of the same errors. Screenshot of failed Quantizer Noise shaping can be found here (http://www.myfilehut.com/userfiles/5120/gcc402.PNG)

[Chainmax]

What's the status on Vorbis decoding? Is libavcodec still a better alternative than tremor?

[Egh]

What's the status on Vorbis decoding? Is libavcodec still a better alternative than tremor?

i don't think there were any updates to tremor in last months...

As for decoding vorbis, I prefer libavcodec for quite some time. Don't even use CoreVorbis and similar stuff.

[Rash]

Just a question. Celtic Druid is making "yes-SSE" compilers, right? :)

I seriously feel a difference on perfomance with and without SSE, and I don't have one tiny little problem with stabilty.

Oh, OK, just one more question. :) Are the CPU flags shown on "Info & Debug" displayed correctly? Somehow I think they are always checked, all of them, but they are not exactly in use.

[celtic_druid]

I compiled termor with low accuracy mode disabled. Link is a few pages back I think.

[issa]

Here is the CVS build of gcc 4.0.2, these should work on all CPU unless
milan's use SSE/SSE2 without checking CPU flags.

http://rapidshare.de/files/8121185/ffdshow-20051125-gcc.exe.html

[videomixer9]

Oh? It consistently crashed VirtualDub with the GCC4.0.2 build, but it works fine with the ICL9.0 build (EDIT: and the msvc71 build is fine, too, but the slowest of the three)...? I'll try a reinstall.

By the way, I downloaded msvcr80.dll into my system and system32 and ffdshow directory, but the new msvc8 build gives this error message upon installation:
http://www.myfilehut.com/userfiles/5120/msvc8.PNG
Even when the system is restarted, and the old ffdshow is uninstalled, the message persists. Is there just something wrong with my computer?
Thanks for all the help :)

EDIT: Reinstall produces both of the same errors. Screenshot of failed Quantizer Noise shaping can be found here (http://www.myfilehut.com/userfiles/5120/gcc402.PNG)

You're not working as admin as it's supposed to be? non-admins cannot register filters without special rights, thus it throws an error. I'm not working as admin either and just use the "run as" feature with the installer as I do with almost any installer for anything, as my own account I work with has like no writing rights except for my personal folder and my data disk. Cannot explain this in many other ways if the installer works for anybody else.

Would be rare though that the person without admin rights to not know it and if it works with any other build it's prolly a loading error.

[yaz]

just found
Daily builds

ffdshow-20051124.exe

wait untill tray icon thread is created
don't rebase some libraries,
re-added resources to ffvdub in gcc build
fixed green artifacts when using chrominance smoother
correct guid for IID_IQualityControl - fixes tmpgenc video
change base addresses of dynamic libraries after building them
correct timestamps with haali/theora/libavcodec combination
remove languages dir on uninstall
don't use __int64 type in csimd.h
option to connect to any filter but allow output format changes only on supported ones - a new default
fast SPP deblocking
dynamically link avisynth.dll from ffavisynth
finally (?) fixed DCT filter
ffavisynth compileable with GCC - ffdshow avisynth filter uses now avisynth C interface, you have to load it using LoadCPlugin
fixed querying for ansi interfaces in unicode build (and vice-versa)



it may (re)solve some problems listed above

the bests
y

[yester]

tested the k6 build on an k6-2+ 500 & windows98se ... won't even install, crash in selection menu. latest milan builds work on k6... (except the cpuload, which goes wrong on second started media to constant 100%)

awarpsharp is provided through a closed-source, binary-only file. It is incompatible with gcc. Ask milan so that he himself goes bugging the awarpsharp original author.


I guess you compiled ffdshow.ax with MSVC then.
gcc can't properly handle milan's code: if -msse is present, some math intrinsics / floating-point conversion will be used. Playing with -mfpmath only disables the former intrinsics. If -msse is removed, all SSE intrinsics are disabled, and the current code doesn't support this.
Same for a -msse2 build on an Athlon XP: it'll crash because of illegal instruction.
Such problem doesn't exist when compiling ffdshow.ax with MSVC.

Here are my attempts (with some heavy modifications to source) to compile SSE-less binaries with gcc:
Pentium II (http://kurosu.free.fr/ffdshow-20051122-21H55-p2.exe)
K6-III (http://kurosu.free.fr/ffdshow-20051122-21H55-k6-3.exe)
I hardly expect them to run OK on those CPUs, and most probably not on other CPUs.

btw, those builds don't need to (nor should they) be mirrored. They are not made for distribution, at all.

[LigH]

There is a new build from Milan online now too.For testing one more time, and none-SSE i guess :sly:
:o Yes, you are right... For your efforts, many :thanks:
__

BTW: Although you disabled it, there is still a text readable "low accuracy mode enabled for tremor" (both in milan's build, and bob0r's ICL9). Probably only a non-changed label.

[issa]

Latest CVS build on 11-26-2005.

SSE2 build (using SSE2 for FP operation instead of x87):
GCC :- http://rapidshare.de/files/8167977/ffdshow-20051126-gcc-sse2.exe.html
MSVC :- http://rapidshare.de/files/8168051/ffdshow-20051126-msvc-sse2.exe.html

x87 build (it should work on all CPU >= i586):
GCC :- http://rapidshare.de/files/8167763/ffdshow-20051126-gcc-x87.exe.html MSVC :- http://rapidshare.de/files/8167872/ffdshow-20051126-msvc-x87.exe.html

Please let me know for the build working or not.
Notice: I had updated the SSE2 build since anonymous cvs got update today for 20051124 build.

[MacAddict]

@issa
The GCC SSE2 build is running _very_ smooth here for me. In fact, almost seems to use a few percent less CPU than previous SSE2 builds. Maybe it's just me though :-) Many thanks for the efforts!

[Chainmax]

i don't think there were any updates to tremor in last months...

As for decoding vorbis, I prefer libavcodec for quite some time. Don't even use CoreVorbis and similar stuff.

I wonder why if Vorbis decoding is enabled then tremor is selected by default...

[falcon2000eg]

You're not working as admin as it's supposed to be? non-admins cannot register filters without special rights, thus it throws an error. I'm not working as admin either and just use the "run as" feature with the installer as I do with almost any installer for anything, as my own account I work with has like no writing rights except for my personal folder and my data disk. Cannot explain this in many other ways if the installer works for anybody else.

Would be rare though that the person without admin rights to not know it and if it works with any other build it's prolly a loading error.
I have the same problem and im the admin ,with msvc8 builds only gcc builds are fine.

[ptiJean]

Hello all,

I have a problem on my PCHC : tried several (about 10 !) versions of ffdshow, using it with ZoomPlayer 4.5 registered and overlay (for my DVD).

I want to force ffdshow output in RGB32 with high quality conversion YV12 -> RGB, but ZP claims that it is impossible to connect pins from ffdshow out to overlay in.

Am I missing something ?
Can you help me ?
Thank you.

PS: ZP 4.5 + AMD 64 3000+, ffdshow overlay RGB32 output, NVidia pure video mpeg2 decoders YV12, I wish ffdshow and overlay could connect :thanks:

[Leak]

Am I missing something ?
Yep. Hardware video overlay on graphics cards is YUY2/YV12 only - it just doesn't support RGB.

np: The Dolls - Motor City (The Dolls)

[ptiJean]

At home I Have 2 PCs with NVidia cards (5600 & 6200) : impossible to connect ffdshow RGB32 to overlay renderer.

But at work, I have one PC with ATI 9600 card, and the connection is possible !

So ?

[thuan]

If you select the output colorspace in ffdshow is RGB32 then the com won't need OverlayMixer I think (because it has been rendered direct to your destop colorspace and I can't find the OverlayMixer filter in the filter chain). On my com(GF4MX) it's work fine with MPC with OverlayMixer selected and in Zoom4.51 is the same with a weird prob (ffdshow output vid in "RGB32,modified" don't know what that's is and the vid looks bad with severe staircase for a few secs, after that ffdshow output in normal RGB32 and the vid plays fine then anyone have the same prob?)

[videomixer9]

Why convert to RGB32 in software anyways with overlay mixing, just to waste CPU cycles on things while your graphics adapter can do everything in hardware for you?

ps: just to remind you, overlay mixer does a conversion to RGB for output on screen within your graphics hardware. If you want to emulate the high quality conversion from ffdshow with this, convert the picture to YUY2 before, that's how ffdshow does it with HQ conversion ... YV12 -> YUY2 -> RGB32 while graphics hardware does a direct YV12 -> RGB which seems to be bad for some cards, however some expect YV12 or YUY2 as input as internal conversion seems to fail if the source is already RGB, driver bug or so most probably.

ffdshow often comes out using less cpu for pure decoding work as many other codecs, this is most prolly often the case because most other decoders do not output n YV12 and convert to YUY2 before. I think both DivX and Xvid do so per default.

[issa]

I try to fixed the problem of msvc build, please try this build and let me know if it work or not.

SSE2 build:
http://rapidshare.de/files/8224664/ffdshow-20051127-msvc-sse2-try4.exe.html

Note: Just try another method, and download link update.

[DeathTheSheep]

lol, sorry 'bout that :)

Actually, I submitted that post at exactly the same time you submitted the other builds, and it works with icl9.

It's in the VFW settings. Here's a screenshot:
http://www.myfilehut.com/userfiles/5120/ffdshow.PNG

However, the ICL9 is 2 times slower than the gcc4.0.2 build on my Intel Celeron D 2.93ghz (I just ran an ASP decoding test with mplayer deblocking).

So, the icl9 version's noise shaping works, but ffdshow in general is much, much slower for me.

Thanks 4 all the builds!
This problem persists with the above 11/26 gcc4.0.2 sse2 build. Make sure to input a "1" in the lowest box ("Quantizer Noise Shaping"). It consistently crashes with the [faster] gcc build but works fine with the [slower] icl9 build. Additionally, the latest above msvc build fails at the same place I described above: "Error while registering ffdshow.ax". I have administrative privilages.

Here are my ffdshow registry settings (Dumped directly by ffdshow): ffdshow_reg.7z (http://www.myfilehut.com/userfiles/5120/CollectedBuilds/ffdshow_reg.7z)

Has anyone been able to reproduce either of these problems? Thanks, y'all.

[NoX1911]

@Thuan: I think i have the same behaviour when using 'Standard Renderer'. Are you not using WinXP (Win2k/9x use 'standard renderer')? There's already a thread at SourceForge: https://sourceforge.net/tracker/index.php?func=detail&aid=1360669&group_id=53761&atid=471489

Regarding software YUV->RGB usage.. Isn't it a must-have if you want to use VMR9 since there is no luminance correction (yuv->rgb) due to missing overlay mixer? At least i didn't manage to get rid of the luminance problem without converting to RGB with ffdshow... hardware overlay doesn't work with VMR9 renderless anymore. It's rendered as texture instead of overlay.

[thuan]

Well, I use XPSP2 and that prob only happen with Zoom not MPC so I think it's not ffdshow fault maybe Zoom.
About VMR9Renderless with MPC I think I have the same color result with YUV2 and RGB32 but RGB32 is certainly slower.

[zilexa]

Why does the "Downloads" page of the official ffdshow site (http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php) only shows ffdshow builds up to 2004, while the "Daily Builds" page and the "getting FFdshow" link on the homepage show all the builds after 2004? (http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=Getting+ffdshow)

Nobody uses the 2004 build anymore.. on the site the daily builds are even promoted as "Getting FFDshow".
An update to this part of the site, with the latest most stable build would be nice!

[Elic]

zilexa
> Nobody uses the 2004 build anymore..
Hmm, I use ffdshow-20041012 only - the last one from sourceforge and IMHO the most stable and bug-free version. Sporadically, I download and try some new version from aziendeassociates, or from freecodec, or so; but they are almost always so buggy and unstable so I return back to 2004 build :(

> with the latest most stable build would be nice!
Sincerely second. :)

[ptiJean]

Can u tell us where to find it ? (20041012)
Thanks.

[marcellus]

FFDShow is permanently developed and improved by milan. In the the mean time the same thing is happening to libavcodec and mplayer, on which ffdshow is partly based. Using ancient versions is not the way to go, IMHO. The way to go is to report issues to milan so he can find sollutions.

[Egh]

zilexa
> Nobody uses the 2004 build anymore..
Hmm, I use ffdshow-20041012 only - the last one from sourceforge and IMHO the most stable and bug-free version. Sporadically, I download and try some new version from aziendeassociates, or from freecodec, or so; but they are almost always so buggy and unstable so I return back to 2004 build :(

> with the latest most stable build would be nice!
Sincerely second. :)

It might be *very* stable... But how do you play AVC streams then? :P

Iirc such things for avc like 8x8dct and qp=0 are supported only from late june 2005 builds. Moreover, it still contain nasty crash bug for high-profile avc streams, and if one parameter was present in stream, that could easily crash ffdshow. That bug was corrected only in middle august 2005 builds :)

So while 2004 old ffdshow might be stable, it lacks some important features as well.

And i think most last builds are actually pretty stable anyway :P

[celtic_druid]

Also if I recall correctly there was a bug with the installer for ffdshow-20041012. If installed on an NT based windows it doesn't correctly install VfW. So no VfW decoding/encoding. Easy to fix by changing program files to progra~1 in ffdshow's vidc entry. But hardly what I would call bug free.

[DeathTheSheep]

Has anyone else noticed that sse2 GCC-compiled builds are a lot faster than ICL9 builds, even on Intel processors?

decoding speed on XviD w/mplayer accurate PP on a Pentium 4 2.4ghz
ICL9: 41fps
MSVC: 69fps
GCC: 76fps

[ExtraEye]

when i use video renderer 9 + output to RGB32 i have a problem with mkvs and ogms with soft subtitles.
the subtitles aren't displayed correctly and are transparent to the video in a way... (unreadable).

to fix the problem i enable colorspace yv12.

is this only me or it's supposed to be like this?

[Egh]

when i use video renderer 9 + output to RGB32 i have a problem with mkvs and ogms with soft subtitles.
the subtitles aren't displayed correctly and are transparent to the video in a way... (unreadable).

to fix the problem i enable colorspace yv12.

is this only me or it's supposed to be like this?

depends on how you define "not displayed correctly". Haven't noticed such behaviour though on ffdshow.

[issa]

Has anyone else noticed that sse2 GCC-compiled builds are a lot faster than ICL9 builds, even on Intel processors?

decoding speed on XviD w/mplayer accurate PP on a Pentium 4 2.4ghz
ICL9: 41fps
MSVC: 69fps
GCC: 76fps

Which version of MSVC build that you are using for comparison?

[DeathTheSheep]

Which version of MSVC build that you are using for comparison?
This one. ;) (http://forum.doom9.org/showthread.php?p=742955#post742955)

[ExtraEye]

depends on how you define "not displayed correctly". Haven't noticed such behaviour though on ffdshow.

like i said, trasparent or black - unreadable.
you do see there are subtitles, but there's no way to actually read them.

[videomixer9]

depends on how you define "not displayed correctly". Haven't noticed such behaviour though on ffdshow.

Yeah I know this problem and it's yet another reason for me not to use VMR9. You can see the border of the subs but the subs, especially with styled subs quite funny are see-through ones. They flicker a bit and keep one picture transparent and the video in the back doesn't fit anymore. Though I think that's something broken in vsfilter.

FFDShows internal softsub filter is the same crap as mplayer/VLC sub renderers. They just stink with styled subs (though they stink all the other time too as shadow etc. all just are looking fucking ugly) which are mosten used in anime only though.

Of course all of the arrogant rest of ppl there wouldn't bother cause they prolly watch movies dubbed to their language or are fanatics of non-styled subs as they have a hard time already reading a single line without any styles. :)

[ExtraEye]

Yeah I know this problem and it's yet another reason for me not to use VMR9. You can see the border of the subs but the subs, especially with styled subs quite funny are see-through ones. They flicker a bit and keep one picture transparent and the video in the back doesn't fit anymore. Though I think that's something broken in vsfilter.

FFDShows internal softsub filter is the same crap as mplayer/VLC sub renderers. They just stink with styled subs (though they stink all the other time too as shadow etc. all just are looking fucking ugly) which are mosten used in anime only though.

Of course all of the arrogant rest of ppl there wouldn't bother cause they prolly watch movies dubbed to their language or are fanatics of non-styled subs as they have a hard time already reading a single line without any styles. :)


so... no way to fix this?

p.s - why call yourself VMR9 if you don't use it? lol.

[darkavatar1470]

hmm, I think I read about that bug on Doom9 sometime ago.... probably in the container section if it's MKV/OGM specific.

[Egh]

Yeah I know this problem and it's yet another reason for me not to use VMR9.

I don't use anything but VMR9 for subs. But I use mpc internal renderer and comparing VSFilter with MPC... Well MPC is far better (though more CPU % as well).

And subs renderer in ffdshow could be better, for sure.

P.S. btw i noticed two corrections for subtitles in ffdshow's log today. But with no messages given hard to tell what exactly was br0ken/fixed :P

[_xxl]

Has anyone else noticed that sse2 GCC-compiled builds are a lot faster than ICL9 builds, even on Intel processors?

decoding speed on XviD w/mplayer accurate PP on a Pentium 4 2.4ghz
ICL9: 41fps
MSVC: 69fps
GCC: 76fps
Sender: nobody
Libmplayer.dll and libavcodec.dll compiled with ICL9 are
wrong?

Sender: milan_cutka
Yes. Both libraries were developed primarly for Linux
projetcs (ffmpeg and mplayer) and to be compiled using GCC.
Hand-optimized SIMD code is written using GCC inline
assembly syntax which isn't supported by ICL9 (on Windows)
nor Microsoft C++ Compiler. To make those libraries compile
with these compilers it's required to disable functions
written in inline assembly. Only libavcodec.dll and
libmplayer.dll built using GCC can benefit from hand-
optimized MMX, SSE and SSE2 code in these libraries.
Only libmplayer compiled with GCC features SIMD optimized
versions of its functions. Otherwise only C versions will
be used resulting in lower performance and, as in this case
shows, limited functionality.
In blockCopy function in postprocess_template.c only SIMD
versions perform lumince levels fixing, C version does
simple copy only.

[Egh]

Only libmplayer compiled with GCC features SIMD optimized
versions of its functions. Otherwise only C versions will
be used resulting in lower performance and, as in this case
shows, limited functionality.


Yes, and that was the reason why one of the celtics' build in
September was slow in some modes. It was due to libmplayer
compiled with ICL, not gcc.

And since that code is hand-written... I afraid it's not properly
optimized for SSE1-only cpus, btw. So SSE2 is a must if you want
some exceptional speed :)

[videomixer9]

so... no way to fix this?


Only if you use MPCs inbuilt subtitle renderer, that one shouldn't be affected by this, if it's too then there's no fix except for fixing vsfilter :/

[_xxl]

ICL Linux is supported?
Which files can be compiled with ICL (on Windows)?
http://cutka.szm.sk/files/ffdshow-20051124.exe
ICL8 + GCC?
Sender: milan_cutka
I haven't tested ICL on Linux and I don't think it can
be used as cross-compiler anyaway. But if it can, it'd be
worth of trying.
With ICL9 you can compile all files which are in projects
included in ffdshow workspace. Additionally libavcodec can
be compiled using ICL and GCC: ICL to compile file
containing C code only and GCC to compile rest.
All files in my builds are compiled using ICL 8.1 except for
libavcodec.dll and libmplayer.dll which are compiled with
GCC 3.4.4.

[_xxl]

tested with:1280 x 720 .mp4
ffdshow-20051129 + nero h.264 parser
ffdshow h.264 decoder 100% cpu,no postprocessing
http://www.moviemaze.de/media/trailer/delivery/66344456615ca7c620887f52fae9156c9bb341959b/king_kong-alookinside_h720p.mov
Win XP Sp2,Amd XP 1600+ 512MB ddram.