ffdshow development

[jpl]

Related to the discussion about compatibility with the K6 series of CPU. There was and issue with the K6 not supporting all the instructions of the P-Pro. Here is an excerpt of a discussion I had relating to crashes in DIVX 4.1x due to the missing instruction. (for more information search for a post from me realted to "DivX 4.12 crashing")

************************************************
************************************************
As I posted in the DivX forums here is some info that I received regarding the crashes with 4.1x versions of the codec on K6 class CPU's.

If you have K6 class CPU the problem with crashes during encoding seem to be more fundamental. The code is calling for an instruction that AMD never implemented. See below for a reply from the author of Virtual Dub in response to the crashes.
+++++++++++++++++++++++++++++++++++++++++++

Please feel free to forward this on to the DivX developers or onto the DivX forum.

This is not a bug in VirtualDub, nor is it a problem with your motherboard. The crash resulted from the DivX 4.12 driver attempting to use an FCOMIP instruction, which was first added by Intel to the Pentium Pro. AMD did not add it to their CPUs until the Athlon, however, so your K6-3 does not support it and fired an Illegal Instruction exception. This is not related to the MMX, SSE, or SSE2 instruction sets.

Interestingly enough, to the best of my knowledge Visual C++ 6.0 cannot generate FCOMIP, so either Intel C++ was used or someone hand-coded this function.

-- Avery Lee http://www.virtualdub.org
The latest version of VirtualDub is V1.4.7 (build 13130).
************************************************
************************************************

I would bet that this is the same problem with the new compiles of ffdshow. I would like to humbly request that this is fixed as I also use ffdshow on a K6 cpu. (However I realize that beggars can't be choosers) My K6-3 may be old and slow compared to the current state of the art but it still works.

<<<caution rant starting>>>
Also I take exception to whoever made the comment about being able to upgrade the CPU for $40. To use that new $40 CPU will require a new $20 heatsink, a new $50 motherboard, a new $20 graphics card (because the AGP 2x card most likely wont work in the new motherboard) and $50 of new memory because the new motherboard probably wont use the old PC100 ram either. After all that hopefully the old 300w power suply is still enough or else that may need to be upgraded too for $30. So now it costs approximately $200 to upgrade the "$40 CPU" to a model that is still quite outdated.
<<<rant over>>>

Thanks,
JPL

[Andy2222]

Originally posted by jpl
Related to the discussion about compatibility with the K6 series of CPU. There was and issue with the K6 not supporting all the instructions of the P-Pro. Here is an excerpt of a discussion I had relating to crashes in DIVX 4.1x due to the missing instruction. (for more information search for a post from me realted to "DivX 4.12 crashing")

<<<caution rant starting>>>
Also I take exception to whoever made the comment about being able to upgrade the CPU for $40. To use that new $40 CPU will require a new $20 heatsink, a new $50 motherboard, a new $20 graphics card (because the AGP 2x card most likely wont work in the new motherboard) and $50 of new memory because the new motherboard probably wont use the old PC100 ram either. After all that hopefully the old 300w power suply is still enough or else that may need to be upgraded too for $30. So now it costs approximately $200 to upgrade the "$40 CPU" to a model that is still quite outdated.
<<<rant over>>>

Thanks,
JPL

ah thx for this info, if its true than the "FCOMIP" is generated by gcc maybe? If i have time i can do a check if gcc build those OP in mplayer or libavcodec. (Its not hancoded in the code)

for the 40$ thing.... check ebay and u will find a lot of board+ram+cpu+heatsink... stuff wich all perform better than a 250Mhz pentium cpu. For 150$ u can get a full working PC already these days. But oki maybe 40$ was a bit low so lets say 80$ :)
---------------------------------------------------------------------

update: oki gcc 3.3.3 dont produce "FCOMIP" if Athos used his posted "-march=i586 -mcpu=i686" settings, but i already posted that -march overwrite -mcpu so the so called pentium pro release is a i586 release for the gcc parts.

gcc only produce "FCOMIP" if u set "-march=i686", so we should avoid using this mode under the gcc parts for now, to help for this AMD K6 problem.

So there should be no problem with Athos release, but ffdshow was compiled using VC 7.1 this time (or was it still 6.0 Athos?) so maybe VC 7.1 produce this OP with the /G6 switch... if so the only way is to go back to "blend" for now or test VC 6.0 with /G6. ( i think "FCOMIP" will prolly be generated also with VC6 if u installed the latest processor pack wich is needed for a ffdshow compile.

Thx for the tip jpl

[athos]

For the latest builds I have used /G6 in VC/ICL and -march=i686 in GCC. Also I use ICL 7.1 since I read that 8.0 check to see if cpu is genuine intel and not only what instructions it supports, and thus disables for example SSE2 code in Athlon64's.

So should I go back to Blend/march=i586?

Btw I noticed that libavcodec has been updated again, so the fix for whatever_it_was < 16 should be in next builds i guess (too lazy to go back and check in thread :) )

[Kurosu]

DAMN ctrl+W :angry:

In short, I've disassembled all dlls and saw that most of the gcc dlls (libavcodec, ff_theora, ff_libmad, ...) are at fault, by including fcomi/fcomip. VC parts are ok, but I guess you should be cautious with ICL builds.

On a second hand, this means ff_theora and ff_libmad are built by gcc. But they don't contain AT&T syntax ASM, so it's safe to build them with VC or ICL, which produce faster code than gcc.

[Andy2222]

Originally posted by athos
For the latest builds I have used /G6 in VC/ICL and -march=i686 in GCC. Also I use ICL 7.1 since I read that 8.0 check to see if cpu is genuine intel and not only what instructions it supports, and thus disables for example SSE2 code in Athlon64's.

So should I go back to Blend/march=i586?

Btw I noticed that libavcodec has been updated again, so the fix for whatever_it_was < 16 should be in next builds i guess (too lazy to go back and check in thread :) )

If this OP realy crash the older AMD than a "blend" and "-march=i586" version is needed, the instruction is only used a few times, maybe we can rewrite the code so it wont be used for further versions.
But for my PC some test's showed that a /G6 version compared to a blend isnt that much faster (1-3% max.) on my Athlon-XP, even with gcc my own "march=Athlon-XP" compile dont run faster than your "i586/686" version's... I get a little boost using the 3.4 prerelease version for libav thats all.

That are my switches for the gcc stuff and my amd-xp:
OPTFLAGS=-O3 -fomit-frame-pointer -march=athlon-xp -mmmx -m3dnow -msse -ffast-math
OPTFLAGS+=-finline-functions -finline -mfpmath=sse
OPTFLAGS+=-fprefetch-loop-arrays
OPTFLAGS+=-momit-leaf-frame-pointer -malign-double -maccumulate-outgoing-args
OPTFLAGS+=-mno-align-stringops -minline-all-stringops

[Owen]

Thanks Andy,
It would seem that there is to much effort requiered to make fully optimised versions and the improvments may not be worthwhile.
I was only dreaming.
Thanks anyway.

Owen

[jk888]

I submitted this issue a few months ago:
http://forum.doom9.org/showthread.php?s=&threadid=72199

When decoding video encoded with Xvid 6of9 custom matricies, ffdshow will display artifacts while the Xvid decoder plays it fine. At that time it was determined the problem is with libavcodec.

I submitted the bug to the ffmpeg developers few months ago and they emailed me back saying fix is it now:
https://sourceforge.net/tracker/?func=detail&atid=116082&aid=918736&group_id=16082

Please implement this fixed version into ffdshow.

[bond]

Originally posted by jk888
I submitted the bug to the ffmpeg developers few months ago and they emailed me back saying fix is it now:
https://sourceforge.net/tracker/?func=detail&atid=116082&aid=918736&group_id=16082

Please implement this fixed version into ffdshow.milan already updated libav because of that
maybe we need a new build to test it out :)

[jk888]

I'm itching for a new build to test it out! I look forward to finally solving this bug which lasted for months.

[TheUnforgiven]

the build 20040424 and other builds i tried contains a broken makeAVIS.
It gives the following error immediately after its start.

"the procedure entry point avs_release_video_frame could not be located in the dynamic link library avisynth_c.dll"

if u have a link to a working version of this utility post it plz.

[athos]

Originally posted by TheUnforgiven
"the procedure entry point avs_release_video_frame could not be located in the dynamic link library avisynth_c.dll"

if u have a link to a working version of this utility post it plz.

I googled and came up with http://kevin.atkinson.dhs.org/avisynth_c/

[TheUnforgiven]

I googled and came up with http://kevin.atkinson.dhs.org/avisynth_c/

i suppose u mean i should update avisynth_c.dll.
i put version 0.15 into win\system32 (overwriting the existing one).
now when i try to run makeAVIS nothing happens at all. no prog no error.

i have avisynth 2.54 if this helps

[athos]

sorry mate, im not even sure what makeAVIS is supposed to do ;)

But milan removed it from the install-script, i suppose this might have been the reason.

[zettai]

dammit, makeAVIS is the only reason I use ffdshow :)

It's a video frameserver for avs scripts for programs that require files with avi headers.

[TheUnforgiven]

makeAVIS is indeed a very important utility. i hope this get fixed soon.
i repeat my request if somebody have a working build plz give a link.

@athos
thanx for the responce. and for your ffdshow builds/hosting which i usually use.

[TheUnforgiven]

i just checked this build:
ffvfw-20031028.exe
makeAVIS does not work here either. maybe its an avisynth issue?
could somebody confirm the bug

[zettai]

I don't get a bug when I use makeAVIS even with the latest build but then again I've no idea what's producing the bug and it could be anything.

[TheUnforgiven]

what a situation. will i need to reinstall windows to make makeAVIS work!.

i assume u use the latest avisynth too

[athos]

New build today.
- VC target: Pentium (/G5). Compiled with ICL7.1 (except TomsMoComp)
- GCC target: -march=i586 -mcpu=i686 (the default from CVS)
- skal's codec included
- Path fix, OM fix

[Arcon]

Originally posted by athos
New build today.

is it me or isn't the new build on the site in your link right now?

[Koepi]

well, the changelog is indeed new ;)

Maybe some ftp troubles i guess.

Regards
Koepi

[Arcon]

Originally posted by Koepi
well, the changelog is indeed new ;)

but i'm not skilled enough to make a binary just from the information contained in it :D

[timeismoney]

Waiting for release and wish h264 code has been finished
Early version can display the 1st frame but can't play or crash
I use MPC 6482 or WMP9

[athos]

Sorry, I was very tired yesterday.
Will upload new build when I get home from work in about 10 hours.

Notice that I updated the favicon.ico though ;)

Edit: Uploaded new build (direct link (http://athos.leffe.dnsalias.com/ffdshow-20040501.exe))

[timeismoney]

Gateway Timeout
The following error occurred:
Server unreachable
-----------------
Please contact the administrator.

I've changed some proxy and got the nearly same message...
Maybe the site got in malfunction? or too busy?

[dragongodz]

works ok here, downloading that is. :)

[jk888]

I'm happy to report that artifacts now longer appear with Xvid encodes using the 6of9-hvs custom matricies. The latest version of ffdshow (ffdshow-20040501) plays all of my test encodes without any artifacts at all. Hurray! Now I can finally do all my encodes with 6of9-hvs!

[easyfab]

I made little test with the h264 codec and it looks good for a so early version.:) but a good cpu is needed -> 720*576 needs ~90% of my 2800+ XP
only cabac option don't work (don't know if it's an encoder or decoder problem)
Is there somewhere docs for all the options (p4x4 p4x8 ...)?

Thanks milan,athos and all others for your work

[Tommy Carrot]

Originally posted by easyfab
720*576 needs ~90% of my 2800+ XP


Hmm, i'm almost able to perfectly play back a 1280*720 test encoding on my 1700+. :confused: A little flickering here and there, but definitely watchable.

And cabac works here, but it increases the playback CPU requirements (so the above mentioned encoding was with cavlc). However, there is an incompatibility between VSS h264 codec with cabac on and ffdshow, because there are artifacts on playback, so at least one of them is not spec compliant.
Is there somewhere docs for all the options (p4x4 p4x8 ...)?
H.264 can use several block-sizes (opposite to mpeg4 which has constant macroblock-size), and there can you enable them. Enabling all can increase the quality, but would slow down the encoding quite a lot.

[easyfab]

ooops 90% was with PP on max. without PP only 66%.

[Wilbert]

i suppose u mean i should update avisynth_c.dll.
i put version 0.15 into win\system32 (overwriting the existing one).
now when i try to run makeAVIS nothing happens at all. no prog no error.
1) put avisynth_c.dll outside the autoplugin dir (as well as all c-plugins).
2) install makeavis from this site: http://cultact-server.novi.dk/kpo/avisynth/avs_cvs.html
3) install latest avisynth (if you have not done so)

This should work. (tried with ffdshow-20040329.exe I think)

[virus]

I've tried a little H.264 encoding (20 secs, DVD source), everything worked fine with and without CABAC, including playback.
BTW enabling CABAC reduced the filesize more than 6% compared to CAVLC (with the very same settings, of course). This is quite a bit for an entropy coder. I think CABAC is the strongest feature in H.264.

[Tommy Carrot]

Originally posted by virus
BTW enabling CABAC reduced the filesize more than 6% compared to CAVLC (with the very same settings, of course). This is quite a bit for an entropy coder. I think CABAC is the strongest feature in H.264.

Based on FFV1, which also uses cavlc and cabac for entropy coder, there are extreme cases where cabac is more than 30% more efficient than cavlc (62MB vs 91MB).:D In my experience cabac is especially great on CGI material.

[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.

[virus]

Originally posted by Tommy Carrot
In my experience cabac is especially great on CGI material. Sure, arithmetic coders do wonders in the low entropy region, where a 10-20% gain (or even more) should be the norm. For natural and/or MC'ed DPCM images (which are not in the low entropy region, usually) both Huffman and Golomb-Rice codes still are very good, so I think 6% will suffice :)
Also, both the loop filter and multiple frame references proved to be quite effective. I'm quite satisfied with the speed of this x264 encoder, too (got ~3 fps on a 560x304 video with all the bells and whistles on, even though constant quantizer = no ratecontrol performed - but probably the encoder can be further improved speed-wise).
Very promising ;)

