ffdshow development

[Neo Neko]

Well I'm not saying libavcodec and ffmpeg can't deliver good quality because they can. But they are not specifically coded for quality as they are for speed. They are intended to be a "real time" encoder decoder solution.

[Andy2222]

more on asm stuff :)

have now nearly a working compile, but the damm yuy2->yv12 asm conversion code from avisynth crash by wrong memory writes...

It's caused by the "sfence" and "emms" command...

So why and when do we need "sfence" btw?

Other strange thing is while "emms" still crash my athlonXP the "femms" dont...? Since on athlon K7+ femms is mapped to emms i dont see why one crash and other not..?

[hellfred]

@Andy2222:
You are compiling on win32 using MSYS / MinGW. Or are you just linking there? I would like to know how you actually compile some critical files with gcc 3.2 and the rest with gcc 3.3. Do you manually start the compiling prozess for those files and then use make / your makefile and let it compile those source-files that have no .o object file next to it?
Or is it possible to define two different gcc's
(GCC32=/paht/to/gcc
GCC33=/Path/to/the/other/gcc)
in the Makefile and then use the relevant gcc for each line of the Makefile?
($(GCC32) -MM $(CFLAGS) problematic_file.c
$(GCC33) -MM $(CFLAGS) $(SRCS) //the rest)
But how to get two gccs working in one MSYS system? the normal way to install an binary packet of gcc is to unpack it into the MSYS root directory and it will override any existing gcc packet. I would really prefere not to have to compile gcc myself using the --prefix option to get two gccs working in MSYS.
I am asking as i would like to compile ffdshow for my system (PIII-550MHz) to be able to run propper postprocessing and hdtv content smoothly. ffdshow build from 20040928 sometimes has problems, and i could use your 30% speedup.

Yours
hellfred

[Andy2222]

hehe my trick is bit simpler :)

I have cygwin and mingw installed, using gcc 3.3.3 maybe update to 3.4 on cygwin since im unable to compile the package on mingw. Mingw uses the org. 3.3.1 or 3.2.3 i just made and zipfile before i updated and can easy delete/unzip to what version i need (since mingw is very small it just takes 10 seconds to do this)

I just compile all with cygwin with the -mno-cygwin options and since cygwin suck in this mode (it still mixx cygwin and mingw header/libs) even if i update all mingw libs/header in cygwin to the latest mingw i still get linking errors in the libstdc++.a.
I than delete the critical files and just run a make under mingw so the critical files get compiled with a older version an linked under mingw wich garantee a 100% working windows version. Cygwin is nice but that u still cant build files without the need of the cygwin1.dll is a shame and the -mno-cygwin -target=mingw dont work realy since cygwin+gcc suck to choose the right libs/path/includes and mixx all up wich end in linking errors.... But on the other hand mingw lacks some needed libs/packages to compile gcc/binutils and some other stuff (even if installed the dev package) im unable to compile many stuff under mingw wich work without problems under cygwin... cygwin just have sucha easy web install and support nearly everything u need as developper.

For me the best way is use cygwin as experimental developper system with latest nasm/yasm/binutils/gcc .... and mingw as stable system in wich i just use whats precompiled from the mingw site.

PS: u will need my new ffdshow sourcecode to compile it with gcc, to many stuff depend on inline asm and if u compile a older non gcc tuned version many asm code is simple replaced by plain c++ functions wich results in much slower code.

But dont worry the upcoming version will be a p4 SSE2 compile and a athlon4/p3 mmx2/sse/3dnow compile, i think the p3 also have mmx2/3dnow right and i test every damm gcc option wich might add speed.

[Andy2222]

damm it damm it damm it!!!!!

fu.... 4 days,
countless hours spending into mmx/sse tutorials..
countless hours compiling the same file over and over..
countless hours trying to understand why emms/sfence crash the memory..
countless hours of shaking my head to the desk..
installed 7 different assembler, 4 diff. compilers, tryed to rewrite to nasm format..

But what was the stupid little error i did while converting to at&t syntax? It was a simple crappy lazy "[]" to put around my %[varname] variable labels... so it looks [%[varname]] and not just %[varname].

I was thinking [varname] already load the VALUE but it dont.. to get the value u need the [] even if it looks crazy to write [%[..]]... that was all....

Sorry had to write this to get away some frustration from the last 3 days/nights. At least im not a ASM noob anymore... :)

