An XviD bug, a newer DShow filter & my new site

[Rrrough]

@ookzDVD

thank you, I already tried, and it's also crashfree here.
but I much rather like to help to sort out the problem if possible.

I think uManiacs build is made of the same CVS-source as Nic's, so that'd rule out a core problem.

Nic, do you use the same compiler options as Koepi ? haven't tried his build yet, but it seems to be crashfree on other's computers, who have the same prob.

cheers

[ookzDVD]

@Rrrough,

Ok,
I already try the Nic's 23/10 on AMD Athlon XP 1800+ & Intel P4 1.8,
and 29/10 only on Intel one, all are crashed.

It's strange since all the builds are use the same core,
I think it's optimization problem or something.

[Gaia]

Do you use any of the credits options? It might cause those crashes because i haven't tried them with these dev-builds.

I currently use Duron 950 with 98se installed for testing and still no crashes. Soon first pass finished with latest Nic build.

[iago]

@Nic and all,

Finally I got my crash too ;), during the first pass of a full movie encode using the 29/10/02 build.

(Celeron 900 - Windows XP Pro)

regards,
iago

[Rrrough]

darn :angry: it crashed again at exactly the same position (after 46970 frames). it seems not to be randomly distributed here for the same settings + source.
maybe some kind of memory leak prob ?

[Jon Ingram]

I have also had virtualdub repeatedly crash while encoding to XviD via Nic's build (29/10), using Windows 98SE on a Pentium III. The exact same settings work perfectly when using uManiac's 24/10 instant build.

[Koepi]

Can you please try my unstable build as well, if it crashes for you? If it doesn't crash it might be some compiler optimizations which are the cause for this behaviour.
(Just as a sidenote, try compiling some programs with -O6 and gcc, you'll get plenty of sig11[e.g. if you compile a linsuxx kernel that way]).

Regards
Koepi

[MaTTeR]

Nic,

The new 10-29 build actually seems pretty stable for me here. I encoded 2 movies today on 2 seperate dual CPU systems without any issues. I'll be running a few more encodes tonight and will report if any problems are seen. Thx!

[Rrrough]

Can you please try my unstable build as well full first pass running - results tomorrow. it might be some compiler optimizations which are the cause for this behaviour I really hope soif you compile a linsuxx kernel that way charming :p

cheers

[Gazza]

Originally posted by Rrrough
darn :angry: it crashed again at exactly the same position (after 46970 frames). it seems not to be randomly distributed here for the same settings + source.
maybe some kind of memory leak prob ?

Are you using the same *.d2v & *.avs each time you test? Maybe you need to start from the beginning again and regenerate these files? Can you run a small test from scratch with just the vob that has that frame where it crashes? When you run the test make sure that the other vobs are not in the same directory - ensures a clean process.

Just a number of suggestions to try.

I'm still using mManiacs 24/10 build and it is working just fine with qpel and b-frames (still very slow though).

[ookzDVD]

@Koepi,

I just try your latest unstable build 22/10 with no crash,
same .avs same XviD's settings. :)

So I think the problem only with Nic's and its optimization. imho.


@Gazza,

uManiac's build is not too slow on my machine, I've got about ~19 fps average. ;)

[Gazza]

Originally posted by ookzDVD


@Gazza,

uManiac's build is not too slow on my machine, I've got about ~19 fps average. ;)

I have a P3, 1GHz with 512M running win2k (with SP3). Not sure why it should run so slow though. Maybe time to clean it out of obscure add-ins....?

[ookzDVD]

@Gazza,

I'll bet you must be use the Convolution3D filter ?

[Gazza]

ookzDVD,

No, I haven't tried that yet as there seems to be conflicting results recorded by others. Also I haven't read up on it in detail to see what it is all about before I jump in and test.

[Koepi]

Ok, next try:

XviD-31102002-1 _ALPHA_ Release

Based on CVS (unstable/dev-api-3 branch) from 31.10.2002 08:00h MET

Changelog:

XviD-31102002-1:
- Fresh CVS checkout. Further QPEL bugfixes.
- New mod. HQ quant type reimplemented.

These qpel fixes make xvid+qpel playable on ffmpeg, older ffdshow,... hopefully even divx5! :)

Usual optimizations, give it a try! Unfortunately I forgot to add iago's brilliant "2pass for beginners" guide - herewith I ask for permission to do so! ;)

Best regards
Koepi

[iago]

@Koepi

That's great, I'd been expecting your new "dev. build" for a while. New Modulated HQ with QPel and B-Frames, and with no decoding problems with ffdshow and others! Thanks a lot, I'll immediately start a full movie encode with it :). And, no need to say that but, please feel free to include "the document" ;) wherever and whenever you like.


