ffdshow development

[athos]

New build. Mostly default compiler flags (ICL+VC+GCC).
Modifications:
- Andy2222's OM fix
- Install path fix
- Skal's MPEG4 codec

[skynetman]

Thx Athos, can u build an P4/Athlon XP optimized version? Your old compile seemed to me much more smooth than 20040501 and i'd like to try this new one with compiler optimization on and off.
THX

P.S.: Still problems when updating an old install of ffdshow. ffdshow.ax can't be replaced by installer, and i have to rename it via explorer then launch setup again

[athos]

Originally posted by skynetman
Thx Athos, can u build an P4/Athlon XP optimized version? Your old compile seemed to me much more smooth than 20040501 and i'd like to try this new one with compiler optimization on and off.
THX
OK, P3 optimized build is up, which should work fine for AthlonXP too. If I targetted P4 it might not work on AthlonXP, since it lacks SSE2 support (introduced in Athlon64).
GCC: -march=pentium3
ICL: /G6 (Pentium Pro, Pentium II, and Pentium III) /QxK (use Pentium3 features)
I also modified install script to delete a forgotten language file.
Direct link: http://athos.leffe.dnsalias.com/ffdshow-20040508-p3.exe

Originally posted by skynetman
P.S.: Still problems when updating an old install of ffdshow. ffdshow.ax can't be replaced by installer, and i have to rename it via explorer then launch setup again
This probably has something to do with Explorer not releasing the direct show filter. Perhaps this is connected to the .avi 100% cpu problem? Check out http://www.tweakxp.com/display.aspx?id=841

[bond]

is it possible to set the idct to xvid by default in ffdshow?

basically none of the popular codecs uses simple idct: xvid, divx5, 3ivx and nerodigital all use the idct which is called "xvid" in ffdshow!

[Jaffy]

Recent few builds of ffdshow no longer decode 120 fps avi correctly. i.e. avi with 30 and 24 fps mix.


Jaffy

[bond]

Originally posted by Jaffy
Recent few builds of ffdshow no longer decode 120 fps avi correctly. i.e. avi with 30 and 24 fps mix.try remuxing them to a variable framerate .mp4 file with the 3ivx or mp4box muxer ;)

[Jaffy]

try remuxing them to a variable framerate .mp4 file with the 3ivx or mp4box muxer

The xvid avi's already burnt to CDR's so... not really what I need.

Just curious though, how does remuxing a 120 fps avi to .mp4 help?

Anyways, last post was just to show that something broke in recent builds.

Both older ffdshow, xvid and divx play these 120 fps files fine.


Jaffy

[bond]

Originally posted by Jaffy
Just curious though, how does remuxing a 120 fps avi to .mp4 help?it will heavily bring down the framerate

[Alxemi]

is it possible to set the idct to xvid by default in ffdshow?

I totally agree with you.
I use to keep ffdshow with my encodes and always have to advice my friends "go to miscellaneous etc etc"

btw the problems with XviD RC are already fixed aren´t they? :confused: (The thread is so HUGE and i´ve been out there the last two months)

[pankov]

Originally posted by debennett2
Is it possible through ANY 3rd party app to load and unload ffdshow presets? That's really the only thing keeping a lot of HTPCers from using it in a regular basis for everything. It's really a pain to load a preset via mouse just to watch dvd and then unload it to watch PVR livetv in 4:3. Any change of this changing in the near future? Maybe there is a workaround that I can do? Thanks!

Edit: and to make sure I don't get flamed, I want to do this manually (i.e. via commandline or something similar) so I have total control via external HTPC and remote apps.

Milan was working on a "remote control API" which will enable external application to control FFDShow.
2003-05-07 13:19 milan_cutka

* first version of remote control API