[Andy2222]

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.

Can u explain your problem a bit more? Im not a HTPC insider. What exact is the problem with the presets?

[debennett2]

Thanks for the reply. I'd like to be able to load a preset (let's say I have one labeled and saved as "default" with no settings applied and then one that labeled and saved as "1776x100" that resizes and does a little filtering) from a command prompt or batch or anything for that matter. Then I could tell my software interface that when I am watching something that I don't want to resize to load my "default" whereas when I want it to resize, it can load my "1776x1000" preset.
Does that make sense?

Thanks.

[yaz]

@debenett22
if i'm right about what u want ... it's quite easy. ffdshow keeps all settings in the registry. pop up regedit & find the actual settings at [HKEY_CURRENT_USER\Software\GNU\ffdshow].
export it to wherever u want and give it a name whatever u like. it is a 'text' file with the extension 'reg'. get back to ffdshow config, set the other 'profile', save it with a different name. ... aso ... u can always reload it/them by double-clicking the .reg fil.
is that what u want ?
the bests
y

[debennett2]

Thanks yaz! I will try that when I get home! Now, I need to see about writing something that will automatically export those reg files or something for other end users so they don't have to mess with the registry themselves...save a few steps for them.

[Andy2222]

Originally posted by debennett2
Thanks yaz! I will try that when I get home! Now, I need to see about writing something that will automatically export those reg files or something for other end users so they don't have to mess with the registry themselves...save a few steps for them.

look here
http://www.avsforum.com/avs-vb/showthread.php?s=&threadid=397891

[yaz]

Originally posted by debennett2
Thanks yaz! I will try that when I get home! Now, I need to see about writing something that will automatically export those reg files or something for other end users so they don't have to mess with the registry themselves...save a few steps for them. on winxp we got the 'reg' command. (afaik, it comes with sp1) it's for handling registry. give it a try. (ye know ... command prompt/reg/... :-) it has many options (and many subopts:-)
the bests
y

[debennett2]

Thanks guys! Let me know if you come up with any other ideas! I'll try those when I get home. Thanks again!

[Blight]

What do people think of the may 1st build? Any major stability issues I should know about?

P.S.
aWarpSharp seems to work now, unless you use chroma sampling which seems to switch the U and V. The ffdshow original warpsharp is broken, seem to use wrong coordinates or something.

[Nikse555]

The may 1st 2004 build works well for newbie me.
I have tried about 20 avi clips with ZP3/WinXP on my VIA C3 933mhz (~equal to an amd/intel 500mhz). It seems as fast as the old version from may 2003 :)

[HLW]

Hi! I am testing the H.264 codec in the new ffdshow build and it seems to be a good start!! But does anyone know what kind of color space this codec use when encoding?

Best regards

Haakon

[Tommy Carrot]

Originally posted by HLW
But does anyone know what kind of color space this codec use when encoding?


I guess YV12, like most lossy codecs do.

EDIT: Yes, i can confirm, that's it. :)

[HLW]

Are you sure? Because when I am doing SSIM compairments, I have to do a converttoyv12() in order to be allowed to run the ssim function with h.264 encoded material.

[Tommy Carrot]

That's strange... I'm absolutely sure it's YV12 here.

[hellfred]

While we are up to talking about encoding: I tried to find out what the different settings for ffv1 encoding do, but i failed.
Can anybody tell me when to choose Coder type vlc and when ac.
What does the contect do? How will the filesize change when i play around with the Keyframe distance, and why?

Hellfred

[Tommy Carrot]

AC (arithmetic coder) is always more efficient (by how much is depend on the content of course), while VLC is almost twice faster. The keyframe distance doesn't really affect to the filesize, so i usually set it to 1 (every frame is keyframe) for the easier editability.

BTW, i finally figured of why does ffdshow have problems with decoding some cabac encoded h.264 videos, but no problems with others. Basicly ffdshow cannot decode the 4x4, 8x4 and 4x8 blocks properly when cabac is on, this might be the reason why they are disabled in the encoder by default and this can be the problem with playing back videos made with the VSS codec (which uses these blocks). Cavlc works properly with every block-sizes.

[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!

[athos]

Neo Neko, that might be due to the -mfpmath=sse flag. Perhaps I should loose that one for next build.

Also, I noticed that at least mplayer is being built with -ffast-math flag (frome the makefile in the CVS). Perhaps that is not soo good, could lead to rounding errors?

Thanks for the feedback.

[Leak]

Originally posted by athos
Thanks for the feedback.

Since the changelog mentioned SPP deblocking being fixed on SSE2 machines I just had to try it out - only to find that it eats my 2.4GHz P4 for breakfast playing a 720x400 XviD encode. It'll use 80-90% CPU when I let it deblock luma only, but if I go any higher it starts getting jerky as hell... whoa... :eek:

Does it somehow not use SSE2 instructions at all or is this the expected behaviour? :confused:

np: While - Spark (Lock)

[Xenoproctologist]

Originally posted by Leak
Does it somehow not use SSE2 instructions at all or is this the expected behaviour? :confused:

It looks like it's just SSE at the moment. Not to say that it isn't expected behavior as well -- it appears to be doing a boatload processing per frame, relative to the fairly-lightweight mplayer postprocessing. I wouldn't count on this being practical for realtime use until GPUs become practical for general-purpose computing.

[Andy2222]

Originally posted by Xenoproctologist
It looks like it's just SSE at the moment. Not to say that it isn't expected behavior as well -- it appears to be doing a boatload processing per frame, relative to the fairly-lightweight mplayer postprocessing. I wouldn't count on this being practical for realtime use until GPUs become practical for general-purpose computing.

yeah it realy consume lots of cpu power, btw for the intrest the code is not using SSE instruction's. Like 90% of all asm ffdshow routines they are written for MMX/MMX2 mostly. So most function's dont use the SSE/SSE2 or SSE3 registers/instructions.

PS: btw what is SPP anyway? Is it a other algo. to deblock/dering? Some get a link or so wich explain's it?

[avih]

Originally posted by Andy2222
...PS: btw what is SPP anyway? Is it a other algo. to deblock/dering? Some get a link or so wich explain's it?

i'd second that. it got me interested after Neo Neko said he's using it, but i don't quite get what it does. (btw, Neo, if you're reading this, i totally missused the filter, so my images on the other thread with SPP are meanningless, sorry ;) )

it seems to reduce the resolution quite heavily (4x on each axis imo) where there's noise, but i'd like to read some more about it. has a very interesting potential imo.

[Vitos]

Originally posted by Andy2222
PS: btw what is SPP anyway? Is it a other algo. to deblock/dering? Some get a link or so wich explain's it? [/B]

Google sometimes can be very helpful:
http://www.hydrogenaudio.org/index.php?showtopic=19578&

And for those who want to go straight to the source:
http://www.utdallas.edu/~aria/papers/vlsisp99.pdf
http://www.utdallas.edu/~aria/papers/spl03.pdf

[avih]

thx Vitos. i did google, but appearantly, not well enough (shame on me). thx again.

ps.
welcome to the forum ;)

[Xenoproctologist]

It doesn't look like turning deringing on with SPP deblocking actually does much of anything -- the filtering effect of SPP deblocking is strong enough to clear the dering threshold.

Thoughts:
1). SPP deblocking is sabotaging deringing. Swap filter order when using SPP deblocking.
2). SPP deblocking does a good enough job of deringing on its own, and deringing with SPP deblocking has issues beside that (see below). Disable deringing when SPP deblocking is enabled.


Approx. CPU Penalty for SPP @ 640x480@24fps (Athlon XP Barton):
Horiz Luma Deblock = 400 MHz
+ Vert Luma Deblock = 700 MHz
+ Horiz Chroma Deblock = 1500 MHz
+ Vert Chroma Deblock = 2100 MHz
+ Luma Dering = 6000 MHz(!!) (guesstimated from framerate)
+ Chroma Dering = 11500 MHz(!!!) (guesstimated from framerate)

Unless I'm missing something (entirely possible -- my C knowledge extends to interpreting from context only), SPP deblocking isn't using it's own deringer -- it's just using the standard Mplayer deringing filter, which is pretty light-weight. If this is so, what the heck is eating up so many CPU cycles when deringing is turned on while using SPP deblocking? Something is very not-right here.

[avih]

actually, after reading both papers (pdf), and watching spp-filtered results, i can't see a direct relation of the papers to this spp filter. for my eyes, when using strong spp filter (slider to the right) it reduces the resolution. on the other hand, maybe that's the effect of many averaging over 4:3 px range, don't know. the spp entry on the mplayer man say's it's a 'simple postprocessing' (i wouldn't call it simple though) and it has the option to force quants (which does support the idea that it's indeed based on those papers).

[yaz]

i use this cute litte stuff for awhile for serving my avisynth scripts to command line (libavcodec) encoders. but with the newest releases i got only a steady ICDecompressError only. the very last compile being able to serve was 040424 no success since then. what'd been changed in this respect & how can i follow that changes. say, how should i modify my mencoder codecs.conf for making the new ffdshow.ax work ? or should i make configuration trick ?
what i noticed, the avis made by the newest makeavis (0405020) can be served with any(!) ffdshow before 040501, so, i guess sg's changed within ffdshow. but what?
the bests
y

[malkion]

guys, help, there are like 56 pages to ffdshow development.

would it be possible to request ffdshow read the aspect ratio info generated by xvid 1.0 and auto resize the video?

[Neo Neko]

Originally posted by malkion
guys, help, there are like 56 pages to ffdshow development.

would it be possible to request ffdshow read the aspect ratio info generated by xvid 1.0 and auto resize the video?

Yes. You can do it already. Just not with the AVI container. Encode your video to AVI as always. Then convert it to MP4 either using GPAC or the Graphedit->3ivxMux->MP4 methods. When played back in WMP, Quicktime, Real Player, or Mplayer the video will scale to the correct AR.

[malkion]

Thanks for the quick response Neo Neko.

I have a 2.4ghz 533FSB P4. With mp4's have u noticed there's a bigger cpu hit? This is in reference to HDTV source encodes. I can play avi's seamlessly, but mp4's will freeze now and then. However, DVD res can still play rather well. This was the reason I was hoping ffdshow can read AR information from an avi. Might my request still be valid then?

[igor1st]

Originally posted by athos
Neo Neko, that might be due to the -mfpmath=sse flag. Perhaps I should loose that one for next build.

Also, I noticed that at least mplayer is being built with -ffast-math flag (frome the makefile in the CVS). Perhaps that is not soo good, could lead to rounding errors?

Thanks for the feedback.

I confirm the blocking-problem with latest p3-build reported by Neo Neko. This not exist with regular build.

Also I want to notice some other problem with different compiles: most versions ffdshow have problems with mplayer's pp on some xvid-encoded cartoons/anime - flickering image. The strength of flickering can decrease by switching decoder to xvid and/or switching another method of pp (SPP hasn't flickering at all). Only one version of ffdshow with which flickering not occure - build 20040514.

[Didée]

This I wanted to ask for a pretty long time now, but never gotten around:

