XviD-26012003-1 (unstable) developer build

[Aktan]

offtopic:

marc had said this once. use the parameters:
moderate_h=30,moderate_v=50
to stop the softening effect of luminance deringing. (or something like that). :)

[Teegedeck]

Yes, but you'll reduce the effect of all other pp in MPEG2DEC3 with this, too, not only luminance deringing. Perhaps you can compare for us the compressibility with this setting and with 'normal' settings.

[mikeson]

@Gazza:

I use C3D with very light settings in most of my encodings because almost all my DVDs are (more or less) bad mastered (there is noise at least). So when I get rid of this noise, I've got better compressible movie with much more 'stable' picture (I know Iago would disagree with me ;) ).

@Steady:

We are still (patiently) waiting for YV12 version of your great filter Dust. ;)

[Manao]

@Gazza : Same thing as Mikeson : When using convolution3d, the flickering ( I use 09/12/2002 build ) is less present, especially on old movie. I've made Rear Window without C3D, with and without fluxsmooth, lanczos @ 640*384, and even if the first pass had a little size ( 700 Mo with fluxsmooth, 800 without, and I aimed 585 Mo for the second pass ), I wasn't happy with the result, because of the flickering, even on the first pass. C3D in this case helps a lot, even if I have to add noise on playback to make the movie more "realistic".

[Space Hopper]

Hmm, i haven't been active on this board much lately, but can you only use B-frames in your first pass?
Just finished encoding K-Pax, and i get a wierd errormessage ontop of the movie: "BROKEN B-FRAME, MISSING R"
I cant read what comes after "R" (runs off the screen).
This happens with whatever b-frame setting i might try. Encoded the movie with 3-150-100.

[kilg0r3]

@ aktan: thresholds do _not_ affect the deringing; unfortunately.

[iago]

Hello everyone,

I absolutely agree with most of what Teegedeck has said. There's indeed no reason for "unnecessary" filtering, especially at this level of XviD development, when we have a real powerful and great working weapon like b-frames to increase compressibility.

However, opposite to mikeson's belief that I will disagree with him ;), there are situations where some "purposeful" filtering will help us a lot.

For example, I still find a combo of "LumaFilter(-2)" with Marc's mpeg2dec3.dll for AviSynth 2.5 and Tom's "UnFilter" with very low settings (say UnFilter(-5,-5) or UnFilter(5,5) depending on the requirements of the source) very useful to get rid of the famous "black-blocking" issue.

That's why I still adorn almost all my scripts with either "LumaFilter(-2).UnFilter(-5,-5)" or "LumaFilter(-2).UnFilter(5,5)" ;).

Also, vlad59's Convolution3D is still the best denoiser ever written imho. With some low thresholds and especially before resizing, I believe it will usually do more good than harm (in terms of visual quality) in most cases, without hurting details.

Well, I guess I'd better cut it now, it's already been a long post! ;)

best regards,
iago

[NuclearFusi0n]

i'm seeing some weird decoding issueswith ffdshow libavcodec, there is qpel smearing, with use xvid, there are flickering blocks - i guess this is what will be fixed with the next ffdshow version =D

[cult]

I always use c3d,unfilter and luma

[CruNcher]

@iago

you should really try out neurons new Msmooth this is in terms of compressibility vs quality the best Filter i saw yet the only problem it's slow ass hell i get on 512x224 4 fps with all other Advanced Simple Profile features but it tries to compress only the not so visible parts of a movie and it does it really good watch it for yourself with the show=true parameter

[Caleb666]

hey guys,

what is the best xvid dshow filter?

do koepi's latest binaries contain nic's dshow filter? or koepi's own latest filters?

I'm also wondering what ffdshow uses to decode xvid... and if it's as good as koepi's and nic's builds are?

im a bit confused about this...

[jcsston]

@Space Hopper
Is only on the first frame? If I open a XviD avi file in VirtualDub the first frame I display has that B-Frame message :confused:

[iago]

@iago

