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

[MaTTeR]

Originally posted by AndyP

As a character moves accross the picture with the dev build he leaves a 'trail' of noise behind him. I will investiagte further and post pictures.

This is the exact same problem I've seen with all the Qpel builds including Koepi's. I think Acaila also confirmed he had seen it too.

[unplugged]

I have seen these (motion?) artifacts too, but must say that they may appear starting with quant=>3. (ATM quant2/QPel+H.263 give me best result I have seen: less noise, no artifacts, 99% real detail :eek: )

This trail of noise and its behaviour reminds me something...
Is this a bit like the "famous" DivX3 smearing effect? :)

[Tommy Carrot]

Just some observation.

I usually test the latest builds with fixed quantizers. I think this is the best way to see what has changed. I keep the results (4 min test sequence from "Lord of the Rings") to compare them to each other.

The newest build introduced some nasty bugs, so i cannot recommend it. Apart the mentioned bugs, the bitrate on fixed quantizer is almost twice of the older builds, and the details are not improved, even has visual artifacts (as was mentioned)

So far the october 11. build was the best. With qpel it keeped the most details on a given quantizer, with only a few artifacts. The Oct.13. build was slightly worse detailwise.

Anyway, when the bugs are eliminated, xvid will have no competition. :) Keep up the good work!

[unplugged]

Note:

XviD-20021021-test-clip looks the worst when decoded with XviD-20021013 installed (dll+ax)
but exactly as opposite
XviD-20021013-test-clip looks the worst when decoded with XviD-20021021 installed (dll+ax)

So it isn't so easy make right comparisons ;)...at the moment, what I can say is that the 13/10 clip decoded with 13/10 binaries looks good and similar to 21/10 clip decoded with 21/10 binaries. (although haven't compared screenshots)

(frames compared with VirtualDub; about dll+ax I checked that they have been *really* updated to system32 every time I have ran uninstall/install)

[Gazza]

Originally posted by unplugged

This trail of noise and its behaviour reminds me something...
Is this a bit like the "famous" DivX3 smearing effect? :)

I don't know if this is relevant but I had similar color issues (comet trails) - see http://forum.doom9.org/showthread.php?s=&threadid=27778. I thought at the time that it was a problem between the versions of ffdshow and uManiacs xvid build at the time. By disabling ffdshow during playback it seemed to get rid of the problem.

[metallikop]

From what I've noticed with this color bleeding problem it only happens when you add Qpel + ffdshow. I can supply clips of when this holds true, qpel enabled and disabled. I tried with Nic's and Koepi's qpel enabled builds.

[MaTTeR]

Two different problems are apparently being discussed on this page. The odd color bleeding or 3D like color problem is indeed an issue with ffdshow, use Nic's filter and the problem disappears for good.

The other more serious problem is actual noise being smeared during motion when Qpel is activated. LOL..it definitely does remind me of some SBC related problems I seen awhile back too. This problem doesn't appear to be related to any DS filter as far as I can tell here.

[HarryM]

I test to decode 13-10-2002-videos with 21-20-2002-decoder too.

Result = foggy trails, ugly look.


I test to encode 2nd pass with 21-10-2002-build (1st pass I use from 13-10-2002-build, no MV hints, no lumi masking, no b-frames) and use 21-10-2002-build for decoding too.

Result = ugly look, I observe blocks (macroblocks) often. But no foggy trails.



The best result I get with 13-10-2002-build for encoding, as well for decoding too. Videos has similar look like to divx3 (nice sharp look :)

[Koepi]

Since there were changes to the ME routines you can't reuse your old statsfiles, do a propper 2pass! :)

Regards
Koepi

[cjv]

Originally posted by HarryM

The best result I get with 13-10-2002-build for encoding, as well for decoding too. Videos has similar look like to divx3 (nice sharp look :)

I have been doing some tests using Koepi's 04102002 stable build, and a fresh dev-api-3 CVS checkout with sysKin's new ME (NO qpel)..both at search precision 6.

I have to agree that the new ME seems more visually pleasing and somewhat sharper (like you mention..more divx3-like)..more noticable when using h263 compared to the old h263, and helps to prevent the blocking on solid surfaces. I am really happy w/visual quality, although file sizes are over 20% higher when using the new ME. And when comparing h263 vs. MPEG quants, the files are almost the same size, whereas before h263 would be approx. 8-10% smaller..depending on source material.