Can someone confirm that there are problems when ffdshow is set to decode "Raw video", to hook it up after mpeg-2 decoding? I have the biggest problems with this, since ... dunno, half an eternity :( (for about a year, with any version of ffdshow)


Test sources:

- DVB captures
- ffmpeg/QuEnc encodes
- CCE encodes


Decoders:

- CyberLink
- InterVideo


Possible results:

- Player vanishes (both decoders)

- Garbled green video (only /w InterVideo)

- Audio plays, but video freezes on first I-frame. On random access, again freezes on I-frame (both decoders)

- [sometimes] works as expected (both decoders - more often Cyberlink, very seldom /w InterVideo)


That behaviour is about the same on my two machines (Athlon-XP, Celeron-2600), and it's driving me nuts! I just cannot get ffdshow to work reliable as post-processor, if it is hooked after the mentioned mpeg-2 decoders.

That's a major concern for me, since playing video files without ffdshow makes me feel like ... do you know those white jackets with the very long sleeves ? ;)

I've tried all input/output colorspace options of ffdshow, overlay settings as well, and a good variety of different players. No success.

Are my machines joking on me, or does anyone have the same problem?


- Didée

[Andy2222]

Thats a know problem with those decoders, for the intervideo decoder u have to add a dmo filter (normal abstract at setting 0) beetwen the decoder and ffdshow. For the cyberlink decoder im not sure but there was a fix also.

so u can use:
windvd decoder->abstarct dmo filter->ffdshow
sonic decoder->ffdshow
elecard decoder->ffdshow (if u can live with the red chroma bug)
opensource mpeg2dec->ffdshow

all this works

[Didée]

Thanks for pointing that out, Andy. I wasn't really aware of that issue, since I never heard anyone complaining about it. (But 50 complaints each month about XviD over/undersizing :rolleyes: )

Okay, I think I'll get the combo InterVideo/ffdshow working then - will check this weekend.

However, I'd be more interested in getting the Cyberlink filters to work with ffdshow. For example, I notice that the WinDVD filters tend to produce pulsation in dark sequences (frequency = GOP length), sometimes even annoying. With the Cyberlink filters, the same sequences appear much more calm...


Why is everything related to mpeg-2 so cumbersome !?


- Didée

[Neo Neko]

Originally posted by malkion
Thanks for the quick response Neo Neko.

I have a 2.4ghz 533FSB P4. With mp4's have u noticed there's a bigger cpu hit? This is in reference to HDTV source encodes. I can play avi's seamlessly, but mp4's will freeze now and then. However, DVD res can still play rather well. This was the reason I was hoping ffdshow can read AR information from an avi. Might my request still be valid then?

I have not noticed more CPU required with MP4. But I don't have HDTV material to test with. :p There can be some hackery done with AVI headers to have working AR resizing. But there is no standard method which causes problems. Native FFMPEG and MPLAYER can read MPEG4 streams in AVI and do AR resizing. Directshow based players can't. An unfortunate simple fact of life.

[malkion]

thanks, neo neko for your view point.

however, i dont think programming AR resizing into ffdshow to recognize avi streams would be that difficult. believe me, i am requesting this because i've already tried existing AR resizing methods and players for HDTV sources. mplayer and VLC can not playback without stutters for 1280x720 material for my computer.

ffdshow can playback avi's at 1280x720 without any stutters whatsoever, except during high cpu usage. it would be just fantastic if ffdshow can resize according to AVI AR pixels.

[Andy2222]

oki im finaly happy with some of my asm optimized code and want to share the result with u all.

PLZZZ keep in mind that this is a prerelease version for testing only (pls dont make the download link public or at least use a own mirror)

NEW ffdshow build ffdshow-20040529a.exe (the "a" stand's for testversion, so dont kick me if it crash)


Whats new in this version? (its a i686 build and u need MMX2)

- MMX2 optimized denoise3d filter (only the "HQ" version for testing)
- some minor asm codechanges wich "should" improve performance
- xvid IDCT as default
- AC3 ffdshow audio filter disabled by default
- my old overlaymixer fix

- libavcodec memory leak fix by Andrew Ivanov
- DwString memory leak fix by Andrew Ivanov


Now i need your help! Post bugs&problems here.... i mainly need input how the new denoise3d code work (if it's faster on your machine or not) best is u use the filter AFTER the resize for testing.

I need input how the filter run's on P4 and P3 CPU's since i could just test on my AMD-XP. I tryed to avoid some P4 problematic code but not sure if it works 100%....

u can grab my version here:
http://mitglied.lycos.de/ieggei2/ffdshow/


PS: if the version runs fine i will release a full version (with some more code optimisation) and send the code to athos too.
Im working on the resizer now, my goal is to get the cool lanczos4 code from avisynth in ffdshow and see what i can do for speed. If im realy lazy i might try to build and code some AMD64 stuff since i like this CPU and want to play around with it :)

[Neo Neko]

Originally posted by malkion
thanks, neo neko for your view point.

however, i dont think programming AR resizing into ffdshow to recognize avi streams would be that difficult. believe me, i am requesting this because i've already tried existing AR resizing methods and players for HDTV sources. mplayer and VLC can not playback without stutters for 1280x720 material for my computer.

ffdshow can playback avi's at 1280x720 without any stutters whatsoever, except during high cpu usage. it would be just fantastic if ffdshow can resize according to AVI AR pixels.

Ok correct me if I am mistaken here. You are trying to play mp4 in VLC or the dog slow Win32 Mplayer binaries. Would that be correct? Would it further be correct to assume that you are saying that in both of those players at that resolution the system can't handle playback and resize. And that it has nothing to do with the container format per say.

If all that is the case have you tried the 3ivx directshow filters from http://3ivx.com? Did you know that they allow playback of MP4 in WMP and that in conjunction with them ffdshow will get the queue to resize on playback to the propper AR? If you have tried this and it still is a problem let me know as I would like to know. But from what I am seeing this is something you have not tried.

[Andy2222]

hi all, i have a question about the AMD64. Im about to get me this cpu today :)

If i use this free WindowsXP 64 version from the MS site will the AMD64 run in long mode? (the mode i can use the extra registers?)

What about all my old Software? Can i run any "old" 32bit software without penalty in this "long" 64bit mode or do i have to worry about something?

Btw what about drivers? Can i use "old" 32bit drivers on this 64bit OS or mix 32/64 drivers?

[malkion]

@neo neko, again, thanks for your views, but i believe we have a failure to communicate. i am not requesting AR auto-resize for a container which already recognizes it. please re-read my first post regarding this matter. i would like to request ffdshow be able to read AR info from an avi stream and resize. however, thank you very kindly for your time.

best wishes.

[Andy2222]

Originally posted by malkion
@neo neko, again, thanks for your views, but i believe we have a failure to communicate. i am not requesting AR auto-resize for a container which already recognizes it. please re-read my first post regarding this matter. i would like to request ffdshow be able to read AR info from an avi stream and resize. however, thank you very kindly for your time.

best wishes.

mhh u mean AR from anamorphic encodes (if pixel AR differs from real AR)? Or simple that u tell ffdshow X for example 1024 in resize and ffdshow calces Y based on the AR from the org. pixel resolution, so u dont rezise to a diff. AR or need do this by hand?

example: a avi with 720x320 pixel AR, u enter 1152 as X (display res) and now ffdshow calc Y to 512 since 720x320 = 1152x512?

So u always get a correct resized movie based on the org. AR and dont need to enter Y for diff. encodes?

U mean this?

[malkion]

thanks andy, say this, an avi stream anamorph size is 960,720 encoded with xvid using 16:9 sized pixels. having ffdshow directly resizing it to 1280,720 from the AR info.

as neo neko has pointed out, this already works with a mp4 stream, as yet still unavailable with avi stream.

[crlorentzen]

Milan, or anyone else, do we happen to have an idea when then next official release will be? One that is compiled and placed on SourceForge.

besides when it's ready.

Sorry if anyone feels that I am out of line, but I do not feel confortable downloading any of these "third-party" compiles.

[Andy2222]

Originally posted by crlorentzen
Milan, or anyone else, do we happen to have an idea when then next official release will be? One that is compiled and placed on SourceForge.

besides when it's ready.

Sorry if anyone feels that I am out of line, but I do not feel confortable downloading any of these "third-party" compiles.

Those "third-party" compiles base on milans "official" work and they are out of the cvs wich milan updates. Athos add's some fixes/settings and compiles the code for u. The version's Athos release are as official as the old one on the SourceForge page. Milan just dont update the compiles anymore, i bet he has enuff work to do with the code already.

Besides Milan would take the same steps Athos do to compile ffdshow...

PS: My version adds some new code and if it works well i will send those changes to milan and the code will be integrated in later "official" versions.

[esby]

Andy2222 went first on the reply...
but i noticed only when i posted the message :)

Well there is not s really a matter of downloading third parties build....

Do you get your xvid from xvid.org (getting source) and build it,
or do you use koepi, gomgon or nic build (or add any official third party site.)

That's the same here.
Milan does not have much time to compile and provide builds,
and since Athos and the others are providing them, it works.

esby

PS: Of course, that won't remove the fact, they are just 'builds' and
might inherit the bug or problems linked to the cvs branch they are from.

[pankov]

I've been following this thread for a long time but I'm a little bit lost now and I'll be happy if someone can clear a few things for me.

1. A long time ago a "green" problem when resizing with FFDShow was discused and I'm not sure it was fixed. Or atleast I still see it on my NVidia card using the latest builds

2. I'm not sure if that's not connected with the previous but when I use FFDShow to decode XviD content I get worse quality than when I use the XviD Decoder. Is this normal?

3. It's probably the same as the problem mentioned from malkion but I'll explain it my way.
Often I make captures from my DVB card (using MyTheatre) and they have non 4:3 AR (for example 720x576) when I try to play them using the Elcard MPEG2 Decoder + FFDShow for PP I get the picture stretched vertically. When I use Intervideo's DirectShowFilters everything is OK. If I use only the Elcard decoder there is no problem too. So I suppose the problem is in FFDShow. Is this true or I'm making some kind of mistake?

4. Is there a place where I can find some options of FFDShow explained? I'm talking about the "Preset Autoloading" priorities and the "Remote control API"

I hope someone will be able to help me in my "quest for knowlage"
:)

[Andy2222]

1. the green bug was fixed, but caused a new "horizontal line" bug (just use "bicublin" or resize Y to a direct multiple from the org. resolution, to avoid this new bug)
The green u see comes prolly from the VMR9 render mode, i dont see green using the overlay mixer on my nvidia card.

2. Its a libavcodec problem but im not sure what cause this, it also is only visible on very rare movies/encodes. U can use the xvid decoder for decoding and ffdshow as raw filter. On fast cpu's the diff. using libav over xvid decoder is just about 5-10% lesser cpu usage. (be sure xvid deblock is disabled)

3. Its an ffdshow problem, just make sure u have "use overlay mixer" enabled at the output pane and try use "keep org. Aspect ratio" at rezise settings.

4. dunno :)

[Neo Neko]

Originally posted by malkion
@neo neko, again, thanks for your views, but i believe we have a failure to communicate. i am not requesting AR auto-resize for a container which already recognizes it. please re-read my first post regarding this matter. i would like to request ffdshow be able to read AR info from an avi stream and resize. however, thank you very kindly for your time.

best wishes.

:| I know what you are asking. But it is basically not gonna happen. :| FFMPEG through Mplayer can playback AVI containing MPEG4 streams with the propper AR. And perhaps you are aware that ffdshow is based heavily off Mplayer and FFMPEG. So if they can do it and they are largely what ffdshow is why can't ffdshow do it? The answer is simple. It can. It's not ffdshows fault. Ffdshow can do what you want just fine. It is a Microsoft Windows or more specifically Microsoft Directshow problem. And it pertains specifically to the AVI parser. A parser which Microsoft is never going to update since they don't use AVI any more. And a parser that basically no one else is going to update since no one should really be using AVI for MPEG4 anymore. So I guess what I am saying is that if you stick with AVI you are thurroughly up the creak without a paddle.

I generated my own HDTV resolution material from video I captured on my own PC. I then encoded it and put it in an MP4 file. Under the latest publicly avalible win32 Mplayer binary the video was so choppy as to be unwatchable. With the latest VLC there was a slight jerk every so often as a few frames were skipped to catch up. Under WMP using the 3ivx MP4 splitter with ffdshow decoding the actual video it played back smooth as silk with the correct AR and no skipped frames. This was on an Athlon XP 2500+ Barton core. So yes it is a bit faster than yours. But with WMP and the same content in either AVI or MP4 CPU usage was about the same. The only difference being that MP4 allows for propper AR.

[malkion]

@neo neko, thanks for your atttention to my query. your last post was very informative and thoroughly answers my question. u didnt have to go to the lengths of verifying HD encodes through mplayer or vlc, but i appreciate it very much. thanks for clarifying.

best wishes.

[Andy2222]

mhh so no1 with a P3/P4 can test my version for the denoise3d speed, i realy need feedback on this?

[Defiler]

I've tried it on all my non-Xeon P4 CPUs, and:
A) Denoise3D works properly, and has a noticeable effect on the video.
B) Enabling it costs almost no additional CPU time. At least, nothing noticeable with the usual tools, on a P4 2.4GHz Northwood.

Andy2222: While you are updating the ffdshow code, could you put some comments in? The #defines are nested so deep that it's hard to understand what is going on without a major time investment.

One bug: When you click on the "preset" ComboBox (the one that has 'default' as the only entry, after a clean installation), the width of the drop-down is much larger than it needs to be. The width of that dropdown should be ("width_of_text" * "screen_dpi") + "width_of_scrollbar"

Edit: Yes, I had "HQ" enabled for the Denoise3D filter.

[Coroner]

Andy222

I have tried your build as well. My findings are much the same as Defiler's.

On a 640x480 Divx5.1 encoded file with denoise3d default settings HQ I am seeing a small perf hit of 5%-10% on a P4B (533Mhz) 2.8Ghz. Very good speed no visual anomalies detected with it on so far. The perf hit was taken from Taskmanager figures, so please take it with a very large pinch of salt.

Now can have it on all the time, thankyou very much for this optimisation.

[Andy2222]

Originally posted by Coroner
Andy222

I have tried your build as well. My findings are much the same as Defiler's.

On a 640x480 Divx5.1 encoded file with denoise3d default settings HQ I am seeing a small perf hit of 5%-10% on a P4B (533Mhz) 2.8Ghz. Very good speed no visual anomalies detected with it on so far. The perf hit was taken from Taskmanager figures, so please take it with a very large pinch of salt.

Now can have it on all the time, thankyou very much for this optimisation.

ah thats nice i was not sure how the code perform on P4 ... i still hate writing asm code for a CPU i dont own and cant test on.
To bad my new AMD64 system wont run... no video.. prolly broken mainboard or bad memory. But this fault gave me time study the AMD64 techpapers and im realy excited what i could do on this machine. As soon as i get it working and winxp 64 installed i will try rewrite the laczos resizer for AMD64, i want to see what 64bit AMD power can do for ffdshow :)
I realy dont like how all the HTPC guys proclaim that u need a P4 cpu with 400+ Mhz DDR ram to run ffdshow ... I just know its all a matter of clever coding not hoursepower. So lets support AMD :)

@Defiler could u be more specific what u mean with more comments? (hich partss?) There are about 200 cpp files... and prolly 500 defines
Btw u are not alone it took me months to get a small clue whats going on in ffdshow...

[Defiler]

Originally posted by Andy2222
@Defiler could u be more specific what u mean with more comments? (hich partss?) There are about 200 cpp files... and prolly 500 defines
Btw u are not alone it took me months to get a small clue whats going on in ffdshow... Coming into ffdshow "cold", the hardest part (for me) is understanding how the incoming video "flows" through the code. It's hard to separate the "DirectShow pin connects from here to there" code from the "Video gets decoded here" sections.
ffdshow's core portions seem to be totally obscured by the vast number of post-processing features.
I really just need a roadmap to the critical decoder features, since those are the ones that truly matter to me.

Thanks for your optimizations. The more assembly I learn, the more respect I have for those who practice it. Heh.

[Coroner]

ah thats nice i was not sure how the code perform on P4 ... i still hate writing asm code for a CPU i dont own and cant test on.
To bad my new AMD64 system wont run... no video.. prolly broken mainboard or bad memory. But this fault gave me time study the AMD64 techpapers and im realy excited what i could do on this machine. As soon as i get it working and winxp 64 installed i will try rewrite the laczos resizer for AMD64, i want to see what 64bit AMD power can do for ffdshow


Well, you've just taken all the indecision out of my next upgrade. AMD64 definitely now! :D Might make SPP PP useable, atm it's pretty slow but it sure looks nice. Good luck with getting your new system going.

Cheers

[Defiler]

Someone buy Andy2222 an Itanium2 development machine. Heh.

[athos]

Great work, Andy2222! Did you send your code changes to Milan?

[Andy2222]

Originally posted by athos
Great work, Andy2222! Did you send your code changes to Milan?

Not yet need some more feedback fist, i also want to profile the code on the AMD64 cpu tomorrow first. I will send u both the new version soon, just want to make sure that its bugfree or we possibly end up like the mplayer resizer. Aka 1 bugfix result in a new bug hehe