But I never found how to use it :(.

Recently he disabled it by default and added a GUI to enable it but I can't find it.
2004-03-08 15:24 milan_cutka

* remote control API disabled by default + GUI control to enable it


May be some of the main developpers can help us find it and probably explain us how to use it in general?

[pankov]

I think that the "Preset Autoloading" is a very usefull thing but I'm not sure that I know how exactly it works.

Can someone explain it to me or point me to the exact place in the source where I can find the priority of the conditions.

In particular I'm interested in the following options
1. "on movie file extension match"
2. "on application exe file name match"

Which one have the priority?
What happens if I have defined two presets for the same extension but for different applicatoins? Which one will get loaded?
Is it possible to dedicate 2 presets for the same application and have one handling .mpg files and the other - broadcasted live streams (without extension)?

Is it possible somehow to use this function to get two different presets loaded depending on the display that the movie is started?
In my case I use ZoomPlayer and I want to scale the picture to different resolution depending on the device that is used for playback (monitor, TV, projector). It's not possible to do simply change the preset afterwards because ZP doesn't react to this resize. I only eiter lose part of the picture (if I increase with resize) or I get black borders (if I decrease with resize) after ZP has already started the playback
:(

[davidh44]

Athos - Any chance of a P4 optimized build?

[dapipa]

i think i found a bug in ffdshow(libavcodec,latest athos'build,but the same goes for build from 20030523),don't know,whether it's already been reported,or there's some solution for it,because finding something in this thread is a real pain(it's HUGE :) ),so,here it is:

in 1 of my latest XviD(RC4)encodes i've noticed red/green trails(blocks)following moving objects,changing IDCT didn't help,but i didn't try to change any other settings,because the only ffdshow's filter i'm using is resizer(set to none,just to crop the picture(720 x ? > 640 x 480)),everything else is turned off...source & XviD decoder doesn't have/show this artefact...i can post some pictures,if it's of any use...

p.s.another bug(?):when setting font color for subtitles to RGB:FFFF00(yellow),there are blue(purple)blocks in the picture,but adding just 'a few drops' of blue color(FFFF11)solves the problem...

p.p.s.sorry,if it's old & long known stuff...

[Beatles]

This may be pushing things to ask but a lot of us would LOVE an AMD64 optimized build.

[Andy2222]

Originally posted by davidh44
Athos - Any chance of a P4 optimized build?

Originally posted by Beatles
This may be pushing things to ask but a lot of us would LOVE an AMD64 optimized build.


A AMD64 (hard to build) or a "special P4" version wont run faster than a normal P3 or "Blend" build.

Why? Since the compiler dont magicaly rewrite the main routines, this can only be done by a programmer by hand. Since the reziser and many other routines are already hand optimized the compiler dont change anything at all. So the only instructions the compiler pseudo optimize if u set the P4 switch are some instructions wich take less than 1-2% overall CPU power. In result this means that a special build dont run any faster at all.

The only other thing besides hand coding is to "try" the diff. compilers on the market Intel6/7/8, Visual Studio 6/7/8, DevPartner Studio, GNU GCC 3.2.3/3.3/3.4.... wich takes time and nearly all products are commercial. Problem is some code run faster with Intel compiler and some with VS or GCC... u can only try and test it...

So there is no need to build a P4 or AMD64 version. The only way to get more speed is by hand optimizing the code for AMD64 or write some SSE2 routines.

Just compare the normal version against the P3 version, the speed gain should be max. 1-2% on a P3/AMD.

Here is a short list of filters wich are already hand optimized for mmx/2 or sse/2 wich wont effected by any compiler switch at all:

- all internal color conversion's
- nic's + mplayer post processor
- asharp, msharp filter
- all rezise filter
- huge parts of libavcodec decoder
- idct
- gradual denoise, mplayer denoise
- mplayer noise
- luma, chroma process
- some of the deinterlace filters

[athos]

New build. GCC was updated to 3.4.0, and then mplayer wont build, so I had to use VC++ for that one.

[Latexxx]

Originally posted by Andy2222
So there is no need to build a P4 or AMD64 version. The only way to get more speed is by hand optimizing the code for AMD64 or write some SSE2 routines.

The why did Anandtech got Lame running one third faster on AMD64 just by recompiling. How did The Jem Report did the same thing using Oggenc. And why does the same apply to OpenSSL/AES which isn't specially optimized for any architecture.

http://www.anandtech.com/cpu/showdoc.html?i=1884&p=17
http://www.thejemreport.com/modules.php?op=modload&name=News&file=article&sid=117&mode=thread&order=0&thold=0
http://www.thejemreport.com/modules.php?op=modload&name=News&file=article&sid=126

[esby]

I guess the differences showed in the lame test, are coming from the fact that the 64bit code is run into a native 64 bits environnement, while the 32 bits code must be somewhat emulated, thus being executed slowly.

I guess we were mostly talking of win32s/ amd or intel build,
When it comes to 64bits it might be another story.

Considered the limited number of people getting AMD64 right now,
considered it might be just a recompilation and not a entire port or adaptation, maybe someone could make one build and run some tests.

esby

That sounds more a problem related to building any X application on a given core/system than an FFDShow speed related problem here for amd64.

[Andy2222]

Originally posted by Latexxx
The why did Anandtech got Lame running one third faster on AMD64 just by recompiling. How did The Jem Report did the same thing using Oggenc. And why does the same apply to OpenSSL/AES which isn't specially optimized for any architecture.

http://www.anandtech.com/cpu/showdoc.html?i=1884&p=17
http://www.thejemreport.com/modules.php?op=modload&name=News&file=article&sid=117&mode=thread&order=0&thold=0
http://www.thejemreport.com/modules.php?op=modload&name=News&file=article&sid=126

I was mainly reffering to the pseudo /P3/P4/AMD switch, oki more information. Im not 100% sure about what code LAME & Oggenc use, i bet they have just plain c or c++ routines. The problem for ffdshow or mplayer.dll is this: It use inline assembler in the c/c++ code wich is hand optimized for mmx or sse and those parts CANT be changed by the compiler even if we use a 64bit switch. So all the handcoded ASM parts are 100% untouched and will run the same way on an AMD64 like they run on a P3. Only if the compiler has plain c or c++ code he will regroup/replace the instruction for AMD64.

Also your talk about 1/3 more performance but if i read all the test carefully some runs also performed worser than the org. x86. But u are right the gain for normal c/c++ loopmath will run 5-20% faster.

From jem report:
"So what should you compare? There are so many numbers in these tables. The AES algorithm is the best to use for comparison because it uses 8-bit operations and has no hand-optimized assembler code associated with it like some of the other cyphers do (it's coded entirely in C). So comparing the AES numbers, AMD64 is almost twice as fast as x86 in the majority of the tests. This reflects a performance enhancement caused by the extra general purpose registers available to the software while in 64-bit mode."

Thats what im talking about, and cause all the CPU intensive main routines are ASM handcoded the compiler just optimize those routines wich take very less CPU power. Its the same problem why a P3/P4 version dont run any faster.


But maybe Athos can try build a 64 bit version, for test proposal. But its damm hard to get all the ffdshow code + libs compiled for 64bit... If i relook the code it "might" be that a 64 bit version of the libavcodec could get a 3-8% performance boost, but we have to test.

[Beatles]

Originally posted by Andy2222
"might" be that a 64 bit version of the libavcodec could get a 3-8% performance boost, but we have to test.

I think there'd be a more than 10% increade and my AMD64 rig is dying to try this.

[Latexxx]

Originally posted by Beatles
I think there'd be a more than 10% increade and my AMD64 rig is dying to try this.

Are you aware of that you need 64 bit version of Windows to run 64 bit binaries?

[Beatles]

Originally posted by Latexxx
Are you aware of that you need 64 bit version of Windows to run 64 bit binaries?

I have the 64 bit Windows OS but you do not need it in order to run an AMD64 iptimized compile. Works just great under a 32 bit OS.

[Latexxx]

Originally posted by Beatles
I have the 64 bit Windows OS but you do not need it in order to run an AMD64 iptimized compile. Works just great under a 32 bit OS.
Yes, but real 64 bit compiles (not just AMD64 optimized) require 64 bit operating system to run.

[Beatles]

Originally posted by Latexxx
Yes, but real 64 bit compiles (not just AMD64 optimized) require 64 bit operating system to run.

Actually that's not quite true either.

[Koepi]

Beatles:
Ah, we're all dumb, you're right. We must have misread the specs for the flat 64bit mode (the _real_ 64bit mode of the amd64) which means not using any 32bit software...
All other 64bit modes (well, there is only one mixed 32/64 bit mode in fact) are for sure not any faster than 32bit modes. (In the contrary, the context switching necessary in the cpu will slow down things considerably.)

Nice to see some wise users around here who know things better than the programmers and educated computer scientists. No need for us anymore, hooray! ;)

Koepi

[DDogg]

I installed ffdshow-20040514. MakeAVIS now fails with a "Runtime Error!" (abnormal program termination). I uninstalled and reinstalled the older version of ffvfw from Sh0dan's sig and now I still get this same error. In fact, even after uninstallation, the ac3 filter was hosed and required reinstallation. I am wondering how I can undo the damage the installation of ffdshow-20040514 caused as I need to get makeavis working again. It seems the uninstall must leave something behind.

[Beatles]

Originally posted by Koepi
Beatles:
Ah, we're all dumb, you're right. We must have misread the specs for the flat 64bit mode (the _real_ 64bit mode of the amd64) which means not using any 32bit software...
All other 64bit modes (well, there is only one mixed 32/64 bit mode in fact) are for sure not any faster than 32bit modes. (In the contrary, the context switching necessary in the cpu will slow down things considerably.)

Nice to see some wise users around here who know things better than the programmers and educated computer scientists. No need for us anymore, hooray! ;)

Koepi

Your sarcasm is infantile at best as is your clear lack of understanding of the AMD64. I'd suggest you do a bit of research before you look even more like a total moron.
Wonderful when diots like you actually think you have a semblance of intelligence little guy.
What a joke you are.

[Ryokurin]

omg.

[bill_baroud]

Beatles : i suppose you read that (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF) and that (http://www.amd.com/us-en/assets/content_type/DownloadableAssets/dwamd_24592.pdf) before talking....
Any 64bits mode on an AMD64 need a 64bits OS, in 32bits legacy mode, only 8 32bits (or less) gpr are used (instead of 16) to comply with x86 architecture :o
w00t that should be waaay faster with twice less registers.

[esby]

The only infantile persons are those who insult people in my opinion...

Personnaly I don't quite understand beatles reaction here,
unless he is someone who had a previous argument with koepi,
which I don't know or doubt -and I don't even want to know-,
and that will have probably nothing to do with the current discussion here.

And 'omg', might be my proper reaction too, maybe more something like being puzzled about understanding the true meaning of this farce...

esby

[arno]

I've just tried running the latest build (20040514) on my brother's Win2K machine, which has an Pentium II 400 MHz CPU, but this build is really slow. From what I've seen, it's at least 20% slower, which is a big impact on such a low end machine which barely can be used for proper MPEG4 encoding at all. For now I've stepped back to the previous build which runs fine. Maybe Athos (or Andy) can have a look at what could have caused this (the new GCC? or maybe other compiler switches)?

Another (more general) comment is that from what I've noted is that the DivX5.11 decoder filter is about 10% faster than ffdshow. I always thought that ffdshow was better optimized and thus faster than DivX5. Any explanation why this seems to be the case?

[iradic]

hi

i have some problems with AR decoding...
file creation: xvid rc4 avi (res 352x288, ar 4:3 PAL) -> 3ivx muxer -> this mp4 file when decoded with ffdshow gives me this (bsplayer - alt + 3):
Video size: 352x288, Aspect: 12:11 (314x288) - where are these numbers come from?!

i think that file is encoded correctly... mplayer plays it at 384x288 so i think ffdshow calculates wrong values ... 12:11 is correct i think -> (352x12) / (288x11) = 4 / 3

using winme with ffdshow-20040501

another thing - in about box i clicked on build info to see versions and it says "xvid.dll - not found" ?? (is this for old xvid ver or what)

thanks

[Andy2222]

wow i just played around with the avisynth integration and ffdshow. I never used avisynth since it looked to much trouble for my simply viewing need's. But since i still mess around with this silly spline/lanczos "horizontal line" bug i gave it a try.

I only can say im amazed. :) i just downloaded the latest 2.55 version and added "Lanczos4Resize(1152,632)" to the avisynth tab in ffdshow and wow all worked and there is no green bug nor chroma horizontal line bug and the video looked realy great and sharp.

The only drawback is the 20-30% more cpu usage compared to the mplayer.dll lanczos method included in ffdshow.

[athos]

Arno, it's probably because mplayer was not compiled with gcc. do you use any postprocessing?

[arno]

Originally posted by athos
Arno, it's probably because mplayer was not compiled with gcc. do you use any postprocessing?

I also tried to disable postprocessing but this didn't fix the problem :-( I also tried chaning the iDCT routine but this didn't work either.

[Defiler]

I'm trying to get a handle on the way ffdshow's code is organized, so that I can use the debugger to help track down future problems.
However, I'm not really familiar with STL, etc, etc..
Can someone tell me where the main entry point in the code is for handling incoming streams of compressed video?

[sysKin]

Okay, I have a small feature request: fix vector visualization with bframes please ;)

Older ffdshows just didn't visualize bframe's vectors and that was fine.
Newer ffdshows just show some rubbish data, which makes it difficult to use this option for anything.
And before you ask, yes, I do use it, not because "it's nice". It's a very useful debugging tool for me :)

Regards,
Radek

[DDogg]

If anybody does run into the same problem as I posted above, make sure ffvfw and dshow are uninstalled. Search reg for all instances of ffvfw and ffdshow and delete. Search HD for all instances of ffvfw and delete.

Then install ffdshow. Worked for me. Whatever it was even caused a crash with the preview screen on dvd2dvd when used. Now, all seems ok.

/Add: I take that back. Makeavis does not seem to function. VDub throws a "-2" error which may be appropriate.

[Omni]

i don't know if someone already noticed, but using ffdshow to decode xvid (haven't tried divx5) with ssa/ass subtitles causes a videodelay of 1 frame compared to the xvid and divx5 decoder. is there a chance to fix this?
(i coded an anime with hardsub karaoke+softsub translation, using xvid with max. consec. bframes=2 maybe this is some sort of decoderlag using libavcodec)
i'm quite happy with the latest ffdshow developement :) keep on your good work

