Problem with Koepi's XviD-09122002-1

[MoonWalker]

I have just encoded a clip with this build but I can't decoded it with ffdshow-20021113. In bsplayer is sais overlay failed and in mplayer it doesn't load...Anyone has the same problem?

Thanks,
MoonWalker

[NiTroGen]

What about the original XviD decoder? Did you try it? Does it work?

[[Toff]]

Maybe you can post your xvid settings.

At least it work here with the default settings and ffdshow from Nov 29 2002.

[bond]

for me there are no problems using 091202 with ffdshow131102 or nic's xvid decoder (also with bsplayer)

[MoonWalker]

Neither Nic's works..It sais Unknown format(XviD)...

My setting where 1-pass quality, b-frames(the defaults with 4), and chroma ME...

MoonWalker

[Koepi]

You seem to finally have somehow messed up your system %) That's quite an unusual behaviour - but certainly not caused by xvid-09122002-1.exe.

Koepi

[Gaia]

Works fine, no decoding problems, i have tried lots of different settings(b-frames+Qpel+crom. mot. etc etc.) but i don't use bsplayer(because i don't like it). I haven't tried GMC...

I use ffdshow 20021129, Zoomplayer and mplayer 6.** without any problems...

[ookzDVD]

No problem on my machine, Win2k, Sp3, Zoomplayer 3.0 beta2, Gabest's MPC 6.4.006,
2-pass int, with B-frame : 3/150/100, Qpel, fourCC:XVID, DV50 compatibility enabled.
ffdshow 20021113 with "used XviD":unchecked and Nic's postprocessing,
with IDCT:XviD.

[cjv]

No problems here at all. Actually, I encoded 6 movies today, and they all look great!

MPEG, DX50, CME, 3/100/150, no Qpel, no GMC, 2-pass internal. Win2k SP3, XP SP1, bsplayer, ffdshow 11-13, no postproc.

cjv

[yaz]

Originally posted by MoonWalker
Neither Nic's works..It sais Unknown format(XviD)...


imho, koepi's right, it prompts a system failure. bsplayer flicks this when trying to load a broken clip (even if 4cc is given!). mplayer shows unknown format for the same. i always got it with clips with interrupted encoding. imho, the file's improperly closed.

y

[MoonWalker]

Well, I just reencode the file and it's ok..Thanks all :p ...

BTW Have anyone noticed some random noise ine faces when using qpel??

Thanks,
MoonWalker

[Tommy Carrot]

I've another problem.

I doesn't matter if you set qpel on or off, it's always off, if you set off the automatic qpel decision.

And i don't like the automatic decision. The picture is definatly more blurrier than with the nov.25. build. (ok, the other new features can cause this too, but i suspect the qpel/hpel switcher.)

[Sirber]

I've got some crash with this build using VDub.

Here's my settings:

Quant: MPEG
Max I: 300
Min I: 1
Max B: 2
Quant: 150/100
DIVX5 Comp enabled
Alt Curve with 175/80, 30% str.

VirtualDub crash report -- build 14328 (release)
--------------------------------------