[Blkbird]

I'm facing a strange out-of-sync problem with ffdshow (various versions from 20031128 to 20040520).

The media files in question are AVI's with DX50 video (29.97 fps for one video and 23.97 fps for the others) and MP3 audio (128 kbps stereo CBR). I use ffdshow's libavcodec to decode the video and would like to use ffdshow to decode the audio as well, but no matter if I choose mp3lib or libmad the video runs ahead of the audio (or the audio trails behind, I can't say which is the case). If I skip to somewhere in the file, the video and the audio are synced for the moment and starts to getting out-of-sync from there on.

If I deactivate ffdshow's handling over MP3 audio and use Frauenhofer, the problem disappears. Unfortunately I can't tell if the video runs slowlier then or the audio runs faster.

I use Zoom Player 3.30, but I've tried Windows Media Player 6.4 with the same result, so I'm pretty convinced the problem is somewhere within ffdshow.

[Shinobu]

Hello,
i've recently spotted a bug with ffdshow vp31 decoding.
keyframes are well decoded but between keyframe it's look like broken frame (moving parts are sheeted a lot).

VP3 decoded by vp3 codec
http://satsuki.yatoshi.free.fr/imgforum/vp3.png

VP3 decoded by FFdshow
http://satsuki.yatoshi.free.fr/imgforum/vp3ff.png

i've cherched but not found this bug so if you know how to debug it ^^, i don't encode in vp3 for a long time but i've some vp3 file so if i can use ffdshow for decoding, I can skip the vp3 codec installation (sory for my bad english)

++

[timeismoney]

Agree

Most of VP3 video decoded by ffdshow will show chroma block

Please take a care

[Andy2222]

new versions are up, a normal and a new P4 and AMD64 only version
feel free to test them :)

2004-07-06 22:00 Andy2222

* SSE2 optimized denoise3d filter (only the "HQ" version)
* new SSE2 optimized FLT_Sharpness_SSE2.dll included with ffdshow (dscaler sharpen)
* fixed memcpy ref. to the faster SSE2 version

2004-07-06 9:00 Andy2222

* fix for WinDVD CLSID crash
* set xvid as default IDCT
* disabled mlib AC3 decoder as default decoder

2004-06-06 8:00 Andy2222

* small fix in denoise3d filter (again)

2004-06-05 12:00 Andy2222

* small fix in denoise3d filter

PS: maybe some1 can provide a mirror? (or Athos can u copy those to your location too?)

[Shinobu]

No news about correction of vp3 decoding ?

++

[timeismoney]

Originally posted by Shinobu
No news about correction of vp3 decoding ?

++ I tried, still buggy... :( :( :(

[Andy2222]

Originally posted by timeismoney
I tried, still buggy... :( :( :(

sorry but this is a bug with the libav codec and i have a hard time to understand how ffdshow is working... i cant fix libav codec related stuff, maybe try to post this in the mplayer bug section or ffmpeg project page.

[timeismoney]

Thanks Andy2222 for your kindly post

I'd try it, but would you or athos mind to post this for us? We're just end user, sorry but I really can't find mplayer or ffmpeg project page... a little stupid, sorry...

[Guy Incognito]

Shouldn't the P4/A64 version work with Pentium M, too, since it also supports SSE2? But I get a crash on some videos with the optimized ffdshow when denoise3d HQ is turned on. The normal version works well.

[Andy2222]

Originally posted by Guy Incognito
Shouldn't the P4/A64 version work with Pentium M, too, since it also supports SSE2? But I get a crash on some videos with the optimized ffdshow when denoise3d HQ is turned on. The normal version works well.

mhh does the Pentium M support full SSE2? Those crashes only apeer if u turn on denoise3d and without it dont crash?

PS: can u tell me what is the X/Y resolution on the videos wich crash?

....oki found a little bug in the P4/A64 version if the X resolution is not divisible through 16...(fixing it soon)

[midiboy]

Hi guys !

Maybe Andy or someone else can help me with a couple of questions I am having regarding ffdshow ... would really be nice of you ! Thanks !

I am currently resizing to 1280x720 using bicubic and I am using elecard or intervideo decoder with VMR9 on FX5700, Zoom Player4 RC2.

1. Why is it that when watching DVD´s I have to set aspect ratio to "no aspect ratio correction" to get correct ratio and with media files like xvid etc. I have to set it to "keep original aspect ratio". It is kind of boring to change between those two settings all the time. Without ffdshow, everything works normal ...

2. I heard different opinions about resizing ... one group says to resize to the panel res. in order to avoid any scaling of the videocard, the other group says to resize to double PAL/NTSC and let the videocard downscale to panel resolution. Which is really better now ?

3. Different output color spaces ( YUV2/ YV12 versus RGB32 ) require totally different brightness/contrast settings on my projector when calibrating it with test patterns. For RGB32 I have to increase brightness and decrease contrast quite a bit. Since all videofiles (HDTV, MP4 etc.) seem to default to YUV2 or YV12 I use that for DVD playback also to avoid switching between different brightness and contrast settings all the time.

I was just wondering why there is so much difference between colorspaces. Some people seem to prefer RGB32 to YUV/YV12 but nobody seems to mention that difference in brightness and contrast associated with it.

By the way, whats better: YUV2 or YV12 ?

I know those may be very basic questions for this advanced thread but maybe they can still be answered especially since you guys seem to really know a lot about those things ... :cool:

Thanks,
midiboy

[Vitos]

Originally posted by midiboy

1. Why is it that when watching DVD´s I have to set aspect ratio to "no aspect ratio correction" to get correct ratio and with media files like xvid etc. I have to set it to "keep original aspect ratio". It is kind of boring to change between those two settings all the time. Without ffdshow, everything works normal ...


It's because DVD movies are anamorphic - they have resolution like 720x576 (it's for PAL), but pixel (or should I say - image) proportions like 16:9. Watching that on 4:3 PC screen without proper resizing gives wrong (vertically stretched) video. On the contrary, XviD and other PC formats have standard 4:3 ratio and doesn't need any resizing. So I suppose that "no aspect ratio correction" just parses proper ratio given on DVD, but "keep original.." treats video as 4:3...


2. I heard different opinions about resizing ... one group says to resize to the panel res. in order to avoid any scaling of the videocard, the other group says to resize to double PAL/NTSC and let the videocard downscale to panel resolution. Which is really better now ?


IMHO depends on videocard, so there's no only one answer. I'd like to know others' opinions as well for modern hardware.


3. Different output color spaces ( YUV2/ YV12 versus RGB32 ) require totally different brightness/contrast settings on my projector when calibrating it with test patterns. For RGB32 I have to increase brightness and decrease contrast quite a bit. Since all videofiles (HDTV, MP4 etc.) seem to default to YUV2 or YV12 I use that for DVD playback also to avoid switching between different brightness and contrast settings all the time.

I was just wondering why there is so much difference between colorspaces. Some people seem to prefer RGB32 to YUV/YV12 but nobody seems to mention that difference in brightness and contrast associated with it.


Again - your videocard gives various results for different colorspaces, I noticed it on my Kyro II too, but not on ATI 8500.
When working in YUY2/YV12 video is displayed according to CCIR601 norm, which restricts luminance to 16-240 range (something with analog television compatibility). In opposite, RGB modes give you full 0-255 range video (so generally more contrast).


By the way, whats better: YUV2 or YV12 ?


YV12 has lower vertical color resolution that YUY2, but since MPEG-2 and MPEG-4 are internally handled in YV12 there should be no difference in playback.

[Andy2222]

A1: this is a "bug" in the way ffdshow handels AR values...maybe we get a fix some day for this.

A2: depends on your card, i have a FX5700U too and i avoid to let the card resize since i can see "grid" artefacts if the video card resize. The "perfect" way atm would be to resize using avisynth plugin using lanczos3/4 to 2*resolution and than let ffdshow scale down using bicubic mode.
I can live with the 1 way ffdshow to native output resolution :) (just test what u like more)

A3: hard to explain, for now all u need to know is dont worry about colorspaces just set ffdshow to use yv12/yuv2 modes. There is no "best" mode, but yv12/yuv2 is the fastest mode so use it.

[Guy Incognito]

Originally posted by Andy2222
mhh does the Pentium M support full SSE2? Those crashes only apeer if u turn on denoise3d and without it dont crash?

PS: can u tell me what is the X/Y resolution on the videos wich crash?

....oki found a little bug in the P4/A64 version if the X resolution is not divisible through 16...(fixing it soon)

Yes, crash only with denoise. Pentium M has support for SSE2, don't know if it's "full".

Resolution is 360x288, so it could be the bug you mentioned.

Another problem, but it seems to exist for several versions now:

If I tell ffdshow to resize to 1024x768, the resolution is 2048x1536 in OGM files (have not tested MKV yet). At least Medial Player Classic says so and the video is very slow and CPU eating.

Edit: Without resize it still shows 1280x720 which is 2x2 the original resolution.

Edit 2: Okay, stupid me, the resolution thing is not a ffdshow bug but a DirectVobSub setting, so forget it. :-)

[marcellus]

Hi,
I have a problem with latest Andy's compiles (ffdshow-20040529a and ffdshow-20040607a -regular version, I have an Athlon XP). I use ffdshow mainly for encoding (mpeg2 and mjpeg). I use graphedit to encode avisynth files and with these releases when I hit play the graph bombs and the OS spits an error message involving libavcodec.dll. When I replace libavcodec.dll with the one that came with latest athos's compile (ffdshow-20040520) the problem is gone.

Another problem with the same compiles is one that I thought was gone some time ago - ffdshow doesn't show up in virtualdub encoding codecs list - meaning vfw interface. Is still "spaces in path" related, when I install ffdshow in a path without spaces the problem is gone.

best regards

[Andy2222]

mhh milan updated the libavcodec files to latest release from Athos latest to my releases maybe there is an error now with the updated files

[marcellus]

Sorry, I was wrong. The problem is not solved at all just by replacing libavcodec.dll. Now is not bombing graphedit anymore but mpeg2 files encoded that way are screwed in chroma. I mean chroma is frozen (taken from the first frame or something like that) and the movement is happening only in luma. I guess I have to go back to latest Athos's release.:(

[oddball]

I have an Nvidia GeForce 440 MX. On the TV out if I have a video file with a resolution larger than say 640x (704x for instance) I start getting black bars top and bottom on my widescreen TV. It does not matter that the bars are cropped on the video itself. The only way I have found around it is to resize in ffdshow to 640x anything over that res.

[Vitos]

Originally posted by Andy2222

The "perfect" way atm would be to resize using avisynth plugin using lanczos3/4 to 2*resolution and than let ffdshow scale down using bicubic mode.


What is it supposed to give? I mean - up-resizing, then down-resizing...? Can't figure out that on my own...

[Andy2222]

Resizing first using the a 2* org. resolution gives a perfect scaled image to let the filters work. If we than scale down to our output resolution by software we avoid artefacts wich could be caused by the simpler video hardware resizer.

But this is only for the videophile users with here expansive projector stuff :)

[midiboy]

Andy, Vitos,

thanks for your answers to my question !

Resizing first using the a 2* org. resolution gives a perfect scaled image to let the filters work. If we than scale down to our output resolution by software we avoid artefacts wich could be caused by the simpler video hardware resizer

Why can´t the ffdshow resizer be used twice in a row then ? Would that be possible ??

this is a "bug" in the way ffdshow handels AR values...maybe we get a fix some day for this.

I also hope someone ( you maybe ?:D ) will fix this .... :)

Thanks !
Alex

[Tommy Carrot]

Could someone provide a fresh build, because the last one is almost a month old and plenty stuff has been changed since then.

[Soulhunter]

Originally posted by midiboy
Why can´t the ffdshow resizer be used twice in a row then ? Would that be possible ??Why not using any filter multiple times ???

Already requested this multiple times... :D


Bye

[midiboy]

Could someone provide a fresh build, because the last one is almost a month old and plenty stuff has been changed since then.

Andy´s builds are very recent and can be had here (http://mitglied.lycos.de/ieggei2/ffdshow/)

I hope it is ok for him to post the URL. If not, please remove ! :)

Also I want to thank Milan for the "resize by a multiple" addon in the latest SSE2 build.

And I want to thank Milan or Andy or whoever did this for fixing the AR issue I mentioned. I think it is ok now ( gotta test some more, but at first glance it worked right )

midiboy

[pankov]

Guys, are those SSE2 builds compatible with my Athlon XP 1700+?
if they aren't is it possible to make a non SSE2 bild with the latest fixes?

Can someone also explain how to use the Remotecontrol API?
I'm a Girder user and would really like to be able to control FFDShow with the remote - especially changing the image settings presets.

[Tommy Carrot]

Originally posted by pankov
Guys, are those SSE2 builds compatible with my Athlon XP 1700+?


No, it crashes here, so i would repeat my request: Could someone share with us a fresh build?

Thanks.

[esby]

I must be missing something...

@Pankov : http://mitglied.lycos.de/ieggei2/ffdshow/
check all the file, there is a SSE2 one, and another one...

@Tommy carrot: do the same, ...

esby

PS: Of course for the blind people: http://mitglied.lycos.de/ieggei2/ffdshow/ffdshow-20040607a.exe

[arno]

Does somebody here (Andy?) know what the new mplayer "accurate deblocking" does?

[pankov]

Originally posted by esby
I must be missing something...

@Pankov : http://mitglied.lycos.de/ieggei2/ffdshow/
check all the file, there is a SSE2 one, and another one...

@Tommy carrot: do the same, ...

esby

PS: Of course for the blind people: http://mitglied.lycos.de/ieggei2/ffdshow/ffdshow-20040607a.exe
I'm not sure if your intention was to offend us but may be you should read more carefully before make any assumptions.
I saw the file that you are talking about and I can say that I have it since 08.06.2004 but the SSE2 build is 10 days newer and in the history of FFDShow this could make a big difference. If you read the changelog.txt file for the SSE2 build you will see that there are a few important fixes that are after 07.06.2004 and those are fixes that I would like to use on my Athlon XP which doesn't support SSE2.
So I second my request for a non SSE2 build with the latest fixes

[Tommy Carrot]

Originally posted by esby
PS: Of course for the blind people: http://mitglied.lycos.de/ieggei2/ffdshow/ffdshow-20040607a.exe

I forgot to say this is not good for me, the most important changes (to me) were done after this build.

[crlorentzen]

latest version crashes my Media Player Classic 6.4.8.2, http://mitglied.lycos.de/ieggei2/ffdshow/ffdshow-20040616_SSE2.exe

using full deblocking and automatci adjustment, as well as some level adjustments.

[Andy2222]

Originally posted by crlorentzen
latest version crashes my Media Player Classic 6.4.8.2, http://mitglied.lycos.de/ieggei2/ffdshow/ffdshow-20040616_SSE2.exe

using full deblocking and automatci adjustment, as well as some level adjustments.

What cpu u have? Are u sure u have a SSE2 capable cpu? Since for me all works fine in Media Player Classic 6.4.8.2.

@Tommy Carrot sorry but im concentrating on my sse2 version atm, no clue what happend to Athos builds, maybe he is in Holiday or work trouble. If i release my new sse2 version i will compile a new normal version too.

[pankov]

Originally posted by Andy2222
...If i release my new sse2 version i will compile a new normal version too.
Great
:)
Looking forward for a new release

