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

[Nic]

Hi,

First:
XviD Bug: This was what was crashing my DShow filter & possibly caused problems for milan with the new dev3 api. In xvid.c there is a line in xvid_init there is a line:
fprintf(stderr,"sad16v=XMM\n");

That is trying to write to stderr which is ok for most things apart from where stderr doesn't exist (like interfaces less programs, i.e. dshow filters). Remove that line, I could use my DShow filter again :) (minor stuff hey, but still took long enough to find)
(of course this isn't really a "bug", because its the dev api, but I thought it may be useful to report it anyway)

Second:
My new DShow filter works with dev3 api (YaY!) but it also now no longer relies on XviD.dll, this means it will no longer cause compatibility problems with each new version (& if you only needed xvid decoding then you could just install the .ax & not xvid.dll). I may add something to make it decode DivX if people want it.

Third:
Is my new site, http://nic.dnsalias.com a new dev3-api build is up (dont know how stable it is, but its there for testing) with the new DShow (src will be up soon). Hopefully my site is a bit easier to use & more useful.

Suggestions/bugs/comments welcome.

-Nic

[Koepi]

Nice work Nic! :)

Can you send me the xvid.ax only please so I can add that (and maybe even build a stand-alone decoder installer from it which I'll send back then of course)? I've plenty of stuff on HD for encoding so I don't have the option to install your build and take it from there (3 movies, some series,..).

Thanks,

Best regards,
Koepi

[Nic]

Sent to your roeder account :) Im hoping it wont get any annoying explorer.exe crashes anymore....

If anyone gets such a crash, could you post it here :) thanks.

-Nic

[Koepi]

Thanks a million Nic,

I'll build the installer ASAP... maybe I'm _really_ fast now ;)

Regards,
Koepi

[Koepi]

Hi Nic,

check your mail at that account you sent it from ;)

Best regards,
Koepi

[Nic]

Cool :) A 100kb XviD Decoder installer, no one can complain at that :D

-Nic

[milan]

ffdshow crashes when it uses xvid.dll from your newest build for decoding. After I saw your DirectShow filter sources I was able to access xvid quantizer table (better postprocessing) and motion vectors (ShowMV filter). Now when MACROBLOCK structure is changed it doesn't work anymore. But API version wasn't changed and I don't see any possilility to distinguish dev-api-3 and API 2.1. The only solution for now is to remove xvid internal structures access from ffdshow.

[Nic]

The way the XviD api works is being changed by gomgom so, hopefully youll be able to get round that soon :)

-Nic

[-h]

ffdshow crashes when it uses xvid.dll from your newest build for decoding. After I saw your DirectShow filter sources I was able to access xvid quantizer table (better postprocessing) and motion vectors (ShowMV filter). Now when MACROBLOCK structure is changed it doesn't work anymore. But API version wasn't changed and I don't see any possilility to distinguish dev-api-3 and API 2.1. The only solution for now is to remove xvid internal structures access from ffdshow.

Well, mapping handles to internal structs isn't really part of the API ;)

It's safe to assume that a 2.1-API DLL can't be mapped in this fashion, due to the gradual changes in structs like MACROBLOCK over time. However 3.0 should always be safe, as there are plans to export a standard array of quant/mv/dc/ac information.

-h

[HarryM]

Cool :)

I test it now...

[Shayne]

Site looks real good nic

[milan]

Well, mapping handles to internal structs isn't really part of the API


I know, but at least core_build could be changed.

[milan]

Cool A 100kb XviD Decoder installer, no one can complain at that


I'm sorry if you did this already, but for realy tiny decoding filter, you could try to remove references to encoding functions. Many of them are in xvid_init function, for example

quant_intra = quant_intra_c; - remove
dequant_intra = dequant_intra_c;
quant_inter = quant_inter_c; - remove
dequant_inter = dequant_inter_c;

Maybe few other changes will be needed, but linker dead code elimination should do the rest. When I was deciding to add xvid decoding routines to ffdshow is was able to compile 75 KB xvid_dec.dll library.

[Nic]

I was thinking the same thing milan :) ill try & cut down the size. Koepi do you have the nsis script you used? :)

Im going to add new luminance code, clean it up alot & add contrast & a few other bits. Then ill just put the source on my site for others to play with :)

Cheers,
-Nic

ps
I forgot the TOO_SMALL_LIMIT def so its probably set to 3 when it should be set to 1. If your planning to do any encoding this weekend, then I recommend Koepi's latest build rather than my own, ill fix that on my site at the latest monday.

[Nic]

New Build up: http://nic.dnsalias.com

Quarter Pel was added to the CVS on the 4th of this month. Ive tried to turn it on with Motion Level 6: Ultra High :) (experimental! But looks good to me!)

TOOSMALL_LIMIT set to 1 this time :)

Cheers,
-Nic

[-h]

Works well doesn't it Nic :)

Unfortunately there are some compatibility issues with inter4v+qpel - msfdam decodes it fine, but libavcodec/divx5/envivio don't like it. Yet.

-h

[Nic]

I know...concerning isn't it? Either Micheal's right and everyone else is wrong. or we've got it wrong.

Dont know about you but I trust Micheal & msfdam :)
(& if christoph gives it the nod & works on it....then YaY! :) )

Cheers,
-Nic

ps
Saw the australian pink floyd on Saturday. Weird hearing floyd songs sung with an aussie twang :)

pps
I assume by msfdam, thats the Microsoft Final Draft AMendment Reference Software?
(I know its obvious but im stupid.... )

[MaTTeR]

Worked very well for me on 2 test clips about 9mins long at 640 resolution. Details and color were superb with no artifacts. I decoded using the latest alpha of ffdshow with no post processing enabled.

Great work guys! Qpel was my long awaited love that I kept looking for, should be fun to test further now.

PS. Compile seems to be pretty fast as well using MPEG quants on both passes.

[Koepi]

Does it work with MVHints, too?
I'm writing out the MVhints now as well (hm. although I use my own compile ;) ), but it would be nice to know if this is a waste of space. I like the idea of quality improving MVhints, that's why I'd like to use it....

Thanks,

regards,
Koepi

PS: Nic, can you send me your updated DSF as well please? I don't know if your old DSF can decode QPEL already... :)

PPS: does it suffice to add a "frame.global |= QUARTERPEL;" after the "frame.global |= HALFPEL" line to activate qpel mode?

[-h]

Does it work with MVHints, too?

Very good question.. I haven't read up on the mechanics of it but since it just seems to increase MV resolution (1 = qpel, 2 = halfpel, 4 = pel) and functions like d_mv_bits() are unchanged, all MV/fcode storage for hints should be fully functional.

PPS: does it suffice to add a "frame.global |= QUARTERPEL;" after the "frame.global |= HALFPEL" line to activate qpel mode?

Yes, but you'll get better results with the qpel-specific REFINE16/REFINE8 flags.

-h

[Koepi]

Thanks Dan :)

*stopping encoding*
*rebuilding XviD*

:)

Thanks a million,
Koepi

EDIT: Hm. there's only halfpel-refine16|8 in XviD.h :-/
Restarting encoding...

EDIT2: stupid me. Ended up in the stable-tree sources on my HD %)
Recompiling with qpel refine flags...

[-h]

Has it crashed for either of you guys? I can only get a qpel encode to work ~5% of the time. Every other time it's an access violation on the first inter frame (?).

Looks like I'll have to start using binaries compiled by someone else :)

-h

[Koepi]

It works perfectly for me (sloooow, but effective in frame sizes...).
Never crashed no matter what I did, and I restarted encoding about 5-10 times now... no crashes.

I might send you a compile, if you like.

Best regards,
Koepi

[Acaila]

No problem for me either, but what do you mean with slow Koepi? I haven't noticed any slowdown at all compared to a normal build (at most 5% speed decrease, but that's all).

All we had to do to use QPel was motion search 6 right?

[reet]

Originally posted by -h
I can only get a qpel encode to work ~5% of the time.
-h

how can I check when a qpel worked??? maybe then i can help
cause i used the last binary on nic's site and everything went OK

i know how to use debugview but i can't seem to find any info about qpel in it :-(

greetz reet

[MaTTeR]

I didn't notice any encoding slowdowns at all. Furthermore I seen no mention of Qpel in debug view either, using MS6 I'm assuming it worked anyway:)

I just noticed a lot of access violations happening when using Decomb in my script now though. Like -h, it does seem to happen at first inter frame. Disabling decomb.dll and everything encodes perfectly though....very odd.

Encoding a full 4:3 DVD with it now using a very basic script, suspect it should be fine.

[Dali Lama]

Hi,

Can I ask what is QPEL used for. Is it a more accurate/precise Motion Estimation routine? My impressions of QPEL in Divx 5 at least was that at low bitrates (aka 1-CD) it increased artifacts, due to the more precise ME. Without it, things were a little bit more blurry but much less artifacts. Also, QPEL seemed to reduce filesize somewhat.

However, with my first impressions of Xvid QPEL, the quality seems to improve a little in complex scenes with fog/ghosting and it doesn't really sharpen. Also, I see no filesize reduction. I will have to test at lowbitrate. These observations are for Quant 2. Overall, I think this is good, because if QPEL is a more accurate ME, which is why Nic put it under that tab in Search=6, then I think QPEL will be used in all encodings.

Also, the speed of Xvid QPEL is ridiculously fast compared to Divx5, both in encoding and decoding.

Good work all,

Dali

[-h]

The goal of motion estimation is to re-create the current frame by copying blocks from a reference frame - the better job it does of re-creating the current frame (i.e. the closer the copied block is to the current one), the fewer bits will be needed to store what's left over.

Quarter-pel motion estimation is just another way of letting motion estimation find blocks which more closely match the current block. If a quarter-pel implementation is good enough, the result will always look better (for a given size) or require fewer bits (for a given quantizer) than an implementation without quarter-pel.

As for what it actually does, you'd have to first understand half-pel motion estimation. In that case, instead of just copying pixels from the reference frame to the current one, pixel values that are "half-way" between one pixel and another pixel are copied. These half-way values are derived by averaging two neighbouring values together, and improves compression by around 30%.

Quarter-pel makes things more complicated. Performing another averaging operation on the half-way values and the original full-pel values would give some kind of quarter-pel position, but would be weighted too far towards the full-pel value and not be terribly useful. The "interpolation" for quarter-pel values actually involves passing full-pel values through a lowpass filter, then performing further averaging between them. This extra lowpass step is part of the reason for quarter-pel mode being slower than full- or half-pel, but the fact that you're doing so many more SAD checks per block search also contributes to it.

All above should have "I think" appended, of course.

-h

[iago]

Hello all,

Currently I'm doing a full 2-pass encode with Nic's 07/10/02 build with motion search 6 and using MVHints too (with h263 quantization). I'll report back the results when finished.

best regards and thanks for the new Qpel feature addded,
iago

[Razor04]

Regarding MVHints...wasn't there a better version of them in the works? One that didn't lose detail but actually improved it? If there is one is it in this latest build from Nic? I can't wait to test this build when I get some free time (College doesn't leave much). Thx!

[Koepi]

@Razor:

if you'd snoop/lurk around a little on this forum, you'd know (a search could help you there, too!), that with sysKin's ME hintedMV is used for further precision in motion estimation during the 2nd pass, thus possibly increasing quality, at least not "damaging" it.

[Razor04]

@Koepi:

I know...I read about it on the dev mailing list...but didn't know whether it had actually been implemented or not. I read this forum regularly and didn't see anything mentioning that it had. Thx for the answer.

[HarryM]

@Nic:

I tested your build 07102002 with ME=5 (qpel not activated?) and ME=6 (qpel activated?).

I see no diferences!

The quality is comparable, the filesize_at_quant2 is very close identical.

I have experiences with using of qpel in divx5. Using qpel has much, much influence with filesize...

I have feeling, that qpel is'nt activated/ready, that I dont see any encoding speed slowdown too. ;)

[Nic]

Well, there is a possibility its not enabled, but it should be(?) But all I did was add the QPel refined flags to the motion 6 field of the vfw. So I may have missed something (I just didnt have the time at work to check).

Koepi/h do you know of anything I may have missed/done wrong?
(if not ill check it out again tomorrow & have a proper look)

Cheers,
-Nic

ps
@koepi: Cant send the filter today :( But I will tomorrow :)

[Koepi]

Nic:

the only thing that misses after that is that
frame.general |= XVID_QARTERPEL; // right after the line
frame.general |= XVID_HALFPEL;

This produces a 10-15% slower encoding here, together with MV hints the image is totally f***ed up, without MVhints it looks somewhat OK, but I don't have a propper qpel decoer at hand so I can't be sure it's right, latest ffdshow snapshot produces some small artefacts at least.
But as gruel et al discussed on devel list qpel is buggy (maybe at least), michael claimed that he didn't write it's bug-free ;)

