My XVid binaries

[Koepi]

There is a Min+Max quantizer edit box on the config GUI. Guess why there is a "1" by default in the min. quant.? ;)
So it is possible to have that quantizer (it doesn't work with DivX3 since the decoder can't decode DRF 1).

To get further into the materia, you should post which binary you use. Since i added modifications and -h as well, and some things aren't in CVS so these changes don't apply to e.g. Nic's binaries, it's easier to track that down :)

Regards,
Koepi

[Franko30]

Originally posted by Koepi

- Added intraframe quantizer lock, hardcoded to 2x-3x until now.
- Added a routine to prevent quantizer jumping, largest jump amount is +-2 now.
- start credits should finally work. forgot to add them to the first pass as well ;)

Have fun!

Best regards,
Koepi


Hi, I'm back (had a little work to do today).

I tested your Feb. 11th Fix 3 binaries against the above mentioned.

Today I used a 15 min. test clip/H.263/2 pass/2nd pass int./desired file size 87632 for 19506 frames

First test with Fix 3 binaries without end credits enabled (start frame 0) to see what the quantizers would do. Resulting File size 88098. Mostly Quantizer 3 and 4 were used (remember: I use input from an analogue source, although the tv signal gets broadcasted digitally to the d-box decoder, system see below, no filtering enabled except smart de-interlace, normal bicubic resize was used). Quant 2 was used 16 times.

Second test was with the above mentioned experimental binaries, start credits from 0 to 1500 and the end credits were the last 500 frames. That is about 10% credits (more than in a usual movie) so the actual happenings in between should have enough bitrate to produce the "Wow!" effect. Resulting bitrate was 88100 and mostly Quantizer 3 and 4 were used - but MORE Quant 3 than 4 (compared both Debugview logfiles). Quant 2 was used 218 times.

Now to what I saw:

I didn't notice any visible difference, everything looks just great!
Only when examining real closely (nose to the screen) with the "fixed" Quantizers there wasn't as much noise around "sharp edges", shapes like people against sky etc.

I guess that from now on I can't contribute anymore to the subject of "quality comparison", as I use analogue input and no DVD-Rips...

But this also means:
Start and end credits are usable, even the experimental build can be used for normal encoding, which I will do tonight ;)

A great Codec and GREAT WORK :D :D :D done by Koepi and the others (I don't know how close all of you work together).


Thanks for another highly usable XVID "manifestation". Keep up the good work!

Frank

[wing1]

It's getting better and better everyday :) As I've said earlier, this codec has a very bright future. I too am using analog capture source as input for encoding.

[Koepi]

Thanks Frank for soing such a great testing job :)
I'm glad that the locked intraframe quantizers and the jumping-quantizer-prevention work as expected :)
(My actual encoding is a much harder job, tested with MPEG quantizer and no jumping prevention, looks still nice, but let's see what happens when it's finsihed with the new build... :) )

Btw., -h will add another way to scale down credits - it's a percentage of the desired bitrate - so if you enter 50% and are encoding with 800kbit/s, it will use 400kbit on credits... so I'll add my additions to his new version as soon as he publishes his changes to CVS (if he didn't do it yet ;) ).

Best regards,
Koepi

[-h]

The "credits rate" functionality has entirely replaced the fixed quantizer option, which I think is a bit unfortunate since having a higher credits quantizer in the first pass made encoding the credits significantly faster.

Once it's settled down, it shouldn't be hard for me (or you ;)) to re-add the fixed-quantizer mode.

-h

[Koepi]

NONONO! I don't want fixed quantizers back! Scaling with just another variable isn't bad and carries the thought of "constant quality" (which 2 pass true VBR should be...).

I meant the other changes:

- intraframe quantizer lock
- quantizer aliasing (jumping prevention)
- and finally, the debug output :)

Would be nice if you could add them, then we wouldn't have to spread X different versions of XviD, which is a BAD thing IMHO.

I would really appreciate it!