[Tommy Carrot]

Ditto. :)

[crlorentzen]

CPU in sig... Northwood-B P4.

[Defiler]

Even though many of my CPUs are SSE2-capable, I am worried about this semi-fork into SSE2/non-SSE2 versions.
After it's all working, can it just use the CPU feature flags to determine which instructions to issue?

[Andy2222]

Originally posted by Defiler
Even though many of my CPUs are SSE2-capable, I am worried about this semi-fork into SSE2/non-SSE2 versions.
After it's all working, can it just use the CPU feature flags to determine which instructions to issue?

For now the SSE2 version just run on SSE2 CPUs. I was thinking about merging the SSE2 code into the normal version but since im working torward a 64bit AMD64 version based on the SSE2 version it would cause more trouble and debug problems.
I dont think its this hard to choose what version u download... we all do this for drivers and other programms. (the code size is also reduced since the SSE2 version dont need the mmx or mmx2 versions)
The other advantage is that i can compile the normal c++/c code for better sheduling on P4/AMD64 cpus since the normal version is still a i586 compile.

[Defiler]

Think about codec packs, though.. If there are two versions, the installer has to choose which one to install automatically, which isn't simple. Imagine if there were four or five different versions of XviD, each with different supported CPUs..

[Neo Neko]

Originally posted by Defiler
Think about codec packs, though..

Id rather not. Codec packs are bad and really should be avoided at all costs. It is a crutch that helps perpetuate user ignorance and can by the actions of a few unscrupulous packers cause problems acrost tons of systems. With the advent of FFMPEG/FFdshow which is practically a codec pack in and of itself you don't really need codec packs.

Originally posted by Defiler
If there are two versions, the installer has to choose which one to install automatically, which isn't simple. Imagine if there were four or five different versions of XviD, each with different supported CPUs..

Ffdshow and Xvid are not specifically coded to any cpu. Meaning that anyone could whip up a version that would play on all pentium or better CPUs. So creating CPU specific compiles is not going to hinder the less educated who use codec packs or those that facilitate them. They just will not get the best performance possible. But they make themselves incapable of getting the best performance even from a general compile. So they loose out any way you look at it. But they only have themselves to blame.

And as stated all the optimisations could be worked back into a general compile.

[TripleA]

Originally posted by Neo Neko
Id rather not. Codec packs are bad and really should be avoided at all costs. It is a crutch that helps perpetuate user ignorance and can by the actions of a few unscrupulous packers cause problems acrost tons of systems. With the advent of FFMPEG/FFdshow which is practically a codec pack in and of itself you don't really need codec packs.


Yes indeed.

Except that some people don't really care what CPU they have, let alone what instructions it supports. In fact, many of them don't know what an instruction is. They just want videos to work when they double click them. And with so many CODECs out there, CODEC packs are inevitable and, when well done, a godsend. Such as Defiler's pack. Please don't listen to the nay-sayers, Defiler, I await the next version...

But should a computer user know such technical details as what CPU s/he has?

I used to think that they should. In fact, years back I used to say that anyone who doesn't know what CONFIG.SYS is shouldn't own a PC (a Mac, of course, wasn't a PC for me back then). But I'm increasingly of the opinion that a PC is just another thing to use. Like a car. Certainly not all people should be mechanics to drive cars...

Just IMHO...

[Koepi]

Show me the free fuel and oil for your car!

As long as it's free, you've nothing to complain about but should be grateful ;) The free service man at the gas station will ask you "may I give you leaded or unleaded fuel?" and you should know that. Even if you're no mechanic.

SCNR, it always happens if I find these analogies...

Regards
Koepi

[TripleA]

Who's complaining? ;)

I'm just saying that CODEC packs aren't Evil.

Edit: But really, even I, who claims he knows these things and are at home with datasheets, find I sometimes have to pause and think when someone asks me if a specific processor supports a specific instruction set (i.e. "Does the Centrino support SSE2?")... So what chance do "normal people" have?

[Koepi]

Normal people have a (short) manual for their computer as well as for their car, they just have to look that up.
And (the place where you put the fuel in, don't know the word in english) has a sticker close to it telling you that also. (Well, no such stickers on computers, but some system info tool like "start -> settings -> system settings" will bring up a dialog where you can see which processor is in your computer and which extensions it supports. A shortcut would be to right-click on "work place" (is it called like that in english windows?) and select "properties". There you have the same dialog.

Of course, this is only valid for win2k/winxp, but i expect people with minor computer knowledge to use those (more XP than 2k I have to admit ;) ).

Regards
Koepi

[LigH]

At least there are codec packs which change more in the registry than necessary (which may even destroy some playback or conversion ability), and there are people who do not use, but abuse them (by mindlessly installing each and every codec and filter). ;)
__

Right-click on the "My Computer" icon on the desktop, select "Properties".

[jimmy basushi]

Originally posted by TripleA

But should a computer user know such technical details as what CPU s/he has?


If they have a question about something why cant they just look at manuals? It isnt hard for me to read an english manual, and im not even a native english speaker or really smart. You dont have to be, you just have to not be ignorant and take the time to learn more instead of living in your little bubble of "it should just work because i want it to work". Anyone who cant or wont take the time to read a manual, really shouldnt be using whatever that manual is for.

[Coroner]

Originally posted by jimmy basushi
If they have a question about something why cant they just look at manuals? It isnt hard for me to read an english manual, and im not even a native english speaker or really smart. You dont have to be, you just have to not be ignorant and take the time to learn more instead of living in your little bubble of "it should just work because i want it to work". Anyone who cant or wont take the time to read a manual, really shouldnt be using whatever that manual is for.

Exactly. I agree completely.

[TripleA]

Well, obviously I am mistaken then.

Only assembly programmers should be allowed to own PCs.

CODEC packs are of the Devil and all authors of such abominations must be burnt at the stake/stoned to death.

BTW, Windows will tell you what CPU you have, if you're lucky. But it will not tell you what it does(n't) support. And will certainly not tell you if it supports it correctly/fully (i.e. iSSE vs. SSE).

[Koepi]

You're right, win2k doesn't tell you about the extensions supported, then this was only valid in windowsxp (don't have that installed here anywhere so i can't check).

For the rest, where should that sarcasm lead to? Make your point more valid? Certainly not.

It's not too much asked to know/to look up which extensions are supported by your computer's cpu, there are simple tools for that (aida / everest home / 3dmark03 / ... stuff that even people without any knowledge use).

Koepi

[TripleA]

You're wrong.

I have Windows XP here. It tells me that I have an "AMD Athlon(tm)" and nothing more.

Which might be OK, except I have an Athlon XP...

The sarcasm is for entertainment. It should not be required to validate my point.

Edit: As it would happen, my cousin just called me: "We just installed this game and it keeps telling us that our computer doesn't support MMX. What is MMX?". I just told her they need to buy a new PC, of course. But I wonder what I would have done had the game not given an error and exited gracefully.

Edit: And before someone jumps to tell me his/her Athlon XP is recognized fine by Windows XP; the point isn't that Windows will always mis-identify the processor, the point is that it won't always identify it.

Not that identifying the processor is enough: assume you somehow know that you have a Duron, what, exactly, does that tell you about SSE support?

[zwahri]

To comment on the whole 'what users know' thing:

USERS DON'T KNOW ANYTHING.
USERS ARE STUPID.
USERS DON'T WANT TO KNOW WHY AND HOW SOMETHING WORKS.

The last year or so should've made this point perfectly clear. Think of any major virus/trojan/worm out there - even the mass media were reporting them and nobody really cared. In fact, of the users I know (which happens to be quite a lot) don't even know about firewalls and virus scanners, at best they've heard the terms before.

Most users want it to simply work. Nobody wants to think anymore. I could tell at least a dozend users who wanted to play movies out of the box but didn't even know what CPU, RAM and GFX-card they owned. The only thing they can tell you is 'I have XP' - and that's only because it's clearly shown at boot time. If I'd change someone's bootlogo and ask him again certainly he'd tell me "OS/2 Warp 4.0".

And we are talking about codecs & filters here - that's software nobody has ever seen or used directly because it's all done inside your favourite video player.... Don't expect the impossible of the typical Windows user, even advanced ones have trouble with that and resort to those ugly codec packs ;)

So, what's my point? I want those optimizations, because they are really useful. I want ffdshow, because it's exactly what those user's want: It plays everything regardless what codec was used right out of the box. But if you're going to release 5 different versions, that'll only confuse users. Make it auto-detect, and that's it.

Sorry, I just couldn't shut up,
Z

[TripleA]

Originally posted by zwahri

USERS DON'T WANT TO KNOW WHY AND HOW SOMETHING WORKS.


Just one simple "correction": "something" -> "anything". ;)

[marcellus]

This is getting OT, but here is my opinion:
But if you're going to release 5 different versions, that'll only confuse users.
Why worry? Well, users got to catch up. I think a clear and visible explanation/help file should be enough. If some user is blind or lazy why everybody else have to suffer? I mean developers are working hard to make a program work better and faster so users should at least read a readme.txt and make some effort on their own.

[Andy2222]

bahhhhh STOP this crazy talk pls.... i will try to implement a CPU detection in the installer, so that ffdshow wont install on wrong systems, maybe i can include both versions in 1 package and the installer check and choose the files automatic :)

[Defiler]

If the people posting in this thread don't need to know the intimate details of fonts and typography in order to write a message, I don't see why the average user needs to know what SIMD method their CPU supports. Thanks for your contributions, Andy2222. I won't say any more on this topic, since I don't want to cause a derailment.

[dimzon]

Originally posted by Defiler
...I don't see why the average user needs to know what SIMD method their CPU supports...
:goodpost:

[Neo Neko]

Originally posted by TripleA
Yes indeed.

Except that some people don't really care what CPU they have, let alone what instructions it supports. In fact, many of them don't know what an instruction is.

And those people have always had the general ffdshow versions. These CPU specific versions are rather new and are for those of us that do know and care. There will always be general compiles avalible for those who wish to make codec packs.

Originally posted by TripleA
They just want videos to work when they double click them. And with so many CODECs out there, CODEC packs are inevitable and, when well done, a godsend. Such as Defiler's pack. Please don't listen to the nay-sayers, Defiler, I await the next version...

But my point with ffdshow is it makes most codec packs redundant. What excatly is it that the codec packs provide that ffdshow does not? I can't see much if anything. Outside of perhaps container specific filters like OGG or MKV. 4 years ago it was quite an ordeal to track everything you needed down. For instance no one divx codec would play back all divx content. Now one codec can play back all divx content as well as Xvid, 3ivx, Mpegable, etc. And ffdshow goes further. VP3, Theora, DV, MPEG1 2 &4, Indeo, and many more you likely never heard of.

Originally posted by TripleA
But should a computer user know such technical details as what CPU s/he has?

Hell yes. On top of that they should know what OS and waht version specifically they use. Have you ever asked anyone what OS they use only to have them respond internet explorer 6? This whole dogma that users should not need to know about their systems is the reason so many people have problems with their systems. Knowing processor type and OS version should be basic knowledge. People should not feel intimidated by their computer.

Originally posted by TripleA
I used to think that they should. In fact, years back I used to say that anyone who doesn't know what CONFIG.SYS is shouldn't own a PC (a Mac, of course, wasn't a PC for me back then). But I'm increasingly of the opinion that a PC is just another thing to use. Like a car. Certainly not all people should be mechanics to drive cars...

Should all drivers know traffic laws? Should drivers know about changing the oil to some extent? Airing up tires? What sort of gas to use? We are not talking about putting a system together by hand. We are talking about checking the computers fluids, kicking the tires, and performing basic matinance. And even putting a system together is nowhere near as complex as working on a car. So why is it that we require people to know so much when they drive a car which at worst in generall injures a few. But when it comes to computers we expect them to have to know nothing and it could bring an entire economy and culture to a halt and stand to kill thousands? I'm serious. As computers and the internet prolifferate at some point you are going to need an internet license. The license would require you to obey the rules and regulations of the information super highway. Including things like safe computing procedures, hardware/software matinance, patching, etc. You would not have to have a license to own a computer just as you don't need a license to own a car. But if you are going out into public spaces where you can endanger the public like the internet I think some education is in order. I am all for Internet Highway Patrol who could pull you over and say.

Did you know your port 23 was open? Oh and we caught you littering a way back. About 500 pieces of spam. I'm gonna have to give you a fine. Have a nice day and remember. Keep our Information Superhighways clean and don't spam.

How many people would instantly snap to attention and watch their PC like hawks if they could get fined or even banned from it for bad computing practice! If that bill comes up I am all over it. It would be an excelent thing. ;)

[Hiro2k]

I sure hope they don't require users to have a liscence. Then I'd be out of a job! I fix computers on a daily basis and sometimes it is a serious hardware malfunctions, but most of the time it's spyware/spam/virus problems. All of those could be fixed by simply updating there scanners and not downloading stupid software, but people are ignorant. And they pay me to fix it. I like the system the way it is ;)