At least XviD should decode that correctly... looking forward to get your actual standalone decoder :) I'll put up a new installer with that if you don't mind!

Regards,
Koepi

[Nic]

Cool :) Ill make a rebuild tomorrow & have another look at the code & make sure my dshow is decoding the QPel ok...
(ill put up the source tomorrow too :) & send you a copy).

Cheers,
-Nic

[Koepi]

Oopsi, so your build isn't doing quarterpel yet? Well, at least sysKin's ME can be tested for bugs that way! :)
I'm looking forward to the new decoder!

Thanks for your great work Nic,

best regards,
Koepi

[iago]

-> Oopsi, so your build isn't doing quarterpel yet? Well, at least sysKin's ME can be tested for bugs that way! :) (Koepi)

It seems with my full 2-pass encode that's about to finish I am testing only MVHints at the moment. Anyway, better than nothing! :) Looking forward to trying the new build with Qpel, Nic ;).

thanks and best regards,
iago

[HarryM]

Originally posted by Koepi
Oopsi, so your build isn't doing quarterpel yet? Well, at least sysKin's ME can be tested for bugs that way! :)
I'm looking forward to the new decoder!

Thanks for your great work Nic,

best regards,
Koepi


@Nic:
@Koepi:

I tested (on Nic's latest binaries) b-frames too (without packet bitstream). For decoding I use ffdshow (xvid decoder cant decode b-frames yet?).

Xvid with b-frames (I use max two b-frames) are very nice for looking ;)
Video is 'slightly' crappy at edges compare to b-frameless, but filesize is about 30% smaller (at quant=2)!

I think, that xvid will be prepare for regular use of b-frames (soon?)... :)

[Teegedeck]

B-frames look very nice to me, also! (Apart from the decoding-problem. As soon as that's solved, I'd vote for making them 'regular', too.)

Well-done all!

[iago]

hello all,

I don't know if it is due to Hinted ME or due to a high average quantizer of ~4, but the resulting encode is really NOT much fun to watch, with an unsatisfactory overall quality and excessive blockiness on the faces, etc...
(2hr-1min / 576*320 / SimpleResize / h263 / motion search 6 / internal linear scaling, no special credits treatment)

best regards,
iago

[Koepi]

@iago:

Try the second pass without MVhints, maybe that helps it :)

My Shanghai Noon encoding looks beautiful so far, when decoded with xvid.dll (via vdub), Nic's "old" standalone decoder produces some minor texture glitches (minor colour mismatches).

Regards,
Koepi

[TheXung]

I'm just jumping with joy now. Quarter pixel is the one feature that I've been waiting for. Now I can happily revert back to using XviD.

From a little test clip I did at quant 3/MPEG, there was a 6% reduction in filesize and the 1/4 pel clip was sharper. The sharpness is comparable to the sharpness gained using 1/4 on divx. It's also nice how there isn't that large of a performance hit. However there does seem to be some discrepencies with the decoders. Divx doesn't decode it right, ffdshow almost has it right except for some issues with the UV channels not being motion compensated right. Nic's Xvid works fine. However, it doesn't decode the bframes.

There also seems to be an issue with using bframes and 1/4 pel at the moment. It doesn't seem to be able to use both at the same time. Turning 1/4 pel on or off produced the same file when bframes is on. Does anyone know if this just hasn't been implemented yet or did I do something wrong. I don't know how to read the mailing list now ever since they took the website down and since I wasn't subscribed to it. What is the state of bframes with curve compression?

[MaTTeR]

@Nic

Possibility to have ModHQ also implemented on your next build?;)

[-h]

Quarter-pel is most likely buggy at the moment, but shouldn't be for long. B-frame quarter-pel support is not yet present (whether encoding or decoding).

-h

[Koepi]

@-h:

when did your crashes with the code occur?
I could reproduce an error when using more than 680MBs/image (e.g. 512x384 resolution). Results in a crash on the first pframe.

Regards,
Koepi

[octapus]

---TheXung
-------------------------------------------------------------------
I don't know how to read the mailing list now ever since they took the website down and since I wasn't subscribed to it.
-------------------------------------------------------------------

Me too. Can anyone post an address where mailing list for xvid can be viewed. I am talking about the mailing list which was inside www.xvid.org (the site is down since 22 august)

[Nic]

The one I check on is:
http://list.xvid.org/pipermail/xvid-devel/
is that the one?

-Nic

ps
Just compiled a new version, qpel looks good, but because it crashes on hi-res stuff, im going to try & debug & fix that before releasing a new build. (QPel decodes fine though it seems :) )

pps
Hmmm, crash occurs on a:
transfer_16to8copy(pV_Cur, &data[5 * 64], stride2);
But I dont know why???

(Actually its a memory error thats causing the debugger to output cr*p so, however, the bug doesnt seem to be there if you encode with bframes not set to -1)

[TheXung]

(Actually its a memory error thats causing the debugger to output cr*p so, however, the bug doesnt seem to be there if you encode with bframes not set to -1)

If you encode with bframes set to something not -1, then it starts using bframes and not qpel, thus no bug crash occurs. or at least that's how it seemed to me because turning the qpel flags off and compiling/redoing exactly the same thing will make a file of the exact same filesize as with qpel turned on.

[Nic]

Oh didnt realise that, I gave up at that point (Im at work & already took the morning off to goto the dentist, so my lunch break was very short). Sounds like isibaar is going to patch image.c soon anyway so that should help matters.

-Nic

[Koepi]

From Isibaar:
qpel can crash because the 6tap low-pass filter is a pretty
bad hack: it reads up to 3 pixels from outside allocated memory which can lead to an access violation.

Regards,
Koepi

[Nic]

Yup, read that, thats when I gave up debugging it :D

-Nic

[cjv]

Just finished testing Nic's most recent build, not for the qpel but for the b-frames.

Motion Search 6, h.263, lanczos, 640x272
First pass size (no b-frames): 1682914
First pass size (2 bframes @ 200%): 1266146

Wow! That's almost 400+ megs saving, and visual quality is nearly identical (all at q2)
All I did is hex edit the avi and changed the FOURCC to divx/DX50 and it plays back perfectly using ffdshow.
I just might add some vorbos audio and burn the first pass, but I want to make sure it will play back in the future and that the resulting stream is valid MPEG-4.
Settings used:
Max b-frames: 2
Ratio: 200%
Packed bit: Unchecked (not sure is this is OK)
DX50 Compat: Unchecked (not sure if this is OK)

I would prefer to make a ISO compliant stream over a DX50 one.
I know b-frames are highly experimental, but in this case I'm happy with the resulting file..it looks great. Is this OK for archival?
thanks,


cjv
(testing some more...)

[-h]

Wow! That's almost 400+ megs saving, and visual quality is nearly identical (all at q2)

Note that setting the ratio to 200% will set B-frame quants to 4.

I just might add some vorbos audio and burn the first pass, but I want to make sure it will play back in the future and that the resulting stream is valid MPEG-4.

Vorbis certainly isn't MPEG-4 compatible :)

I can't recall how XviD stores "dead" frames in AVI files when DivX 5.x compatibility is disabled. I'd hope they're not N_VOPs (they would have to be dropped by the MPEG-4 muxer) and that they're not included in timecode calculations, but I'll have to check.

With the settings you specified though, you can be pretty certain that it's spec-compliant MPEG-4 video, just in the wrong container.

-h

[Nic]

If you used my build...why didnt you use AviC that comes with it to change the FourCC rather than doing it the hard way ??!? :) :)
But im glad it worked great for you :)

-Nic

[cjv]

@-h:
Thanks for your reply. I keep the AC3 on my HD and just use Vorbis/OGM until the MP4 file format is more widely supported. I will re-encode the audio to whatever (AAC), but once the VOBs are gone, I just want to be sure the video is compliant. I'll wait for your reply on "dead" frames before I delete the VOBs, though, just to be sure. One question, does selecting DX50 B-VOP Compat. make an invalid MPEG-4 stream in any way, or is it just a safe idea to select it for now?
Just looked through the b-frame encode again, maybe I'm blind, but all I can say is WOW! Great work! (haven't tested 2-pass yet however)

@Nic:
Hex editing is just so much more fun! :)

cjv

[-h]

I'll wait for your reply on "dead" frames before I delete the VOBs, though, just to be sure. One question, does selecting DX50 B-VOP Compat. make an invalid MPEG-4 stream in any way, or is it just a safe idea to select it for now?

XviD currently relies on VirtualDub recognising the "dead frame" code XviD and DivX 5.x send back to prevent storage of the frame altogether. That means the stream is good to go as far as MP4 compatibility goes. Well, so long as there aren't bugs we don't know about yet :)

DivX 5.x compatibility mode outputs an N_VOP frame with a duplicate timecode. That will mean that the muxing program will have to know that detecting duplicate timecodes means the frame to be discarded is the N_VOP. I don't know whether current tools are aware of this, or even the P+B packed AVI frame that this mode creates.

-h

[Teegedeck]

From a first try-out, it seems that at least Nandub doesn't know how to handle this (with DX5-compat.-mode on). Video gets async more and more during the clip.

[cjv]

First pass of Austin Powers finished, 5% comp. check was 54%, however, after using the whole first pass stats file, comp checked jumped up to 69%!!

I originally used 576x320 w/bilinear, h263, 2 b-frames @200%, no packed bitstream, no DX50 compat, and first pass was 957,842 and looks great. (a bit blurry of course)
Now, 69% is way to high for a 1CD rip, so I must decide when I re-encode whether to use bicubic resize or raise the resolution up to 640x..decisions, decisions. :)

Anyways, did a few 2-pass size checks w/b-frames (using internal linear..hope this is enabled in your build Nic?):
desired size: 45,000
result: 45,012
result: 45,008

Personally, I can see no reason why I won't use b-frames from now on! (unless something goes wrong with Austin Powers that is..but so far things are looking very good)

cjv

EDIT: Just finished muxing the first pass file with Vorbis audio q=0.250 using OggMux-0.9.3 and everything worked perfectly and everything is in sync.

[Gazza]

I've just finished trialling Nic's version of the codec dated 7th October 2002 and I thought I would pass on my initial results.

Settings where Motion search 6, MPEG, FourCC was xvid.
B frames was set to -1
I used the default alt curve (that is no alt curve)
I-frame boost was 0%
High bitrate scenes = 0
Low bitrate scenes = 0
(the last three settings using Koepi's advice from work done on his statsreader utility)

Visually the output was pretty good (however I used an old noisy source). My target file was 1323932Kb and the final file size was 1323922Kb which is about 0.00076% accurate - wow!

The encode seemed to be very slow though. Frames per sec in the second pass dropped from 11/12 fps to 7/8 fps. This extended the overall two pass encode time from about 7 or 8 hours average to over 12 hours.

I'm going to give B frames a go on the same source - can anybody advise on settings I can use for the first time?

[Emp3r0r]

I'm doing some testing with B-frames also, I've set up the following testssource=mpeg2source("C:\VOBs\thehaun.d2v",cpu=0,idct=5).crop(2,60,-3,-60)
source=source.LanczosResize(640,272)
return source.freezeframe(0,0,1500)

# video size: 737 MB, 754255 KB, 914 kbps
# creditsA: start=0 end=0
# creditsB: start=153419 end=1621176 - Ultra High, h263, no packed bitstream, no DX50 compat

1 b-frames @100% : size 1,122,664KB
2 b-frames @100% : size 1,147,084KB

1 b-frames @200% : size 819,532KB
2 b-frames @200% : size 735,770KB

bframes disabled : size 1,113,726KB

divx5 bframes only : size 826,010KB

I can't comment on visual quality (I will soon) because I'm not at the computer that is doing the encodes. B-frames look very promising for descreasing filesizes, hopefully they look good too ;)

[cjv]

@Emp3r0r:
I'm interested in your visual impression of 2 b-frames @ 200%...compared to no b-frames at all. I can hardly tell a difference, but you know when you've looked at the same clip over and over and over again..they all start to look the same! I'm thinking that even if there is a very slight decrease in quality at constant quant 2 (which I've mostly been testing), the drastically reduced file size definately makes up for it because in 2-pass, you will end up with a lower average quant.

cjv

[Nic]

New build up at:
http://nic.dnsalias.com

QPel has been fixed with larger resolutions & looks great! I tested B-Frames & although XviD doesn't decode them correctly, they are encoded well now (use ffdshow to decode them) :)

-Nic

ps
@Koepi & h: So whose dealing with XviD B-Frame decoding? is that still chem?

[Koepi]

@Nic:

chem has disappeared some months ago it seems, so now nobody is at it...

Regards,
Koepi

PS: Nic, can you send me your DSF please? :)

[Nic]

Thats a real shame...

-Nic

ps
Sent to your lycos account... :)

[tangent]

Originally posted by Gazza
Visually the output was pretty good (however I used an old noisy source). My target file was 1323932Kb and the final file size was 1323922Kb which is about 0.00076% accurate - wow!

I hope you mean 99.99924% accurate :)

[cjv]

Not sure if this is a known issue, or my dumb mistake, but I've been testing Nic's 10-10 build (loaded defaults first), and turning on b-frames (I used 2 @ 200%), no packed bitstream and no DX50 compat.

Choosing either MPEG or h263 quant type (w/b-frames ON) always results in identical files (binary compare) and from the appearance it looks like its using h263.

Results (file sizes):

Search5-h263-nobframes.avi: 9,180
Search5-MPEG-nobframes.avi: 10,438
Search5-h263-2bframes.avi: 5,766
Search5-MPEG-2bframes.avi: 5,766

Search6-h263-nobframes.avi: 8,698 (Qpel by default)
Search6-MPEG-nobframes.avi: 10,406 (Qpel by default)
Search6-h263-2bframes.avi: 5,762
Search6-MPEG-2bframes.avi: 5,762

cjv
PS (regardless, the results still look great!)

[Emp3r0r]

Here are the visual results from Nic's Oct 7th build using b-frames.
Zipped PNG's (http://jvance.com/hitme.aspx?url=http://jvance.com/files/frame93081.zip)

I grabbed the shots through virtualdub and saved them using photoshop 7. The frame is not a keyframe. Enjoy.

Woops, I just noticed I didn't grab the same frame for all shots... Don't know how that happened but anyway my conclusion is that bframes are doing their job nicely (reducing bitrate when set=2) and without sacrificing quality. Great work guys.

[Gazza]

Originally posted by tangent


I hope you mean 99.99924% accurate :)

OK I stand corrected.

I just finished a second encode with the same settings as above but with with max frames set to 2. The other b frame related boxes remain unchecked. I did the encode as a second pass only (original 1st pass was with b frames set to -1). Quality seems similar to a non b-frame encode but the frame rate dropped to about 4 or 5 fps --- very, very, very slow. It took about 9 1/2 hours just to do the second pass!

If you do a two pass encode with B-frames, do you need to do both passes with B-frames set?

Anyway file size results I got are

Without B-frames 1323922Kb
With B-frames 1320174Kb

A little size reduction compared to the results of others. Maybe I will re-run again with B-frames set for both passes. However this could take 17+ hours based on the low frame rate.

[wing1]

@nic

build 10-07-2002 w/ Qpel -> 20fps => same source w/ b-frame -> 14fps
build 10-10-2002 w/ Qpel -> 16fps => same source w/ b-frame -> 14fps

what has changed?

Quality wise, both builds produced equivalent output, only Qpel speed dramatically reduced. Was the earlier version just a fluke with the encoding speed using Qpel?

[-h]

what has changed?

I believe the first build only added Qpel support (i.e., no Qpel positions were actually searched, so it wouldn't do anything). The second build enabled Qpel refinement, which will achieve better quality but is slower thanks to more candidate checks during motion estimation.

-h

[Gazza]

Thanks -h,

However I just did a quick check with Nic's 10 Oct binary and fps has still droppped from 12fps to 4/5 fps. I would love to know how wing1 got up to 20fps...

At a fps of between 5 to 6, a 2 pass encode will take about 14 or 15 hours....?

Do I need to disable Qpel manually if using B-frames to get the speed up? Is there some double processing going on with both Qpel and B-frames activated?

Gazza

[trbarry]

The second build enabled Qpel refinement, which will achieve better quality but is slower thanks to more candidate checks during motion estimation.

-h -

Occasionally I think I'm being creative and instead come up with some fairly dumb questions, so please bear with me. ;)

But it seems as things go from half pel to qtr pel to whatever that at some point the cost of all the candidate checks would be more than a numerical solution to calculate the fractional pel location between any square of four adjacent pixels.

Say you were searching motion both horizontally and vertically within a unit square, in a range of 0 to 1 fractional pixels. The interpolated value to compare against seems like it might be the bilinear interpolation value we use in BiLinearResize. Offhand this would seem to be a continuous value with derivatives in that area and you could calculate the best match point directly, if any. (if the answer even fell in the square)

But if you were doing quarter pel you might end up doing 25 SAD's just to handle that little square. (0, 1/4, 1/2, 3/4, 1)^2

Is this (continuous pel motion search) done, and if so, does it work? I confess I didn't really try to work out the math, and should think these things through more thoroughly before asking, but I haven't been drinking. ;)

- Tom

[wing1]

@-h

Thanks.

@gazza

nothing special really. I throw my typical captured clip with a simple avisynth script at it. Normally, I would get around 12-14fps out of most of the xvid builds; However, using Nic's 10-07-2002 build I noticed it jumps to 20fps which is quite surprising to me too, and this prompted my querry above.

[Gazza]

Originally posted by wing1


nothing special really. I throw my typical captured clip with a simple avisynth script at it. Normally, I would get around 12-14fps out of most of the xvid builds; However, using Nic's 10-07-2002 build I noticed it jumps to 20fps which is quite surprising to me too, and this prompted my querry above.

It is weird how you get a performance improvement and I get the opposite. I also used to get about 12-14 fps. Just an idea but I use;

mpeg2dec.dll 184Kb dated 24/4/2002 and the BicubicResize that came with avisynth.204.

Is there another resize method which is better/quicker? Could it be that there is a better version of avisynth? Which version are you using?

[unplugged]

Originally posted by Gazza
Is there another resize method which is better/quicker? Could it be that there is a better version of avisynth? Which version are you using?
www.trbarry.com/SimpleResize.zip
Very fast, although not better quality but it is very close to BicubicResize(x,y,0,0.5), however make yourself a comparison...

[Gazza]

Thanks unplugged - I will give it a go and let you know if this fixes my problem.....

[Nic]

New build up:
http://nic.dnsalias.com

XviD now decodes B-Frames thanks to Isibaar! :) & so now does my DirectShow filter :)

Cheers,
-Nic

[Nic]

I Take that back! theres still a bug with xvid decoding bframes! :(

-Nic

[rui]

Unfortunelly, i can confirm that. But since, at least in my experiments, qpel is working better than b-frames, i am only using it for now, and your ds filter seems to be working very nicely with it. In fact, i had some problems decoding with motion 6 (qpel enabled) with ffdshow, even the latest. But for b-frames it was ok.

[unplugged]

Another thing...
Has "TOO_SMALL_LIMIT" fix included officially in CVS?

[Koepi]

Not really, in CVS / dev-api-3 the value is lowered to 2 (Nic and I do set it to 1 though).

Regards,
Koepi

[Gazza]

In my last posts I reported a problem with encode speed. In the end after a number of different attempts (including going back to earlier versions of xvid) I dumped the sample video source I was using and started again with a new source. The first source was a digitised version of an old movie with heaps of noise. I wanted to see if the recent versions of xvid amplified this noise - it seems to a little.

Anyway, trying a newer source seems to have fixed my speed problem. Using Nic's 10 Oct version, without B-frames encodes it zooms along at about ~14 fps. However the resulting encode is cr*p with problems in the colours (reds and blues bleeding through object outlines). With B-frames the encode speed drops to about ~12fps but the quality is comparable to Koepi's 23 Sept version of xvid. Note, with B-frames enabled, the fps jumps about from 8fps up to 16 fps but is generally high.

I'm happy with the speed but note there is still a few problems that I thought the community needed to know about.

See Ya

[edit] - I actually used Nic's 11 Oct version in the tests above. Sorry about that.

[Koepi]

<repeat>For decoding xvid qpel you need xvid decoder from nic and disable ffdshow to decode xvid</repeat>

ffdshow/ffmpeg/libavcodec decode xvid qpel with the reported colour mismatches/bleeding, it's known for several days now.

Regards,
Koepi

[Gazza]

OK, got the message and thanks for the advise.

[Nic]

Also my build has TOO_SMALLLIMIT set to 2 rather than 1.
Ive reloaded it with it set to 1 (but havent changed any text on the site)

Just re-download.....

-Nic

[Koepi]

Nic,

we should really force someone (-h?) to change that in CVS, it's one of the things I (and now you start with that, too) forget most of the times...

:)

Regards,
Koepi

[Nic]

I know ive got a huge list of things to do at present everytime I do a compile:

1) Add #ifdef __cplusplus extern "C" type lines to image.h
2) Get rid of the fprintf(stderr in xvid.c in xvidinit
3) Set TOOSMALL_LIMIT to 1
4) Set BFRAMES & BFRAMES_DEC in all project settings
5) Change the pmv_presets in the vfw to valid values
etc etc

I posted an email to that effect to the xvid team list, but it hasn't shown up as yet (well not for me?). I also stated that the:
if(BitstreamShowBits(&bs, 8) == 0x7f)
{
BitstreamGetBits(&bs, 8);
return XVID_ERR_FAIL;
}
Hasn't fixed the bframe decoding problem. which is not surprising as sending an xvid_err_fail is going to cause problems for any decoder when asking for a frame (just getting the 8 bits & continuing doesn't work either obviously). But I don't know enough about B-Frame decoding to fix it up. I guess isibaar is our best bet...-h you got any clues? :)

Cheers,
-Nic

[Koepi]

Hehe, your post arrived :)

Hm, setting BFRAMES & BFRAMES_DEC within the project files... I only set them in xvid.h and then somewhere in vfw, I think config.h, that suffices as well ;)

We should think about making "New Modulated HQ" mode a standard as well as some people reported they have some satisfying/nice results with it.

Regards,
Koepi

[Nic]

Well the email has bounced to me yet, oh well. I cant get to xvid.org at all either...can others?

-Nic

[-h]

Say you were searching motion both horizontally and vertically within a unit square, in a range of 0 to 1 fractional pixels. The interpolated value to compare against seems like it might be the bilinear interpolation value we use in BiLinearResize. Offhand this would seem to be a continuous value with derivatives in that area and you could calculate the best match point directly, if any. (if the answer even fell in the square)

You could try this, however quarter-pel data isn't calculated bilinearly only, but in addition to a 6-tap filter. It would be tricky to guesstimate correctly, but I suppose it's possible.

It would certainly have benefits for half-pel mode..

Also I'm teaching at a kindergarten this afternoon, but once I get home again I'll change TOOSMALL_LIMIT, vfw presets and other things that aren't working too well at the moment.

-h

[trbarry]

You could try this, however quarter-pel data isn't calculated bilinearly only, but in addition to a 6-tap filter. It would be tricky to guesstimate correctly, but I suppose it's possible.

It would certainly have benefits for half-pel mode..

-h -

Again, I haven't even proven I could do this, but I think I could.

But if the problem with qpel using a 1/4,3/4 average is just that it is too close to the single pel answer, that maybe wouldn't be a problem here. A direct calculation in integer arithmatic could maybe find the closest 1/32 or 1/64 pel answer in the same time. So if an optimim "sum of squared error" answer exists then it would probably (maybe?) find it pretty closely.

I'll see if I can work out the math so I can have a better idea what I'm really talking about here. I just posted the idea last night on a silly impulse but thinking about it again a bit more today hasn't showed any obvious problems.

Is anything smaller than 1/4 pel even allowed in MPEG4?

- Tom

[Nic]

Just to say that isibaar re-entered his fix for B-Frames (which I should have really been able to come up with myself). But it still didnt work with my DShow, but it was my DShow's fault this time, re-wrote bits of it & now its done :) . New build will be up shortly.

-Nic

ps
The weird thing is if I had sent the email to only Koepi like I meant to, instead of the whole xvid team, this might not have got fixed for a long time... :)

[cult]

just finished my test with qpel enabled.nics 10/10 compile.My settings were:cpu=6,lumoff=-2,temporalsoften (2,3,3),BicubicResize(640,352,0,0.75).h263 for both passes,no lumi,Iframe q 2-4,Pframe q 2-8,used alt curve,and starting and encoding credits,with 31q.The result is amazing!Maybe a little bit blurry.Perhaps I should use sharp bicubic,instead of neutral...
Target size:2446325kb,estimated:2.506.147.840 bytes(2447410kb).
The movie is bbc's lost world,tough source for compressing.As long as I can see everything looks perfect.No blocks,no strange colors,no nothing.Thanx guys.
Now testing same movie,same settings with bframes.It should take long...

[iago]

@cult