you should really try out neurons new Msmooth this is in terms of compressibility vs quality the best Filter i saw yet the only problem it's slow ass hell ... blah blah blah...

@cruncher,

Thank you very much for your suggestion, but I am not interested. I am glad with what I can get using some other great filters such as UnFilter, Convolution3D, FluxSmooth, BlockBuster, PeachSmoother, etc.

Btw, this is the XviD forum, and I guess it would be better to turn back to the subject, that is, XviD matters.

regards,
iago

[Gazza]

Dear all,
Thanks for all your impressions and opinions regarding necessary/unnecessary filtering - it still comes down to personal choice in the end. However I do take note of the inputs from iago, teegedeck, mikeson, manao....

I know that this is not exactly xvid but it is related to this issue of filters, etc, I installed the latest avisynth 2.5beta last night and found that I couldn't use convolution3d (I think it needs to be re-compiled to suit avisynth 2.5beta).

After searching for a version of mpeg2dec that wouldn't crash and using only lumafilter and lancosresize the result was still very nice which is a true reflection on the quality of xvid in this latest build.

[CruNcher]

@iago

sorry for my little excursion into the of-topic

@all P4 users

Do you also experience problems with refdivx lumimasking in koepis
new build @ encoding, especialy Williamete users ?

[Space Hopper]

Originally posted by jcsston
@Space Hopper
Is only on the first frame? If I open a XviD avi file in VirtualDub the first frame I display has that B-Frame message :confused:

No its through the entire movie, and its pretty much unwatchable, the framerate seems wrong too. And I have NOT been messing with that, and the movie encodes just fine if I turn bframes off.

It messes up with these settings (VirtualDubMod 1.4.13 & AviSynth 2.5 beta and 2.5 plugins):
--
avisynth:
ConvertToYV12()
crop(2,74,714,436)
Convolution3D (0, 3, 4, 3, 4, 2.8, 0)
BicubicResize(496,208,0,0.5)
--

xvid settings:
qpel, lumi mask, chroma motion, gmc.
bframe: 3-150-100 (have tried other values)
The rest is pretty much what you can read from iagos xvid document.

If I recall correctly I didn't have this issue with the 4.dec build.
Any help is appreciated

[MaTTeR]

Yep, been seeing the same thing here all day as well. Oddly enough, the movie playsbacks without the "decoder lag, broken b-frame" message as long as it's not played in fullscreen mode. A quick work around for me is to use libavcodec(ffdshow) instead of Xvid.dll. As Space Hopper already pointed out the message appears with various B-Frame settings.

I still see flickering blocks in random spots as well, think Kilgor mentioned this previously. Still though, the quality is very beautiful :-)

@Nic,
I can confirm the earlier report of the decoder not seeking properly too. Seems like it might pause/freeze on random frames, sometimes during playback. Let me know if you need more details.

[Space Hopper]

I've been probing my ill videostream some more, and the quality here is far from acceptable. I don't blame xvid for that though. I suspect avisynth has something to do with it, maybe ConvertToYV12.
All textures are blurred, its quite noticable on facual textures. And its the same with conv3d turned off and all the neat algoritms off (qpel ect.).

Gonna try an older avisynth now.

[EDIT]
Didn't help, so avisynth wasn't the quilty part.
Maybe im just an idiot.
I just cant get a clear and sharp picture.. Its blocky no matter what setting i use, and its not a noisy dvd.
The output pane in vdubmod looks nice and sharp.

1pass quality based at 100 makes blocks.
2 passes with more than enough bits available makes blocks.
I dont get it.
I feel like quitting

Btw. I dont get that bframe error message with this avisynth version (2.07).

[NuclearFusi0n]

make sure "use xvid" is checked in ffdshow configuration

[kastro68]

Originally posted by Space Hopper
I've been probing my ill videostream some more, and the quality here is far from acceptable. I don't blame xvid for that though. I suspect avisynth has something to do with it, maybe ConvertToYV12.
All textures are blurred, its quite noticable on facual textures. And its the same with conv3d turned off and all the neat algoritms off (qpel ect.).