[Neo Neko]

Originally posted by TripleA
Who's complaining? ;)

I'm just saying that CODEC packs aren't Evil.

No one here did. Just that they were bad in general. And that most codec packs have caused bigger problems than they solved. And that most of them have become redundant in recent history. There will always be a niche for codec packs. Just as there will always be a niche for malware. Not that the two are synonimous.

Originally posted by TripleA
Edit: But really, even I, who claims he knows these things and are at home with datasheets, find I sometimes have to pause and think when someone asks me if a specific processor supports a specific instruction set (i.e. "Does the Centrino support SSE2?")... So what chance do "normal people" have?

Centrino has nothing to do with MMX, SSE, or SSE2. Because Centrino is not a processor. It is the greater package. Pentium M is the processor. And if you can type "processor instruction set" in google you will get links to many many programs that will diagnose and tell you exactly what CPU you have and what it can do. So simple my father can do it. Sure users are fairly stupid in general, but only because we allow them to. It's going to have to change. ;)

[Neo Neko]

Originally posted by Hiro2k
I sure hope they don't require users to have a liscence. Then I'd be out of a job! I fix computers on a daily basis and sometimes it is a serious hardware malfunctions, but most of the time it's spyware/spam/virus problems. All of those could be fixed by simply updating there scanners and not downloading stupid software, but people are ignorant. And they pay me to fix it. I like the system the way it is ;)

I doubt you would be out of a job. In fact you might have a much more in demand job. Imagine how many people out there have computers crawling with nasties and are totally unaware? Now imagine if they were required to be aware. Not that they should have to know how to fix it themselves. But know it is there and needs to be fixed. At which point they take it to you. Have mechanics and auto body shops disappeared since people were required to be licensed to run on public roads? An Internet License is quite possibly the single biggest boon the tech support industry may ever see! Beyond increasing the ammount of work for repair people it would create new jobs as well. With the recent attacks on akami I think it is not an unreasonable request.

[Defiler]

I lied. Here's another post. :D

Installing ffdshow does not address:
Audio playback (AAC, AC3, Vorbis, etc.)
Matroska support
Ogg Media (OGM) support
Working subtitle support

Furthermore, roughly half of the released ffdshow versions have major incompatibilities with certain popular codecs. Even if ffdshow were the only thing worth installing, there would be a 'market' for pre-tested ffdshow builds.

Furthermore, various of the other components required have semi-complex requirements themselves: VSFilter and Matroska Splitter have different builds for Win9x and WinNT systems, several of these things require the Visual C++ runtimes which most users lack, etc. Also, many users are on dialup, and the DefilerPak (chose the name as a joke, but it caught on. Heh.) is about half the size of all the component installers taken separately.

I'm not claiming that codec packs are amazing works of art.. but deciding on your own that users should know all sorts of technical details before being allowed to watch video just shows that you don't understand the whole market. The tens of thousands of DefilerPak users aren't stupid. They just have better things to do with their time.

Finally, this whole side-conversation started precisely because there ISN'T currently a non-SSE2 build of ffdshow that includes the latest fixes. Currently, this statement is not true: "There will always be general compiles available for those who wish to make codec packs."
However, I'm glad to hear that this will continue to happen. That's all I care about.

I normally try not to talk about codec packs on Doom9. Sorry for doing so accidentally.

[Neo Neko]

Originally posted by Defiler
I lied. Here's another post. :D

Installing ffdshow does not address:
Audio playback (AAC, AC3, Vorbis, etc.)

Don't be so sure. Some of Athos's recent compiles have offered AC3 and even AAC decoding. And it works.

Originally posted by Defiler
Matroska support
Ogg Media (OGM) support

Granted. But that is not much. And alot of people don't yet use those unfortunatly.

Originally posted by Defiler
Working subtitle support

When did it stop working? Sure VSfilter is better. But it works. ;)

Originally posted by Defiler
Furthermore, roughly half of the released ffdshow versions have major incompatibilities with certain popular codecs.

Really? Which ones. There is a VP3 decoding issue and a huffyuv encoding issue. Anything else? Last I tried it worked fine with all my Xvid and Divx encodes. It decodes Mjpeg and Huffyuv fine as well. And users don't absolutely need the latest greatest ffdshow cvs and test binaries. Honestly the last stable build over at source forge is highly adequate for most people. I can't wait till Milan releases another stable build.

Originally posted by Defiler
Furthermore, various of the other components required have semi-complex requirements themselves: VSFilter and Matroska Splitter have different builds for Win9x and WinNT systems, several of these things require the Visual C++ runtimes which most users lack, etc. Also, many users are on dialup, and the DefilerPak (chose the name as a joke, but it caught on. Heh.) is about half the size of all the component installers taken separately.

That's life. And that is the history of computer software back into time immemorial. And it is NEVER going to change. Personally a user should be able to tell if they are running 9X or NT. I mean the 9X versions say 9X at every boot up. And last I saw all NT versions including NT5.1(XP for the lay people) say NT on boot up. If a user does not know or can not find out that is pretty sad. :P But then again so is thinking IE6 is their OS. And they do that.

Originally posted by Defiler
I'm not claiming that codec packs are amazing works of art.. but deciding on your own that users should know all sorts of technical details before being allowed to watch video just shows that you don't understand the whole market.

I understand the world, and the Microsoft market as you describe it. Where the user should not have to know anything. Look where that has gotten us. :D The average computer user is giving their system over to organised crime for it's own nefarious purposes from mass unsolicited direct mailing to distributed attacts against key internet infrastructure as seen recently. There is not that much in ffdshow that beginners would have to configure. But it is there when they are ready.

Originally posted by Defiler
The tens of thousands of DefilerPak users aren't stupid.

No one said they were. Ignorant is something else. But not always a bad thing. I admit there are times when an all in one pack could be nice. But you just have to live with the fact that many people are jaded and rightly so against codec packs. Having said that nothing I have said here has been about you or yours specifically. Just codec packs in general. They are just an outmoded paradigm.

Originally posted by Defiler
Finally, this whole side-conversation started precisely because there ISN'T currently a non-SSE2 build of ffdshow that includes the latest fixes. Currently, this statement is not true: "There will always be general compiles available for those who wish to make codec packs."

Not true. Compile it yourself. Or ask athos nicely if he will. No one has to do anything special to make vanilla compiles. So rasing a ruckus when someone does do special work is counter productive.

Originally posted by Defiler
I normally try not to talk about codec packs on Doom9. Sorry for doing so accidentally.

No problem. ;)

[TripleA]

I understand what you're saying, Neo. And in another age I would even have agreed with it. But I now think things should not be so complex. Sure, it would be better if every computer user knew everything about their computer, but they don't. And the way things are headed now, tomorrow's users will know less than today's. But I would still like them to have a pleasant computing experience.

Sure, some CODEC packs cause problems. But that only means, IMHO, that one of the better ones (i.e. Defiler's) should be upgraded to semi-official status. Because, why do you think so few people use Matroska? Certainly it's technically superior to AVI. But to open MKV files, the user needs to install an extra filter just one time on the very first run and it will run for the rest of Windows' life. This very simple act, further complicated by need to install a different filter for each of WinNT & Win9x, is the single biggest hurdle, IMHO, in the way of Matroska's widespread adaptation. If the user only had to double click a single icon to get support for everything, this problem would disappear. Or at least get smaller.

Sure, it would be better if the user knew things and acted on that knowledge. But the choice isn't between the user using CODEC packs and the user acting knowledgeably, it's more like between the user using CODEC packs and the user walking away from you.

I would like to eventually see the light of open source spread to the darkest corner of every last HDD on the planet (i.e. Bill's personal PC ;)). And yet I see users lured away by the glamour of simplicity and ease-of-use. At first, I technically didn't understand the decision: "But it takes away your control of the machine!", I screamed. Then slowly I saw that they never had control of their machines. I had control, and I'm still free to retain it. But to normal users the choice is between being able to use their machines to produce something and spending the day on the phone with tech-support.

This has gotten quite far from ffdshow and I believe it's time to pull the reins a bit: like it or not, ffdshow is one of the highlights of open source. It's expected to be perfect and it's expected to "just work", not only as commercial software does, but even better. I understand Koepi saying "But it's free! And the developer isn't required to cater to the users' every whim", for truly the developer isn't required to do anything. Indeed, free software developers retain the right to walk away at any moment. At the very least, they leave behind a heap of source files so a later developer can take up the banner without having to re-invent too many wheels; and that, IMHO, is much better than what the best closed source software can provide (where's QEMM? Helix's DiscMinder? PCTools? All buried somewhere in Symantec). So, while indeed the developer(s) of ffdshow aren't required to provide perfect software, their software is close enough to perfect that it's expected to be. This is an accolade to be treasured: it's no longer "geeks'" software, it's software for the unwashed masses.

I sincerely hope the distinction I'm trying to make and my message are clear enough, or I'm in for a rough ride ahead ;).

In any case, back to the context of this particular SSE2 build of ffdshow, it indeed is an early development build. Most probably not fit for public consumption, actually. And I'm sure that the code would later have been merged with the one-size-fits-all ffdshow we all love once it got close to final and it was shown that it does indeed work. So perhaps this whole line of conversation is a bit pre-mature. But really, this thread looks from where I'm sitting to be 30 40-post pages long. That's a heck of a lot of posts, and I'm sure a few more wouldn't hurt anyone... ;)

P.S. I know Centrino is the platform, but people see ads for Centrino laptops and Pentium 4 laptops, at least in my part of the world. Can you guess what they assume Centrino to be...? In any case, I was quoting an actual recent question. And I did, indeed, have to pause and think before answering. But, perhaps significantly, I did not bother to correct the mis-conception regarding Centrino...

Edit: Grammar, grammar, fancy grammar.

[m0rbidini]

Anyone who has done some kind of end-user support on a daily basis about these issues knows that codec packs are evil for end-users. A big percentage of complaints come from users that installed them. ffdshow doesn't usually conflict with nothing. It's the codec packs that do those things, at least most of them.

When I have end-users (when I say end-users I'm referring to those who have little knowlegde about this stuff) asking me how to solve their DivX/XviD playing problems (and most of them don't wanna know about Matroska or OGM, cause most of them don't have these kind of files) I just say:

- remove all codec packs from your system;
- remove all DivX/XviD codecs from your system;
- reboot and make sure they were uninstalled;
- install ffdshow (link to one site that usually has the latest builds);
- install Media Player Classic (even if it's just for testing; some players - not all - complicate this for the end-user);
- (Optional) explain that ffdshow has subtitles support and how to use it;

Normally this solves all their problems.

End-users that need Matroska and/or OGM support can also use MPC (it has splitters for both). If they don't like MPC then I just link them to the latest Matroska Splitter and/or OggDS 0.995, respectively. Etc, etc.

I'm not saying that this is the more correct way of treating this, from a "pedagogic" point of view. This may not be the only solution (I can also recommend installing the XviD and/or DivX's decoders instead of just ffdshow, but I usually prefer this way) 'cause some may prefer DivX/XviD standalone decoders and/or other players. But it's better than just give them a codec pack, 'cause if something doesn't work it's much harder to find the culprit.

Cya

[crlorentzen]

Originally posted by Andy2222
What cpu u have? Are u sure u have a SSE2 capable cpu? Since for me all works fine in Media Player Classic 6.4.8.2.

Just wanted to make sure you saw it, all pertinant infomation on my computer alwasy been displayed in my SIG, but since you couldn't see it here it is...Intel Pentium 4 Northwood-B 2.66Ghz 533Mhz FSB (133x4, quad pumping you know).(someone please tell me I am not crazy, this chip supports SSE2 right? SiSoft has always said soo)

anyways I just reinstalled the lates SSE2 Compile (ffdshow-20040616_SSE2.exe) and am testing, it seems SPP Deblocking crashed MPC 6.4.2.8 always.
1. All other sections unchecked
2. Set slider to zero
3. Selected SPP Deblocking
4. move slider up one.
5. release
6. MPC Crash

SPP looks terrible too in this build...
ffdshow-20040607a.exe, no problem just very slow on SPP.
ffdshow-20040520-p3.exe, no problem just very slow on SPP.

tested in DivX 5, XviD , MP43, DivX3.11a...all crashed MPC. (ffdshow-20040616_SSE2.exe)

any ideas? Nvidia Driver version 60.85 WHQL certified every other driver completely up to date.

[Andy2222]

So only SPP deblocking crash your mpc?

Its useless atm anyways, maybe i take a look if i have time. Im about to finish the resizer work and will release a new test version "soon". I made many alignment changes and hopefull i solved all memory crashes this way. I need some more time to finetune the new code for max. performance but in general im happy with the improvements.

The main advantage (except for the better speed) will be the fixed parameter setting wich allows to choose what tap deep in lanczos/bicubic mode u want. U can choose from Lanczos1 over Lanczos4 to Lanczos10 if u want :)

I also changed some default parameters and u can choose a very fast 4 tap bicubic mode wich will look good for most ppl.

[crlorentzen]

Thanks Andy, just note SPP Deblockling only crashes MPC with the 20040616_SSE2 release.

and I would still like someone to conferm I am not crazy that my CPU has SSE2 Support.

[smokeslikeapoet]

A P4 has SSE2 support. If you have any question about the capabilites of your CPU any benchmarking or system diag utility should. I use Sisoft's Sandra (http://www.download.com/3000-2086-10264518.html). A nice little freeware app called CPU-Z (http://www.cpuid.com/cpuz.php) will show you your supported instruction sets, too. I have an Athlon 1800+ so I'm going to try the P3 SSE compile.

[esby]

you could use avs2avi, now DGIndex (dgmpgdec),
and check the help>SIMD menu...

it will show you the list of instruction available for your cpu...

esby

[crlorentzen]

Originally posted by smokeslikeapoet
A P4 has SSE2 support. If you have any question about the capabilites of your CPU any benchmarking or system diag utility should. I use Sisoft's Sandra (http://www.download.com/3000-2086-10264518.html). A nice little freeware app called CPU-Z (http://www.cpuid.com/cpuz.php) will show you your supported instruction sets, too. I have an Athlon 1800+ so I'm going to try the P3 SSE compile.

tank you...I had used SiSoft and had seen it marked...but I wanted someone else to confirm. I was kindof annoyed about the post asking me what CPU I have when it was in my Sig, just wanted to drive the point home...sorry all for wasting time and being a little mean.

[HeadlessCow]

Showing signatures is an option. Given the profusion of retarded signatures that people use...it's also a nice option to have turned off :-p

[P0l1m0rph1c]

Originally posted by esby
you could use avs2avi, now DGIndex (dgmpgdec),
and check the help>SIMD menu...

it will show you the list of instruction available for your cpu...

esby

er... avs2avi != DGIndex. Maybe what you meant was DVD2AVI.

[esby]

yeah, you are right, i meant dvd2avi :)