@Nic and all,

I didn't get any crash during the first pass with the 29/10/02 build when using only QPel and this time "no B-frames", with the same encoding parameters as the my previous try.

best regards,
iago

[ookzDVD]

@Koepi,

Thank you for the latest build, 31/10,
I notice that the Nic's DSF is still the old one 23/10,
I think there is a new one, 29/10 for latest Nic's XviD build 29/10.

@iago,

I think there is an optimatization problem.

[Rrrough]

First pass successfully finished with Koepi's 22/10, heading for 31/10 now. thanks for helping.

cheers

[Koepi]

@iago,

I think there isn't any qpel code for bframes yet, at least I didn't see it :-/
Thanks for the permission to include the doc! :)

@ookzDVD:
Sorry, I don't have my hands on a newer DSF than that one :) BUT: if it works with ffdshow now (need ~13hours from now to verify that ;) ), it shouldn't be a problem, right? ;)

Best regards
Koepi

[ookzDVD]

@Koepi,

Ok, no problem ;)
I can overwrite the old one with the new one ;)
btw, ffdshow ? which build ? which IDCT ?

Thank you.

[Smiff]

Nic's build crashes Vdib for me every time, doing 2 pass with default settings or b-frames... gonna try Koepi's :)

[Nic]

I replied to an email from Isibaar today to tell him about the problems with crashing, it sounds like his been working on the QPel side of things anyway....Id be very surprised if trying a different build stops the crashing.

-Nic

ps
Actually there have been changes to the dev3 cvs in the last 20 hours that might help (?). It should definitely help visual quality :) as a chroma rounding bug has been fixed in Qpel. Im unable to make a new build today. will do tomorrow.

[Rrrough]

@Nic,

does your 29/10 build have the same CVS-source as uManiacs 24/10 build ? I think there was quite a delay of CVS updates after october, 21th, and the main updates till october 24th were due to some testings of milan IIRC.
Both Koepi's and uManiacs builds run crashfree here, so maybe it really is an optimization problem ? Could you please check Koepi's ICL 6 compiler options/optimizations ?
Thanks for your efforts.

cheers

[Nic]

Id be surprised, I think Koepi gave me his options a while back, his are alot more optimising than mine, so it should be the other way round. Tomorrow ill put out a build vc6 compiled. isibaar once mentioned he thought that ICL optimised too heavily. It will at least help with testing for now.

-Nic

[Rrrough]

alright then, be sure that I'll be there for testing :)

cheers

[Rrrough]

Gazza,
Are you using the same *.d2v & *.avs each time you test? Maybe you need to start from the beginning again and regenerate these files? Can you run a small test from scratch with just the vob that has that frame where it crashes? When you run the test make sure that the other vobs are not in the same directory - ensures a clean process.
sorry, I didn't see your post until now. I am pretty sure I'm using the same d2v and avs file, as those are the only ones I have created right now, and I'm leaving them untouched for fair testing. I'll try to sort out, which VOB it is and try to compress it seperately, but I can jump to the frame in vdub-preview (going from some frames before to some frames after it) without having vdub crashing. and still, it doesn't crash with the two other builds :confused:
I hope it'll get sorted out soon.

cheers

[Nic]

Ok, heres the latest cvs code with QPel chroma fix compiled with VC6 for testing:
http://nic.dnsalias.com/XviD_Install.exe

The text on the website hasnt changed but the link will work & you can test its the correct version from the readme (i.e. 1/11/02)

See how you get on with it & see if crashes still occur. (also the drop in speed would be interesting to know & if any quality improvements are visible with this version).

Cheers,
-Nic

ps
I know LAME when compiled with ICL & VC6 the quality difference can be noted on some samples. (at least thats what Dibrom stated a while back). So maybe the same might apply? (or maybe not as XviD is mainly asm & fixedpoint/integer math which wont be (too) effected)

pps
@Koepi:
http://nic.dnsalias.com/xvid.ax
latest xvid filter. :)

[HarryM]

I tested Koepi's 31102002 build and registered any little (but visible) color blending (or chroma shift?) at using q-pel.

[Koepi]

I included an old directshow filter of nic into that build. Please download latest ffdshow alpha build (31102002 i think) and use it for decoding xvid (without using xvid). Does that problem still occur?

Regards
Koepi

[Smiff]