Gonna try an older avisynth now.

[EDIT]
Didn't help, so avisynth wasn't the quilty part.
Maybe im just an idiot.
I just cant get a clear and sharp picture.. Its blocky no matter what setting i use, and its not a noisy dvd.
The output pane in vdubmod looks nice and sharp.




The later Xvid builds are giving me poorer results. The most recent Xvid build that i can use with good results is Koepi's 9-12-2002 build.

Any later builds give close up facial shots excessive freckles/blockiness.

I use B-frames, chroma est, q-pel everything else is on default. No post processing in ffdshow. Use Xvid is not ticked... when it is ticked an error message is displayed.

[Wormz]

@Space Hopper: Are you using the beta of Convolution3D with YV12 support? If not, that might be causing your problem but I'm not sure...

[Lefungus]

Bug report:

RefDivx lumimasking always crash on my computer. It's a p4 cpu. I use xvid with virtualdub. One second after the beginning of any pass, i get a program failure. It is said : Crash Reason : Privileged Instruction. It happens each time. Other xvid options like bframes, qpel, gmc or chroma ME don't change this behaviour

Lumimasking was working great with Koepi 03/01/2003 unstable build

[Valky]

Originally posted by kastro68

I use B-frames, chroma est, q-pel everything else is on default. No post processing in ffdshow. Use Xvid is not ticked... when it is ticked an error message is displayed. [/B]

I have this same problem. I encoded 'The Natural' with this latest build and everything seems fine with ffdshow if I dont tick that 'use xvid..' But if it's ticked, all the players closes themself immediately. I also get that 'lag decoder b-frames..' error with virtualdub, but it doesn't affect playing movie anyhow.

[JimiK]