esby

[Andy2222]

Originally posted by smokeslikeapoet
I have an Athlon 1800+ so I'm going to try the P3 SSE compile.

There is no SSE version, ffdshow dont use SSE code only mmx and mmx2 :) but try whatever runs fine for u.

[crlorentzen]

Originally posted by Andy2222
There is no SSE version, ffdshow dont use SSE code only mmx and mmx2 :) but try whatever runs fine for u.

Andy, I think someone else has done p3 compiles. Maybe it is not SSE...but they are marked as p3,and since p3 supports MMX, MMX2, and SSE...maybe he made some changes to make use of SSE.

EDIT: http://athos.leffe.dnsalias.com/ (Athos apparently compiles what he brands as p3) http://athos.leffe.dnsalias.com/ffdshow-20040520-p3.exe for instance

[Andy2222]

ah u refer to Athos P3 versions, yes he did release a "/G6" or so calles "P3" compiled version. There are no special changes for sse or P3 the compiler just "try" to shedule some instructions better for P3 compatible cpu's. If it runs faster for u use it :)

[athos]

I also used /QxK, which supposedly uses P3-specific instructions. Dont expect any real world differences though.

[SeeMoreDigital]

Nice to see you back athos :D


Cheers

[jerry07]

there are the latest no sse and sse1 version at this japan website
http://www.h7.dion.ne.jp/~moroheiy/

[Tommy Carrot]

Originally posted by jerry07
there are the latest no sse and sse1 version at this japan website
http://www.h7.dion.ne.jp/~moroheiy/

Damn, finally a new build, and i cannot use it cuz it doesn't appear in the virtualdub (apparently the "installer doesn't like win98" issue). :mad:

[Andy2222]

Originally posted by Tommy Carrot
Damn, finally a new build, and i cannot use it cuz it doesn't appear in the virtualdub (apparently the "installer doesn't like win98" issue). :mad:

Its nice to see some1 else is also compiling fresh versions, but i dont know why they label it SSE and SSE2 since there are no code changes compared to the normal MMX/MMX2 compile. Those are prolly G6 (P3) and /G7 (P4) compiles, wich wont make any diff. at all.

The problem is that those versions are also fully Visual Studio compiles wich disable all the gcc inline asm, in fact if u use the resizer the code is 1000% slower wich also apply to the postprocessor and other mplayer routines.

The best would be that Athos release a new build? I still have some tests to run before i can release a new version.

[Lobuz]

@athos
Just remember that ffdshow-20040520-p3.exe was corrupting some of video while decoding. I think that was qpel+Bframes or qpel+GMC(I can't test now cause my AthlonXP is fried). So it's advisable to use some optimisations with caution.

Regards
Lobuz

[athos]

New build. i686 target, install path patch, OM patch, skals mpeg4.
Download and changelog, see my sig.

[Defiler]

Originally posted by athos
New build. i686 target, install path patch, OM patch, skals mpeg4.Excellent. Thank you.

[ViCroié]

WHOAAAA, great new accurate deblocking :D

it's GREAT!

Thx allot :thanks:

[Andy2222]

also new SSE2 build

here are some additional hits to the new version

Hint:
The Parameter setting in the resizer tab direct influence the filter/tap deep and wich internal routines are used.
For Lanczos the parameter choose the mode/tap deep
(3 = lancsoz3, 4 = lancsoz4, 5 = lancsoz5 ...)

Speed tips:
1: use a filter (level/denoise...) before u resize to force max. performance
2: The new default Bicubic setting is a special tuned setting, for best performance dont change the parameter.

3: Dont go higher than 4 aka Lanczos4, or slower internal routines are used.
4: in Bicubic mode dont set Luma sharpen higher than 1.60 or slower routines are used.
in lanczos3 mode dont set Luma sharpen higher than 0.62/0.82 or slower routines are used.
in lanczos4 mode dont set Luma sharpen higher than 1.20 or slower routines are used.

5: avoid using Chroma sharpen, if u do dont go over 1.20 or slower routines are used.
6: always try to output YV12 colorspace at the output pane
7: Spline & Sinc use slower, lesser optimized routines so avoid those modes.

So mainly use bicubic with the new "default" setting and only Luma sharpen (0-1.6).
Lanczos3 and Lanczos4 are also well optimized, but anything higher is not, like Lanczos with parameter higher than 4 or Spline/Sinc, avoid those modes.

PS: bugs/crashes ... per private message pls. Also gimme some feedback on the resizer speed on P4 since i could not test the code on a P4.

[masken]

Is there any chance of improving the installer so that it supports silent installs? (/Silent switch for example).

...and perhaps also return an errorcode upon failure.

Perhaps also some additinal switches, like:
/DisplayProgress
/PostProcessing:[0-6]
/AutomaticQualityControl
...etc.

Or alternatively, the HKLM keys explained so one could just import values silently after an install to set the preferences.

[Blight]

Nice work andy.

Any chance that the Frame Rate Doublers could be detached from the deinterlacers? There are a few cases you would want both at the same time.

And something completely inventive... How about removing all the categories and making the whole thing object oriented, so you can simply add a "resize" object, then another effect and another resize, etc... So you can create a customized effect queue with multiple effects of the same category.

[Andy2222]

Originally posted by Blight
Nice work andy.

Any chance that the Frame Rate Doublers could be detached from the deinterlacers? There are a few cases you would want both at the same time.

And something completely inventive... How about removing all the categories and making the whole thing object oriented, so you can simply add a "resize" object, then another effect and another resize, etc... So you can create a customized effect queue with multiple effects of the same category.

um, i understand what u mean, but thats work milan need do. I feel more comfortable in the inner core :) aka asm code. I realy like to shake my head around how i can fit datas in registers or what instruction to use and to reoder stuff.
I dont have this much expierence with big object oriented projects, so i will stick with little optimisations and bugfixes and let Milan do the big math :)
My next big goal is a working 64bit version. I like the challenge and i bet this will a funny thing to do and i can learn lotsa stuff :)

[athos]

Blight, I think that's is a really cool and useful idea! Perhaps the best way to implement it would be a new project which takes ideas and code from ffdshow/ffmpeg/mplayer etc? Because I think it would be too much of a rewrite of ffdshow, it might just be easier to start over. But it is an exciting idea.

[LoopDeMack]

Bug in new ffdshow or ????
In some xvid movies I got only gray picture, in my collection I found 7 xvids not compatible with latest ffdshow-20040616_SSE2, I tried with ffdshow-20040701_SSE2 and its same ,if I try to use xvid trough ffdshow instead of libvacodec its fine or if I use some older version of ffdshow.
P4,2.8c/win200pro/Nvidia5600/Starstorm detonators 56.72/

[pankov]

@Athos & Andy
Guys, can you make a non SSE2 build that will include this very needed bugfix and a usefull feature?
2004-07-01 Andy2222 (ffdshow-20040701_SSE2.exe)
...
* fixed "green" shift resize bug
* new default Bicubic Parameter, wich force a faster internal routine (only with the new default parameter)
...

I don't know why but this "green" problem is veeeery visible on my TV and it kills the pleasure of watching movies

[Andy2222]

Originally posted by LoopDeMack
Bug in new ffdshow or ????
In some xvid movies I got only gray picture, in my collection I found 7 xvids not compatible with latest ffdshow-20040616_SSE2, I tried with ffdshow-20040701_SSE2 and its same ,if I try to use xvid trough ffdshow instead of libvacodec its fine or if I use some older version of ffdshow.
P4,2.8c/win200pro/Nvidia5600/Starstorm detonators 56.72/

small fix pls test if this fix your problem

changelog:

2004-07-02 Andy2222 (ffdshow-20040701a_SSE2.exe)

* more robust/compatible compiling options for libavcodec.dll & mplayer.dll

2004-07-01 milan_cutka

* logoaway processes chroma planes
* MSS2 support in VFW

[bond]

the problems with cabac have been fixed in the ffmpeg h.264 decoder and it should be stable to use now. time for updating libav used in ffdshow :)

[LoopDeMack]

Originally posted by Andy2222
small fix pls test if this fix your problem

changelog:

2004-07-02 Andy2222 (ffdshow-20040701a_SSE2.exe)

* more robust/compatible compiling options for libavcodec.dll & mplayer.dll

2004-07-01 milan_cutka

* logoaway processes chroma planes
* MSS2 support in VFW

Now, its ok.

See you, m8y.

[Andy2222]

Originally posted by bond
the problems with cabac have been fixed in the ffmpeg h.264 decoder and it should be stable to use now. time for updating libav used in ffdshow :)

Milan is a fast devil :)

here is your fixed version

2004-07-03 milan_cutka (ffdshow-20040701b_SSE2.exe)

* updated libavcodec - h.264 decoding fix,
* support for AVC1 FOURCC - official FOURCC for mpeg4 avc video

[Tyrael911]

have u guys stopped releasing p3 optimized versions?
the last one is from 05-20 and it crashes on some xvid movies, as Lobuz said before...

[dahlgren]

maybe stupid question or it doesn'r belong here, but:

how can i use pan & scan with zoomplayer+ffdshow?

[bond]

Originally posted by Andy2222
2004-07-03 milan_cutka (ffdshow-20040701b_SSE2.exe)