Remember these tests were conducted with supposedly unstable code (although I must say it's suprisingly stable and awesome) :)

cjv

[HarryM]

Originally posted by Koepi
Since there were changes to the ME routines you can't reuse your old statsfiles, do a propper 2pass! :)

Regards
Koepi

This can't make so big quality change, I think.

[unplugged]

Originally posted by MaTTeR
The other more serious problem is actual noise being smeared during motion when Qpel is activated. LOL..it definitely does remind me of some SBC related problems I seen awhile back too. This problem doesn't appear to be related to any DS filter as far as I can tell here.
Indeed,

@Gazza & @Metallikop

I have also written that I have used VirtualDub for comparisons, so NO DirectShow filters (.AX) are used to decompress frames, but only the respective codec (XviD.DLL). Thus sure ffdshow has nothing to do with smearing problem that I mention.

Plus, I have encoded my test clips using constant quantizer (2 and 3) without using any older/newer stats file.

[Acaila]

This is the exact same problem I've seen with all the Qpel builds including Koepi's. I think Acaila also confirmed he had seen it too.Indeed I have. The problem however is that the smearing effect (which looks very much like DivX3's in fact) doesn't always occur at the exact same place when you re-encode the video, but does always occur somewhere in a movie when you use QPel.

Like unplugged said this smearing is seen in VDub as well so it's not a playback problem. And it happens with both Nic's and Koepi's QPel builds.

[ookzDVD]

@Koepi,

any plan to release new unstable build,
'cause your build is faster than Nic's on my machine.

thank you.

[Koepi]

XviD-22102002-1:
- Fresh CVS checkout. QPEL bugfixes. Small ME updates.
- New mod. HQ quant type reimplemented.

Regards
Koepi

[ookzDVD]

@Koepi,

Thank you for your fast response ;)

[unplugged]

Originally posted by Koepi
XviD-22102002-1:
- Fresh CVS checkout. QPEL bugfixes. Small ME updates.
- New mod. HQ quant type reimplemented.
Pardon,
~identical~ as Nic 21/10?

[Nic]

Not identical is Koepi uses different compiler options & it has his HQ Mod quant....& isibaar has updated motion_est.c too....

-Nic

[unplugged]

Koepi's 22/10 dev-build has massive playback (with players only) smearing with its Qpel made videos since it's bundled with non updated DirectShow filer (13/10).
In fact, playing without xvid.ax (regsvr32 /u xvid.ax) video and Qpel are OK, no noticeable smearing ;).
Haven't tried lastest Nic's xvid.ax yet (21/10), I will "mix" them...

[ookzDVD]

Trying to encode with latest Koepi's 2210 with disable the B-frame = -1, Motion Search 6, and everything is ok, playback is no problem at all, quality is awesome. ;)
_but_
with B-frame max = 2, there is still a problem while playback sometime I see the artifacts in the random location. :(

[milan]

Michael Niedermayer just commited "xvid qpel bug workaround" code to ffmpeg CVS. I'll quickly test it and then update libavcodec in ffdshow and propably tomorrow new ffdshow alpha build will be released.

[HarryM]

Originally posted by milan
Michael Niedermayer just commited "xvid qpel bug workaround" code to ffmpeg CVS. I'll quickly test it and then update libavcodec in ffdshow and propably tomorrow new ffdshow alpha build will be released.


Thanks (mnohokrat diky).

[Smiff]

Koepi
could you please _not_ bundle with Nic's filter

Nic
Could you please make your filter and encoder releases seperate.

As someone pointed out, it becomes uneccesarily tricky to install Xvid atm.

[Nic]

Hi Smiff,

When its installed does it take presidence over ffdshow then? If so I could change the merit down so ffdshow will always be used instead...
???

Any other suggestions on this? I do feel that the xvid directshow filter should be given out with the package, as xvid's decoding should always be available....

Ill go make a new build now which should help the playing, if people can test the filter to see if the problem still appears that would be great. (ill send the filter to Koepi).

Thanks for the feedback,

-Nic

[Koepi]

Thanks Nic :) I'll upload a new standalone decoder installer as well as a new binary package with an updated xvid.ax then.

I will always include a DSF, as Nic pointed out it shouldn't be necessary to install something separate. I didn't notice artefacts when playing back with the older xvid.ax but if you say so I believe you.

Regards
Koepi

[Nic]

Well ive built a new version, & cant see any decoding problems...