Thanks in advance ;)

Warm regards,
Koepi

[-h]

I-frame quant settings are done, quant smoothing (last_quant +- 2) is done, debug I'll get around to ;) but I'm still getting this ridiculous VC bug, even on my work comp with SP5.

Either way, it'll be done tonight. I might just get fed up and commit the whole lot anyway :)

-h

[gldblade]

Wow, that's what I call fast development.

Just wondering, I heard somewhere that Koepi's latest build does not have the pink bug. Can anyone confirm? I've done a little testing and I don't see any pink, but I just want to make sure.

[Koepi]

I don't see any pink either.
This has nothing to do with that I'm color blind...

sorry, I'm not :)

But well, sometimes there is pink: when it belongs there. Since I encode a western movie ATM there is some pink ;)

The bug is solved in the core-lib in CVS since 11.02. IIRC.

Regards,
Koepi

-h:
Thanks mate, saves me a lot of work :) As I'm writing and watching the debug output of the second pass I'm _really_ impressed what those modifications are able to do. For me it's never SBC/DivX/Nandub again (I hope). :)

[Ripe73]

HI Coders!!

I encoded a movie with XviD-12022002-1(Koepi)
177501 Frames(118min)
XviD Settings
2 pass Int.H:263
M.Search 5
Q.Type 5
No L.Masking(both pass)
Endcredits:169883 Q:12
Final size:1396MB(GKnot calculated) saved 4mb for subbs!

Well i did the movie twice i did not know that the endcredits start should be on the first pass too so the movie was undersized:D
I have not seen the whole movie just a couple of scenes and they look amazing:) so clear
I will report later if i see something strange

Thanks

[-h]

!@#$!@#$%!@#$!@#

All that's holding back a cvs commit is this VC6 __int64 bug - any better way to work with the values we're going to see in .stats files? I can commit now, but if the 1st pass is bigger than 4 GB there'll be trouble.

-h

[Koepi]

Hmmmm... since XviD is alpha there shouldn't be a problem with that limitation. It's for advanced users in it's current state as I understand it, and those wouldn't dare to compress anything that exceeds 4GB on 1st pass to 1 or 2 cd.... ;)

Just my oppinion.
If it's still the error, that the wrong variable gets used... It works for me if you just declare an int. Isn't that int64 anyways by default?

Maybe I'm still too sleepy to get the point there, but this is just an idea.

Regards,
Koepi

P.S.: thanks Ripe73 for the feedback. Nice to know that it works out well for you as well :)

[-h]

@Koepi - I'm trying to message you on icq but trillian is spitting out "Error while sending IM: Not supported by client."

I think a second pair of eyes would be very useful right about now.

-h

[Nic]

@Koepi the standard int/long is a 32bit integer....

@h:
What is the bug with the int64 (ive never come across it!) If you could tell me how I could re-create it quick, I can do some tests for you.....Have you got service pack 5 on?

Cheers,
-Nic


ps
looking forward to the CVS commit :)

[-h]

@Nic: I think I'm going insane.

Anyway, I'll commit what I've done only use long's instead of __int64's. The issue I have at the moment is:

if (codec_is_in_credits(codec, frame))
{
credits += nns.bytes;
}

Now in that bit of code, if "credits" is a long or int, it adds fine - if it's an __int64, it stays 0 no matter how much I add to it. Driving me insane.

Also, 2-pass mode is currently undersized, but that can be fixed later. Best to just commit this stuff and let the bugs be fixed by people who haven't got brain-freeze :)

-h

[Nic]

LoL -h

Ill do a little test with _int64
im assuming is credits a int64 and nns.bytes is a int...right?
(im in the UK so ive only just got up so my brain should work for about the next twenty mins :)

Could you also do a little explanation on how to do an external 2pass with the new code (or how to do an internal one?) Looks very confusing now (also both stats boxes load/open stats...is that right??? :)

Cheers,
-Nic

[Nic]