It seems from your post that you've already used sharp bicubic -> (0,0.75). The blurriness you get is possibly due to cpu=6 and temporalsoften(2,3,3) besides h263 quantization, none of which I would prefer to use for an encode more than 1CD whereas you go for 3CDs if I'm not wrong! However, I don't know anything about the compressibility of that movie, but personally I've never aimed for more than 2CDs so far.

regards,
iago

[cult]

yes you are right iago.I was going to use soft but then I changed my mind.I watched the vobs and they are almost identical.There is a slight bluring too.Now,about the bframes.I encoded about 5% of the same movie and watched the result.I have a strange problem.In vd,when I jumb to a specific time in the movie,the bframes version shows another frame than the original,the qpel version shows the right.Can someone explain that?
Is it safe to demux qpel with nandub?(yes I keep the ac3).
In case the bframes work with which prog can I mux the ac3?

[MaTTeR]

Originally posted by cult
In vd,when I jumb to a specific time in the movie,the bframes version shows another frame than the original,the qpel version shows the right.Can someone explain that?

I recall several threads in the DivX5 forum months ago about this very issue. If memory serves you should be able to find a good explination in that forum about it.

Muxing/demuxing AC3 with a B-Frame encode seems to work fine on several clips I used yesterday. NanDub and Vdub both coped without issue so I can't think of any reason why not use the same tools your use to.

[Acaila]

I recall several threads in the DivX5 forum months ago about this very issue. If memory serves you should be able to find a good explination in that forum about it.
Posts from months ago are no longer searchable I believe. Not sure.

The cause for the wrong frame number on B-frame encodes is because B-frames require both the preceding and following reference frame be decoded before they themselves can be decoded. In the event of 8 B-frames in a row this means you can get quite a mess in VDub because B-frames can't be referenced by B-frames, which in turn means you need to decode the 9 frames following the first B-frame to decode it :).

Apart from the viewing order in VDub/NanDub everything should still work ok.

[wing1]

@gazza

sorry for the late reply. Just got back on line :D

Most of my encoding methods are quite unorthodox from the rest; Hence, What I used may not be usable by most. But since you asked, here is my typical setup.

Capture setup:
xvid (koepi 9-4-2002)
704x240 (704x480 vertical reduction x 2)
CBR-1pass @ 1600
CBR setting 80/800/2000
Motion Search -> 6

Avisynth 2.06
LoadPlugIn("c:\avisynth2\others\warpsharp.dll")
SetMemoryMax(256)
avifileSource("d:\capture000.avi",false)
convertfps(23.976*3)
selectevery(3,1)
simpleresize(512,200)
dnr2(3,1,1)
tweak(bright=10,cont=0.92,hue=2,sat=1.5)
UnsharpMask(strength=32,radius=3,threshold=5)
unfilter(0,58)
temporalsmoother(5,1)
_2dcleanyuy2(0,5,1,1,0,5,5)
lanczosResize(528,200)
tomsmocomp(1,-1,1)

encoding system is AMDXP 1900+ with 1Gb of SDRAM running on win2K...

[Gazza]

Thanks wing1,

Hum, I can't say that I use the same as yourself but you have certainly given me a few things to look at and consider...

Not only have we recently got new features in xvid to play with but there seems to a whole load of other new things (avisynth filters, alternate versions of mpeg2dec.dll, etc) to look at also. The range of things to twiddle with in the last few days is considerable.

Ta

Gazza

[Nic]

My new build is up:
http://nic.dnsalias.com

This one does have _working_ support for B-Frame decoding. Sorry about the mistake last time.

Cheers,
-Nic

ps
@Koepi:
sending the .ax now ;)

[Lefungus]

Hmmm, Q-pel and Bframes seems to work together with this build. They're still minor glitches in some parts of my clip test but it looks promising.

Ah yes, bframe decoding works for me now with your new decoder nic !

Edited- Is Qpel still disabled when you use Bframes ? Koepi says so in another thread.

[wing1]

@nic

Oh yeah :D Simply awesome stuff.

[Shayne]

Must be getting cooler across the pond also Nic your hoppen again

Thanks for the new builds and i also would like to know if Qpel is still disabled when you use Bframes

[Nic]

@Shayne & lefungus:
Thats something thats been interesting me & ive been meaning to test. I dont know actually why using BFrames would turn off the QPel code. But it may well do, so ill go now & have a look :)

(cooler across the pond? Its bloomin' freezing :D )

Cheers,
-Nic

[gldblade]

I dont know actually why using BFrames would turn off the QPel code
Supposedly XviD is buggy when both are activated.

[wing1]

Has anyone noticed the seek time is getting slower when playing back b-frame encoded xvid? It seems like the keyframe is being stretched out 2x when B-frame is activated.

2 Max B-frame + DX50 B-vop enabled + max I-frame interval 300

edit:
adjusting max I-frame interval by x/2 seems to bring back the seek time to normal.

[Aktan]

Nic, is your build using EPZS^2 motion estimation? Also what do u mean by only /O3 was used?

[Didée]

@ wing1

I figured the same by analyzing dbgview logs.
At first, I thought that with Bframes enabled, the codec gives a da*n about my specified Iframe interval.
Looking a little closer, it seems that Iframes are placed as usual, but the Bframes simply "don't get counted" for the interval length.

Actually, 2-pass is not yet adapted to respect the characteristics of Bframes, not even their bare presence ...

Regarding this, as well as the fact that overflow treatment is runnig crazy throughout the whole second pass, one must admit that the result is INCREDIBLE.
Once Bframes, Qpel and 2-pass-mode will be tearing together on the *same* end of the rope, doom9 may start another codec comparison ;)

[Nic]

(All dev3 api builds now using Syskin's new Motion code, (that kinda based on PMVFast/EPZS....). /O3 is a setting for the Intel Compiler that just tries to do its best with optimisation, but should allow most CPU's to still use the binary)

Cheers,
-Nic

[Bulletproof]

Hey Nic, I don't know if these bugs have been already reported since I don't have time right now to go through this thread (it's 5:30am).

I recently downloaded your latest beta today and tried Motion precision 6 and B frames set to 1, ratio to 200. Custom quantizer matrix. 1 pass quant to 2. Set to decode with Xvid decoder.

The result during playback came out to be choppy (like its dropping frames) and even the picture breaking up with lots of blocks everywhere.

So I tried changing the motion precision to 5. No difference still.

Then I changed the decoder to use DivX 5.0 and everything seemed to playback well. However, why would the XviD decoder give me problems, could it be because I used a custom quantizer? I understand this is a work in progress right now, this is not a rant of any sort and I'm curious to know if its an error on my part.

EDIT: I also had luma masking on, but not sure if this caused any effects?

[Nic]

Thanks for the bug report :)
When you get chance (& perhaps some sleep :) ) Could you try doing a bit without lumimasking & then without the custom matrix & see if it still occurs? (I do it myself, but im at work :( )

Anybody else having similar difficulties?

Cheers,
-Nic

[Gaia]

No playback problems just endcoded full movie lumimasking off but with custom matrix. Your decoder works great!

[Bulletproof]

Ok, I did another test. It seems either DX50 compatible B-frames or Bitstream packing caused the "choppyness" to the video, disabling that makes the xvid decoder play it back smoothly, but this did not stop frame breakups.

It seems to be related to something syskin said I think, he said currently scene changes are not getting their I-frames properly right now, and I get corrupted frames right when scene changes happen.

[Bulletproof]

Ok, another test.

Packed Bitstream is causing the choppy frames for me, it's description says its supposed to prevent delay of decoding for some frames, but its doing the opposite for me.

DX50 compatible B-frames enabled this time, and used H263 quantizer. This time the video decoded without any problems.

[ookzDVD]

@Nic,

It's my first time using B-frame from XviD,
2 Max B-frame with 200% and using MPEG-custom Reference-Divx's Good matrix, no lumi masking, 2-pass with Ext. Koepi's linear scaling,
all are working well and the result with your latest DS filter is
nice.

PS. If you don't mind, would you provide the XviD decoder DS filter only installer which support the latest B-frame ? :)

Thank you.

[Nic]

@ook:
Im glad its working :) I think now I know the filter is pretty stable I may as well make a filter only install...

Cheers,
-Nic

[Koepi]

Nic's latest standalone decoder is up on my site, sent it out to Nic, too :)

Enjoy,

regards,
Koepi

[iago]

That's great! Thanks man! ;)

iago

[Nic]

Cheers Koepi, I went to build it..then realised I didnt have the latest filter on this computer (didn't have to download from my own site).

So, if people wanted one more feature added to my DShow filter what would it be? Contrast? (I think ill add one more thing & just call it finished...(but obviously ill recompile it as the core gets updated))

Take Care,
-Nic

[Koepi]

@Nic,

well, contrast is fine. What about hue and saturation? So we have a full flexed DSF - I never touched those sliders but somehow I feel they have to be there ;)

Cheers,
Koepi

[HarryM]

B-frames + Nic's newest DS decoder works only with

packed bitstream = OFF
DivX5 compatibility = ON(!) (ffdshow works with OFF too. Why Nic's DS don't? Video is crappy fom time to time.)

I test B-frames + 2-pass AltCC. Good result. It works too.

Good work, Nic. Thanks.

For max B-frames>3 I recommended compensate a/v delay too. For PAL and e.g. max.b-frames=3: +120 miliseconds.

Any experiences with a/v sync and b-frames?

[Shayne]

Nic question for you

I have used your oct 13 build 3 times and twice everything came out great the 3rd i have the following problem:

Movie length 1:53:34

script
SetMemoryMax(100)
#
# PLUGINS
LoadPlugin("D:\Video\Avisynthv\Filters\mpeg2dec.dll")
LoadPlugin("D:\Video\Avisynthv\Filters\Decomb.dll")
#
mpeg2source("E:\Work\Dont.d2v")
#
#
Telecide()
Decimate(cycle=5)
#
# CROPPING
crop(64,57,592,363)
#
# RESIZING
LanczosResize(512,256)

Xvid config

search = 6
quant = h2.63
bframes= 2
all else default

requested vid size 628000
final vid size 555000

My question is why the final vid size would be so far off target from that requested.

The first 2 were correct and the only thing i can think of was the resize was set to 640x not 512 as here?

[TheUnforgiven]

. I dont know actually why using BFrames would turn off the QPel code. But it may well do
@Nic
maybe i can confirm that,
using ffdshow enable OSD frametype
without using b-frames frame type can be P QPEL but no QPEL when using b-frames

[MaTTeR]

Nic,

The only thing I could think of that most people might like to see in the DSF would be the "Add Noise" option similar to ffdshow or uhm maybe DivX5:) Just a thought.

[Acaila]

@Shayne:

Sounds like saturation to me. Increase the resultion to get a bigger (and more detailed) movie.

B-Frames (and QPel as well that I have seen) increase compressibility by a lot. This means your movie will reach maximum quality at a much lower filesize. Once its maximum quality the codec can't make a bigger file.

[Nic]

I can only think that Acaila is right, & remember that B-Frames are experimental...so strange things can happen :)

@HarryM:
I knew Id forgotton something to put in that sticky. Yes Bitstream Packing should be off & DX50 Compatibility ON.

Cheers,
-Nic

[iago]

Originally posted by MaTTeR
Nic,

The only thing I could think of that most people might like to see in the DSF would be the "Add Noise" option similar to ffdshow or uhm maybe DivX5:) Just a thought. I totally agree! ;)
That would be great. And even (I'm repeating this everywhere when I find the opportunity :D) such an "add noise" option that it would/could add more noise to dark areas, or at least add noise to dark parts not less than light areas, just like the "mplayer noise" option in ffdshow! :) Just another thought.

iago

[Pasqui]

@HarryM
I did an encode of Starship Troopers using latest Koepi's build and B-Frame:
packed bitstream = OFF
DivX5 compatibility = ON
max b-frame = 6
linear curve

This encode is by far the best I've done so far for this movie. B frames are just so impressive !!!
I also get an A/V synch issue (even with ogm), which is quite understandable as multiplexing tools aren't designed for b frames. I'll check this evening wht is the delay

Pasqui.

[ChOcO-Bn]

Encoding anime with B-frame still works very fine ^^ good for me :))))
packed bitstream = OFF
DivX5 compatibility = ON
max b-frame = 4
200%
altcc high 500/100

++

[Acaila]

@Nic:

As is the case with DivX5, both B-frames and QPel decoding take up a lot of cpu cycles. Enable either one in your encode and you need a 1GHz+ machine to play it back smoothly, enable both and you're looking at 1.2GHz+. Most people don't like to use DivX5's decoder because of this, some people can't even.

Now that these features are also being implemented with XviD I expect the same thing to happen here. I for one like XviD's (your :)) decoder and see no need (yet) to switch to ffsdhow.