Apart from the high CPU usage, im looking into that now.
(the latest version is on my site even though the website text isn't uploaded yet)

-Nic

ps
Im going to lower the merit to MERIT_UNLIKELY too, so ffdshow will always get used if XviD is selected in ffdshow.

pps
High CPU usage was due to my cr*p graphics card, my mistake.

[Smiff]

I mean in the unstable releases. If Keopi includes Nic's DSF, half the time it will be out of date, since he's not doing his own DSF builds. Sure you should have a decoder with stable releases, obviously :)

The problem is that i can't unpack the Nullsoft installers (?) to get at xvid.ax, it's not a big deal, just an inconvenience and i don't like doing more installs/uninstalls than necessary :)

Nic
the problem is not the priorites, that's all fine thanks.. i have always used ffdshow's codec tab to choose which to use (usually completly unchecked, I don't trust ffdshow atm ;)), no problems.

[Nic]

Ahh yes, does it comes up with cant replace xvid.ax? Thats because windows explorer.exe stupidly captures xvid.ax. Restarting your computer then installing will remove that problem.

(or you can even kill the explorer.exe process then run explorer.exe again. That will allow the install too).

My filter is kept upto date, very regulary recently & Koepi has the latest build always as far as I know (??)

-Nic

[AcidJunkie]

here are also no problems at all using koepi's 22102002 build. i thunk it's even a little better picture not using nic's standalone 13102002 for playback...

i've done bringing out the dead (1:56:03) with 640*272 to 735 MB (qpel enabled, hinted me disabled, lumi enabled) in 2passes.
(also used c3d). results are very good (at least for me being new to xvid).

so far
ACID

[Nic]

My new build is up properly now...so please give that a try if you can.
( http://nic.dnsalias.com )

-Nic

ps
@Koepi:
my email is slow today so xvid.ax is at http://nic.dnsalias.com/xvid.ax :)

[Koepi]

Thanks a million Nic :)

d/l'ing now, hopefully the ASCII transfer doesn't break usability of the ax ...

I'll edit this post to give propper feedback!

Best regards
Koepi

[Koepi]

ARGS! It doesn't work for me ?!? It uses xvid.dll now to playback xvid videos :-/ Maybe your "priority-patch" for ffdshow should be removed again, I never had a problem there...

Thanks for your work Nic,

Koepi

[Nic]

try http://nic.dnsalias.com/xvid.ax now if you can, that has the merit set to normal (rather than preferred as it was in the first place)

(the build on my site has been updated too)

-Nic

[Koepi]

Ok, new standalone decoder uploaded!

Just to make sure it works and if you have ffdshow installed, you have to set it to decode xvid, then to using xvid, and then disable all again - at least it worked for me that way ;)

Thanks Nic for your great work! Sorry for not sending out the installer now as I'm quite in a hurry...

Best regards
Koepi

[unplugged]

Originally posted by Nic
Well ive built a new version, & cant see any decoding problems...
Of course, but things go well only with B-frame based videos, or with Qpel based videos encoded at least with CVS 22/10.

Is there anything that can be done with Qpel videos encoded with CVS 12/10, 13/10 and 21/10 that are no more exactly decoded? :(
(those encodings WERE VISUALLY PERFECT, but with newer xvid builds, since 22/10, smearing has magically appeared during decoding!)

Has anyone red my post (http://forum.doom9.org/showthread.php?s=&threadid=36396) regarding build versions decoding incompatibility?

Thanks, I hope to have a little response about this from Devs.

P.S.: I can post very small clips in my FTP if any sample is needed to test decoding of 12-21/10/2002 videos...

[-h]

I doubt they were spec-compatible, thus when XviD changed to better reflect the spec, the behaviour that previous encoders assumed would exist at the decoder end was no longer in place. Thus we get artifacts :)

I doubt it's fully spec-compatible at the moment either. All you can really do is re-encode, switch xvid.dll around for playback, or wait until (or if) libavcodec supports the old buggy behaviour.

-h

[Smiff]

I just want to say, I also have some encodes from that time, but mustn't complain because we used those builds on the clear understanding that they were "unstable", and so imho as users we should just er how to put this politely 'shut up and deal with it' (go back to the source, etc.), because frankly if I were a dev having people ask for workrounds on the decoder side would piss me off, really. But it would be nice if e.g. unstable builds had a link to a thread where users could report issues found quickly... i don't know but there could be room for improved communication perhaps.


Could someone explain to me, when you check "use xvid" in ffdshow, what is it using exactly?

[unplugged]

Thanks -h, finally this has been the clarification that I was waiting for. ;)

Do you know any good/excellent ISO-MPEG4 player or decoder that can we use for reference testing?
(if possible with Qpel support)

(MPEG4-IP?)

[Smiff]