__int64 credits=0;
int num = 5;
long a = 12413423;
credits += a;
credits += a;
credits += num;
printf("\n\n64: %ld",credits);

Just tried the above code, didn't get any problems......
Do you have service pack 5 on?

Good luck, hope you dont pull you hair out :)

-Nic

[-h]

I just committed my "changes".

I encountered the __int64 issue when "unsigned long total" and "unsigned long credits" in codec.c are __int64 instead.

I have no idea why internal 2-pass encodes are undersized now.. I assume I'm missing something obvious.

Internal encode instructions:
- perform 1st pass
- set mode to "2-pass - 2nd pass Int.", click on the "Internal 2-pass options" button and enter desired file size

External:
- perform 1st pass
- set mode to "2-pass - 2nd pass Ext.". Load 1st pass stats file in GKnot, do stuff to it, save as a new .stats file. Load the new stats file in XviD's second .stats text box.

-h

[Nic]

I hope the changes go in straight away cos im just downloading them :)

Im going to look into the codec.c __int64 problem as well. Oh, & maybe ill compile this with VC7.....Better go install it :)

Cheers,
-Nic

[Nic]

Latest Version 13/02/02

main:
www.freewebz.com/xvid

mirror:
xvid.stormpages.com

Cheers,
-Nic

Changes:
Compiled with VC7
-h's & Koepi's changes (Start Credits bitrate, etc)
(maybe slight bug with undersized 2pass files)

ps
Could people please test this version for me :) Compiling with VC7 has produced a smaller .DLL file & might be quicker or cause problems.
(The DShow is the older version, couldn't get it to compile under VC7 yet)

[saVe]

just an idea: couldn't it be possible that the undersizing in 2pass happens due to quantizer aliasing? when the codec can't choose quantizers that differ more than 2 from the previous one like it would without quantizer aliasing it's clear that filesize is less predictable.

can you confirm this?

[Koepi]

Nope, that's not the reason. Jumping prevention + intraframelock are known to possibly produce oversized files when too strict settings are used.
This is a matter of the new credits scaling algorithm IMHO. I'll look deeper at it when -h figured out how to solve the __int64 problem. Until that I'll stay with my build as it works as I expect it to ;) (No offense in here again, but I like my work and want to use it a little ;) )

Regards,
Koepi

[-h]

The credits undersizing is just mind-boggling.

During testing, I get:
1st pass size = 160000
desired size = 50000
curve = 3.2 (1st / desired)

Voila! Same as it was before, and I didn't change any of the 2-pass frame-size generation.

After a VC re-install, __int64 seems happy again, so I merged it (along with a minor interface enable/disable fix). Now I've just got to figure out what's going wrong with the curve calculation.

-h

[Koepi]

My encoding should be finished in ~2 hours, I'll checkout the CVS then again and try to give you a helping hand.
Mathematics often gave me a heaache because I just saw what I wanted to do and not what the thing I wrote down actually does - sometimes it's a blockade in the mind, so I think I can try to help! :)

Regards,
Koepi

[Nic]

Doing a quick test, it appears that a VC6 compile is slightly quicker than a VC7 one!

Then again ASM cant be speeded up, so I guess any difference is always going to be minimal.

-Nic

[-h]

The math is right, and it's generating the right curves, but "something" is breaking down when it comes to actually generating quants.

Maybe I'll just add "curve_movie *= 1.02" at the end ;)

-h

[rui]

Well, i just made a quick test using the latest Nic's build. The source was an AVI file, already encoded with divx4 (i am at work, and this is the only thing i have). I used quantization H.263, 5 search precision, no credits start or end, 2 pass using the Xvid 2 pass, not Gnot.
The source file has 8000 Kb in size, i didn't convert any audio, and pointed a 2000 KB end file size for the codec, but it turned out that the final AVI had ~ 15.000 Kb.
I don't know if this was a very small test and isn't valid, but the end file got much bigger than the source file.