Disassembly:
013ebc60: ff03 inc dword ptr [ebx]
013ebc62: ff03 inc dword ptr [ebx]
013ebc64: c08b73580fafc6 ror byte ptr [ebx-50f0a78d], c6
013ebc6b: 8b09 mov ecx, [ecx]
013ebc6d: 03cf add ecx, edi
013ebc6f: 03c8 add ecx, eax
013ebc71: 894b4c mov [ebx+4c], ecx
013ebc74: d1ee shr esi, 1
013ebc76: 8d1412 lea edx, [edx+edx]
013ebc79: 03d2 add edx, edx
013ebc7b: 03d2 add edx, edx
013ebc7d: 8d4c2d00 lea ecx, [ebp+ebp+00]
013ebc81: 03c9 add ecx, ecx
013ebc83: 03c9 add ecx, ecx
013ebc85: 0fafce imul ecx, esi
013ebc88: 8bb42480010000 mov esi, [esp+180]
013ebc8f: 8b6e08 mov ebp, [esi+08]
013ebc92: 03ea add ebp, edx
013ebc94: 03e9 add ebp, ecx
013ebc96: 896b44 mov [ebx+44], ebp
013ebc99: 8b6e04 mov ebp, [esi+04]
013ebc9c: 03ea add ebp, edx
013ebc9e: 03e9 add ebp, ecx
013ebca0: 896b40 mov [ebx+40], ebp
013ebca3: 8b6c243c mov ebp, [esp+3c]
013ebca7: 8b7500 mov esi, [ebp+00]
013ebcaa: 03f7 add esi, edi
013ebcac: 03f0 add esi, eax
013ebcae: 897328 mov [ebx+28], esi
013ebcb1: 8b742444 mov esi, [esp+44]
013ebcb5: 03f7 add esi, edi
013ebcb7: 03f0 add esi, eax
013ebcb9: 89732c mov [ebx+2c], esi
013ebcbc: 8b742440 mov esi, [esp+40]
013ebcc0: 03f7 add esi, edi
013ebcc2: 03f0 add esi, eax
013ebcc4: 897330 mov [ebx+30], esi
013ebcc7: 8bb4247c010000 mov esi, [esp+17c]
013ebcce: 8d343e lea esi, [esi+edi]
013ebcd1: 03f0 add esi, eax
013ebcd3: 897334 mov [ebx+34], esi
013ebcd6: 8b7508 mov esi, [ebp+08]
013ebcd9: 03f2 add esi, edx
013ebcdb: 03f1 add esi, ecx
013ebcdd: 89733c mov [ebx+3c], esi
013ebce0: 8b6d04 mov ebp, [ebp+04]
013ebce3: 03ea add ebp, edx
013ebce5: 03e9 add ebp, ecx
013ebce7: 896b38 mov [ebx+38], ebp
013ebcea: 8bac2490010000 mov ebp, [esp+190]
013ebcf1: 8b14ad60d44001 mov edx, [ebp*4+0140d460] <-- FAULT
013ebcf8: 895350 mov [ebx+50], edx
013ebcfb: 8b14ade0d34001 mov edx, [ebp*4+0140d3e0]
013ebd02: 8bac24a8010000 mov ebp, [esp+1a8]
013ebd09: 895354 mov [ebx+54], edx
013ebd0c: 8b94248c010000 mov edx, [esp+18c]
013ebd13: f7c200000300 test edx, 00030000
013ebd19: c7436800000000 mov dword ptr [ebx+68], 00000000
013ebd20: 7546 jnz 013ebd68
013ebd22: 8b7304 mov esi, [ebx+04]
013ebd25: 8d5601 lea edx, [esi+01]
013ebd28: 83fe00 cmp esi, 00
013ebd2b: 0f4cf2 cmovl esi, edx
013ebd2e: 83e6fe and esi, fe
013ebd31: 8b13 mov edx, [ebx]
013ebd33: 897304 mov [ebx+04], esi
013ebd36: 8d7a01 lea edi, [edx+01]
013ebd39: 83fa00 cmp edx, 00
013ebd3c: 0f4cd7 cmovl edx, edi
013ebd3f: 83e2fe and edx, fe
013ebd42: 8b730c mov esi, [ebx+0c]
013ebd45: 8913 mov [ebx], edx
013ebd47: 8d5601 lea edx, [esi+01]
013ebd4a: 83fe00 cmp esi, 00
013ebd4d: 0f4cf2 cmovl esi, edx
013ebd50: 83e6fe and esi, fe
013ebd53: 89730c mov [ebx+0c], esi
013ebd56: 8b7308 mov esi, [ebx+08]
013ebd59: 8d5601 lea edx, [esi+01]
013ebd5c: 83fe00 cmp esi, 00
013ebd5f: 0f db 0f

Windows 5.1 (WinXP build 2600) [Service Pack 1]

EAX = 00000000
EBX = 0400edf8
ECX = 00000000
EDX = 00000000
EBP = 30347039
DS:ESI = 0023:033b0090
ES:EDI = 0023:00000000
SS:ESP = 0023:0400ec08
CS:EIP = 001b:013ebcf1
FS = 003b
GS = 0000
EFLAGS = 00010202