PS: that means i just need review all the asm code again for this little error and maybe that was all to get it working finaly..

[arno]

Originally posted by Andy2222
damm it damm it damm it!!!!!

fu.... 4 days,
countless hours spending into mmx/sse tutorials..
countless hours compiling the same file over and over..
countless hours trying to understand why emms/sfence crash the memory..
countless hours of shaking my head to the desk..
installed 7 different assembler, 4 diff. compilers, tryed to rewrite to nasm format..

But what was the stupid little error i did while converting to at&t syntax? It was a simple crappy lazy "[]" to put around my %[varname] variable labels... so it looks [%[varname]] and not just %[varname].

I was thinking [varname] already load the VALUE but it dont.. to get the value u need the [] even if it looks crazy to write [%[..]]... that was all....

Sorry had to write this to get away some frustration from the last 3 days/nights. At least im not a ASM noob anymore... :)

PS: that means i just need review all the asm code again for this little error and maybe that was all to get it working finaly..

Just wanted to let you know that your efforts are highly appreciated!!!!!!!!

[Andy2222]

thx :)

PS: can some1 confirm this pls (with amdxp or intel) u need SSE

use xvid to force output yuy2 format and set ffdshow to yv12 output only (u need 09+/2003 version) now disable all filters but postprocessing nic's.

aka: xvid decoder yuy2 -> ffdshow yv12 -> video render

Now the sse yuy2 to yv12 code should be used wich, seems working but now just tunr on and off the Nic's box aka enable disable it. I just notice that if i use rezise/spline and use nic's PP before, by just enabling and disabling the cpu usage LOWERS from 100% to 60%?
Lets say it again enabling nic's PP lowers the CPU usage if the yuy2 conversion code is used? Something is wrong here....

[athos]

I'm really excited to test this new version when you are done Andy. About this 10-30% speed increase, is this compared to my november build or the january build?

[Andy2222]

Originally posted by athos
I'm really excited to test this new version when you are done Andy. About this 10-30% speed increase, is this compared to my november build or the january build?

its against your 9/10/11 2003 versions the 01/2004 is total crap :)

some more asm stuff pls maybe this time a little hint?

We have:

pmm1 = (uint64_t *)(&(v[1])); /* this is a 32-bit aligned pointer, not 64-aligned */

(why a 64 bit uint is than used if its just 32 bit, would uint32_t not do the job as well?)


than
mov eax, pmm1 (here the adress is stored in eax)

