luma +mvh

[cult]

for 1st time i tried luma masking and mvh.It didnt work :(
i tried it using it during both passes.when I tried to watch the clip,zoom player crashed.Even had crash in windows exploer during the preview through windows explorer.
Then I used luma maskin with mvh only with 2nd pass.Same problems
I am using koepis 17/04 version.(it is the luma+mvh version,isn't it?)
.h263,xvid fourcc,curve agression-medium,high-250,low-150,automatic strength 50%,automatic bonus,max bitrate 10000,max overflow 60%,max degretion 60% and activated credits for start and end of movie with 26 i-frame and p-frame quant.
windows 2k,celeron 950,256 ram.
I am doing something wrong?

[-h]

I can't remember when I merged the lumi + mvh stuff.

Try a later build maybe?

-h

[Acaila]

Changelog:
XviD-17042002-1:
- EPZS and EPZS^2 code activated
- Fresh CVS checkout
- Fixes for hinted MVs and luma masking
I haven't tried it yet, but maybe it's still broken? This is the latest build btw.

[rui]

This isn't related with mv hints+lumi, but i didn't wnated to open a new thread only for this, so i hope cult doesn't mind. Here goes:
I've tried a new build that uManiac has in his site, xvid.alpha.21.04.2002.1720, but when trying to play xvid clips encoded with prior builds, a error message appears, saying:

xvid.dll implements a newer api version; update your directshow filter

Then i tried to replace the xvid.ax that came with this build, with the xvid.ax that comes with Nic's and Koepi's builds (it's Nic' ds filter with post processing), but i get the same error, which i expected since Nic's ds filter is also prior to this new uManiac's build.
This new build is supposed to have fixed the quantization matrix.

Edit: i forgot to say that after the error message shows up, i press OK and the clip plays fine, only without any kind of post processing.
If i still want post processing i have to use the ffdshow filter, which by the way doesn't show that error message :confused:

[Koepi]

API version changed from 2.0 to 2.1.
Nic has to recompile his filter to make it work properly with that again...

[rui]

Hummm... Nic? Are you out there, buddy? :D

[Nic]

Always..... :D

-Nic

ps
Recompiled....Get at: http://nic.dnsalias.com :)

[Swede]

It's *very* funny to watch the logs grow at a time like this :)
@nic: Obviously do people like your work...

[22/Apr/2002:11:24:17 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:24:19 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:24:27 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:24:41 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:24:44 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:25:01 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:25:11 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:25:16 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:25:20 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:25:27 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:25:28 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:25:29 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:25:32 +0200] "GET /XviD_Install.exe HTTP/1.1"
[22/Apr/2002:11:25:34 +0200] "GET /XviD_Install.exe HTTP/1.1"

[Nic]

:D I'd almost be interested in logs that look like:

GET /DVD2AVI..secret :) ..ZIP HTTP/1.1

I wouldn't mind knowing how many people have looked at my beta version :) (should only be very few :) )

-Nic

[-h]

Hrm I guess it could still be broken, but it's been working for everyone else? I'm not sure.

-h

[rui]

I just finished two small tests, both using MPEG costum matrix AND lumi enabled in both passes. I used MV hints also. The xvid build used was the latest Nic compilation, dated from today (thanks Nic for constantly support our requests :)

The first test was done using a clip from the movie The Haunting. Very slow motion, so i configured Alt Curve to low agression, 200% high and 25% low. The resulting avi played fine in both media player 6.4 and bsplayer. The quality is correct, but i didn't made any comparisons with a non lumi clip.

The second test was done using a trailer from the movie The Replacements. Very fast action, with some (few) slow motion scenes, so i used alt curve with high agression and 300% high and 75% low.
The resulting avi was also good.

So no problems here, both with lumi and costum matrix.

BUT they were only two small tests, it doesn't mean a lot.

EDIT: i am curious about costum matrix. I remember having read in the forum that the default MPEG costum matrix should be even sharper than MPEG only (?)

[rui]

By -h:
Just looked over the new quantization matrix stuff:

- Yes I know the entry screen is ugly, maybe I'll pretty it up.
- The MMX code for MPEG quantization (that includes "MPEG" and "Custom") has been disabled, as it broke the custom mode. So, anyone using MPEG or Custom with today's build will see much slower encodes.
- The quant matrices are sent when the encoder is initialised, so we can't send updated tables whenever we feel like it (i.e., we can't use different tables for low or high quants). Since these tables are stored in the VOL header, this is a future possibility.