MM0 = 0000000000000012
MM1 = 000000000000000c
MM2 = 9d9d9d9d9d9d9d9d
MM3 = 0000000000000000
MM4 = 0000000000000000
MM5 = 0000000000000078
MM6 = 000000000000007b
MM7 = 00000000000001fa
Crash reason: Access Violation

Thread 00000b68 (Main thread)
T:\projects\VirtualDub_old\main\Init.cpp(219)
T:\projects\VirtualDub_old\main\Init.cpp(238)
T:\projects\VirtualDub_old\main\Init.cpp(256)
T:\projects\VirtualDub_old\main\Init.cpp(318)
T:\projects\VirtualDub_old\main\Main.cpp(182)
T:\projects\VirtualDub_old\main\Main.cpp(205)
T:\projects\VirtualDub_old\main\VideoSource.cpp(566)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(126)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(128)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(126)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(128)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(126)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(128)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(411)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(427)
Thread 00000b98 (FastWriteStream)
Thread 00000b9c (Processing)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1455)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1483)
T:\projects\VirtualDub_old\main\Dub.cpp(2840)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(515)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(526)
T:\projects\VirtualDub_old\main\VideoSequenceCompressor.cpp(358)
T:\projects\VirtualDub_old\main\VideoSequenceCompressor.cpp(371)
T:\projects\VirtualDub_old\main\Dub.cpp(3022)
T:\projects\VirtualDub_old\main\Dub.cpp(3220)
T:\projects\VirtualDub_old\main\Dub.cpp(2835)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1455)
T:\projects\VirtualDub_old\main\VideoSource.cpp(1483)
T:\projects\VirtualDub_old\main\Dub.cpp(2840)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(515)
T:\projects\VirtualDub_old\main\FilterSystem.cpp(526)
T:\projects\VirtualDub_old\main\VideoSequenceCompressor.cpp(358)
Thread 00000ba0 (I/O processing)