Do you think it's possible to someday decode videos with these features enabled in XviD much faster than DivX5 does? I know the decoder is already very much optimized, but with the few QPel tests I've done cpu load does increase quite a lot. Not to mention if I enable B-frames as well.
I've got a piece of video lying around here that even -I- couldn't play smoothly if I didn't have dual processors ... and that's with only with QPel enabled.

Or am I addressing this to the wrong person and is all that part of XviD's decoding and not your filter?

[rui]

Well, everybody loves b-frames :)

But i don't :D

That is, i love Qpel more. The encodes i have made with it and without b-frames (since enabling b-frames un-enables(?) qpel, correct?) are more sharper than with b-frames.

Hope you wonderfull people can make a build with b-frames and qpel at the same time. :)

[MaTTeR]

I'm with you on that rui. Most people might not notice or care about the difference that B-Frames adds. Guess I'm just a Qpel sort of guy also:D

[Nic]

@Acaila:
It is far more to do with XviD Decoding than my filter. However, the XviD decoding I believe will use a lot less process than the DivX filter, but a problem may occur due to incompatibility issues. But im pretty sure eventually XviD & DivX will be 99.9% MPEG-4 compatible one day (but I bet you XviD alot before DivX ;) ).

-Nic

[Shayne]

@Acaila

So i guess you are saying gknot compressablity check and setting really does not come into play here?

Are people having problems with divx5 because i think that is what it was written for and at the 512 rez i am at .2 ratio.

Edit: sorry guys went over to the dark side and read Acaila sticky on file size............. it explained very clearly there. Need to vist this forum with all the xvid jumps.

[Bulletproof]

Originally posted by iago
I totally agree! ;)
That would be great. And even (I'm repeating this everywhere when I find the opportunity :D) such an "add noise" option that it would/could add more noise to dark areas, or at least add noise to dark parts not less than light areas, just like the "mplayer noise" option in ffdshow! :) Just another thought.

iago

If I change my desktop color depth to 16-bit I get noise during playback and it really does help, it even stops color bleeding. But noise is noise ;)

[Emp3r0r]

Would it be possible to have some sort of post processing (maybe it should be pre-processing) that blurs the very dark (possibly blocky) areas? I think this or maybe the noise thing mentioned above would be value added to the decoder.

[rui]

I don't know if this already has been reported, but i can't use the HME option anymore (wanted to test it). Using Nic's latest build with all defaults (no b-frames) except:

MPEG
6 in motion search precision,
high% and low% in internal curve comp at 0
500 delay

Vdub crashes just at the start of the second pass. Could be the Qpel?
I will try at 5 motion search, since Nic' build says it's enabled at 6.

EDIT: No, it crashes at 5 too. So, or Qpel is enabled at 5 too, or this as nothing to do with Qpel.

[-h]

Yeah hints with QPel is sick from all accounts, I've been meaning to look at it but things keep jumping up.

It could be something to do with sysKin's 2nd pass hint refinement trying to refine a QPel position incorrectly, I'm not sure yet. Perhaps the hints should always be stored with half-pel (or even full-pel?) precision.

-h

[MoonWalker]

Hi,

Just did a encode of the lobby scene of The Matrix, with Quantizer Mode @ 2 and Quality @ 90, Motion 5 and B-Frames 2 with packed checked and debug..All the clip ended like this..I used Nic's 13-10-02 XviD..Just thought it whould be right to report it..

MoonWalker

[Emp3r0r]

try without packed bitstream and enable divx5 bvop compatibility

[Nic]

New build up:
http://nic.dnsalias.com

changes:
"minor updates - mostly speed but also b-frame's quality"
"some qpel bugfixes, fixed MV hints (but works only without qpel)"

Cheers,
-Nic

[serbersan]

Nic, with your lastest build I noticed a little problem that I haven't noticed with 13/10 build.

Using constant quantizer 2 (with 3 ant 4 too) with b-frames in static backgrounds there are a little displacements of the static objects by moments.

I try to explain better.... a bed well a little portion of it in one moment has a little movement and inmediately it returns to the original position. This occurs in all part of the frame with an static background, I haven't noticed it in faces or other moving objects.

If you or other want images I could post them.

Maybe this post could help if this is an error not noticed yet by your or if it isn't an error....

Thanks, Sergio.

[serbersan]

Sorry, one more thing.



I have started the first pass and after 33 secs in second try 32 and 33 in the third try, I 've obtained a virtualdub crash.

Used bframes with a max 5 and 3. level 6 mpeg in the post before I used the same settings.

With the 13/10 I haven't found this problem.

Only want to report those 2 bugs for if anyone haven't reported yet.

Thanks again, Sergio

[Koepi]

Did you use lumi masking or MV hints?

Please post your settings when reporting bugs :)

Regards
Koepi

[HarryM]

Originally posted by serbersan
Nic, with your lastest build I noticed a little problem that I haven't noticed with 13/10 build.

Using constant quantizer 2 (with 3 ant 4 too) with b-frames in static backgrounds there are a little displacements of the static objects by moments.

I try to explain better.... a bed well a little portion of it in one moment has a little movement and inmediately it returns to the original position. This occurs in all part of the frame with an static background, I haven't noticed it in faces or other moving objects.

If you or other want images I could post them.

Maybe this post could help if this is an error not noticed yet by your or if it isn't an error....

Thanks, Sergio.


@Nic:

I have problems too. Maybe identical.

When I using your newest build 21-10-2002, I see from time to time any foggy-trails(?) (my visual simile- something such as using of 'modulated quant'-videos with DivX5 DS decoder).
Videos encoded with this build are overall nausea (low quality, why?). Build 13-10-2002 is much, much better...

All are O.K.? Is qpel corectly activated?


Thanks for your work. I'm not critic, only alpha tester :)

[Nic]

No, its good you point these things out. :)

I released the build as I thought changes might occur. the build settings were exactly the same (as long as I didn't forget anything stupid).

So it must be the new changes. If you could supply as many details as possible (like did you use QPel/BFrames etc etc), ill make sure isibaar & sysKin who made the changes get the needed info.

But ill look into it more tomorrow & get back ot you :)

Cheers,
-Nic

[serbersan]

Well exactly my settings are:

In the encode where I've seen the little displacements:

1 pass constant quantizer proved with: quantizers 2,3 and 4.
Motion Search precision: 6
MPEG
No lumimasking
The rest by defaults
In b-frames:
--Maximum: proved with 2,3 and 5
--B-frame Quantizer Ratio: 200%
--The rest options are unchecked

Well the second encode (the one that crashed virtualdub):
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

The crash is after aprox. 30 sec.

Do you want that I post the debug info of virtualdub or/and the images with the problems I talked above??

[serbersan]

Originally posted by HarryM

For max B-frames>3 I recommended compensate a/v delay too. For PAL and e.g. max.b-frames=3: +120 miliseconds.

Any experiences with a/v sync and b-frames?


HarryM I've encoded blade2 with max b-frames=2 and the sound is perfect, have you noticed this problem only with max b-frames >= 3???

I've used ogm as container and an ogg track.

Sergio.

[AndyP]

@Nic:

I have problems too. Maybe identical.

When I using your newest build 21-10-2002, I see from time to time any foggy-trails(?) (my visual simile- something such as using of 'modulated quant'-videos with DivX5 DS decoder).
Videos encoded with this build are overall nausea (low quality, why?). Build 13-10-2002 is much, much better...

All are O.K.? Is qpel corectly activated?

I think I have noticed this as well. Encoded 300 frames of the Matrix using following avs with Koepi's 04/10 build and your latest dev build.

Settings the same for all:
Default apart from:
Motion search 6 (therefore qpel with Nic's)
No bframes
MPEG quant
No lumi
1 Pass Quant 3 fixed

As a character moves accross the picture with the dev build he leaves a 'trail' of noise behind him. This is seen in vdub although not v. noticable when watching using xvid ds filter. However, when using ffdshow there is colour distortion in the distribution of the 'trail' seen in vdub. Almost certain it is due to qpel as if I compare dev build output +/- bframes then the with bframes does not have the 'trails' on motion search 6, which is in keeping with qpel not functioning with bframes.

I notice that the qpel picture seems much more 'noisy' overall when compared with the original avs in vdub.

I can post pics or avi clips if needed.

Kind Regards,
Andy

avs
---
LoadPlugin("mpeg2dec.dll")
LoadPlugin("convolution3d.dll")
mpeg2source("E:\DVD\THE_MATRIX\The Matrix.d2v")
trim(142800,143100)
crop(4,80,712,416)
BicubicResize(640,256,0,0.5)
Convolution3D(0,4,4,4,4,2.8,0)

Updated x 2

[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.

[HarryM]

I don't help for me... :(
Nic's build 13/10/2002 is the best (max visual quality) of latest compilations.
I tested 21/10 and 23/10 too, but quality isn't good. Smearing, little blurring, sharpless...

Why?

I use-

motion search = 6 (qpel=ON?)
I frame-interval = 500
h263 quant
b-frames = -1 (without b-frames, only I, P frames)
AltCC = default
next relevant settings = default


Do I make any errors or what???

[Gaia]

Just encoded full movie with latest Nic build(B-Frames enabled 2 and 200%) with VDub. No crashes, works fine! No decoding problems either. Yes it was 2-pass encode like always, no QPel, No MV hints.

[HarryM]

Originally posted by Gaia
Just encoded full movie with latest Nic build(B-Frames enabled 2 and 200%) with VDub. No crashes, works fine! No decoding problems either. Yes it was 2-pass encode like always, no QPel, No MV hints.

???

Do you use motion search =5 or =6?
I think, that you use =6, you use automatically b-frames + qpel in one, not only b-frames.

[unplugged]

Originally posted by HarryM
I don't help for me... :(
Nic's build 13/10/2002 is the best (max visual quality) of latest compilations.
I tested 21/10 and 23/10 too, but quality isn't good. Smearing, little blurring, sharpless...

Why?
Have you red my post?

I cannot advise to use Qpel at all, if you are satisfied by CVS 13/10 (I m satisfied too by all recent 13-23/10) then try to decode 13/10 encodings with latest decoders (21-22-23/10) and you will see too much smearing even with 13/10 encodings (!)

In fact these compiles are very good when used with same CVS date decoder, they appears good... but they all are out of standard

I don't use Qpel anymore nor B-frames for serious work ATM. ;) (stick to 04/10/2002 stable compile, it's quite excellent for me ;) )

[HarryM]

Originally posted by unplugged

Have you red my post?

I cannot advise to use Qpel at all, if you are satisfied by CVS 13/10 (I m satisfied too by all recent 13-23/10) then try to decode 13/10 encodings with latest decoders (21-22-23/10) and you will see too much smearing even with 13/10 encodings (!)

In fact these compiles are very good when used with same CVS date decoder, they appears good... but they all are out of standard

I don't use Qpel anymore nor B-frames for serious work ATM. ;) (stick to 04/10/2002 stable compile, it's quite excellent for me ;) )

But I completely use only one build for encoding and decoding!

I encode movie with 13/10/2002 (two passes) and watching with 13/10/2002 decoder.
I encode identical movie with 23/10/2002 (new two passes) and watching with 23/10/2002 decoder.

Sure. When I use identical encoder and decoder, result is relatively O.K., no big smearing, etc.

But...
13/10/2002 have still much better visual quality than 23/10/2002 (only for me?).

[Gaia]

I use motion search 5. QPel is useless for me. Never liked it in Divx5 either.

[Didée]

@ InfoCynic, OffTopic

use this shortcut:
"RUNDLL32.EXE xvid.dll,Configure"

this was pointed out by -h some time ago.

-----------------------------------------

More OnTopic

Somehow, for me too Nic's 13-10 build seems to produce the best visual quality. I use B-frames a lot, qpel not at all.
But my decoding is always done by ffdshow (need it often for some unique reasons), so my impression is to be taken with care, since the discussion is mainly about nic's filter.

But I'm really amazed how things are evolving!

[Smiff]

Nic
someone mentioned this before and i thought "he's going mad" but now i also have to keep re-applying the settings in your DSF - they keep resetting to defaults (no PP, brightness in centre).

[Nic]

Ill check it out...are you just using media player?
(the settings are just held in the registry so I dont know why theyd reset)

Cheers,
-Nic

[DBaT]

-edit- One more important lesson learned, check always the original DVD when nothing else helps lol. Just got to used to dvds with good quality.
----------------
I have for some time made 2-pass test encodes with b-frames enabled to see how they turn out and I haven't run into any special problems.
However now I got one encode with frames that aren't quite right and I haven't seen anything like this before so I'm not quite sure whats causing it. I browsed trough the forum but couldn't find any attachments with similiar problems so I don't know if anyone else has run to the same problem as I'm not sure what to call these bad frames.