[-h]

@rui - I certainly haven't seen that!

Could you list all the (20 odd ;)) parameters you used for encoding? sounds like credits or quantizer settings have messed it up.

-h

[Koepi]

rui,

the intraframe quantizer lock can screw up here, you should disable it for such small files.
(Intraframe quantizer lock can produce oversized files in case the bigger intraframes can't be compensated by interframes. As addition, the quantizer jumping prevention takes away more possibilities to compensate....)

Hopefully this solves the trouble,

Regards,
Koepi

[rui]

Well, lets see: my settings were: for the first pass i used motion search precision 5, quantization H.263, max keyframe interval 300, quantization tunning max 31 and min 1, fourCC Divx.
i didn't touch the debug tab, so everything was as default. I didn't choose smooth quantizer fluctuation.
For the 2 pass, i didn't use any credits options, both start credits and end credits weren't selected. I didn't choose Luminance masking either.
Desired filesize was 2000 Kb.
The source file was the AVI that Tom's Hardware Guide made about that running a quake3 loop and then removing the fan of the cpu.
Its an AVI divx4, i believe. It has a total size of 10.230 Kb (not the 8000 i said, but). The final AVI has a total of 15.174 Kb
Any more info please tell me, i will be glad to help.

[rui]

Well, i just made the exact same test, with the exact same settings, EXCEPT, that this time i choosed in the debug tab the "smooth quantizer fluctuation +-between 2 frames".
This time, the encoding time was MUCH faster (i am using a P2 350), i even saw in my monitor ~20 fps (??). And the final filesize was 2104Kb. :)

What did the "smooth quantizer fluctuation +-between 2 frames" made to change both the speed and final size?? Is this the "the intraframe quantizer lock" that Koepi talked about?

Thanks

[lar1r]

I tend to record TV shows and fit about 4 hrs on one CD. But because each hour is recorded seperately I don't know what the expected file size should be. Some files are less complex than others.

Will there be an option to simply state the bitrate for 2 pass mode?
(or have a choice b/w filesize or bitrate)

Thx

[wing1]

Is it my computer? Just download's the latest build13/2/2002. Removed Divx4.12 codec from system, installed xvid codec and registered filter,xvid.ax. Encoded a matrix trailer clip using (1-pass CBR, 1800kpbs, 5 motion, H263 quantizer, quantize min=1 & max=7, xvid 4CC, default for the rest). Play back using WMP and it acts as if there is no codec existed in current system, and it attempts to download it from web page. It went to the motion of searching for codec for about 30seconds, and then load video. Why is this happening? It does not act like this before. NT4.0(service pak6, 733 PIII, 256Mb, 8Mb ATI video card).

[-h]

@lar1r:
Setting a bitrate for 2-pass mode is the same as setting a desired file size - setting a desired size just saves you the calculation.

If you want the complexity spread across the 4 files, so they all have the same quality (thus different file sizes), you should do all 4 1st passes, find the file size that the .stats file captured (GKnot can do this?), then set the desired size for each file to be a scaled down copy of the 1st pass output so that it fits onto 1 CD. Or there might be a better way I've overlooked.

@wing1:
The XviD .ax filter you downloaded is not configured to play DivX content - you'll have to change the FourCC code of your avi to XVID instead of DIVX (the new codec frontend gives this option in a drop down box).

Edit: hmm just read that you set the fourcc, I'm not sure what's going on in that case.

-h

[wing1]

I also noticed during full screen playback, the filter is using pal mode framesize. The clip frame size is 512x384 @ 24fps. The codec that was used on the original clip is divx3.11. I used vdub to re-encode the clip to xvid for testing purposes.

[Franko30]

@ Koepi:

Yesterday evening, after reading, that you clened up the XVID dialogue etc. I downloaded and installed your Feb 13 binaries.