You would now be able to make a "middle ground" set of matrices which lie between MPEG and H.263, giving you the best of both worlds if you may. I'll upload said table as a file you can load in with the "Load" button if anyone wants to experiment.

I found this in the forum, when costum matrix first apeared.
So, then costum matrix is a middle ground between H.263 and MPEG.

I also found out a post from -h, stating that costum matrix uses MPEG quantization method, only with diferent values from the normal MPEG:

By -h:
Well the custom quant matrix actually quantizes using MPEG quantization, just with different values. H.263 uses a different method of quantizing altogether.

[Nic]

@h:
You've taken out the build information from CONFIG?....c'mon dont let a lstrcmp(...) command stand in your way.. :D

-Nic

[-h]

You've taken out the build information from CONFIG?....c'mon dont let a lstrcmp(...) command stand in your way.. :D

It was never actually enabled - simply by uncommenting that CONFIG item, and the lstrcmp during DRV_OPEN, the codec crashed every time. For no reason.

Drove me nuts for a while, so I gave up :)

-h

[Gazza]

@-h

Assuming I'm on the same wavelength as Nic, I also would like to see the build information displayed when configuring the codec through Vdub.

With so many builds coming, it is sometimes confusing to know which one you have installed.

[Nic]

:D it is very weird....I tried adding it to ICM_CONFIGURE (on mine it doesnt crash but the configure dialog won't open).Its to do with the registry editing (rather than the strcmp). But I have absolutley no idea why :) (ill eventually fix it, one less thing for you to worry about -h...I can imagine this GUI stuff is probably sending you crazy :) )

-Nic

ps
Ok, now I know what it is, set the char build[50] to a char build[MAX_PATH]...You are using that as the fixed size when doing your REG_STR loops.

However, :D There is another problem. the XVID_BUILD equals two different things. One in DriverProc.c & one in codec.c. That means it will _always_ detect a difference in the registry build & set the version to the one in the driverproc.c, but when detecting it again from codec.c it will be different again, etc etc....ill go away & fix that.

[-h]

Ok, now I know what it is, set the char build[50] to a char build[MAX_PATH]...You are using that as the fixed size when doing your REG_STR loops.

Of course you are right. Heh I just tried it, saw that it screwed up the Configure/About buttons (quite impressive I thought!) and moved onto something else :)

However, :D There is another problem. the XVID_BUILD equals two different things. One in DriverProc.c & one in codec.c. That means it will _always_ detect a difference in the registry build & set the version to the one in the driverproc.c, but when detecting it again from codec.c it will be different again, etc etc....ill go away & fix that.

Ouch, XVID_BUILD is calculated more than once during compilation? That's one advantage of __TIMESTAMP__ I guess, there'd be no such issue.

-h

[Nic]

Unfortunatly even with TIMESTAMP you'd still get the issue :( because if driverproc.c or codec.c were modified at different times (which is almost definite I suppose)...then you'd get different timestamps in each file.

The only way to do this right is to move the check into codec.c. But that is easier said than done (without doing a hack :) ). Or move the reg_str stuff into driverproc.c but that isnt good....or make XVID_BUILD a global string & set it in driverproc with a strcpy(XVID_BUILD, __TIME ,etc) :)

Also Gazza is right I think, a static with the time & date info in the debug tab probably would be good....but don't bother yourself with it, ill do it at some point :)

Anyway, these are such minor issues, they don't merit all this text :)

-Nic

[-h]

The only way to do this right is to move the check into codec.c. But that is easier said than done (without doing a hack :) ). Or move the reg_str stuff into driverproc.c but that isnt good....or make XVID_BUILD a global string & set it in driverproc with a strcpy(XVID_BUILD, __TIME ,etc) :)

Well since the reg_strs array is global (hehe), it could be un-const'ed and driverproc.c could lstrcpy its version of XVID_BUILD into the struct at DRV_OPEN. Unless I'm missing something..

Also Gazza is right I think, a static with the time & date info in the debug tab probably would be good....but don't bother yourself with it, ill do it at some point :)

The About box already displays the date/time of compilation..? That's what XVID_BUILD was originally for.

-h

[Nic]

Oh....yes....the about box....Doh!...Forgot about that one, havent used VirtualDub much recently.

& yes what you suggested should work (seeing its global, I didnt notice that :) )..case solved :)

-Nic