yay, Koepi's latest works great (no crash during encode + great quality - is the Qpel safe to release now?) decoding with ffdshow and Nic's 2002-11-1 DSF (don't use the 2002-10-23 DSF, that shows colour problems!)

EDIT: waaaiit. spoke too soon as usual. Only Nic's 2002-11-1 DSF (posted on its own above) seems to be able to decode Keopi's 2002-10-31 Qpel without a Chroma problem. Guess i answered my own question - no it's not safe to release Qpel encodes yet.

[unplugged]

Originally posted by HarryM
I tested Koepi's 31102002 build and registered any little (but visible) color blending (or chroma shift?) at using q-pel.
I can confirm too :(, it's not a decompression problem,
latest ffdshow-20021029 and EnvivioTV MPEG-4 player (after conv. to .MP4) give me the same chroma coloring artifact (with Qpel, of course).

[Rrrough]

:) :p :) :p :) :p :) :p :) :p :) :p :) :p :) :p :)
HOORAY !
full first pass without crashing !
going for second pass now !
so no more crash test (dummies) needed ? I hope so !
or are there any other results ?

cheers

[miha]

Isn't umanic's site suppose to have same sort of automatic checker and builder of Xivd builds if he detects some change in the cvs dev3 tree ?
If so why is it not working and if it is a manual run script where can I get it ?

[ReferenceDivx]

I think his building script needs to be updated to reflect the lack of a qpel.h file somewhere.

[Rrrough]

Nic,

your latest build is definetly working crashfree here. 2 full second passes, no crashing. I hope, the problem is finally sorted out. thank you very much for your work on it.

ReferenceDivx,

Isibaar said on the xvid-devel list, that qpel.h is not yet needed. Instant build system didn't always kick in before, maybe there's some trouble with his system...?

cheers

[MaTTeR]

Originally posted by Rrrough
Nic,

your latest build is definetly working crashfree here.

Same results here, I've encoded no less than 5 different movies with various settings and scripts and not had a problem. Also suprisingly I didn't notice any sort of performance difference compared to the typical ICL builds. If a quality difference between ICL and VC6 exists then my eyes certainly don't see it.

Now if I can only get this friggin YV12 encode working....:devil:

[Franko30]

Originally posted by unplugged
I can confirm too :(, it's not a decompression problem,
latest ffdshow-20021029 and EnvivioTV MPEG-4 player (after conv. to .MP4) give me the same chroma coloring artifact (with Qpel, of course).


Hi unplugged,

I guess it IS a decoding problem, as the ffdshow-20021014-se decodes Koepis XviD-31102002-1 unstable build correctly.

Koepi states on his site:
"qpel code is fixed now so that ffmpeg, ffdshow (and hopefully divx5) can decode it correctly!"

As Nic's DShow Filter doesn't decode the new Koepibulid correctly, but the older ffdshow can, does anybody have the same feeling as I do?
Maybe ffdshow got fixed to decode the older qpel builds correctly, while the XVID people fixed the qpel stuff to be decoded correctly by ffdshow - and so, again, we end up with decoding errors.

A wild theory, I know - but might be possible...

Apart from the confusion:

Qpel works excellent for me.

Cheers

Frank

edit, update:

Just installed Koepis XviD-02112002-1 unstable build. And guess what? The Dshow filter included with this build decodes the clips made with XviD-31102002-1 correctly, but has the chroma problems on the encodings of the XviD-12102002-1 build. But those get decoded correctly with the ffdshow-20021029.

Yeah! Are we having fun yet?

[unplugged]

It's a pretty difficult thing, there are bugged encoders that sometimes get compensated by using bugged decoders (that was the trap that f@ck@d me a pair of encodes :(), ATM with Qpel it's a roulette...
so Envivio MPEG4 player give me a *little* and more secure reference point for testing effective quality.

To be honest, after re-testing again Koepi's 31/10 and viewing with Envivio there is only little smearing on moving objects but not color/chroma shifting.
Finally Nic's DShow filter 01/11 show perfectly those videos.

Which can I trust from, Envivio or xvid decoder? :p

[miha]

XviD-02112002-1.exe von Koepi
GMC support (search precision ultra)does he mean by that 7- ultra or 6-ultra high becose i dont se any new option ultra

[Koepi]

There's only search precision ultra (6) - dunno what's 7?

Regards
Koepi

[Franko30]

Hi,

tonight i encoded two Star Trek Next Generation episodes with Koepis new 02112002-1 unstable build, Qpel enabled using AltCC, after loading the defaults I used the exact same settings for Motion search precision, Quants, I-frame bost, AltCC etc. as before with the 31102002-1 build.

Just wanted to inform that the resulting (video only) AVIs play fine (XVID DShow Filter, several players), but Nandub gives the following error, when searching in the clip:

"error fetching frame (then the frame number): Video SourceAVI error: unspecified error (-100)"

Something like that never happened before, strange.

Going back to the 31102002-1 build.

Frank

[iago]

@Koepi and all

I just wanted to report that I've been getting very good results, with no crashing and with no decoding problems (using Nic's xvid.ax dated 1.11.2002) with Koepi's 31102002-1 build using B-frames 3/150.