Trying to encode the evry same testfile as during the last few days, I encountered nothing but crasehs when starting to encoded, no matter what settings I used for XVID (set fourcc DivX or XVID, Quantizers etc.). Mostly VirtualDub crashed in a way that I couldn't even get a crashinfo - the first time an application made my whole XP system freeeze...

Then at 3 a.m. I gave up. :confused:

Just now I had the idea to download Nic's newest binaries (that should be the same now concerning XVID dialogue and features) and voilà - it works! :D


Only half an hour ago I could finally get a crashinfo.txt from VirtualDub. I'll try to add it to this post as attachment (don't want to fill this forum up including it into the post).

BTW:

Why is your xvid.dll 212 kb in size and Nic's only 180 kb?

Frank

edit: Well, it seems that file attachments still aren't possible.

[rui]

I placed some posts above a message saying that I did a test with Nic’s latest XviD build, and got an oversized file (bigger than the source file). That was true, but for that test I used a small avi file already compressed to divx4. So I wasn’t sure about the results being valid.
Now I have made another test, this time using a chapter ripped from a Pal DVD (The Haunting), and I must say this:
XviD is the best!! The file size was exactly the one that Gnot calculations gave me.
I want to apologize to Nic, –h and Koepi, the ones that are the face for XviD in these forums, for having some (but little) doubts about their XviD builds.
I made the same test again, this time using divx4, and the resulting avi file, besides being undersized, was inferior in quality to the XviD avi.
Ok, my world is in peace again. Keep the excelent work.
P.S. I am still using fourCC Divx, because of the postprocessing.

[-h]

Trying to encode the evry same testfile as during the last few days, I encountered nothing but crasehs when starting to encoded, no matter what settings I used for XVID (set fourcc DivX or XVID, Quantizers etc.). Mostly VirtualDub crashed in a way that I couldn't even get a crashinfo - the first time an application made my whole XP system freeeze...

Heh we should be proud then! :)

Only half an hour ago I could finally get a crashinfo.txt from VirtualDub. I'll try to add it to this post as attachment (don't want to fill this forum up including it into the post).