For me ffdshow also crashes every player when "Use XviD" is checked. I had this for some builds now. Strangely, when I already had this problem with an own build I compiled from CVS, one of Koepis later builds didn't have this problem. Now his latest builds also crash the player when using them in ffdshow. So I'm just using ffdshow and everything is looking great (I don't use QPel).
Best regards,
JimiK

[Space Hopper]

Originally posted by Wormz
@Space Hopper: Are you using the beta of Convolution3D with YV12 support? If not, that might be causing your problem but I'm not sure...

Thanks for the suggestion, but no, that aint it.
Tried both the beta and the non-beta, and none at all.
Same unatractive picture

[trbarry]

"It is said : Crash Reason : Privileged Instruction. It happens each time."

I think P4's can call it a priviliged instruction when the data for certain SSE2 instructions is not 16 byte aligned. Go figure.

- Tom

[Valky]

Hmm.. I did use qpel, but I did have many other xvid movies also on HD without qpel. Ffdshow didn't show me any error just closed the movie immediately.

And I am using Athlon XP+ 1700. This problem didn't exist with previous builds.

[kastro68]

My concern isn't the fact that an error message is displayed when "use xvid" is ticked.

I am concerned with the quality of the encodes with the later xvid builds after koepi's 9/12/2002 build. The 9/12/2002 build gives me great results. I don't know how to describe it, but it is very obvious on close ups of faces... a bit like a frosty image.

I believe i may be experiencing the same problem as Space Hopper.

I have also encoded the same clip with the same settings on two independent systems with different hardware and still experience the same problem.

I think it may have something to do with the b-frames... i have yet to do an encode w/o b-frames and see if the problem still persists.

[kilg0r3]

Originally posted by kastro68

I am concerned with the quality of the encodes with the later xvid builds after koepi's 9/12/2002 build. The 9/12/2002 build gives me great results. I don't know how to describe it, but it is very obvious on close ups of faces... a bit like a frosty image.


same here. difficult to describe.

[Bulletproof]

Try turning Q-pel off and see if that helps. Do you mean you're seeing noisy patterns, or something different?

[Space Hopper]

Originally posted by kastro68
My concern isn't the fact that an error message is displayed when "use xvid" is ticked.

I am concerned with the quality of the encodes with the later xvid builds after koepi's 9/12/2002 build. The 9/12/2002 build gives me great results. I don't know how to describe it, but it is very obvious on close ups of faces... a bit like a frosty image.

I believe i may be experiencing the same problem as Space Hopper.

I have also encoded the same clip with the same settings on two independent systems with different hardware and still experience the same problem.

I think it may have something to do with the b-frames... i have yet to do an encode w/o b-frames and see if the problem still persists.

I might make some more test tonight. Play around with different setting-combinations.

@kastro68
Disabling bframes didnt help me out. But let me know if it did the trick for you.

[wing1]

@gazza
The output pane in vdubmod looks nice and sharp.

I don't know for sure, but I think somehow vdub convert your AVS output to RGB or something and sort of make it look better looking. I have observed the same thing with TMPGEnc output pane during VCD/SVCD encoding. They produced very nice looking panes, but playback are full of Mblocks. My preference is either monitorfilter() from avsmonitor, wmp or BSplayer for checking my AVS output.

If Koepi's build 26012003-1 can't give your encoding result Mblock free at 1pass 100 quality...Something is very wrong for sure. If your source has jitter blocks (mosquito noises), then it can cause xvid encoder to produce Mblock in the output (especially when B-frame is envoke). However, 1pass 100 quality should have seen that and bump the datarate sky high(500-600Kbps), and at that datarate you might as well encode using MJPEG or Huff instead :D

This build is simply superb in term of quality. However, the edge sharpness from this build is slightly soften when compared to 12092002-1 build. Nevertheless, the overall quality, especially B-frame, is much better IMHO.

I don't know if anyone noticed this but B-frame definition 2-3/100-150/100-900 makes very little difference in term of overall quality (even in freeze frame mode!!!), but the filesize decreases(~200-800Kb/min) as the offset is increased. I started to see Mblock in high motion scenes only when offset is around 700-800. Perhaps, it is the soften edge sharpness which is helping in reducing Mblock in B-frame. Maybe, something that Foxer has mentioned earlier in this thread regarding ratecontrol, which is affecting B-frame for 1pass encoding...I like it :D

1st frame reporting B-frame lagging existed after CVS build december 14, 2002 14:00 (d/l all of uManiac's insta-build and trial/error all of them to track down when it came about). If I remembered correctly that Edgomez has mentioned something about that in the recent changelog. I don't see any problem with that when using ffdshow to playback the xvid encoded clips.

[Teegedeck]

Originally posted by wing1

If Koepi's build 26012003-1 can't give your encoding result Mblock free at 1pass 100 quality...Something is very wrong for sure. If your source has jitter blocks (mosquito noises), then it can cause xvid encoder to produce Mblock in the output (especially when B-frame is envoke).
What did you expect when your source has artifacs? :rolleyes: Try filtering your source before encoding.
However, 1pass 100 quality should have seen that and bump the datarate sky high(500-600Kbps)
I see that you don't quite understand how quality/quantizer-based encoding works. Please search the forum a bit.
(even in freeze frame mode!!!)
Now, what is this? Have I missed something?
I started to see Mblock in high motion scenes only when offset is around 700-800.
Someone's posted an Excel thing that tells you how your B-frame settings influence actual quantizers. Have a search for it.

Nice that you're content even if you're having problems with some aspects of XviD ATM.

Greets,

Tee

[iago]

I don't know if anyone noticed this but B-frame definition 2-3/100-150/100-900 makes very little difference in term of overall quality (even in freeze frame mode!!!)

I don't know what "freeze frame mode" is either ;), but I'm sure that a quantizer offset of 100 and a quantizer offset of 900(!) would "make" a lot of difference:

Say past P frame quantizer is 2 and future P frame quantizer is 4 for a B-frame. If your setting is ratio:100/offset:200, b-frame quant would be ((3*100)+200)/100 -> 5. If your setting is ratio:100/offset:900, b-frame quant would be ((3*100)+900)/100 -> 12. That means a huge difference imho, which will absolutely reflect in quality, if there's not something going wrong with these calculations, and I don't think there is ;).

You can use "ffdshow -> OSD -> frame mean quantizer" and see that the formula applies correctly.

regards,
iago

[wing1]

@Teegedeck

I don't have a problem with encoding using Koepi's recent build -> @gazza does.

I see that you don't quite understand how quality/quantizer-based encoding works. Please search the forum a bit.

What I have observed when I use this function, is the datarate rises to meet the demanding scene or noisy scene (big frame size) and falls as the scene is quiet (small frame size). If your input is very noisy(mostly the cause) or have heavy movements, the codec will see this and either push the quantizer way up or raise the datarate to meet the demands if quantizer does not meet the demands (dip into the bit bucket?). Hence, I see the 500-600Kbps. There are three modes for 1pass encoding: CBR, quantizer, and quality base. I have observed datarate is more likely to rise in the quality mode depending on the % quality setting.

@Iago

Freeze frame mode...bad wording choice on my part :D

What i am referring to is during pause on playback. Previous xvid builds, Bframes tends to be ugly during pause on playback, if # of Bframe exceeds 3 or quantizer ratio is more then 150 or offset is more then 300. This build produces great looking Bframes during pause. I generally use 2/100/300 for B-frame on previous builds; However, this build I can push the #Bframe upto 5 or the quantizer ratio upto 200 or the offset upto 600 and B-frame still looks good during pause.

btw... I am commenting based on CBR mode: I have used CBR from the first time I use XVID and have tweak it to work the best for me.

I am complementing this build as being the best so far, and not saying it is bad in anyway. Great build xvid developers!

[Space Hopper]

Originally posted by wing1
@Teegedeck

I don't have a problem with encoding using Koepi's recent build -> @gazza does.



I don't think gazza has any problems, I do however.
It was my post you quoted :)