I tried to narrow down and find whats casusing the problem by running
over a dozen of fixed pass1 quant2 encodes with trim to find if it was my avisynth script or some combination of settings causing this.

Xvid settings / latest build by Nic

MPEG quant / H263 (both tried)
Motion Search 5
B-frames 2 / 200%
Comp 50 ON
No lumimasking
No hinted ME
Int AltCC 00

In my avs I tried with different settings like, minimal settings,no croping, no IVTC, old mpeg2dec, different rezise .dll and different sizes etc. I though first that I might done bad IVTC but I could find the same effect on frames even when I left it to 29.95 fps.

In my avs I tried turning on/off with following

MPEG2Dec3
basic mpeg2dec
IVTC2.2
Decomb 4, latest
SimpleResize
BicubicResize
lanczos3
Convultion3D

Attached a frame from my first 2-pass encode .jpg

[Smiff]

Originally posted by Nic
Ill check it out...are you just using media player?
(the settings are just held in the registry so I dont know why theyd reset)

Cheers,
-Nic


zoomplayer. and i haven't rebooted the PC for a while so i'm not sure when it's happenning... actually this is in a way good cos i watching my Xvid encode without PP thinking "hmm this ain't too bad" ;) ;)

[InfoCynic]

Originally posted by Didée
@ InfoCynic, OffTopic

use this shortcut:
"RUNDLL32.EXE xvid.dll,Configure"

this was pointed out by -h some time ago.

Hey, the topic is "An XviD bug, a newer DShow filter, and my new site." :)

Yep, and I believe I even mentioned that in my post. Nifty little shortcut but that doesn't access the DSF (=Direct Show Filter), it accesses the codec configuration dialog.

[Nic]

Ill try & come up with something to bring the dialog settings box up....

-Nic

[Didée]

Sorry, my fault. I was reading & posting in a great hurry...

[unplugged]

Originally posted by HarryM
But I completely use only one build for encoding and decoding!

I encode movie with 13/10/2002 (two passes) and watching with 13/10/2002 decoder.
I encode identical movie with 23/10/2002 (new two passes) and watching with 23/10/2002 decoder.

Sure. When I use identical encoder and decoder, result is relatively O.K., no big smearing, etc.

But...
13/10/2002 have still much better visual quality than 23/10/2002 (only for me?).
Hope only for testing...

What I mean is that QPel is probably buggy in all builds anyway (yet), so what kind of "standard" MPEGs are you going to make?

You feel to bundle every movie.ogm with the right XviD build version every time for each video you encode... ? :rolleyes:

[Rrrough]

I guess everyone in here is aware of the unstable status of these releases, at least should be because everyone offering binaries indicates it (ok, maybe a greater bold red flashing font could help).
I for one know that if I want to keep movies I encode 'em with stable builds, while the unstable builds are surely meant for merely testing and impressing chicks with. I am really thankful, that I have the chance to test what's going on on the bleeding edge, although my results can be completely useless - so what ?

[Boardlord]

Hi Nic!
I am, like everyone, grateful for all your hard work. I only use your XviD decoder, and I have a little problem with your newest(10/23) one. If I install it, in Zoom Player I can't access its properties page. If I reinstall the older(10/13) one I can access its properties again. Is it a bug, or I did something wrong?

[iago]

-> I guess everyone in here is aware of the unstable status of these releases, at least should be because everyone offering binaries indicates it (ok, maybe a greater bold red flashing font could help).
I for one know that if I want to keep movies I encode 'em with stable builds, while the unstable builds are surely meant for merely testing and impressing chicks with. I am really thankful, that I have the chance to test what's going on on the bleeding edge, although my results can be completely useless - so what ? (Rrrough)

So what?! Shouldn't users/testers report what they observe when they use the dev. builds and the options provided with them such as QPel and B-frames? I guess most people already know the unstable status of these binaries. Imho, only by testing and reporting the possible bugs and problems can we achieve more "stable" binaries, including these new features as well.

regards,
iago

[Rrrough]

So what?! Shouldn't users/testers report what they observe when they use the dev. builds and the options provided with them such as QPel and B-frames? I guess most people already know the unstable status of these binaries. Imho, only by testing and reporting the possible bugs and problems can we achieve more "stable" binaries, including these new features as well.

of course users/testers should REPORT, that's how development will move on, but not COMPLAIN that there's something ugly or whatever and thus are forced to use a stable build. It was just a friendly reminder of the unstable status, as I felt that there were some complaints in here. and I guess that's the least the devels would need.

cheers

[iago]

@Rrrough

OK man, I see your point! As a result: No whining but keep on reporting! ;)

regards,
iago

[Rrrough]

No whining but keep on reporting!

:) Yeah man !

btw, I also wanted to report that Nic's 21/10 build was always crashing on first pass at the same positiion (~40000 frames), whenever I enabled b-frames (3/150). I wasn't sure if it was the build though, but with installing the 23/10 build - voilà, the result is just beautiful. I always get the "macroblock error" before keyframes when not using "DivX5 compatibility" with both ffdshow and Nic's filter, but that's pretty logical, as there is no decoding of B's before I's as of yet, or am I wrong here ?

cheers

[Gaia]

All these dev-builds by Nic and Koepi have worked fine in my tests. I had one very strange problem but i solved it myself...

I can't undestand these reports about crashes, i have always done 2-pass encodes(i know it is not recomended but it works for me) and never have experienced any crashes during encoding. One solution might be that you are using interlacing filters it crashes in my tests too if i try to use them but i figured out that long time ago.

Also a lot of you don't say what settings you used and what kind of Avisynth scripts.

[Rrrough]

I was using a plain PAL progressive movie - no need for deinterlacing here. As for avisynth, I used Marcs MPEG2DEC/no PP, did only crop, lanczos resize with and without convolution3D(0,2,2,4,4,2.8) before it. nothing special here. XVID settings:
Search precision 6
Quant. type MPEG
No lumi-masking
B-Frames 3 - 150
anything else - XVID default
crash occured during 1st pass. (~40,000 frames)
I didn't change anything else but the build. And I can reproduce the error by reinstalling 21/10 build. Anyway, it's no big prob anymore, as the 23/10 build solved it.

[ookzDVD]

@Nic,

Latest Nic's 23/10
Ooops, my virtualdub just crashed last night,
I tried to encode the "Murder by Numbers" trailer,
with B-frame max = 2, but after 60% the virtualdub was crashed. :(

Thank you.

[Gaia]

Originally posted by ookzDVD
@Nic,

Latest Nic's 23/10
Ooops, my virtualdub just crashed last night,
I tried to encode the "Murder by Numbers" trailer,
with B-frame max = 2, but after 60% the virtualdub was crashed. :(

Thank you.

Again another stupid bug report. You didn't say what settings you used, no avisynth script. Just finished my 5th test full movie encode with latest Nic build and still no crashes. I can't understand how you guys manage to do it?

@Rrrough who said QPel(motion search 6) is working with B-frames?
I haven't tried it myself since very first dev-builds but in my tests it crashed then! Does QPel work now with B-Frames? Anyone?

[ookzDVD]

@Gaia,

Ooops, sorry, it was my mistake,
I just forget to disable the Qpel,
change the motion search from 6 to 5. :)

The AVS Script is OK.

[Rrrough]

who said QPel(motion search 6) is working with B-frames?
no one ! it's been discussed that QPEL is automatically disabled when using bframes.
I tested other dev builds with the same settings (search precision 6 PLUS bframes) before and never had a crash. and with the current 23/10 build - still no crash.

You didn't say what settings you used, no avisynth script. I haven't tried it myself since very first dev-builds but in my tests it crashed then!using interlacing filters it crashes in my tests too if i try to use them

[ookzDVD]

@Rrrough,


no one ! it's been discussed that QPEL is automatically disabled when using bframes.


hmmm, I think we have the same prob, 1-st pass crached with 23/10 ;(

[Manao]

I've also to report crash with the Nic's 23/10 build. I was unable to begin the first pass of an encoding which works fine with Koepi's 22/10 build. I tried 3 or 4 times, it crashed everytime, so I switched back to the Koepi's build. The error I got was something like 'memory cannot be read'

The settings are the default except :

BFrame 2, 200 %, DX-50 B-VOP compatibility
I NOT discard the first pass, no MV, no credits

The avs was :

avisource("foo-vfapi.avi")
converttoyuy2()
convolution3d(0,4,4,4,4,2.6,0)
bilinearresize(320,240)

I had to use a vfapi file since the source was MPEG-1 ( I used TMPG -> tpr file, then vfapi, because I really wanted to use convolution3d, but perhaps was there a nicer way ? )

My system now :

Athlon XP 2000+
512 MO RAM
Win 2K SP3

To be precise, when switching to the Nic's build, I didn't change the settings ( since they 'stay' from build to build ), so perhaps the install changed the settings without I seeing it.

I will try again this build when I have time. Should I use DebugView to get some more precise data ?

Edit :

I forgot, I also got a crash with Koepi's build, on another movie, only once, I wasn't able to reproduce the phenomenon. It might have been to much applications opened in the same time, and the use of the hack for improving memory management posted by Koepi on the General Forum.

[Gaia]

Still never have had crashes like you keep reporting. I don't believe it's a bug. Just somenthing else. Stupid settings, your system or whatever. Maybe time to format and reinstall Windows? I have so far encoded 5 full movies with latest Nic build and about 15 short clips without any crashes!

[ookzDVD]

@Gaia,

Ok, thank you,
I will try to use the motion search = 5 (disable the QPel),
I hope it will work, I'll report the result.

Thank you.

[Nic]

Ill try making up a new build. I think I may have tried something to optimise it (which I thought I'd turned off). Hopefully this will help.

-Nic

[Rrrough]

@Nic
thanks for your effort. hope that will help. (well, 23/10 is definetly fine with me, finished another full 2-pass this morning)

@serial-tester (aka iago :) )

did you do full 2-pass tests with Nic's 21/10 and 23/10 builds ? any problems there ?

@all

I'm using a PIII-650, 128 MB RAM, WinXP-SP1 (don't laugh)

Virtual dub was silently crashing on me (no error message), I had debug view running, but it was just stopping reporting.

@gaia

As you proved to be so experienced you surely want to prevent everyone with this prob from reformatting the windows partition and share your magic non-stoopid settings!

[MaTTeR]

Originally posted by Rrrough
Virtual dub was silently crashing on me (no error message), I had debug view running, but it was just stopping reporting.

Same happened here at least 5 times during first pass. I went back to the 10-13 build and don't have the problem now.

[HarryM]

Originally posted by MaTTeR


Same happened here at least 5 times during first pass. I went back to the 10-13 build and don't have the problem now.


10-13?

But you have problems with compatibility at newer/bugfree versions now. 10-13 use another/bugged ME compare to 10-21 and 10-23.

[Nic]

Well I rebuilt the source, no new news item until I know it works. but try downloading the new build I guess & see if it helps? If not then theres a bug in the new dev CVS code.....

-Nic

[majerle]

Ehmm, I am using your XviD_Install_231002.exe and i encoded several movies (harry potter 1, panic room ...) and i NEVER had problems at all.
1' pass
Settings for XviD (23/10/2002 14.06.03) Mode: 2 Pass - 1st pass, Discard 1st Pass: ON, Motion Search Precision: 6 - Ultra, Quantization Type: H.263, FourCC Used: XVID, Max I-frame Interval: 300, Min I-frame Interval: 1, Lumimasking: OFF, Interlacing: OFF, Greyscale: OFF, Max B-frames: 1, B-frames Quantizer Ratio: 200%, Packed Bitstream: OFF, DX50 B-VOP Compatibility: OFF, Print debug info on each frame: OFF, Min I-frame Quantizer: 2, Max I-frame Quantizer: 31, Min P-frame Quantizer: 2, Max P-frame Quantizer: 31, Max Bitrate: 10000kbps, Max Overflow Improvement: 60%, Max Overflow Degradation: 60%, Start Credits: OFF, End Credits: OFF,

2' pass

Settings for XviD (23/10/2002 14.06.03) Mode: 2 Pass - 2nd pass Int., Dummy 2nd Pass: OFF, Desired Size: 570000KB, I-frame Boost: 0%, Below I-frame Distance: 10%, I-frame Bitrate Reduction: 30%, Curve Compression: Payback with Bias, Bitrate Payback Delay: 250frames, High Bitrate Scenes: 25%, Low Bitrate Scenes: 10%, Hinted Motion Estimation: OFF, Alternative Curve System: OFF, Motion Search Precision: 6 - Ultra, Quantization Type: H.263, FourCC Used: XVID, Max I-frame Interval: 300, Min I-frame Interval: 1, Lumimasking: OFF, Interlacing: OFF, Greyscale: OFF, Max B-frames: 1, B-frames Quantizer Ratio: 200%, Packed Bitstream: OFF, DX50 B-VOP Compatibility: OFF, Print debug info on each frame: OFF, Min I-frame Quantizer: 2, Max I-frame Quantizer: 31, Min P-frame Quantizer: 2, Max P-frame Quantizer: 31, Max Bitrate: 10000kbps, Max Overflow Improvement: 60%, Max Overflow Degradation: 60%, Start Credits: OFF, End Credits: OFF,

Using dvd2avi_nic ... :p

Thanks for your work Nic !

Andres

[iago]

@Nic and all,

With my one pass and two pass test encodes using the 23/10/02 build, I haven't got any crashing problems so far. Also, I haven't had any decoding problems with ffdshow latest (20021014-se) either (In the Codecs tab -> only "XVID" checked / "Use XviD" unchecked) when using 6.Ultra High, B-frames 4/200 and "DX50 B-VOP Compatibility".

Many thanks for the good work! ;)