[Koepi]

How do you notice a 1 frame delay? I played around a little with frame-offsets/audio delays and found 1 frame to be close to unnoticable...

What do you use to show the subtitles? Maybe that filter is buffering up a frame as it doesn't know about ffdhsow decoder but about xvid/divx?

Regards
Koepi

[Omni]

if you have hardcoded subtitles with additional softsubs timed exactly as those hardsubs (e.g. japanese kanji+romanji hardcoded and english translation as softsubs) you can notice it on fades between between the lyrics. (i verified it with mpc and zoomplayer + frameskip forward)
i'm using the matroskapack 1.0.2 + the newest vsfilter (2.33).
only ffdshow +xvid decoded via libavcodec causes this delay using ffdshow with xvid decoder set to xvid the timings are correct.
seems like libavcodec causes 1 frame delay.

[M7S]

I've noticed some slowdown with the 20040514-build, too. CPU use is 100% when I decode a mkv with xvid video and two aac audio tracks. With the 20040508-build CPU usage is around 70%. No postprocessing are used but I'm resizing with lanczos (608-->640). I've got an Atlon XP 1700+ and I'm using win2k.

[Vitos]

Hello to everyone!

No one has noticed this little bug yet, so that was my final reason to register on this great forum. :)

Since 20040325 compilation of ffdshow, "Show OSD message after keypress" in "Keys & remote" section doesn't work. Maybe it isn't function used by many people - but I lack it a little bit. Often I compare, how will my fresh-encoded video look like with post-processing or noise turned on or off - so then I use keyboard shortcuts. It WAS nice to know, what I am switching and I hope it will be fixed soon by The Great Ffdshow Masters... ;)