013ebcf1: xvid!xvid_init [013a0000+a0b4+41c3d]
77f46e44: ntdll!RtlTimeFieldsToTime [77f40000+64ff+945]
77f50d06: ntdll!RtlUnwind [77f40000+10c44+c2]
77f6591f: ntdll!NtContinue [77f40000+25913+c]
77f50d2f: ntdll!RtlUnwind [77f40000+10c44+eb]
77f41ef9: ntdll!RtlpUnWaitCriticalSection [77f40000+1bfe+2fb]
77f41ec8: ntdll!RtlpUnWaitCriticalSection [77f40000+1bfe+2ca]
77f417b2: ntdll!RtlAllocateHeap [77f40000+16a1+111]
013f9d0f: xvid!xvid_init [013a0000+a0b4+4fc5b]
013f9c06: xvid!xvid_init [013a0000+a0b4+4fb52]
013eb6e6: xvid!xvid_init [013a0000+a0b4+41632]
77f4166a: ntdll!RtlFreeHeap [77f40000+156b+ff]
013f9b96: xvid!xvid_init [013a0000+a0b4+4fae2]
013cea8e: xvid!xvid_init [013a0000+a0b4+249da]
013cebec: xvid!xvid_init [013a0000+a0b4+24b38]
013cea8e: xvid!xvid_init [013a0000+a0b4+249da]
013bc600: xvid!xvid_init [013a0000+a0b4+1254c]
013b9b90: xvid!xvid_init [013a0000+a0b4+fadc]
77e748b0: kernel32!SetThreadExecutionState [77e40000+34772+13e]
013bb3b4: xvid!xvid_init [013a0000+a0b4+11300]
013bb3ef: xvid!xvid_init [013a0000+a0b4+1133b]
77e748b0: kernel32!SetThreadExecutionState [77e40000+34772+13e]
77e7487d: kernel32!SetThreadExecutionState [77e40000+34772+10b]
77f69ba4: ntdll!RtlConvertUlongToLargeInteger [77f40000+29b3d+67]
77f69b78: ntdll!RtlConvertUlongToLargeInteger [77f40000+29b3d+3b]
77f50bf4: ntdll!CsrCaptureMessageString [77f40000+10a8b+169]
77fa4dbd: ntdll!KiUserExceptionDispatcher [77f40000+64daf+e]
77e53887: kernel32!RaiseException [77e40000+13837+50]
77f607af: ntdll!_vsnprintf [77f40000+20782+2d]
77f60909: ntdll!_vsnprintf [77f40000+20782+187]
77f608ce: ntdll!_vsnprintf [77f40000+20782+14c]
77f4b4ab: ntdll!vDbgPrintExWithPrefix [77f40000+b474+37]
77e53887: kernel32!RaiseException [77e40000+13837+50]
013e96bc: xvid!xvid_init [013a0000+a0b4+3f608]
013f2f27: xvid!xvid_init [013a0000+a0b4+48e73]
013f27fb: xvid!xvid_init [013a0000+a0b4+48747]
013bc9fc: xvid!xvid_init [013a0000+a0b4+12948]
013b846e: xvid!xvid_init [013a0000+a0b4+e3ba]
77d1a657: USER32!wvsprintfA [77d10000+a4fc+15b]
77d1a564: USER32!wvsprintfA [77d10000+a4fc+68]
77e749fd: kernel32!OutputDebugStringA [77e40000+349b7+46]
013a2619: xvid!00002619
013aa09f: xvid!xvid_encore [013a0000+a05c+43]
013a543f: xvid!0000543f
013a9d44: xvid!DriverProc [013a0000+9ac4+280]
0473928e: DVD2AVI!0000928e
04736254: DVD2AVI!00006254
04733311: DVD2AVI!00003311
0473a986: DVD2AVI!vfGetPluginFunc [04730000+9a30+f56]
0043e31e: cc_row()
0043eda9: Resampler::_DoRow()
0043f4a4: Resampler::Process()
00436ce3: resize_run()
73b2181d: MSVFW32!ICSendMessage [73b20000+17f4+29]
73b24789: MSVFW32!ICCompress [73b20000+4728+61]
00471da1: VideoSequenceCompressor::packFrame()
0046b3ff: Dubber::WriteVideoFrame()
77e5a652: kernel32!WaitForSingleObjectEx [77e40000+1a5a2+b0]
77e5ac21: kernel32!WaitForSingleObject [77e40000+1ac12+f]
0046bebf: Dubber::ProcessingThread()
0046bd86: Dubber::ProcessingThreadKickstart()
0048419c: _threadstart@4()
77e5d33b: kernel32!RegisterWaitForInputIdle [77e40000+1d2f8+43]

-- End of report

[Koepi]

sirber:

which CPU are you running it on?

Tommy Carrot:

if you don't like a feature, just switch it off, but don't whine around that you don't like it! The dyn hpel/qpel decision is giving performance improvement on "mixed" material.

all:

hell, what a bitching & whining around the last two days. You wanted developer binaries, you got warned that there is some experimental code in which can break _everything_, you know about the risks, but you complain?
Come on, sit back, relax, and think about it again. I'd be lucky not to provide developer binaries and safe some work with "unnecessary" work like reminding you about the readme's, documentation, development status,...

Thanks for respecting that.

Best regards
Koepi

[TheXung]

You're Q-pel checkbox isn't working. Only the dynamic one. Frankly, I didn't even see where the dynamic flag was in the api. I just assumed the dynamic decision was built in q-pel now. I still don't see where the dynamic decision flag is.

[Koepi]

TheXung:

maybe my local source tree has different code than CVS? E.g., check the "About" box.

I've got some code from sysKin directly to check it out.

Koepi

[Infophreak]

Yes, it is quite important that there are someone out there who are making binaries available of the latest and greatest in the CVS tree. Not all of us have either the money to buy a compiler, or the will to download a pirate version of MSVC. Of course, there is ICL, but that's only usable for 30 days, right?