I haven't been able to find the problem yet. Maybe the problem will go away by itself with the next xvid releases.

[MoonWalker]

BWT You can see the quantizers of B-Frames using xda v0.20(and soon v0.21 with a GUI by Nitrogen :) )..You can also see if you change the ratio/offset how the b-frame quantizers will change :) :) :)


MoonWalker

[kastro68]

Originally posted by Bulletproof
Try turning Q-pel off and see if that helps. Do you mean you're seeing noisy patterns, or something different?



The problem that i was experiencing seems to disappear when q-pel is not being used. Is there something buggy with q-pel that i don't know about?

[Gazza]

I have upgraded my avisynth to the latest 2.5beta and latest Koepi xvid (26 Jan). Then I have tried encoding two different video streams (no qpel, brames (3,100,200), and gmc). I noticed that I could not get the video and audio to sync (using ogm) no matter what I tried. Repeating the encodes without bframes fix it for me.

Anyone else see the same thing?

[Koepi]

I experienced the same synch issues only with "das boot". Currently reencoding with xvid-02022003-1 (hihi :P ) to see if the latest changes to vfw (well, just changing 1 line in the code...) work as well for 2pass encodes.
I think it's solving those issues as my "ugly hack" can have the side effect of more pad-frames within the bitstream get treated as real frames, thus adding delay. (Strange enough, it worked well for a TV/VHS capture and apocalypse now redux bilingual 1xcd).

Maybe smartripper is tricking us with the audio delay?

Regards
Koepi

[fraatz]

hi!
koepis hack doesn't care about frametypes, so the delayed bframes are not buffered back to the bitstream in vdub as real frames...
you have to calc delay, take a look at the first post on 2nd side of the audiodelay thread here in the xvid forum to solve this.
however, i did a cvs checkout and the problem seems to be fixed already. wait for the new binarys.....
-f

[iago]

@Koepi,

Heya my friend! ;) I want to point out one more time that your latest binary absolutely rules in the encoding arena in terms of visual quality! :)

And I guess there are only just a few steps to a real "monster build" (as Sigmatador had defined it :D).