regards,
iago

[Rrrough]

@Nic

thanks for looking into it, will try a full first pass now and report back tomorrow (...slow machine... my coffee machine is way faster...)
thanks again !

cheers

[Manao]

Well, I gave a try to new Nic's build (29/10), same settings, same type of conversion ( mpeg-1 -> tmpeg -> vfapi -> avs -> vdub ), and alas same results :(. While encoding the first pass, a random crash occurs, which ends Vdub. In the same time, I was watching a movie ( bsplayer + ffdshow + div3 ), and only OE and opera were running in the background.

It seems that the same problems occur with Koepi's build, since I also got another crash with this one( a reboot this time ), but it happens less systematically, and even seldom.

Tomorrow, I will make some tries with and without bframe, and different sources, with Nic's build, to see if it helps. I will also make a little test with my RAM, since I bought 256 Mo recently and check if my system isn't totally messed up.

I hope I will not have to go back to an older build ( even if it means that my system is screwed up ), because I came to really love bframes.

[iago]

@Nic

Thanks for the new 29/10/02 build, with which (unlike the 23/10/02 build) I can finally use your DSF to decode. Great! ;)

iago

[lighty]

It seems that a prob occur when using Credits quantizer.

If I specify that I want to Encode credits at the start of movie (for example 0-1830 frames) and Encode credits at the end of movie (231587-243836) with Quantizer 20--- then it seems that XviD get "stuck" at quantizer 20 for the whole movie so:
1. I get a few hundred Mb undersized movie
2. Quality of video is terrible

The example I used was from Star Wars LD ripp.
It has 243836 frames and I used QPel as well as MPEG quantizer.
This problem occurs regardless of length of movie, AVS script, quantizer, QPel, B-Frames, XviD version (I obviously tried everything).

I specify Start credits frames and End credits frames both in 1st and in 2nd pass but as long as I use Start credits quantizer the whole movie gets screwed. If I use only End credits quantizer function everything is fine...

Any ideas?

[MaTTeR]

Originally posted by HarryM



10-13?

But you have problems with compatibility at newer/bugfree versions now. 10-13 use another/bugged ME compare to 10-21 and 10-23.

Yep, it's odd but Vdub would just disappear without warning. Never seen that happen before. Thx for the new build Nic, I'll try it out later this week when I have some new source to test on;)

[ookzDVD]

@Gaia,

I still got problem even I have change the Motion search to 5,
disable the QPel. Try the latest 29/10 build still got the problem. :(

So.. I think I just un-lucky find the clip which B-frame got problem. :(

PS. Just try with uManiac's 24/10 build, with same clip and same XviD's setting, and the problem is gone ;) _but_ the playback only
working well with the Nic's DSF 29/10.

[Gazza]

I had similar problems with Nic's 23/10 build. First it worked OK once but when redoing the test (using different resolutions, etc) it would not work and repeatedly crashed vdub after about 10 min into the first pass. I also tried single pass, with and without qpel but no good.

Then I installed uManiacs 24/10 build and all problems seem to have gone away....

I am testing uManiacs build at the moment but it hasn't crashed and the second build is nearly done (using qpel plus b-frames (2, 200%), mpeg, everything else default, lanczosresize).

My only grumble with b-frames is the slow speed, I have a P3, 1GHz, 512M system but each pass is ~5fps which is about 50% the speed without b-frames.

Next I want to test Nic's 29/10 build...

[Aktan]

Originally posted by Manao
I had to use a vfapi file since the source was MPEG-1 ( I used TMPG -> tpr file, then vfapi, because I really wanted to use convolution3d, but perhaps was there a nicer way ? )


You could try using DirectShowSource("blah.mpg") which will decode it in YUY2 I think.

[HarryM]

I have question about q-pel for xvid's makers (mainly Isibaar).

Q-pel is designed as additional ME feature alongside normal ME or totally replace normal ME?

When is additional... Can you make separate checkbox for g-pel in xvid settings (like to lumi masking, interlace mode or b/w mode)?

I am disliked from set of q-pel instead ME=6... :(

[Rrrough]

Hi all,

bad news :( , 29/10 build crashed again, again at position ~40,000 (I kept the log file, but it's at home). again, vdub crashed silently, debug-view stopped reporting.
Right now, I'm doing one more first-pass with the same settings along with debug-view to see, if the crash occurs at exactly the same position.

@Nic:

If you want, I can send you the log-file if it's of any value to you.

cheers

[ookzDVD]

@Rrrough,

Try uManiac's 24/10 build, I can solve the crash problem with this build.

[Nic]

Ill let isibaar know about the crashing today...
No need for logfiles as I dont think they'll say much.

@iago:
yup I thought Id better fix that, I also tried to impelment a rundll32, configure for it but didnt have time. Ill do that soon.

@HarryM:
In my builds preset 5 is the same as preset 6 would be (full quality) but without the QPel. It would be easy to add a checkbox to the vfw for QPel. Im sure one of us will get round to it soon.

-Nic

[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;)

[Koepi]

Extra switches are always the biggest problems fopr noobs, they are so n00bish they don't even know what "search" is and at which temperature it has to be served!

;)

But anyways, here we go:

XviD-03112002-1:
- Fresh CVS checkout. GMC decoding support added.
- New mod. HQ quant type reimplemented.
- Added checkboxes for qpel/gmc for better control.

Dunno if those switches work correctly (and I don't know how to verify if the bitstream really contains qpel/gmc) because I switched to yet another avisynth-alpha build with some bugfixes included and maybe caused by that my bitrate distribution looks different...

Anyways, at least we can try ;)

Best regards,
Koepi

[cjv]

@Koepi:

Excellent idea to implement the check boxes..they will make testing so much easier..thank you very very much!!!

I can confirm the qpel check box works...at Motion 6.
I just change the 4CC to DX50 and if the encode looks messed up using the DivX5 dshow filter, we can assume something worked. :)

The GMC checkbox, however, produces files that are exact to files encoded without GMC checked (binary compare)...so my _very_ limited tests conclude that the GMC checkbox does not change anything (at least when used on its own).

cjv

EDIT: tested using h263, constant q2, no lumi, motion 6, avisynth 2.06.

[Koepi]

I'm sorry, I messed up the checkbox-analysis (I was activating GMC when using interlaced - forgot to change the control while copying some code ;) ) - this is fixed now, redownload the build if you already have it. I didn't change the name because it's a minor GUI glitch IMO.

Now GMC checkbox should work as expected!

Thanks for letting me know cjv! :)

Best regards,
Koepi

[lighty]

@Koepi

So what does Motion search precision 6 now does if there are now dedicated checkboxes for QPel?:confused:

lighty

[Koepi]

MSP 6 does now what it did before: it throws everything up to halfpel at the moving pictures[tm]. It's what you can find e.g. in the XviD help file or XviD options explained (which have the same content).

Koepi

[ookzDVD]

Wow... lot's of XviD build this weekend ;)
My last try with full encode was Shrek with Koepi's 31/10
and playback use Nic's 01/11 DSF, use B-Frame and result is OK,
as iago report on other post.

[lighty]

Originally posted by Koepi
MSP 6 does now what it did before: it throws everything up to halfpel at the moving pictures[tm]. It's what you can find e.g. in the XviD help file or XviD options explained (which have the same content).

Heh- I simply wasn't sure if everything was back to the old. Tnx!

[Koepi]

XviD-04112002-1:
- Fresh CVS checkout. GMC improvements.
- New mod. HQ quant type reimplemented.
- Added checkbox for chroma motion estimation (slow but better PSNR).

Damn, development in lightning speed, eXtreme coding ;)

Regards,
Koepi

[cweb]

Originally posted by MaTTeR

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

I don't get them usually.. Oh well, I reverted to the stable build by Koepi. I noticed that LUMI Masking is working better in the stable build (I tested lumi on in both passes and got excellent results. I also tried 1st pass - MPEG and 2nd pass - New Mod - the results were good.) Thanks anyway. Perhaps I will have a go with the dev. build by Koepi to see what it does with B-frames... but I am still afraid to use them to archive anything I encode - they might not decode well in future builds or will the proper decoding be guaranteed somehow?

Today I found probably what was the first xvid clip I encoded from DV using a shareware program called AVIedit. It was terrible quality for sure as it was interlaced and I didn't deinterlace! I know much better now thanks to these forums, even the software I'm using is much different and more optimized - dvd2avi (except for DV source files), avisynth 2.x, decomb for deinterlacing, convolution3d filter, virtualdub or tmpgenc for extended formats like KVCD, oggmachine and oggmux (thks Koepi once more for these programs) to create an OGM.

[MaTTeR]

Originally posted by Koepi
Damn, development in lightning speed, eXtreme coding ;)

You can say that again, hard for me to stay on the cutting edge now days :D Thx for the new build Koepi.

@all,
I haven't tested Qpel in the last 3 or 4 dev builds. Is the noise smearing effect still happening?

Edit- I did a full 2 pass encode last night with Koepi's 03112002(re-release) build using GMC. The resulting AVI file plays back just fine but unfortunately Vdub still refuses to preview or edit the file thinking that corruption exists.

[Rrrough]

@MaTTeR,

did you notice any filesize in-/decreases in first pass resp. did you get a quality improvement with second pass ? I'm testing now only with short clips, but mostly I get a filesize increase.
and did u try combining gmc and bframes yet ? i have some playback problems with that combination, but I'm still trying to figure out what's happening, so it's too early for a "bug-report".
well, there's supposed to be GMC improvements in Koepi's latest build, gonna test.

@Koepi

I read somewhere ;) that the momentary state of GMC is translation (i.e. same as DivX5) - and translation takes places in halfpel - is there a seperate VOL-header written for each frame then or does GMC exclude QPEL generally ? What I mean is, does it make sense combining QPEL and GMC ? I know I can find out by testing, but it'll take quite a while until I'm at my test-setup again.

cheers

[MaTTeR]

Originally posted by Rrrough
@MaTTeR,
did you notice any filesize in-/decreases in first pass resp. did you get a quality improvement with second pass ? Yes, the first pass filesize did increase very slightly when using GMC but not enough for me to worry about. Looking at the numbers, I'm very happy with what I see so I hope the visual quality is improved slightly also. I honestly expected a bigger difference in first pass size as this movie has alot of pan&scan scenes.
With GMC-
1-Pass Size : 1404456615 Bytes or 1371539 KBytes
Scaled Size : 774168009 Bytes or 756023 KBytes
Actual Size : 774171986 Bytes or 756027 KBytes

Compressibility : 55.12%
Relative Quality of XviD avi : 68.24%
Absolute Quality of XviD avi : 97.21%
Average Quantizer Used for Movie : 2.931
Without GMC-
1-Pass Size : 1398214565 Bytes or 1365443 KBytes
Scaled Size : 774167875 Bytes or 756023 KBytes
Actual Size : 774144382 Bytes or 756000 KBytes

Compressibility : 55.37%
Relative Quality of XviD avi : 68.67%
Absolute Quality of XviD avi : 97.26%
Average Quantizer Used for Movie : 2.913
I haven't done a visual test yet on my TVout setup because I'm unable to cut a clip with Vdub and burn to CDRW for the HTPC. Maybe I should have encoded straight to OGM to see how Vdub would have handled it. Guess I'll have to burn the entire movie for now and go watch it :-)

and did u try combining gmc and bframes yet ? Nope, I'm not really into using B-Frames unless the source is really nasty or it's a 4:3 flick which would demand it. Most of my sources are 16:9 widescreen.

Edit- This thread is sort of convoluted at this point. Would it be a good idea to start a thread for the newer "developer" builds?

[iago]

@Koepi,

Hey man! I can't catch up with this development/coding speed these days with my poor celeron 900! ;)