now my gcc compile crash cause it try this?
movq mm1, qword ptr [eax] /* mm1 = *pmm

(so it try to move the value of the memory adress stored in eax assuming its a qword)

Thats what VC6++ replace the line with:

movq mm1, MMWORD PTR [eax]

This MMWORD thing is something used with the processor pack stuff and 64bit integer types.

Normal quad word is the same but MMWORD can be up to 80/96 bit i think.

So why the gcc compile crash?

Oki i can direct use movq mm1, [%[pmm]] but i think the adress is used by eax cause its faster than get the adress direct out of the memory, maybe its often needed in a loop?

So whats all this int64 stuff about and whats this MMWORD?
Maybe gcc cant see that a cast is needed with this pointer while VC6 can and replace the code with the MMWORD and internaly it checks before it do the actual operation?


[update]
seems the problem is that gcc dont allow to store a 64bit (uint64_t) pointer adress into a 32bit register, wich is oki since its not allowed. I just wonder why VC6 allow this with MMWORD...

[Asmodeus]

Sorry for make an inroad, but I have one question. Your goal is new version of ffdshow only, or you also try do develop ffvfw?

---------------------------
Poor english team member :D

[oddball]

Looking forward to try your version Andy2222 :)

[Andy2222]

Originally posted by Asmodeus
Sorry for make an inroad, but I have one question. Your goal is new version of ffdshow only, or you also try do develop ffvfw?

---------------------------
Poor english team member :D

my first and only goal atm is to get a ffdshow (only the video filter + libavcodec part) wich work without mayor bugs and work as fast as possible. So no im not looking into the ffvfw parts.

For the future i might add some cosmetic stuff for some filters and if i worked through all those asm/mmx/sse tutorials "might" be able to optimize some code :)

[Asmodeus]

Thx for reply Andy.
It would be nice to optimalize few options in ffvfw, but for now smash every bug in ffdshow ;) Keep going. You doing great job ;)

[Didée]

Andy,

may I ask if you could have a look on the following issue:

It's a known fact that ffdshow doesn't decode XviD content fully correct. There are small glitches like too strong "floating-wall" artefacts, and too strong "I-frame-pumping"/"I-frame-refresh-effect".

These seem to be IDCT issues. Changing ffdshow's IDCT to "XviD" doesn't change anything in this regard.

The big question is now:
- is ffdshow's (resp. libavcodec's) implementation of XviD-IDCT buggy?
or
- is XviD-IDCT not envoked at all, even when checked?

It would be very, very nice if this problem could get narrowed down - or if it could even be solved!
(Currently, if one produces full-featured X-high-quality streams at big framesizes, there are only twopointfive possibilities: -1.Realtime playback with artefacts (ffdshow) -2. Slow motion without artefacts (xvid.ax) -3. Go back to the future & by a PC)

Regardless of if you can say/do something about this, or not: a really big THANK YOU for all your efforts, Andy!

crowds are cheering AN-DY ... AN-DY ... AN-DY ... AN-DY ... ;)

- Didée

[Andy2222]

mhh is that problem ffdshow related or also in mplayer?

I need some help with that problem: The libmplayer.dll is desinged to be compiled with gcc (cause of the at&t inline asm stuff) so i need to compile it with gcc wich work great.

Since atm im advancing my asm knowledge i "play" around with the AMD profiling (CodeAnalyst) tool for windows wich realy works nice with the Vc6 code + the .pdb file.

Is there any way to build the libmplayer.dll under gcc so i can use the debug/.gdb infos with teh AMD tool, or with Intel VTune?

I tryed the -g and -ggdb switch but under xp it seems i cant use the generated infos.

U know a way? Since profiling under gcc wont help here since the libmplayer.dll has to work with fddshow.ax.
It would be nice to get it worked since gcc allow -g debug options with -O. options and i realy would like to see what gcc change at some parts of the code and how this improves performance. But i need to find a way to debug/profile the ffdshow/dll gcc compiles under windows using the AMD tool.

[Andy2222]

a little update for u

With the help from <alex_here> and <vektor> from the matroska/tvtime irc channel's (i bugged them with asm questions) i could finaly understand the basic concept of mmx/sse optimizing and how the processor access data and how to align them correct.

In result i could rewrite the bottleneck of the denoise3d filter wich is the most consuming filter in ffdshow and now its 2.5 times faster :) I will do some more optimizations and hope to get it 4 times faster.

Since that worked out well i will profile the other filters too and try fix spoted bottlenecks. The reziser wich is already mmx/mmx2/3dnow optimized could maybe get also some updates.

For the release i just can say if im happy with the overall speed i will release it. Means it must be at least 30% faster than any older version with (rezise, postprocess, denoise3d, asharp, levelfix, noise) enabled.

[Coroner]

Great stuff Andy2222!

Thanks for all your work.

:)

[nanoflower]

It's great that you are putting in all of this work, Andy. It should help make everyone much happier with ffdshow. One question that keeps coming up is, is it possible to get a bug-fix release some time soon, and then follow up with the optimized version. It would help if there was a version of ffdshow that worked better with the current version of XVID (handling multiple B frames in a packed bitstream.) That seems to be the biggest complaint I see.

[hellfred]

I just want to cheer you on a little bit, too. (Good english?)

Hellfred

[Danzel]

Good Work Andy, hopefully with some of your changes ffdshow will become the great all purpose decoder it once was.

From the libavcodec Changelog on h263dec.h:
Revision 1.144 / (download) - annotate - [select for diffs] , Thu Jan 15 01:29:26 2004 UTC (5 weeks, 4 days ago) by michael
Branch: MAIN
Changes since 1.143: +12 -6 lines
Diff to previous 1.143
xvid "packed" stuff support


If the libavcodec in ffdshow was updated to cvs version then it should be able to decode xvid with packed bitstream. (From what that says)

Danzel.

[Dark_Angel_PT]

Just want to congratulate Andy2222 for all this work in developing ffdshow.

I read in the inmatrix forum that you are not thinking of including the audio filter in your work. Is there a possibility to include it , even if without any changes/improvements?

And what about updating the libavcodec? Will it be possible to ffdshow to be the best all-in-one decoder as it once was?

[P0l1m0rph1c]

Originally posted by Dark_Angel_PT

And what about updating the libavcodec? Will it be possible to ffdshow to be the best all-in-one decoder as it once was?

It still is ;)

Great work Andy! Looking forward to try a new version soon :)

Cheers

[Andy2222]

Originally posted by Danzel
Good Work Andy, hopefully with some of your changes ffdshow will become the great all purpose decoder it once was.

From the libavcodec Changelog on h263dec.h:


If the libavcodec in ffdshow was updated to cvs version then it should be able to decode xvid with packed bitstream. (From what that says)

Danzel.

mhh can some1 post a link to a small video with sucha packed bitstreams so i can test if the actual version can handle it and if not i can try fix that.

[sysKin]

Originally posted by Andy2222
mhh can some1 post a link to a small video with sucha packed bitstreams so i can test if the actual version can handle it and if not i can try fix that.
http://homepages.ihug.com.au/~syskin/pb.avi
I have maximized number of b-frames to make the effect as clear (and painful) as possible :)

Good luck,
Radek

[Kurosu]

Originally posted by sysKin
http://homepages.ihug.com.au/~syskin/pb.avi
I have maximized number of b-frames to make the effect as clear (and painful) as possible :)

Good luck,
Radek
I've just tested it against a ultra-hackish build of ffdshow/VC7+gcc: if Andy2222 ports newer libavcodec, it should work OK. But there are quite a few painfull changes:
- Coder's context no longer holds per-frametype min/max frame mean quants; ffvfw's rate control is mostly broken because of this
- pixel ration has again changed
- there is much stuff to clean out of the files in libavformat
- showMV is broken and maybe some other stuff I didn't dare testing

In any case, I wish good luck too to Andy2222 to rationalize all the changes.

[Andy2222]

Btw im still looking for a way to use MASM/VC6/ICL8 obj files with the gcc compile/linker.

So far i came up that mingw and masm output coff (pe-i386) format, i use VC6/ICL8 to just output a asm file of the .cpp file. Than i build the coff format with masm out of it, after that i use "objcopy -Ope-i386" to get a clean version. But that dont work dllwrap/gcc linker cant still find the function names.

I came up and changed the names in the ASM file from
"?functionname@@QAAXHZZ LABEL NEAR" to "_functionname LABEL NEAR" but this still dont work...seems there is some kind of declaration in the gcc asm output files for gas.

So anyone have an idea how i can convert masm coff to a format the gcc linker/dllwrap understand under mingw?
Or at least know what else i have to change in the ms compiler/ICL asm output file to match the gcc name/call conventions?

I did not try to change the asm file so gas can understand it fully maybe that will be a better way to try, but for that i have to know what is different in the VC6/ICL8 asm output file compared to the gcc asm output for gas....

[Blight]

Andy:
I would like to second the motion of a stable ffdshow release. A lot of people use ffdshow as a general-purpose decoder rather than a post-processor and just getting it to play without any quirks would be good.

[Danzel]

you could try using the linux intel compiler and then using its output with gcc.. maybe?
(I dont know if the windows icl license allows you to use the linux version)

Danzel.

[dimzon]

I think that "add noise" and "resize" features work's incorrect together.

"add noise" is first and "resize" is after - it's not good. I think it's more proper to make "resize" and after "add noise"

[Andy2222]

Originally posted by dimzon
I think that "add noise" and "resize" features work's incorrect together.

"add noise" is first and "resize" is after - it's not good. I think it's more proper to make "resize" and after "add noise"

hehe oki i will change the colors of the damm mini arrows to move the filter position :)

There are little "invisible" arrows (up/down) for every filter so u can change the position to what u like. Just mark a filter and whatch the white arrows just before the name. Its not your fault i did not notice them neither on my first ffdshow use.

[Andy2222]

Originally posted by Danzel
you could try using the linux intel compiler and then using its output with gcc.. maybe?
(I dont know if the windows icl license allows you to use the linux version)

Danzel.

That what i was trying last night, but since i realy dont want switch to linux every time i need a working linux under VMWare or VPC. I had big troubles get debian work under vmware... i now try redhat if that fail suse...

I need a noob safe linux since, i dont want read linux manuals also(all the asm stuff is enuff for my tiny brain). I need a easy install and easy to use dist, if its possible with all developper tools preinstalled. I dont want setup/install a whole working linux by hand... Since i just need it for compiles.

I tryed that CoLinux thing but in the boot image is nearly nothing preinstalled and i dont know how to boot it up with one if the debian cd iso's or redhat iso's.

[dimzon]

Originally posted by Andy2222
There are little "invisible" arrows (up/down) for every filter so u can change the position to what u like. Just mark a filter and whatch the white arrows just before the name. Its not your fault i did not notice them neither on my first ffdshow use.
WOW :eek:

wise rissan saw (approx. in english) : age to live - age to lean

[hellfred]

There are some linux live CDs (like Knoppix for example) that have quite easy to us "install to disk" skripts, too. I do not know if those will work together with VMWare etc. But you can give it a try. You will have to install linux ICL manually, but most of the other porgramming tools should be shipped together with the linux live CD. Knoppix and Kanotix (derivation of the later one) are based on debian, so installing software can usually be archieved via apt-get install command easily.

hellfred

[Andy2222]

good news Milan is working again :) today he updated the cvs with some small updates

---------------------------------------------------------------------
working again... :) just few fixes and new features for now:

fixes in subtitles reader,
fixed mono audio processing,
SPP deblocker from mplayer,
volume normalization from mplayer,
updated installer to NSIS 2.0 final,
updated xvid to latest RC,
output colorspace is preset option,
updated libavcodec (now plays packed xvid b frame streams, some corruptions of picture after seeking),
fixes of few uninitialized variables found by DevStudio
---------------------------------------------------------------------

i just tested the new version, the old bugs are still in but i can merge my fixes with the new version. So far the packed xvid b frame streams seems to work with the testfile i got.

oki Athos got the new version rdy so hurry and grab them.

thx Athos!

[athos]

No reason to wait, here's the new build: http://athos.leffe.dnsalias.com/ffdshow-20040225.exe

Changelog: http://athos.leffe.dnsalias.com/ffdshow-changelog.txt

Note: This is based on milan's cvs, you will have to wait for Andy2222 to release his build with the cool assembly stuff. Compiled with MinGW and VS6, no ICL.

[Selur]

got a littel 'request' for the upcoming ffdshow versions:

All versions after ffdshow-20030816 won't work for me as post-processor* without killing aspect ratio informations.
(also see: here (http://forum.doom9.org/showthread.php?s=&threadid=69683&perpage=20&pagenumber=2))

Would be nice if someone could investigate what was chanced after this build,...
(since I'd like to use als newer version of ffdshow)

Cu Selur






*in overlay mode with raw video support enabled

[bond]

selur,
is overlay mixer2 used in the dshow graph?

[oddball]

That corruption on ff/rw in the new build is nasty. Hope it's fixed soon.

[Selur]

is overlay mixer2 used in the dshow graph?
can't find a info about it if I render the file in graphedit, but if you mean if I tried in newer version if it works if I set the over lay to 'gray/black activation' mode,.. tried both but it none helped, it only seems to work with builds where one couldn't switch between the 'gray/black activation' mode for overlay.

[bond]

Originally posted by Selur
can't find a info about it if I render the file in graphedit so you mean that with both 'gray/black' ffdshow never uses overlay mixer2 automatically?
if this is true than there is surely something borked, as it should use it (and does it that way with the old builds)

[iradic]

Hwy, what about "Automatic preset loading" - does this work?
Here ffdshow always crashes (winME - ffdshow versions I tried - latest sourceforge, athos 23112003, athos 25022004) after trying to setup automatic preset loading...

Thanks...

[Selur]

so you mean that with both 'gray/black' ffdshow never uses overlay mixer2 automatically?
if this is true than there is surely something borked, as it should use it (and does it that way with the old builds)[/quote]
The Filtergraph in Graphedit looks the same, no matter what ffshow version I use (overlay enabled) and for most versions it doesn't change if I change from 'gray' to 'black' or from 'black' to 'gray' for all the versions which got the possibility to switch between 'gray' and 'black'.

Hwy, what about "Automatic preset loading" - does this work?
Never tried it, but I will. ;)
(though I can't see how this will help :) )
=> works but doesn't help


---------

with the newest version:
- if I enable 'gray' overlay control&co works, but aspect ratio flag is lost
- if I enable 'black' ffdshow is no longer in the filter chain

Cu Selur

[communist]

Cool - one clip that was always stuttering (716x576, XviD 2pass / 2B-frames / PB / QPEL...) at around 14 fps with ffdshow and XviD decoder now runs almost fluid :D
Keep up the nice work :)

Only thing I encoutered so far is that when you seek through the file it has that sliming / crawling effect that vanished after some time.

[sysKin]

@devels

Hi,
I was working on this XviD directshow problem (http://forum.doom9.org/showthread.php?s=&postid=450683#post450683) recently. In short: playback is not fluent with overlay mixer but is fluent with VMR9 mixer. When I was working on it, I discovered that ffdshow (latest build compiled by Athos) has exactly the same problem.

Since I figured out what the problem was, I'll share my findings, hoping that it will help you as well. Note that I haven't seen ffdshow's code so *maybe* this is not it. Maybe.

Anyway, the problematic code was as follows:

CXvidDecoder::Transform(blahblah)
{
blahblah;
decode_frame_blah(and blah);
more_blah;
if (xvid_frame_type & VOL) { // we had a VOL header, most likely a keyframe
some_more_blah();
pOut->SetDiscontinuity(TRUE); // removing this fixed the problem
}
}

I can't really answer why the code was there, it shouldn't really be there according to MSDN. It also only happened once per keyframe, while stuttering was visible everywhere. Anyway, it's most likely a DX9 bug which XviD had to work around.
Please check if you have similar code. If yes, removing it will fix stuttering without any known side effects (xvid's dshow never had it before RC1).

I hope it helps,
Radek

[LeQuack]

sysKin:

Yes I had, and still have the exact same problem. Playback stutters with overlay mixer, but not with VMR9. Both in xvid and ffdshow decoders. But I think this happened to me even before the 1.0 versions.

[athos]

A little soon perhaps, but i saw that milan has made some work on the xvid decoding so i put up a new build today: http://athos.leffe.dnsalias.com/ffdshow-20040227.exe

Changelog:2004-02-27 12:15 milan_cutka

fixed for vc6

2004-02-26 21:18 milan_cutka

no message

2004-02-26 19:47 milan_cutka

libavcodec's noise reduction (when encoding), storing of quantizer
matrix in memory presets

2004-02-26 17:31 milan_cutka

no message

2004-02-26 17:27 milan_cutka

merge FRAME and FRAME_TYPE types

2004-02-26 14:15 milan_cutka

updated vc6 projects for libavcodec and libmplayer

2004-02-26 12:21 milan_cutka

graph when encoding, few variables moved out from Tffvfw

2004-02-26 09:30 milan_cutka

minimal compilation is sometimes broken in VC6

2004-02-26 06:29 milan_cutka

just small fixes

2004-02-25 20:00 milan_cutka

fixed few DevPartner warnings

2004-02-25 18:50 milan_cutka

checkbox for SPP soft thresholding

2004-02-25 18:33 milan_cutka

decoding by xvid4 seems to work

2004-02-25 15:21 milan_cutka

working of xvid4 decoding

[The Link]

When seeking in a xvid file (encoded with rc1 or rc2) with this new build I get this (http://www.beingalink.de/files/snap.png).

edit: only when using libavcodec, xvid4 seems to be ok

[bill_baroud]

yeah i got that too, until the next key-frame or so.

[Arcon]

i tried some of your latest builds, athos, but all of them crash every player if i use xvid as decoder for xvid content and set the postprocessing to maximum with nic's pp enabled. if i set pp to 4/6 or disable nic's pp it works without problems.

the (very old) 24042003 build doesn't have this problem.

edit: happens also with libavcodec as decoder. also selecting spp under postprocessing crashes bsplayer and wmp.

[Leak]

Originally posted by Arcon
i tried some of your latest builds, athos, but all of them crash every player if i use xvid as decoder for xvid content and set the postprocessing to maximum with nic's pp enabled. if i set pp to 4/6 or disable nic's pp it works without problems.

the (very old) 24042003 build doesn't have this problem.

edit: happens also with libavcodec as decoder. also selecting spp under postprocessing crashes bsplayer and wmp.

Well, I just managed to get an almost freshly installed W2K to bluescreen when using XviD 4, SPP postprocessing and moving the slider to the far right after rendering a file in GraphEdit.

Am I the only one who wishes for a fully documented, polished version of ffdshow through not adding bells and whistles for a while? ;)

np: Repeat - Studio 6122 (Miss Kittin - Radio Caroline Volume 1 comp.)