Attachments are probably still stuffed (I didn't see attachments pending approval listed in the mod menu), feel free to post the crash info here.

Why is your xvid.dll 212 kb in size and Nic's only 180 kb?

Nic's is compiled with VC7, Koepi's with VC6. Different compiler cores, I would say.

-h

[Franko30]

Originally posted by -h
feel free to post the crash info here.

-h

OK, here it comes!

Frank


Crashinfo VirtualDub 1.4.8:

VirtualDub crash report -- build 13719
--------------------------------------

Disassembly:
77d1ca00: jbe 77d1ca12
77d1ca02: push ebx
77d1ca03: mov bl,[ecx]
77d1ca05: mov dl,[eax]
77d1ca07: mov [eax],bl
77d1ca09: inc eax
77d1ca0a: mov [ecx],dl
77d1ca0c: dec ecx
77d1ca0d: cmp ecx,eax
77d1ca0f: ja 77d1ca03
77d1ca11: pop ebx
77d1ca12: ret 0008
77d1ca15: sub ecx,00000069
77d1ca18: jz 77d1c85c
77d1ca1e: sub ecx,00000007
77d1ca21: jz 77d47faf
77d1ca27: sub ecx,00000003
77d1ca2a: jz 77d1caf5
77d1ca30: dec ecx
77d1ca31: dec ecx
77d1ca32: jz 77d1c863
77d1ca38: sub ecx,00000003
77d1ca3b: jnz 77d1c97d
77d1ca41: cmp byte ptr [ebp+11],00
77d1ca45: push 10
77d1ca47: pop ebx
77d1ca48: jz 77d1c867
77d1ca4e: cmp dword ptr[ebp-32],00000000
77d1ca52: setz al
77d1ca55: dec al
77d1ca57: and al,e0
77d1ca59: add al,78
77d1ca5b: mov [ebp+11],al
77d1ca5e: jmp 77d1c867
77d1ca63: cmp [ebp-20],eax
77d1ca66: jnz 77d4ed06
77d1ca6c: mov ecx,[ebp-12]
77d1ca6f: mov ecx,[ecx-4]
77d1ca72: mov [ebp-44],ecx
77d1ca75: mov [ebp-40],eax
77d1ca78: jmp 77d1c89d
77d1ca7d: add ecx,esi
77d1ca7f: jmp 77d1c9d5
77d1ca84: mov dl,[eax] <-- FAULT
77d1ca86: inc eax
77d1ca87: test dl,dl
77d1ca89: jnz 77d1ca84
77d1ca8b: sub eax,esi
77d1ca8d: xor esi,esi
77d1ca8f: xor edx,edx
77d1ca91: cmp [ebp-16],edx
77d1ca94: jge 77d4a796
77d1ca9a: sub [ebp-8],eax
77d1ca9d: cmp esi,edx
77d1ca9f: jnz 77d3ff80
77d1caa5: cmp dword ptr[ebp-28],00000000
77d1caa9: jnz 77d4eca1
77d1caaf: cmp dword ptr[ebp-8],00000000
77d1cab3: jg 77d4eccc
77d1cab9: test eax,eax
77d1cabb: jz 77d1cad3
77d1cabd: dec eax
77d1cabe: cmp dword ptr[ebp-4],00000000
77d1cac2: jz 77d1c939
77d1cac8: mov dl,[ecx]
77d1caca: mov [edi],dl
77d1cacc: inc edi
77d1cacd: inc ecx
77d1cace: dec dword ptr[ebp-4]
77d1cad1: jmp 77d1cab9
77d1cad3: dec eax
77d1cad4: mov [ebp-24],eax
77d1cad7: test esi,esi
77d1cad9: jz 77d1c929
77d1cadf: push dword ptr[ebp-36]
77d1cae2: push 00
77d1cae4: push dword ptr[077d6d1a4h]
77d1caea: call dword ptr[077d112e4h]
77d1caf0: jmp 77d1c929
77d1caf5: test esi,esi
77d1caf7: jnz 77d3ff4b
77d1cafd: add dword ptr[ebp-12],00000000

Windows 5.1 (Win2000 build 2600) []

EAX = 00000002
EBX = 0000000a
ECX = 00000002
EDX = 00000000
EBP = 0477f7d8
DS:ESI = 0023:00000003
ES:EDI = 0023:0477f8bd
SS:ESP = 0023:0477f7a0
CS:EIP = 001b:77d1ca84
FS = 0038
GS = 0000
EFLAGS = 00010202

MM0 = 0000000000000000
MM1 = 0000000000000000
MM2 = 0080008000800080
MM3 = 0000000000000000
MM4 = ddc1666666666800
MM5 = aa25c89a02752000
MM6 = ddc1666666666800
MM7 = f800000000000000
Crash reason: Access Violation

Thread 00000428 (Main thread)
T:\projects\VirtualDub_old\main\Init.cpp(115)
T:\projects\VirtualDub_old\main\Init.cpp(134)
T:\projects\VirtualDub_old\main\Init.cpp(152)
T:\projects\VirtualDub_old\main\Init.cpp(214)
T:\projects\VirtualDub_old\main\Main.cpp(181)
T:\projects\VirtualDub_old\main\Main.cpp(204)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(427)
Thread 000004dc (FastWriteStream)
Thread 000004d8 (Processing)
T:\projects\VirtualDub_old\main\Dub.cpp(2809)
T:\projects\VirtualDub_old\main\Dub.cpp(2813)
T:\projects\VirtualDub_old\main\VideoSequenceCompressor.cpp(336)
Thread 000004e8 (I/O processing)


77d1ca84: USER32!wsprintfA(0, 0) [77d10000+c96a+11a]
77d1c97c: USER32!wsprintfA(77f888, f8a04e) [77d10000+c96a+12]
00f61e50: xvid!00001e50(477f888, f8a030)
00f6566b: xvid!xvid_encore(df2258, df2264) [00f60000+4930+d3b]
00f64973: xvid!xvid_encore(3a9de, f8ffffff) [00f60000+4930+43]
00f6152b: xvid!0000152b(df3968, 477f92c)
77f416f5: ntdll!RtlFreeHeap(12, e409e8) [77f40000+1597+15e]
77f416f5: ntdll!RtlFreeHeap(77f42e0f, 77f4180b) [77f40000+1597+15e]
77f42e0f: ntdll!RtlTimeToTimeFields(77f4180b, 0) [77f40000+2a1d+3f2]
77f4180b: ntdll!RtlAllocateHeap(0, 88) [77f40000+16f8+113]
77f416f5: ntdll!RtlFreeHeap(77f417cd, 0) [77f40000+1597+15e]
77f417cd: ntdll!RtlAllocateHeap(0, 2) [77f40000+16f8+d5]
00f6433c: xvid!DriverProc(df3968, 477fe04) [00f60000+4140+1fc]
77f416f5: ntdll!RtlFreeHeap(77f417cd, 77f4180b) [77f40000+1597+15e]
77f417cd: ntdll!RtlAllocateHeap(77f4180b, 143450) [77f40000+16f8+d5]
77f4180b: ntdll!RtlAllocateHeap(143450, 7ffd8000) [77f40000+16f8+113]
1a41c670: urlmon!CompareSecurityIds(14, 1729a8) [1a400000+1bfc3+6ad]
1a4015ca: urlmon!000015ca(0, 1a41c60a)
1a41c60a: urlmon!CompareSecurityIds(477fb40, 1) [1a400000+1bfc3+647]
1a41c445: urlmon!CompareSecurityIds(1729a8, 0) [1a400000+1bfc3+482]
76261694: CRYPT32!00001694(1, 0)
77f41858: ntdll!RtlAllocateHeap(400000, 1) [77f40000+16f8+160]
77f41898: ntdll!RtlImageDirectoryEntryToData(400000, 1) [77f40000+185b+3d]
77f55c91: ntdll!RtlConvertExclusiveToShared(400000, 1) [77f40000+15c40+51]
77f55cc3: ntdll!RtlConvertExclusiveToShared(477fc64, 1) [77f40000+15c40+83]
77f6e3aa: ntdll!LdrInitializeThunk(0, 18) [77f40000+2e386+24]
77f55e66: ntdll!RtlConvertExclusiveToShared(477fc50, 77f48b49) [77f40000+15c40+226]
77f48b49: ntdll!CsrNewThread(7ffd8000, 7ffdf000) [77f40000+8a8e+bb]
77f48a8d: ntdll!RtlUnicodeStringToInteger(77f6f3ef, 77f48a57) [77f40000+8862+22b]
77f6f3ef: ntdll!NtTestAlert(77f48a57, 477fd30) [77f40000+2f3e3+c]
77f48a57: ntdll!RtlUnicodeStringToInteger(477fd30, 0) [77f40000+8862+1f5]
77f48a57: ntdll!RtlUnicodeStringToInteger(77f6e5bf, 77f4107b) [77f40000+8862+1f5]
77f6e5bf: ntdll!NtContinue(77f4107b, 477fd30) [77f40000+2e5b3+c]
77f4107b: ntdll!KiUserApcDispatcher(477fd30, 1) [77f40000+106c+f]
73b4175d: MSVFW32!ICSendMessage(df3968, 1) [73b40000+1734+29]
73b4469c: MSVFW32!ICCompress(73b59460, 4008) [73b40000+463b+61]
0477fe98: 0477fe98(0, ffffff)
0046d99c: VideoSequenceCompressor::packFrame(73b59460, 1)
0477fe98: 0477fe98(0, ffffff)
00467167: Dubber::WriteVideoFrame(3ad0000, 477fec3)
0477fe98: 0477fe98(826376b1, 477ff70)
77e578b0: kernel32!WaitForSingleObjectEx(77e59d6a, c) [77e40000+17800+b0]
77e59d6a: kernel32!WaitForSingleObject(c, 3e8) [77e40000+19d5b+f]
0040b740: AVIPipe::getReadBuffer(40b75a, adafb0)
0040b75a: AVIPipe::getReadBuffer(adafb0, 0)
00467b23: Dubber::ProcessingThread(467bcf, 4880000)
00467bcf: Dubber::ProcessingThread(4880000, 3ad0000)
00467a96: Dubber::ProcessingThreadKickstart(47f7c8, ad9f90)
0047f7c8: _threadstart@4(ad9f90, 0)
77e602ed: kernel32!OpenConsoleW(3df04e8, 0) [77e40000+20235+b8]

-- End of report

[-h]

Darn that's not from any of the .asm files - it looks like a compiler issue. I couldn't trace that back to the code itself unless I had the asm listings generated when that dll was compiled :(

-h

[Koepi]

I'll rebuild my dll today, checking the code. It doesn't crash here, that's amazing... Maybe I included an older build instead that one I'm currently working with....
EDIT:
Nope, it's the right dll, doesn't crash here... If I use XviD and start saving an avi more than once, I've to reopen the XviD compressor dialog because else I would get an "video encoder error: -100".
Maybe it's some of the variables I use, maybe this is a memory leak,... I've to check that. Expect an update in a few minutes.

I'm sorry that you tested for nothing :-(

Regards,
Koepi

[-h]

Dude Koepi.. what on earth is trillian doing!

Can you describe what you mean by saving an avi more than once? Sounds like something I did.

-h

[-h]

Trillian died again. I just committed my changes, nothing major but should fix that crashing bug & roll in some more debug output.

-h

[Nic]

Ill put a new build up tomorrow (taken today off to be with my girl) :)

-Nic

[Koepi]

Well well, so then I put up a new build ;)