Thanks for the new build with great extra/experimental features! :)

best regards,
iago

[OntzA]

I don't know if this has been reported before. When I encode any file using b-frames it doesn't matter what kind of quantition matrix you use, it always gets the same size.

I have read some threads complaining about xvid's performance with anime... but I encode a lot of anime and using brand new b-frames it looks wonderful with lower bitrates than before.

It's incredible how fast is going xvid's enconding right now... What's happening, did you programmers take some kind of speed pills? :D
Keep going with your work! This and other projects demostrate how better is opensource to those paying tools. And thanks Koepi, your builds are really helpful for testing new features.

Sorry if my English isn't good... it's not my mother language.

[Rrrough]

@OntzA

don't worry, your english is very good. I also made this observation some time ago, and wanted to do a binary compare of the resulting files, but never got around to it and forgot about it as development sped up so much. as it seems there actually is a problem with that.
anyone else tested it ? gonna start that binary compare, as soon as I get to it (which will unfortunately take a couple of days now :( )

cheers

[Koepi]

No need for a binary compare. In that configuration always h263 quant type gets used.

Koepi

[Rrrough]

@Koepi

thanx for clarifying. any idea about GMC + QPEL ?

cheers

EDIT : is that planned to be changed (bframes + cust. quantization) ?

[Koepi]

What's wrong with GMC+QPEL? sysKin stated that his chroma ME is qpel capable, and he was a little bit unclear about his GMC additions, but for now GMC is just using halfpel precision according to gruel, dunno if sysKin fixed that.

Regards,
Koepi

[Rrrough]

just asking if encoding with gmc (halfpel precision) statically disables quarterpel precision (for the whole encoding) or dynamically (for single / group of frames) ? does one exclude the other (on a per frame or a per encoding basis) ?

cheers

[OntzA]

@Rrrough

ffdshow's OSD using libavcodec using gmc+qpel says gmc frames are GMC QPEL, so i guess it's gmc+qpel after all.

@Koepi

Do you plan to program MPEG quantizer matrix support with b-frames or it's out of MPEG4 specs?

[iago]

@Koepi,

Some initial and very limited constant quant 2 test results with the 04112002-1 binary and Avs 2.5:

b-frames (3/150): 15576 kb
b-frames (3/150) + cm: 15524 kb
b-frames (3/150) + qpel: 15586 kb
b-frames (3/150) + gmc: 15594 kb

(I did a couple of short test encodes in addition to that as well, all of which giving similar file-size results to the above.)

Visual quality seems pretty good with all of them and the "cm" option does not introduce much speed drop imho.

As for the "gmc" encodes (with b-frames), I cannot decode them successfully, neither with ffdshow (14 oct. or 29 oct. releases) nor with Nic's latest DSF. Any ideas that will help?

regards and thanks again,
iago

[OntzA]

I can decode gmc together with b-frames without problems using ffdshow-20021014-se
Do you decode it using libavcodec or xvid?
Well, it decodes without problems... but i think gmc+bframes is buggy. gmc alone and gmc+qpel works fine :)

Edit: I forgot to mention, i use ogm as container, not avi.

[iago]

I can decode gmc together with b-frames without problems using ffdshow-20021014-se

Well, I absolutely cannot. Blocks floating all around, both with and without "Use XviD", when trying to decode "gmc + b-frames".

As for "gmc" alone, (I think) it decodes correcly when "Use XviD" unchecked. However, it causes error and crash when "Use XviD" checked.

So I'm editing my previous post as: [...] "gmc" encodes (with b-frames) [...]

iago

[OntzA]

Those blocks appear all the time? Because i have noticed them, but only when there are gmc frames (as i have seen in the OSD). Every other frames decode OK.

[iago]

Well, as I mentioned in my previous posts, this decoding problem is pertaining to only "b-frames + gmc".

Imho, b-frames with XviD work very well and I've been getting pretty good results with b-frames 3/150 for a long while.

iago

[OntzA]

I think I didn't say it clearly...
First: It decodes well until an gmc frame arive, that frame decodes crappy and next p frame goes well
Second: Do you have the same problem or it just doesn't play the whole file.

In my tests i have seen that gmc alone and gmc+qpel are working, but gmc+bframes is buggy.

And yes, b-frames alone are wonderful, and if you use new color ME with anime file is smaller and I think there's a quality improvement, but it's too early to take that conclusion. I'm encoding Melty Lancer OVA 5 using bframemax5/150% and cm. Tomorrow I'll test QPEL+GMC with the same episode. I'm really looking forward to seeing qpel+gmc+bframes working, I hope would know more C programming...

[iago]

@OntzA

After checking with OSD, it seems that problems (with "gmc + b-frames" encodes) occur when GMC frames arrive and the rest of the frames (P and B) decode fine.

regards,
iago


Btw, Sorry, I couldn't reply to your PM, but yeah I can say that my CPU is burning like hell! ;)

[nexus]

@OntzA

I just started to do tests with features like B-frames, etc and therefore i did a few test just to see which of these new (at least for me) features work together. I get the same result, if i use B-frames and GMC the video looks really ugly. But chroma, QPel and B-frames are working really fine together. No decoding probs with Koepi's XviD-04112002-1.exe.

@Koepi: Good job! :-)

[iago]

Some more very short quant 2 - compressibility test results with Koepi's 04112002-1 build and AviSynth 2.0.6:

gmc: 19590 kb (decodes fine with ffdshow Oct.14)
qpel: 18120 kb (decodes fine with ffdshow Oct.14)
gmc + qpel: 18138 kb (decodes fine with ffdshow Oct.14)
gmc + b-frames (5/150): 16192 (decodes badly with ffdshow Oct.14 when gmc frames arrive)

regards,
iago

[iago]

@nexus,

Currently, Qpel doesn't work with B-frames. When you use B-frames, Qpel is not used.

iago


I believe the next great step in XviD development will be making b-frames (it's quite good in its current status imho and it's absolutely not a feature to be disregarded) work together with Qpel and (without problems with) GMC.

And I'm sure, with XviD's lightning fast development, it will not take long to have all these great features together! ;) Once more, many thanks to all XviD developers/coders for their great efforts.

best regards to everyone

[Gaia]

Sorry figured it out myself

[Rrrough]

@iago, Ontza et al.

well, it seems GMC and QPEL work together, thanks for answering my question in a practical manner :)
still it will take some days to return to my test setup, which is like a torture with all those new goodies in xvid.
I noticed the same as you guys when trying playing back bframes + gmc encoded movies.
are you able to edit gmc-clips with vdub and koepis latest build now ?

@iago especially

bframes 3-150 work like a charme for me, I'm glad that the person with probably the most practical experience can assure this. ;)
hope, bframes + MPEG quants (and maybe even custom quants) will work some day.

cheers

[unplugged]

Originally posted by Rrrough
@iago, Ontza et al.

well, it seems GMC and QPEL work together, thanks for answering my question in a practical manner :)
still it will take some days to return to my test setup, which is like a torture with all those new goodies in xvid.
I noticed the same as you guys when trying playing back bframes + gmc encoded movies.
are you able to edit gmc-clips with vdub and koepis latest build now ?

@iago especially

bframes 3-150 work like a charme for me, I'm glad that the person with probably the most practical experience can assure this. ;)
hope, bframes + MPEG quants (and maybe even custom quants) will work some day.

cheers
I advise to create small .MP4 test file and test with some reliable ISO-MPEG4 player ;)
It's the best way to know what you are getting with unstable builds (I use these binaries because are VERY good), I use EnvivioTV and what I can say is that ATM GMC with QPel does NOT produce standard videos yet, but garbled in certain parts. (XviD-20021104)

[Gaia]

If somenthing gets played with Envivio TV it doesn't nessecary mean that it's MP4 compliant. I have noticed this several times. So don't trust it.

[Rrrough]

what I can say is that ATM GMC with QPel does NOT produce standard videos does envivio play movies with only QPEL or only GMC then (sorry, can't test now) ?
XVID qpel is more MPEG-4 compliant than DivX5-qpel, but I guess from a manufacturer's point of view, at least as it concerns mass market, they'll probably orientate on DivX5 compatibility, even though not all advanced simple profile features are implemented.
Or take it the other way around, modulated quants aren't really MPEG-4 compliant, still they get played back (I think) by envivio.

cheers

[unplugged]

I don't trust entirely EnvivioTV, simply it trust it *more*.
But, again, if anyone know some reliable ISO-MPEG4 as alternative we can give a try.

With EnvivioTV I have seen XviD QPel support growing during last month builds and just a week ago it (XviD and Qpel) starts to look perfect with Envivio player.
(first Qpel implementations builds were very messed up, despite XviD decoder played good :-/)

ISO-MPEG4, at least for me, is important as LAME goes perfectly and maintain the standard ;).
Don't know about modulated quantizers, I don't use this feature.

[MaTTeR]

Nobody else has any comments on Qpel from Koepi's latest dev build? It seems to me the "smearing noise" artifact has disappeared for some reason. Anyone seen it? I dont recall reading anything about a Qpel update in the changelog. Ripped "Lost in Space" at an average bitrate of 1208kbps with Lanczos @ 640 resolution and overall quality is outstanding IMO. Perhaps one of the shaprpest and most detailed rips I've done in recent times.

Going to encode it once more with YV12 now and hope it looks even better:)

[miha]

There ware many changes in the cvs from Friday can somebody create a new binary I still don't have virtual c++ so I cannot compile my one :(

[lighty]

Originally posted by MaTTeR
Going to encode it once more with YV12 now and hope it looks even better:)

Wouldn't encoding with YV12 just get you some extra speed but nothing in terms of quality? At least that't the way I understand it by reading FAQ in Avisynth section.

[Koepi]

Then you clearly read it wrong.

Since there's less colour space conversions (=interpolations), you'll get a "more original" image.

It's clearly stated in the FAQ.

Regards
Koepi

PS: I've a working binary with all latest changes on my computer, I need to find some minutes to build an installer & release it...

EDIT:
XviD-09112002-1:
- Fresh CVS checkout. YV12 decoding support (faster than DivX5).
- New mod. HQ quant type reimplemented.

(+ some other changes which I already forgot)

[Kyo]

Many thanks Koepi for ALL this work!

Testing.... Testing....

Cheers.

[lighty]

Originally posted by Koepi
Since there's less colour space conversions (=interpolations), you'll get a "more original" image.

Ehh- I guess I must've got it wrong then- I thought it was simply a matter of reducing a number of non-interpolating conversions for the sake of speed. Mea errata!:stupid:

BTW- tnx for the new XviD binary.;)

[Bulletproof]

Is there really a difference between a file that was encoded from RGB vs a file that was encoded from YUY2 (Besides speed)? I don't seem to be able to tell the difference. So I'm guessing I may not see a difference between YUY2 and YV12(?).

[Rrrough]

I can see a clear difference here, the yv12 clip colors look much closer to the original than yuy2 and rgb. are you sure there was no conversion in between (for example unintentionally using original vdubmpg2 instead of sh0dans version) ?

cheers

[HarryM]

@Koepi:


DS Filter (xvid.ax) in your 09112002 build is probably buggy. I it use for decoding lot of xvid's movies and mainly for videos with width lower 512 I see only something like gentle-diagonal stripes :(

Any videos get O.K., any videos don't (see above).

In use at vdub (VfW interface) is all O.K., ffdshow O.K. too.

[ookzDVD]

@Rrrough,

I can confirm that too,

the yv12 clip colors look much closer to the original than yuy2 and rgb



@HarryM,

I use Nic's xvid.ax dated 01/11, no playback problem.
Just try the latest ffdshow build 10/11 with no problem also.

[HarryM]

Originally posted by ookzDVD
@Rrrough,

I can confirm that too,



@HarryM,

I use Nic's xvid.ax dated 01/11, no playback problem.
Just try the latest ffdshow build 10/11 with no problem also.


Latest Nic's standalone decoder is O.K. too, right.

[NiTroGen]

Originally posted by ookzDVD
Just try the latest ffdshow build 10/11 with no problem also. Where did you find this build? Last build (and quite buggy) is dated 28/10 and Athos said that the next alpha version will be compiled in a couple of days.

[lighty]

Originally posted by NiTroGen
Where did you find this build? Last build (and quite buggy) is dated 28/10 and Athos said that the next alpha version will be compiled in a couple of days.

I think he is talking about 11/10 alpha version but he is using US date format so his 10/11 US is not 10/11 EU but 11/10 EU. Heh- US should have go metric long time ago... :p

[ookzDVD]

@NiTroGen,

There is new build today, Nov 12, 2002

http://www.sekxx.org/ffdshow/

PS. Thank you to athos, it's his page.