* updated libavcodec - h.264 decoding fix,
* support for AVC1 FOURCC - official FOURCC for mpeg4 avc video hm it crashes here in ffdshow.ax, no matter what content i try to decode with it :(

[Andy2222]

mhh what CPU u have and does it also crash on simple divx5 or xvid if u try use libavcodec? Can u test if u can use the normal xvid decoder and ffdshow as raw filter without crash?

...this is realy bs, why i never get those crashes while others do. Its frustrating to hunt bugs/compiler errors if u dont get them :(

[bond]

i have a pentium3 with 866mhz

it already crashes if i only try to place it in the graph by selecting it via the filter list in graphedit :(

[Andy2222]

oki my fault i still havnt added code to detect the CPU features in the installer, to prevent the install on wrong systems. The problem is your pentium3 has no SS2 and so it crashes. The versions with ".._SSE2.exe" only run on AMD64, Pentium4 and PentiumM CPU's.

sorry

[hellfred]

So much to the discussion whether a DAU / normal computer user should know what extensions are supported by his CPU. :D

Sorry Bond, did not want to hurt you. But it fitted so splendit to the discussion that was going on here some pages ahead of this message.

[iradic]

MMX -> Pentium MMX, Pentium II, K6, K6II, K6III and later
iSSE -> Pentium III, all Duron (called 3DNow extension), all Athlon (called 3DNow extension)
SSE -> Pentium III, Duron (core Morgan), Athlon XP and later
SSE2 -> PIV

taken from: Dust- a noise remover (http://forum.doom9.org/showthread.php?s=&threadid=42749&perpage=20&highlight=loadpluginex.dll&pagenumber=5) thread...

[dragongodz]

i still havnt added code to detect the CPU features in the installer
So much to the discussion whether a DAU / normal computer user should know what extensions are supported by his CPU.
a user should know what cpu they have atleast so just have that selectable from the installer.

[Nikse555]

A MMX version would be nice... plz

I have an VIA C3 933 Mhz processor (equal to p2 ~550mhz) with MMX/3DNow!

[thop]

Originally posted by pankov
@Athos & Andy
Guys, can you make a non SSE2 build that will include this very needed bugfix and a usefull feature?
2004-07-01 Andy2222 (ffdshow-20040701_SSE2.exe)
...
* fixed "green" shift resize bug
...

I don't know why but this "green" problem is veeeery visible on my TV and it kills the pleasure of watching movies
I second that request.

[Andy2222]

It isnt this easy since i use a little diff. code compared to the mmx2 version. I did not realy "fix" the bug, its more like i noticed that my version seems to not have those bugs. I can try if i find whats wrong, but i did not planed to rework the org. mmx2 code.

[pankov]

Andy,
pleaaaaase do it - the green fix is really important for me.
I'm gona puke of all this green stuff - since I've noticed it I can't watch a single movie with pleasure
:(

[SMF007]

I just noticed something about the audio filter. The resampler only downsamples (as it's clearly named). I know upsampling doesn't increase the audio quality, but I was trying to use ffdshow to resample PCM streams for AC3filter to re-encode. I was just thinking that if it's doing resampling already, why could it not upsample too?

Any thoughts on upsampling of audio?

[Andy2222]

new version up (normal mmx and SSE2) just few fixes:

2004-07-09 Andy2222

* Luma Offset/Gain fixed

2004-07-08 milan_cutka

* clear input buffer when decoding audio using libavcodec
* better keyboard handling in codecs and keys pages

2004-07-07 milan_cutka

* fixed aac decoding
* imported faad2 library
* working on liba52 integration
* better ac3 support

2004-07-06 milan_cutka

* working on audio part 2
* multithreaded encoding using libavcodec
* split long subtitle lines

[thop]

Is ist just me or did CPU usage really go down with the latest version? It used to be 20-30% here, now it's 5-20%!

[swalker]

Andy2222, could you fix your local copy of ffdshow.ax.manifest? The one in your builds is broken (widgets do not pick up windows xp theming) and does not look anything like the cvs version.

[RadicalEd]

A non-sse2 version that decodes cabac correctly. SWEET. Thanks.

[pankov]

Andy,
in the non SSE2 version log I didn't see the "green fix". Does this mean that it's not implemented yet?
I'm not at home now so I can't check it myself.

[marcellus]

The new (non SSE2) release is really faster. I can now capture at 704x576, crop , resize (bilinear), denoise 3d (non HQ), deinterlace, addborders via avisynth and encode mpeg2 at 480x576 all in real time and decent quality. My CPU (AthlonXP 1800+) stays at 88-95% usage (no more dropped frames). Really great!

BTW, is there any way to add borders in ffdshow like in avisynth, without resizing the image to make room, just add them around the image? It would be cool, because now I have to use avisynth and is slower (not by much, but when CPU is at 95% usage the difference might mean dropped frames). To make myself more clear: I capture at 704x576, I crop it to 656x512, I resize it to 448x512 then I add borders to make it 480x576 to obtain the final m2v file (after I demux the avi) at SVCD resolution, ready to be burned without more encoding.

Selecting multiple threads has any speed effects with only one processor? I supose not, I didn't noticed any. Selecting more than one thread with mjpeg makes the encoder do nothing at all (but doesn't crash either :cool: ).
My problems with previos Andy's builds (mpeg2 and mjpeg encoding crashes) - gone. :) :cool:

One odd thing though (I think it's an old issue): mjpeg decoding of files encoded with ffdshow is normal but when I try to play avi files made by my digital camera there are swaped UV. With picvideo as decoder I dont't have this problem.

bye and many thanks!
marcellus

[bond]

ok i now tested it myself and the pervious problems ffdshow had with cabac decoding have definitely been fixed now! so ffdshow should be a very stable codec

should because i noticed another problem:
everytime i play a h.264 stream (tried it with one encoded with x264, CABAC, All BlockSizes, 5 ReferenceFrames and Q13) in graphedit, i get the first time a pretty dark, more grey picture, after i push stop and play again the color is the right one

anyone else experienced this?

[oddball]

All ffdshow builds since about february or so exhibit jerk-o-vision on playback. I've never gotten smooth playback with the later builds. If I playback with plain vanilla XviD 1.0 decoder it's smooth as silk.

[Andy2222]

@Pankov yes, im not at home atm and had no time to look into this yet

i will also check the manifest problem if im back

for the speed, i did not realy enhanced something in this release but we integrated the new mmx2 denoise3d (HQ version) code in the cvs and this version, so i suggest to only use HQ.

@oddball sorry to hear this, but its prolly no ffdshow problem since with all filters disabled and only using libav codec u should be able to decode a xvid movie without problems even on a 500mhz pentium. I also never heard about speed problems for pure decoding only of xvid movies. Did u try build a manual graph without adio filters in graphedit?

[Sirber]

bug report: lastest ffdshow crash with awarpsharp and post processing enabled. :o Gonna try with avisynth awarpsharp soon :)

[Andy2222]

Originally posted by Sirber
bug report: lastest ffdshow crash with awarpsharp and post processing enabled. :o Gonna try with avisynth awarpsharp soon :)

mhh cant confirm this, pls send me your ffdshow filter chain (what filters u use and in wich order) per PM.

thx

[nanoflower]

Any idea when the MPEG2 decoding will be fixed in libavcodec? I notice that the FOURCC column under the supported codecs is marked as "currently broken". When trying to play back an MPEG2 stream I'm only seeing the key frames so the B and P frames are being skipped. It would be nice if ffdshow could decode them.

[bokus70]

What is the difference between the athos and andy222 versions? SSE2 instructions? Something else?

I just recently popped into this thread only to find myself puzzled about these two builds.

thx

[sh0dan]

Originally posted by iradic
MMX -> Pentium MMX, Pentium II, K6, K6II, K6III and later
iSSE -> Pentium III, all Duron (called 3DNow extension), all Athlon (called 3DNow extension)
SSE -> Pentium III, Duron (core Morgan), Athlon XP and later
SSE2 -> PIV
A bit outdated:

SSE2 -> P-IV, Opteron, Athlon 64
SSE3 -> P-IV Prescott, Athlon 64 - 90nm, AMD Sempron.

- Since both Intel & AMD has added SSE3 into existing processors, it will probably cause some confusion, when it will eventually be utilized. (SSE3 isn't that big a change, though - at least for video processing).

[Andy2222]

Originally posted by sh0dan
A bit outdated:

SSE2 -> P-IV, Opteron, Athlon 64
SSE3 -> P-IV Prescott, Athlon 64 - 90nm, AMD Sempron.

- Since both Intel & AMD has added SSE3 into existing processors, it will probably cause some confusion, when it will eventually be utilized. (SSE3 isn't that big a change, though - at least for video processing).

So AMD actually integrated SSE3 in the latest AMD64 versions? I just wonder cause i read that AMD dont plan to integrate SSE3 soon, since they dont see much support for it.
On the AMD site i cant find infos about SSE3 support on AMD64 CPU's, can u gimme a link.

"SSE3 isn't that big a change, though - at least for video processing"

SSE3 has those nice horizontal add/sub stuff wich is common used in codecs and video processing, i dont know how its integrated in the CPU and how much cycles it takes, but at least having a horizontal add command saves the register copy and reorg. instructions, so those instructions are very helpfull for vector operations.

[Sharktooth]

SSE3 -> P-IV Prescott, Athlon 64 - 90nm, AMD Sempron.

Athlon 64 - 90nm is the NEXT generation of Athlon 64, not the current one.
Sempron is (will be) the new low end CPU from AMD available in both Socket A and Socket 754 (no 64 bit execution).

[Longinus]

Is it just me, or Andy's site don't work any more?

[athos]

New build today. Pentium (vc++) / i686 (gcc) target. Usual fixes.

[Leak]

Originally posted by Longinus
Is it just me, or Andy's site don't work any more?

Yeah, seems like Lycos.de pulled it - I'd guess it was producing too much traffic, and with today's free webhost offerings this is a big no-no...

np: Radiohead - Where Bluebirds Fly (Com Lag (2+2=5))

[Guy Incognito]

I uploaded Andy's latest SSE2 build to my webspace, you can get it here (http://blubb.at/sesshoumaru/ffdshow/).

[Andy2222]

Originally posted by Leak
Yeah, seems like Lycos.de pulled it - I'd guess it was producing too much traffic, and with today's free webhost offerings this is a big no-no...


jup just got the mail today, they "unplugged me"...
I will try to find a solution for a more stable webhost.

[fakey]

Originally posted by sh0dan
A bit outdated:

SSE2 -> P-IV, Opteron, Athlon 64
SSE3 -> P-IV Prescott, Athlon 64 - 90nm, AMD Sempron.

- Since both Intel & AMD has added SSE3 into existing processors, it will probably cause some confusion, when it will eventually be utilized. (SSE3 isn't that big a change, though - at least for video processing).


Some more things.:)

No SSE2/3 implementation in Socket462 Sempron.
coz it has old AthlonXP core.

And some rumours suggest that only 2ch ver.(socket939?) of Sempron will implement SSE3.

[Leak]

Originally posted by Andy2222
jup just got the mail today, they "unplugged me"...
I will try to find a solution for a more stable webhost.

Couldn't athos host those files at his sourceforge project? That would also solve the problem that people looking at the project page download the ancient alpha build that's up there...

np: Radiohead - Skttrbrain (Com Lag (2+2=5))

[athos]

The Sourceforge project is milan's, and he asked me not to put up alphas there until he felt the code was more stable..
But maybe I can find some other place.

[Leak]

Originally posted by athos
The Sourceforge project is milan's, and he asked me not to put up alphas there until he felt the code was more stable..
But maybe I can find some other place.

How about a second sourceforge project? ;)

np: T.Raumschmiere - Dual Kanal (Anti)

[Sharktooth]

Originally posted by fakey
Some more things.:)

No SSE2/3 implementation in Socket462 Sempron.
coz it has old AthlonXP core.

And some rumours suggest that only 2ch ver.(socket939?) of Sempron will implement SSE3.
Sempron will be available for Socket A (ahtlon xp, but only for motherboard wich supports 200Mhz FSB) and socket 754.
It is not based on the old Athlon XP core but on the Athlon64 core with 64 bit execution disabled.
The 3100+ will be clocked at 1800Mhz.
No SSE3 cpu from AMD is actually in production.
A quick search on the internet will confirm what i said (some guys are actually testing those CPUs).
However also those informations are subject to changes.
Please dont spread false rumors.

[Longinus]

@Andy2222

I have some space on my server if you like.
How much bandwidth did your lycos page used??
Mail me if you are interested (longinus@gmail.com)

[fakey]

Originally posted by Sharktooth
Sempron will be available for Socket A (ahtlon xp, but only for motherboard wich supports 200Mhz FSB) and socket 754.
It is not based on the old Athlon XP core but on the Athlon64 core with 64 bit execution disabled.
The 3100+ will be clocked at 1800Mhz.
No SSE3 cpu from AMD is actually in production.
A quick search on the internet will confirm what i said (some guys are actually testing those CPUs).
However also those informations are subject to changes.
Please dont spread false rumors.

Yes, Sempron will be available both for Socket A(Socket462) and Socket 754.
(and for Socket939 by Q1'05)
And No, Socket462 Sempron IS based on AthlonXP core unlike Socket754 one.
Anandtech says it's Thoroughbred and some other says Barton or Thorton, not certain which is correct but they're all AthlonXP core.
Sempron is only common trademark in AMD's value line for two explicitly different CPUs from different generation core.
I don't want to discuss something based on rumours either.
Sorry for being OT.

[Andy2222]

Originally posted by Longinus
@Andy2222

I have some space on my server if you like.
How much bandwidth did your lycos page used??
Mail me if you are interested (longinus@gmail.com)

thx for the kind offer, Athos was already so kind and got me access on his host.

[Andy2222]

[edit]
problem solved

[Sharktooth]

some AMD sempron informations can be found here: http://www.theinquirer.net/?article=17314
Nothing of real interest...

[faxmactor]

I have video that is likely to be made with an buggy, early Xvid 1.0 (or earlier) build. It has lots of b-frames but no keyframes in the beginning.

Xvid is able to display it correctly as well as mplayer (which uses libavcodec, too), so I came to a conlusion that this issue could be fixed in ffdshow as wll. Milan, please have a look at.

A screenshot: HERE (http://ozdtersegi.axelero.net/ffdshow_issue.jpg)

A short clip (2,5M) demonstrating the issue "live": HERE (http://faxmactor.port5.com/Excel%20Saga%20-%2001%20-%20The%20Plan%20To%20Murder%20Koshi%20Rikudo%20(AHQ).ogm)

[Bogalvator]

Did you try setting the IDCT setting to XviD? (under the "Miscellaneous" section)

[Soulhunter]

Some questions regarding ffdshow's audio decoder !!!


As its possible to upsample the audio...

- Could it be used the fix the SoundBlaster upsampling problem ???

- Should I upsample everything to 96000Hz for a Audigy2 ZS ???

- Is Kaiser "the best" upsampling algorithm of ffdshow ???

- Is it better than the Audigy's "bad" resampling ???

- When yes, how much better is it ???


Tia n' Bye

[SeeMoreDigital]

Originally posted by faxmactor
A short clip (2,5M) demonstrating the issue "live": HERE (http://faxmactor.port5.com/Excel%20Saga%20-%2001%20-%20The%20Plan%20To%20Murder%20Koshi%20Rikudo%20(AHQ).ogm) How about having the encode in an AVI container!

[faxmactor]

Originally posted by SeeMoreDigital
How about having the encode in an AVI container!
How about Matroska ;) BTW, it was not me who encoded this series, so can't do anything about it. But I don't think that the container format has anything to do with the video stream having been encoded with a dev version codec.

[Coroner]

@Soulhunter

The upsampling problem isn't solveable. It's a hardware issue with them. Some other cards (Not creative)with hacked drivers etc will give a non re-sampled output. There are few cards that will give a bit perfect output.

The EMU Digital Audio System cards which use a derivative of the EMU10K series will give bit perfect output. So will the Chaintech AV-710 with hacked firmware and drivers, although I think just the latest drivers will do it now. The M-Audio Transit USB (I have one) has bit perfect output with standard drivers. Of course none of these cards will do 3D audio EAX etc. Not sure on the AV-710 though, but I presume kmixer in windows will re-sample it anyway.

In short in order to get a non re-sampled bit perfect out put in windows one has to stuff around a bit.

For music I use foobar2000 with the ASIO output plugin and no re-sample output at 24 bits. For MPC I'm not sure whether it is possible to do it. A kernel streaming output or ASIO would probably do it.

For more info on the evil of kmixer and non bit perfect cards see Head-Fi Computers as source forum (http://www4.head-fi.org/forums/forumdisplay.php?f=59)

It's a rather in-depth topic. Basically at the end of the day you can't get non re-sampled bit pefect output from any Creative card. Even the digital outputs on these cards are re-sampled. You can of course use a better software upsample to 48Khz before hand (or 96khz, if you choose) but it still will not be bit perfect. Unfortunately Creative continues to force this resampled non bitperfect problem on you no matter what. If you play games though I guess your stuck with them, as sensaura etc just from my experience isn't up to scratch.

[athos]

milan gave me the go, so this is the first release in over a year to be put up on sourceforge:
http://sourceforge.net/project/showfiles.php?group_id=53761&package_id=59355&release_id=255667

Plain vanilla; should work on i586 (Pentium) and up.

[bond]

Originally posted by athos
milan gave me the go, so this is the first release in over a year to be put up on sourceforge:
http://sourceforge.net/project/showfiles.php?group_id=53761&package_id=59355&release_id=255667great!

maybe we should take this opportunity and close this 65 sites strong thread and continue the discussion in a new "ffdshow development #2" thread? i think noone finds anything anymore in this thread :D
what do you guys think?

[Tommy Carrot]

IMO the most important infos about ffdshow should go to a sticky, and this thread should be keeped for the normal everyday discussions about ffdshow (so we'd have a chance to make it the longest thread in doom9 :D).

[bond]

okidoki, from my point of view its not a good idea to have too long (like 65 pages) threads, as its simply far too difficult to find any infos in them anymore

thats why this thread is now closed and everyone is invited in continuing the discussion about ffdshow development in the new and cosy ffdshow development #2 (http://forum.doom9.org/showthread.php?s=&threadid=80256) thread :D