I fixed the issue with the first pass crashing (dumb error from my side, tried to print out an __int64 as int...).
Further -h solved the problem where aborting an encoding process and starting over would result in a "can't start video compressor: -100" error.
Else it's just the most recent CVS which most of my changes incorporated already, but readded debug output on both passes to see if everything works alright.

Best Regards,
Koepi

[ChristianHJW]

@koepi, @nic, @-h :

nice battle you have here ... who is the leader in nr. of new builds per day right now :D ? If any of you could find interest in writing a MCF parser instead you made me a happy man .... Tronic stated there would be happening something on monday .... and he wanted me to organize that a MCF parser is being done .... but i honestly dont have a clue who to ask now :( .... Nic would be my 1st bet, with respect to his unrivalled background in DirectShow, but he fell in love with XviD it seems .... ;)

[-h]

Heh well I haven't used, let alone compiled the dshow filter yet, and haven't even looked at dshow as an API. So I might not be your best bet :)

Then again, I'm running low on ideas for XviD that I'm experienced enough to implement. Might be time for a change.

-h

[ChristianHJW]

You're gladly invited to help us out -h .... i remember when Matthias Lenk coded the excellent Dedynamic filter, he said it wasnt big deal at all. The main core of his Dedynamic.exe was coded in assembler ( for speed ).... all he did was to download the M$ DirectShow SDK and played with one of the example filters, i guess it was called 'gargle' or so .... 2 days after that i had the 1st alpha on my HDD .... it worked fine from the very 1st day ... Blacksun implemented it in PowerDivX and the rest is history .... you see, its very easy :D ...

[Nic]

I did offer to give up the "battle"....But I think Koepi's winning, but ill keep mine up for now :) (Ive got it so it does the CVS download & compile from a batch file :)

(Hmmmm...The new project manager at work has very good DShow experience....maybe I can rope him in as well :) :)

-Nic

[Nic]

Latest build up :)

www.freewebz.com/xvid

-Nic