unplugged that's an excellent question, i was going to ask that but forgot :)

[unplugged]

Originally posted by Smiff
I just want to say, I also have some encodes from that time, but mustn't complain because we used those builds on the clear understanding that they were "unstable", and so imho as users we should just er how to put this politely 'shut up and deal with it' (go back to the source, etc.), because frankly if I were a dev having people ask for workrounds on the decoder side would piss me off, really. But it would be nice if e.g. unstable builds had a link to a thread where users could report issues found quickly... i don't know but there could be room for improved communication perhaps.
Smiff, I have been [mis]understood, my point is a "little" different,
I'm not certainly complain about anything to anyone.

My point was *the clarification*, because along this view we could imagine having severals old videos really not fully working with standard MPEG4 because does not exist a piece of working ISO-MPEG4 player to test them all, yet.

Example:
Whe encode with version A and decode with version A, result: OK
encode with version B and decode with B, result: OK
encode with version C and decode with C, result: OK
with C whe can decode A B C, but maybe none of them A B C are really compilant with theoretical and official standard Z, without a f@ck@d ISO player to check DivX/XviD works in progress :)
Quite disarming! :D

[unplugged]

I have just downloaded from Envivio company EnvivioTV MPEG4 player :), I have heard good things from Envivio AAC implementations so something has advised me to give a look to its site for some MPEG4 stuff...

Well, just only one free download and it's the thing that I was searching for! :D
http://www.envivio.com/products/etv/download.jsp (2Mb)

I'm using tool "mp4creator.exe" (from MPEG4-IP project binaries) to convert AVIs to MP4.
Well, with EnvivioTV I'm able to view XviD-23/10 encodings without any artifact, but XviD-23/10 Qpel encodings still have color smearing quirks :p
haven't tried yet videos with B-Frames...


P.S.: EnvivioTV operates by adding plugin for WMP, RealPlayer and QuickTime; once installed, the RealPlayer implementation seems to perform the best in terms of speed.

[ckjnigel]

Mozillazine has the Build Bar forum where users can say: "Send Link doesn't work![WinMe, 2002102208]...Anyone else seeing this?" (e.g.) Usually it takes under three hours for a response such as: "Yes. Bug fix checked in and will be in tomorrow's build." I think XviD has sufficiently large a following for this to work here, too. I think this works to build rapport between coding developers and crash test dummies.

[Koepi]

There's a huge difference between xvid and mozilla:

Mozilla has plenty paid coders working on it. Mozilla is huge.

XviD is too small for that IMO.

Regards
Koepi

[serbersan]

I've tested the 23/10 build from Nic and I want only to report that this build continues crashing virtualdub, this time at 96% of the first pass. For the rest I've obtained the same result of 21.

My settings:
2pass - 1pass: (after load defaults)
Motion Search precision: 6
MPEG
No lumimasking
No hinted ME
In b-frames:
--Maximum: 5
--B-frame Quantizer Ratio: 200%
--The rest options are unchecked

Regards, Sergio.

[Nic]

Hi serbersan,

Ill do a two pass with it tomorrow to see if I get the same results....Anybody else having the same problem?

Cheers,
-Nic

ps
I assume your using the latest version of VDub & have clicked Load Defaults regulary. Also maybe try changing the path were your writing your first pass stats file too....

pps
Im going to do a proper encode of a movie over friday so I can hopefully pickup on any bugs....

[iago]

@Koepi and Nic

Whatever I do here (even by uninstalling ffdshow) I can't decode my rips using Nic's DSF. (Currently Nic's 23/10/02 binary installed.) Any help would be appreciated! ;)

Koepi, your method unfortunately didn't work here friend ;).

regards,
iago

[Shayne]

Yes Nic i have to got crashes in vdib with your last 2 biulds.

This is in BFrames for sure. When it is enabled the process is hit and miss weather vdub crashes or not. On one encoding i ran it three times to get pass 1 and 2 for pass 2.

When bframes is disabled it runs smooth as silk. 4 encodings no crashes.

PS great quality boost in the latest builds:)

[cult]

same here with nic's build of 21.Couldnt try 23 because I was in midle of encoding with koepis.

[InfoCynic]

Hey, is there a command-line to access the DSF properties page, and could you install a shortcut to it on the XViD program group? :) Kinda like rundll32 xvid.dll, Configure :) It's VERY hard to change postprocessing settings...
Thanks!

[ookzDVD]

@Nic,

Thank you for the latest build 23/10/2002,
finally the B-frame works very well on my machine.