[athos]

Originally posted by M7S
I've noticed some slowdown with the 20040514-build, too. CPU use is 100% when I decode a mkv with xvid video and two aac audio tracks. With the 20040508-build CPU usage is around 70%. No postprocessing are used but I'm resizing with lanczos (608-->640). I've got an Atlon XP 1700+ and I'm using win2k.
I think lanczos resizing is using mplayer, which was compiled with VC++ for this build, instead of gcc as usual. Because of this, regular c code was used instead of faster asm code. Next build will be gcc again.

[arno]

Originally posted by athos
I think lanczos resizing is using mplayer, which was compiled with VC++ for this build, instead of gcc as usual. Because of this, regular c code was used instead of faster asm code. Next build will be gcc again.

Well, the odd thing is that I disabled all options in ffdshow, and the problem still remained (slowdown), and thus no resizing is used whatsover (except the one applied by BSplayer itself). Also note that I only seemed to be able to produce this problem on the P2-400 of my brother, at home on my XP1800 it seems to run fine.

[ryuu1232003]

Originally posted by arno
Well, the odd thing is that I disabled all options in ffdshow, and the problem still remained (slowdown)
if you disabled all options, ffdshow uses swscale in libmplayer to convert colorspace.
(at 20040514-build, now it's not)

athos,
how about making new binary? now can compile with gcc 3.4

[athos]

New build, and also a P3 optimized build.
Regular:
-VC++ 6: /G5 /O2
-ICL7.1: /G5 /O3 /Qipo
-GCC3.4: -O3 -march=i586

Pentium3:
-VC++ 6: /G6 /O2
-ICL7.1: /G6 /O3 /Qipo /QxK
-GCC3.4: -O3 -march=pentium3 -mfpmath=sse -funroll-loops

* Andy2222's OM fix
* Install path fix
* IDCT=Xvid as default (thanks, swalker)

[Neo Neko]

Athos I am having some problems with your recent P3 build at least. I'll try the regular binary later. But the recent P3 build is showing strange blocking when decoding varrious Xvid encodes via libavcodec. Though CPU usage is good.

I am using it on an Athlon XP 2500+ Barton core which has always handled SSE optimisations fine. So there might be something wrong with the compile settings. I will attach an example pic. And if there is something I can do that might be more helpfull just ask.

[avih]

Neo, it's a hidden message, don't u see? flip the blocks 3 times, rotate to the left once, bounce twice, decode the morse code, and there u go "We're on a mission from god!" (exclamation mark included in the source) ;)

[Alxemi]

IDCT=Xvid as default (thanks, swalker)
Thanks a million!