I'd help out testing, if it wasn't for my slow-a** 600MHz/128MB RAM computer with way too little HDD space free (the latter is the biggest problem). :(

It would be really nice if there was such a thing as an MPEG-4 validator in existance, but I guess that that is only going to happen if someone sits down and codes it. Quite "unsexy" work, and noone wants to do "unsexy" stuff, right?

[Koepi]

We're trying to validate our code every now-and-then with reference ISO impementations, thus we have a kind of a spec-validator (if it doesn't decode it's not spec compliant, quite easy ;) ).

But it can happen that some code snapshot isn't spec compliant, which get's "repaired" ASAP. That's what I mean with "don't whine around" - it'll get fixed for sure.

Then on the other hand, writing "xvid-09122002-1 seems not to be mpeg4 compliant" (and just as a note, not with anything attached to it) is quite useful for us indeed.

Regards
Koepi

[Sirber]

Modo --> Please erase this reply. I hitted "submit" twice by error. Sorry

[Sirber]

@Koepi

I have a AMD Athlon TBird 1.333 Ghz, with 512 PC-133 SDRAM, on a ECS K7S5A. I wrote to VDub about this because I have no problem with DVD2AVI, so I don't think it's a XviD problem.

XviD stable release works #1.

[cjv]

@Infophreak:

Slightly OT, but have you tried compiling XviD with http://mingw.org ?

I used to use mingw all the time on win32 (before our college gave us VC++ for free this year). It may not be the sexiest, and it may not even work with XviD (I haven't tried it, but I recall seeing makefiles for it), but hey, its a great compiler, its free and worth a try. :)

cjv

[mfluder]

Hi,

I'm using MinGW to compile XviD for a long time now. With stable branch it works out of the box but with dev-api-3 branch you have to modify some files to be able to compile it. Even though I have VC++ I'm still using MinGW because gcc is a great compiler and if used properly it can produce very fast binaries where speed is comparable to ICL. All this and the fact that is opensource (which is the main reason I'm using it) makes it the best compiler in my opinion. If there is enough interest I can write a step by step guide on how to compile dev branch.

mfluder

[-h]

I'm surprised dev-api-3 doesn't work straight from CVS - a number of the core developers use *nix almost exclusively.

-h

[JimiK]

Sorry that I also stay offtopic. I'm also using MinGW and I was not able to compile the source (too dumb) ;) So I would definately vote for an document that explains how to do it.
Thank you very much,
JimiK

[MoonWalker]

Some on-topic now :)..

I have noticed that the stats file doesn't have the same frame number as the movie..At my recent encoding the movie has 130647 (taken from the avs) and the stats file ended with 130651 (taken from statsreader and Gknot)..Is this normal???

My setting :

Motion : 6
Quant : Mpeg
Chroma checked
B-Frames 4/150/100

and credits trim


MoonWalker

[Koepi]

those 4 bframes require 4 delay-frames for filling the buffers, so it is normal.

[sam_b]

Sorry, to go back guys, but I would very much appreciate a step-by-step compilation quide with mingw. I tried yesterday and failed miserably. Not tried stable code.

[mfluder]

Originally posted by -h
I'm surprised dev-api-3 doesn't work straight from CVS - a number of the core developers use *nix almost exclusively.


It's not that much work to make it compile. You just have to add some includes and also you have to use portab.h from stable branch which also needs to be modified a little.

@all
I'll write instructions on how to do this, just give me a few hours because I can't do it right now.

mfluder

[mfluder]

I assume you already know how to use WinCVS and that you downloaded dev-api-3 sources. If not just tell me and I'll explain how to configure WinCVS too. Now download MinGW from http://www.mingw.org/ install it and add "C:\MinGW\bin" to your path. You also need to download nasm from http://nasm.sourceforge.net/. You need to download win32 version of it. You also have to rename "nasmw.exe" to "nasm.exe" and copy it to a directory which is in your path ("C:\MinGW\bin" for example). You are now ready to start compiling but you first have to modify some files.

xvidcore\src\image\font.c
You have to add this includes at the beginning of the file:

#include <stdarg.h>
#include <stdio.h>


xvidcore\src\image\image.h
Also like the previous one, at the beginning of the file:

#include <string.h>


xvidcore\src\utils\ratecontrol.c
Here you need to replace this:

DEBUGCBR((int32_t) (rate_control->frames - 1), rate_control->rtn_quant,
(int32_t) deviation);

with this:

DPRINTF(DPRINTF_DEBUG, "CBR: frame: %i, quant: %i, deviation: %i\n",
(int32_t) (rate_control->frames - 1), rate_control->rtn_quant,
(int32_t) deviation);

When I think about it I could add this as macro in portab.h but I guess there is no need for that as ratecontrol.c will be replaced soon with new rewriten version.

xvidcore\src\portab.h
This is the most important file that needs modification. I don't have time to write changes so I'll attach it to this post. I'll just say that this is portab.h from stable branch and I defined some macros in it which are specific for dev branch like DEBUG1, DEBUG2, etc.

There are some other things that have to be done (like Makefiles) but I don't have time to do it right now (I'm off to see M. Night Shyamalan's Signs) but when I get back I'll post about this and also explain different flags in Makefiles that can make binaries faster.
Oh yes, for compiling core you have to use djgpp makefile - Makefile.dj. You will also get some warnings from gcc but it's okay, they are not that important.

mfluder

[mfluder]

I forgot to attach portab.h so here it is.

[mfluder]

Ok, now about makefiles. For core makefile - Makefile.dj you have to add "-DBFRAMES_DEC" as a flag to enable bframes decoding. You can add this flag right after "-DBFRAMES" or you can make it as a separate flag, whatever you like more. That's all you need to make the core compile and have all features enabled. I suggest you compile first without any other flags enabled and then test speed by using some short clip and avs2avi for example where you can see average fps and encoding time. Concerning the vfw makefile - Makefile.mingw I suggest you disable all optimization flags as there is not anything you can optimize for speed in vfw interface and they will only make your dll file bigger if you unroll loops. I'll explain what are the most important flags that can influence core speed:

-march=? - this will optimize the code for specific processor. I'll list the options you can use.

These are valid for every gcc version:

-march=i386 -mcpu=i386
-march=i486 -mcpu=i486
-march=i586 -mcpu=i586
-march=i686 -mcpu=i686
-march=pentium -mcpu=pentium
-march=pentiumpro -mcpu=pentiumpro

And these are valid only for gcc versions greater than 3.1 (if you are using current MinGW you will have gcc 3.2):

-march=pentium-mmx -mcpu=pentium-mmx
-march=pentium3 -mcpu=pentium3
-march=pentium4 -mcpu=pentium4
-march=athlon -mcpu=athlon
-march=k6 -mcpu=k6
-march=k6-2 -mcpu=k6-2
-march=k6-3 -mcpu=k6-3
-march=athlon-tbird -mcpu=athlon-tbird
-march=athlon-xp -mcpu=athlon-xp
-march=athlon-mp -mcpu=athlon-mp

You should try a few different optimizations. For me, for example, -march=i686 gives better results than -march=pentium-mmx.

-funroll-loops - as the name says this will unroll loops and make the loops faster. For me this doesn't improve speed at all but that doesn't mean it will not improve speed for you so you should definately try it and see for yourself. Just to mention that this will make dll bigger in size.

-O, -O2, -O3 - in my case this have the most influence on speed. -O3 will usually give you the best results. You will have faster code at the expense of longer compilation time but I guess you can wait a little longer :)

These are the flags that I found to have the most influence on speed. If someone else knows some other flags please post them. I suggest you also take a look at Makefile.linux because there you have many flags you can also test. Here are the flags that I use:

CFLAGS = -Wall -DARCH_X86
CFLAGS += -DBFRAMES -DBFRAMES_DEC
CFLAGS += -march=i686 -mcpu=i686
CFLAGS += -O3

I hope someone will find this useful. If you have some questions please ask and I'll try to answer them.

mfluder

[Infophreak]

How fast are the binaries produced by mingw compared with ICL 7.0 which appears to be the speed king these days?

[greycortex]

Hello all,

I've recently encoded a capture I made with my ASUS V7700 card an episode of "Home Movies" On the Cartoon Network. With the new 12/9/2002 Koepi's build of Xvid, I decided to give bframes and chroma motion detection a go. I'm not sure, but I think that the 11/2002 ffdshow filter doesn't process this information well, is this correct? ie, when I view in virtualdub, all is well, but when I fire up mplayer I get some very odd artifacts where there's some bad chroma noise. The wierdest thing about this is that it appears normal initially, then gets progressively worse. I've included a quick screenshot of when it gets bad.

The question is this: should I just not use the chroma motion when I've probably got a bunch of chroma noise, as in a ntsc capture, or is there something odd in the ffdshow config, as it was ok in Vdub?

Thanks!

[Koepi]

grey,

chroma motion is something which could be called "search precision 7", it's additional search for movement.
Thus it can't produce those artifacts you describe, it's just an addition to the normal motion estimation. Qpel can cause some noisy blocks though. Maybe you're experiencing them.

As you write that it's a real bad problem you might have switched GMC on - it's buggy ATM, don't use it.

Regards
Koepi

[JimiK]

@mfluder
You've got PM

@greycortex
Koepi said that croma motion has no influence on chroma in the picture. It's just another refined motion estimation. He said you could see it as motion search precision 7. I wonder if chroma noise could screw up the motion estimation, after noise has no particular direction. So I would think it's safe to use this option, but maybe I'm wrong (helpful, huh?).

Edit: Sorry, I did not see that Koepi already answered, before I posted. But it looks like I was right, yay!!

Best regards,
JimiK

[fraatz]

mplayer can't decode qpel xvid files without producing artifacts...
maybe that's your problem
-f

[omol]

Originally posted by mfluder
These are the flags that I found to have the most influence on speed. If someone else knows some other flags please post them. I suggest you also take a look at Makefile.linux because there you have many flags you can also test. Here are the flags that I use:

CFLAGS = -Wall -DARCH_X86
CFLAGS += -DBFRAMES -DBFRAMES_DEC
CFLAGS += -march=i686 -mcpu=i686
CFLAGS += -O3

I hope someone will find this useful. If you have some questions please ask and I'll try to answer them.

mfluder

-fomit-frame-pointer, maybe? And also, will -msse/-msse2 will do any good?

regards,
omol

[greycortex]

I had (2-pass) encoded a couple of streams, each with the following enabled:
motion search: 6
Q type: H 263/New mod
Fourcc: Xvid
I-frames: 1-300 limits
Qpel+GMC+Dyn hpel/qpel
Bframe: 4/200/100
B-VOP compat checked

With these files, if I check "use XVID" in ffdshow, Those particular artifacts disappear, but then the bframes don't decode correctly. Now, I made encodes without "chroma motion" selected, and I don't get that progressive noise problem. Included is the same frame without "chroma motion" selected. At the places where the artifacts appear, there is some rather severe chroma noise. Should I just not use it for this type of stream? If not, why does that type of noise go away when not using ffdshow?

I can't seem to get these attached messages to display, so I'll upload them to my ftp site in a bit.

[cjv]

Originally posted by fraatz
mplayer can't decode qpel xvid files without producing artifacts...
maybe that's your problem
-f
If by mplayer you mean http://www.mplayerhq.hu/homepage/ then what xvid build/mplayer version are you referring to, as I play all of my xvid encodes with mplayer and have no problems with qpel.

Maybe you're seeing the b-frame bug..for that try -lavdopts bug=16.

cjv

[greycortex]

I'm not having problems with qpel. If I use chroma motion I have progressively noisy blocks in placed with high chroma noise until it gets to an I-frame. This is using ffdshow. If I use Xvid, build 09122002 as the decoder, then the noise goes away, but I don't get bframes to decode well at all, an expected behaviour I understand.

[Koepi]

i repeat for the X-th time: don't use GMC, it's buggy and just a proof-of-concept.

I have a new core+decoder build lying around here in whcih bframe decoding is fixed by suxendrol, so expect the decoder to work nice with the next pblic build.

Regards
Koepi

[cjv]

@Koepi:

Just a suggestion..next build, maybe disable the GMC checkbox in vfw, seeing as most people use your builds. Seems to cause lots of problems..actually most posts lately have been complaints, makes it hard to weed through.

cjv
PS any news about official aspect ratio support :)