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.