QPEL: Do previous & current dev-builds make good but buggy non-standard encodes?

[unplugged]

I have made different encodes using motion search 6 (qpel) with 11/10, 12/10, 13/10 and 21/10 CVS dev-builds, they look from pretty good to excellent in playback...
but only when ran with XviD compiles of the respective date!
(otherwise starts to appear hell of smearing artifacts)

I well know these are *unstable* builds, but what's strange is that motion/quality is near to perfect when I play them with "respective" encoder date/version...
when I use more recent builds to decode previous created (qpel) AVIs I see smearing artifact appearing.

Are these all bugged non-standard MPEG4 videos? :scared:
"If the binaries are bugged" why does encoding and decoding using the same CVS version give very good results? (no smearing surprises)

I have several clips that encoded and gone perfectly with quality, but now decoded with 21/10 and 22/10 builds they looks orrible! (smear everywhere)
This happens with o without DirectShow... so even with VirtuaDub session.

[Asmodian]

That is the impression I got from the developers (just reading posts), B frames are in final form (current encodes with B frames should be playable in the future) and Qpel is not - encodes made with Qpel may be/are incompatible with future builds of Xvid.
Hopefully qpel will become finalized soon so I can start making archival encodes with qpel on (Or I could just burn the xvid I encoded with to every cd of encoded material - if it won't play with future versions of xvid just install the one it was encoded with ;) ).

[kastro68]

I used DX50 fourcc for all recent Xvid encodes and i don't appear to be experiencing any problems at all, even with q-pel...am i missing something?

[unplugged]

That is the impression I got from the developers (just reading posts), B frames are in final form (current encodes with B frames should be playable in the future) and Qpel is not - encodes made with Qpel may be/are incompatible with future builds of Xvid.
What has "tricked" me to (wrongly) use QPel has been the specular behavior established by encoder motion bugs viceversa compensated and covered by decoder motion bugs (since they are based by the whole experimental code).
Simply I have seen better overall image and I have used Qpel, never thought that really encoder and decoder was toghether in "magic errata harmony".

The lack of one, at least one complete (full working) MPEG4 player is quite demoralizing...
We can get day after day lot of encoded stuff and have not even any opportunity to test if it's ISO compilant or not... :(
For example it's a bit like working to develop LAME while haven't any decent official MP3 decoder to fully test where and how things are going to become... (better or not)

[unplugged]

@Nic and dev-Guys

Does working on decoding engine taking base on xvid source itself can endorse possible internal xvid bugs for several times in future giving quirks and problems like the Qpel encoding/decoding behavior mentioned in post?.

Shouldn't be better to build DShow decoder using independent source code most strictly based on ISO criterion?

Don't know particulars or indepth, just my dumb questions...