I have one question if you don't mind: What is that "b-frame decoder lag" which occurs when you load a b-frame encoded clip into VDub(Mod)? Is it something very bad? :D

regards,
iago

[Koepi]

Selam iago, dostum!

Well, bframe decoder lag is very easy to explain.

Let's say you have a sequence IBBBP.

You can decode the iframe. But you get in trouble with the bframes: they reference the future pframe, which isn't loaded yet. So you need to fill up the decoder buffers with the bframes until the pframe arrives and _then_ you can finally decode the bframes up to the pframe.

Now let's switch on dx50bvop compatibility:
the bitstream looks like this IPBBB.
You could decode the Iframe, the pframe belongs on 5th position, so you have 1 frame _nothing_ until the bframe arrives and can be decoded. 1 frame lag.

That message just means that the decoder buffers get filled, nothing more, nothing less.

Regards & serefe,
Koepi

[sprit]

Originally posted by Koepi
Let's say you have a sequence IBBBP.
[...]
Now let's switch on dx50bvop compatibility:
the bitstream looks like this IPBBB.
Isn't the frames always placed in encoding order in the bitstream?
My understanding of 'dx50bvop compatibility' is that the frame immediately before an I-frame can't be a B-frame.
The sequence IBBPBBI would be made DivX compatible by making the second last frame a P-frame, IBBPBPI stored as IPBBPBI.

[Wormz]

Originally posted by sprit
Isn't the frames always placed in encoding order in the bitstream?
My understanding of 'dx50bvop compatibility' is that the frame immediately before an I-frame can't be a B-frame.
The sequence IBBPBBI would be made DivX compatible by making the second last frame a P-frame, IBBPBPI stored as IPBBPBI.

Maybe he meant packed bitstream??? I'm not sure, just a guess....

[Boardlord]

Man!! I can't believe my eyes! Just encoded Family Man (2h 05m) to 1cd xvid with Koepi's latest build. Guess what! Astonishing!
Why do we need DVDs anymore??? ;)

[kastro68]

Originally posted by Boardlord
Man!! I can't believe my eyes! Just encoded Family Man (2h 05m) to 1cd xvid with Koepi's latest build. Guess what! Astonishing!
Why do we need DVDs anymore??? ;)

did you use q-pel???

[Boardlord]

Yes,I used it along with GMC, CM, Bframes.
I used the xvid decoder from Nic's last build. It works for me correctly, but it just doesn't like DirectVobsub. Subtitles are not shown if Nic's decoder is in use. If I switch to ffdshow subs are displayed correctly. But the last ffdshow alpha (2003-01-03) doesn't decode qpel correctly, so till a new one arrives I'll use Nic's decoder and settle with not having subs. :) :)

[Gazza]

Originally posted by Koepi
I experienced the same synch issues only with "das boot". Currently reencoding with xvid-02022003-1 (hihi :P ) to see if the latest changes to vfw (well, just changing 1 line in the code...) work as well for 2pass encodes.
I think it's solving those issues as my "ugly hack" can have the side effect of more pad-frames within the bitstream get treated as real frames, thus adding delay. (Strange enough, it worked well for a TV/VHS capture and apocalypse now redux bilingual 1xcd).

Maybe smartripper is tricking us with the audio delay?

Regards
Koepi

Did you manage to track down the reasons why there is a delay. I just repeated it again without bframes and I am not sure now if the audio slightly leads the video - a slight difference in lip sync. Maybe its just my eyes/ears playing tricks. However the lack of sync with bframes does seem to be a problem though.

[Nic]

I recently have re-written the dshow filter, and maybe that will make a difference (this is like the nth time, ive lost count, this time I cheated and looked how ffdshow does it ;) )

I still get slowish seeking and sometimes it switches to B&W on me. I have absolutely no idea how that can happen. So if I can resolve that Ill be very happy :)
(Ill look at the vobsub problem too :) (& add that YUY2 switch for Jasmin ;) )

-Nic