regards,
iago

[MaTTeR]

Originally posted by Franko30
Just wanted to inform that the resulting (video only) AVIs play fine (XVID DShow Filter, several players), but Nandub gives the following error, when searching in the clip:

"error fetching frame (then the frame number): Video SourceAVI error: unspecified error (-100)"

I can confirm this happened to me also when I switched from motion search 5 to 6(Ultra-GMC & Qpel). The Qpel/GMC encode appears to playback just fine in TCMP but all Vdub and NanDub versions I have wont allow editing due to the fetch error.

[miha]

did you tray the 1.4.11 version becouse it works fine for me ... but i have to use ffdshow decoder for playback becose nic's will not decode correctly

[MaTTeR]

Originally posted by miha
did you tray the 1.4.11 version becouse it works fine for me ...
Yes, I tried Vdub 1.4.11, 1.4.10, VdubMPG2, VdubAVS&OGM and NanDub. All give the same error and refuse to preview the file. I just tried a different 90MB clip newly encoded and got the same result. I should also mention these were encoded using YV12. Just to clarify, the problem is only happening for me when I encode using motion search 6(ultra) with Koepi's 02112002 dev build.

[Koepi]

suxen_drol commited GMC decoding into CVS some hours ago. Unfortunately I don't have the time now to make a new build (with qpel+GMC as extra switches), so you must be a little patient.

GMC isn't giving any bitrate gains for now, it's just a "proof of concept" and a basic implementation.

Regards,
Koepi

[Lefungus]

Unlike Qpel, it seems that GMC is activated even when bframes are used with an ultra high motion search precision in your last build, Koepi.
I say so because i can't decode my new test clips.
And if i put motion search precision to 5, it works again.
Maybe i'm wrong, i don't know

[cweb]

Hi,
Please excuse me if this has been reported - I could not find it using search thus I presumed it might be of interest.

While I usually use Koepi's build (great stuff :)) I decided to have a go at encoding a small clip using B-Frames (2, 200%) - kind of an experiment, so I installed Nic's latest build, and I managed to get a crash - basically a page fault when the encoded clip is viewed. I got the same result viewing it as an AVI file using WMP 6.4, Zoom Player and an OGM created with VirtualdubAVSandOGM viewed with ZoomPlayer. I set the b-frames setting both in the 1st pass and in the 2nd pass. I used Iago's settings as a test. Luma is off, as is interlaced and grey-scale.

No xvid clips would play anymore then, and I had to reboot (I'm
running win98 on an Athlon MP) to get xvid clips to work again.
I then encoded the clip using CBR 920 bitrate.
The ffdshow I had installed was not allowing me to view the clip (Even though using XVID was ticked), so I just uninstalled it to allow NIC's DSF to decode it. Ok, I need to update ffdshow, but I don't really need it right now.
The CBR clip with B-frames worked well.

I tried again something different. I recalled how when I use luma -
I usually have to enable it in the 2nd pass only, or I get artifacts. I thought that was standard practice - well it worked for me.
This time, I tried to do the same with B-frames. I set the number to -1 (to disable them) in the 1st pass. Then in the second pass I set them back to 2. The result seems to have encoded well. But is this the right way to go about it, or a bug, or some mistake of mine?

Of course, this was an experiment, and for archiving I think I'll
stick to Koepi's stable builds.. Thanks Koepi for your build.
BTW does anyone know if one can build XVID using Mingw? Which gcc's cause problems (can one use the newest 3.x versions?) if any?

cweb

[Rrrough]

"error fetching frame (then the frame number): Video SourceAVI error: unspecified error (-100)"
actually, by looking closely, the frame number from the error message isn't the frame number you're jumping to. it seems, vdub isn't able to decompress the frames, to which GMC has been applied (taking a rough guess here).
It reminds me of the times, where vdub wasn't able to handle DivX5 b-frames... anyway, XVID's GMC is still in it's infancy, I guess, so it's a wise move from Koepi wanting to add extra switches for QPEL and GMC !

cheers

EDIT : RRROUGH !!! READ BEFORE YOU POST :o SHAME ON ME
suxen_drol commited GMC decoding into CVS some hours ago. of course vdub can't handle GMC frames, how should it :o

[MaTTeR]

Originally posted by Rrrough
so it's a wise move from Koepi wanting to add extra switches for QPEL and GMC ! I'll agree with that 100%, not to mention the extra switches might cause less confusion for nOObs.

@cweb,
I always assumed PageFaults were just a "feature" of Win98;)