XviD-26012003-1 (unstable) developer build [Archive]

NuclearFusi0n

27th January 2003, 12:40

Originally posted by terwin
Yes, good work.

I have just testet a short clip (one chapter of Star Wars Eps2) with b-frames 2/100/100, chroma motion and qpel and it works fine for me. No oversize problem.

But XviD doesn't pay attention to the maximum i-frame intervall. I have set it to 300 frames but in some cases there are more then 600 frames between two keyframes.

cu terwin
read the forum - it's known.

The Edge

27th January 2003, 13:14

I see over on betanews (http://fileforum.betanews.com/detail.php3?fid=1043648426), Koepi's 26012003-1 XviD gets a mention.
Also gets 5/5 :)....well deserved.

Very nice codec. In my opinion it's better than the DivX 5.03. I can make my files better looking and smaller with XviD. Keep up the exelent work XviD developers and fans :-)

Again, thanks Koepi.;)

Edge

Sigmatador

27th January 2003, 13:42

thx koepi your build rox again ^c^

what about the max iframe interval bug ? (can someone confirm terwin ?)

iago

27th January 2003, 13:46

@Sigmatador

Since it's a known problem, and since it's stated one more time even in this very thread, does it make any sense to repeat the same issue over and over?!

iago

Sigmatador

27th January 2003, 14:49

ok, forget what i wrote ;) (but it's the last bug to obtain a monster build :D )

iago

27th January 2003, 14:57

"...monster build..."

Hehe, I like it! :D

b1ahb1ah

27th January 2003, 18:30

thx Koepi!
You r0x and xvid too !:)
I just test with an extract from The Silence of the Lambs, and no oversized, very good job koepi ...

terwin

27th January 2003, 21:21

Since it's a known problem, and since it's stated one more time even in this very thread, does it make any sense to repeat the same issue over and over?! Ok, sorry. :o

But I have always read about a problem with the minimum i-frame intervall. Besides it wasn't mentioned in kilg0r3s bug list.

Foxer

28th January 2003, 01:05

Took a quick look at the sourcecode..

It turns out that the core is now setting something it was supposed to and the vfw had made reservations for it but for some reason, it was decided that the variable it was supposed to be stored in was to be used for B/SKIP/PAD/DELAY flags.

Since this change, rate control w/ bframes has been messed up.

Koepi, until the new frametype flag or hlength variable is decided upon, an easy fix to make in your build is to zero nns1.dd_v instead of setting it to stats->hlength in codec_2pass_update() in 2pass.c

NuclearFusi0n

28th January 2003, 01:22

OMFG the quality in this encode i just made - wow. wow!! XviD is progressing at such a fast rate, thank you Koepi! :)
now we just have to wait for the next version of ffdshow and we're all set :D

hayami

28th January 2003, 05:39

Just finished a 56min 2pass encode, filesize problem is gone now =)
ChromaME + LM + Bframe = rocks!

NuclearFusi0n

28th January 2003, 10:23

Originally posted by hayami
Just finished a 56min 2pass encode, filesize problem is gone now =)
ChromaME + LM + Bframe = rocks! Don't forget QPEL and GMC! :D

tiki4

28th January 2003, 14:31

Yess!

Encoded Wild Things on 1 CD yesterday: QPel + Chroma + GMC + B-frames looks better than ever (never used GMC before in XviD, but there seem to be some scenes where it is really useful).

:) :) :)

Keep up the great work, all of you!

tiki4

Boardlord

28th January 2003, 16:20

Maybe repetition, but just finished encoding Stripes with qpel, gmc, bframes, chromaME. AWESOME for me too!!!
If only we had an ffdshow build with the simple idct now...

kilg0r3

28th January 2003, 19:42

is there a way to manually change iframes to b/pframes in the statsfile?

NuclearFusi0n

28th January 2003, 22:36

http://iupload.net/012003/xviderror.png

Settings for XviD ()
Mode: 2 Pass - 2nd pass Int.
Dummy 2nd Pass: OFF
Desired Size: 1045477KB
I-frame Boost: 0%
Below I-frame Distance: 10%
I-frame Bitrate Reduction: 20%
Curve Compression: Payback with Bias, Bitrate Payback Delay: 250frames
High Bitrate Scenes: 0%, Low Bitrate Scenes: 0%
Hinted Motion Estimation: OFF
Alternative Curve System: OFF,
Motion Search Precision: 6 - Ultra
Quantization Type: MPEG
FourCC Used: XVID
Max I-frame Interval: 300, Min I-frame Interval: 1
Lumimasking: OFF
Interlacing: OFF
Greyscale: OFF
Quarterpel: ON
Global Motion Compensation: ON
Chroma Motion: ON
Max B-frames: 3
B-frames Quantizer Ratio: 150%
B-frames Quantizer Offset: 100
Packed Bitstream: OFF
DX50 B-VOP Compatibility: ON
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: %, Max Overflow Degradation: %
Start Credits: OFF, End Credits: OFF,

The first encode of the matrix went fine. I then made a new AVS file, tried encoding it, it always dies out on the 2nd pass. Here's the AVISynth script
LoadPlugin("C:\Program Files\AVISynth\mpeg2dec3.dll")
mpeg2source("F:\Matrix\Matrix.d2v")
crop(0,64,720,352)
Full anamorphic resolution, 720x352

MoonWalker

28th January 2003, 22:42

Hmm...I get this message when XviD fails to load the 1pass stats file..Are you sure the stats file is accesible for the 2ndpass??

MoonWalker

P.S Windowsblinds???

NuclearFusi0n

28th January 2003, 23:56

Originally posted by MoonWalker
Hmm...I get this message when XviD fails to load the 1pass stats file..Are you sure the stats file is accesible for the 2ndpass??

MoonWalker

P.S Windowsblinds???
well, it encoded all the way to the scene where they break morpheus out of the compound with the bigass helicopter, and it looked great all the way up to that point.

not windowblinds, XP themes ;)

MoonWalker

29th January 2003, 00:01

Hmm..Maybe your stats files got corrupted somehow?? Can you open it with GKnot or XviD Stats Viewer (http://homepages.pathfinder.gr/statsviewer) ??

MoonWalker

frodoontop

29th January 2003, 00:11

I had about the same problem with the second pass. There was a simple solution though. Just hit the load default button and restore your old settings(they didn't seem to matter) and things work again. At least for me. Hope this is helping...

NuclearFusi0n

29th January 2003, 00:22

Originally posted by frodoontop
I had about the same problem with the second pass. There was a simple solution though. Just hit the load default button and restore your old settings(they didn't seem to matter) and things work again. At least for me. Hope this is helping...
I load defaults every time i install a new build

what i find strange is that it worked FINE for encoding the matrix at 672 x 272, and when i use the EXACT SAME SETTING for a higher resolution encode it does this - makes no sense to me :( (i just changed the AVS file and ran the exact same job again in virtualdubmod's job control)

I'll try it again when my encode of Donnie Darko finishes up.
Originally posted by MoonWalker
Hmm..Maybe your stats files got corrupted somehow?? Can you open it with GKnot or XviD Stats Viewer (http://homepages.pathfinder.gr/statsviewer) ??

MoonWalker
I'm going to run through both passes again, it takes a decent 8 to 10 hours or so to encode on my Athlon XP 2000+. See ya tomorrow :D

SiXXGuNNZ

29th January 2003, 07:13

very nice, I encoded chapter 15 of the matrix with divx 3.11, divx 5.03 pro, koepi's 04102002 and koepi's 26012003

low motion on divx 3.11(it looked better then divx 5.03)

divx 5.03 I only used bi-directional

with 04102002 I used the settings from the guide on doom9

with 26012003 I also used the settings from doom9 but for b-frames I used 3/150/100 and chroma motion only

all 4 seemed to hit the filesizes pretty dead on.

I can barely tell any diff between the two xvid encodes, but the divx 5 was a 10 pass and looked like crap imo

the two xvid encodes were both 2pass

what's the eta on a stable binary with the b-frames enabled? I only ask because of the compatibility thing. personally I think the new build is rock solid, will try out qpel and gmc later.

NuclearFusi0n

29th January 2003, 08:55

OH MY MOTHER F-ING JEESUS CHRIST WOW!

I'm encoding movies on 2 cds, with FULL ANAMORPHIC RESOLUTION (minus the crop for 2.4:1 movies), and 5.1 448Kbps AC3 tracks and it's looks ABSOLUTELY FANTASTIC.

:eek: this is absolutely jaw dropping quality. from my viewing position, a few feet away from a 19" diamondtron monitor, it's VERY hard to tell the difference between the dvd and the encode. i'd have to be looking for artifacts. the average layperson (read: cute chicks that i wish would watch movies with me) couldn't tell the difference.

wow.

To every single XviD developer: THANK YOU!

Teegedeck

29th January 2003, 09:18

That about summs it up. Ugly two-pass hacks or not, in the not-too-distant future, I'll have to list the name of every single developer in a big :) thank you note here on the forum. Boy; B-frames, chromaME, GMC and Qpel! Every single one of them actually working unlike some well-known commercial codec! And instead of just relaxing the developers are thinking about how to tweak the MPEG4-standard to get even more quality-improvements out of it - boy, boy, boy; you guys are just great!:cool:

Garfield

29th January 2003, 11:58

I made a 2 pass encoding of the Big Lebowsky with B-Frames and Chroma Motion only, with linear curve by defauts and the agressive quantizers settings in iago's tutorial and i'm very impressed by the result.

Thanks to all developpers for this nice work

Sigmatador

29th January 2003, 11:59

[i]the developers are thinking about how to tweak the MPEG4-standard to get even more quality-improvements

I love it :D

The Edge

29th January 2003, 12:13

I totally aggree with everything said so far.....
For a though test for the new build I encoded LOTR:TTT dvd (yes, I'm a bold boy:eek: ) and what can I say.
It's a 1CD encode with an average bitrate just shy of 500kbs
XviD & mp3.....Quarterpel, GMC and CMotion all enabled.
Thanks XviD. I look forward to XViD 1.0

Edge

tiki4

29th January 2003, 12:33

@The Edge:

Maybe it's time now to think of how to get the bitrate of multichannel audio down to say ~64 kBit. If Monty at xiph just had time to implement some more things into Vorbis like full channel coupling...

What comes next? 3 hours of LOTR on 1 Floppy?

Cheers,

tiki4

The Edge

29th January 2003, 12:56

@tiki4
That would be tough. I remember reading that microsoft said it could be done with their super-duper windows media codec:)

Edge

tiki4

29th January 2003, 13:01

Back to topic:

I compared a first pass with the latest stable build of Koepi and with latest unstable with all features enabled (Chroma, QPel, B-frames 2, GMC). The size went down from something like 1100 to 700 MB. Maybe there will come a time we don't need a second pass anymore. Movie was still 'Wild Things'.

tiki4

iago

29th January 2003, 13:02

Hello everyone,

I also agree with all the praise that goes to this latest build by Koepi. Yeah, visual quality is absolutely striking, b-frames work great (only except Min-Max I-frame intervals in two-pass), file-size accuracy is re-gained, and even Qpel and GMC are behaving now! ;)

Thanks again to all XviD developers for this great achievement!

best regards,
iago

sam_b

29th January 2003, 14:58

This new build has got be be breaking the laws of thermodynamics or entropy or something :D Scary quality. Fastastic job all you devels.
But I like NuclearFusi0n's comment the best :)

Two questions though? How are you all viewing the output, ffdshow, xvid.ax, envivio, 3ivx.....? And, (sorry if this is old) is RefDivx's lumi code in CVS now? If not, what is the reason?

majerle

29th January 2003, 15:41

YAAB ! (Yet Another Awesome Build)
Truly fantastic, i encoded an old, noisy film "The Warriors".
As you can suppose 1 cd backup( Bf 3-150-200, GMC, CM, Qpel) ,ogg 96k, near full resolution (688*xxx) , and avisynth 2.5b(plus come c3d) : FANTASTIC!

Thanks guys ! Nothing more to ask.

Andres

EDIT : 690mb + zoomplayer3.5 + oggds0995+ ffdshow(latest) --> A near DVD

Nic

29th January 2003, 16:22

Just as something to do, I uploaded a new build with a new DShow filter.

The DShow may still have the same old problems, or it may be working ok. Its hard for me to say. Seems ok though :)

http://nic.dnsalias.com

-Nic

ps
Mine won't have Koepi's oversize fix.

bond

29th January 2003, 16:53

Originally posted by sam_b
...sorry if this is old, is RefDivx's lumi code in CVS now? If not, what is the reason? Originally posted by Nic
ps: Mine won't have Koepi's oversize fix. hm i hope that the future xvid development will not be divided too much :(

kayman

29th January 2003, 18:15

ive been encoding a few episodes of jeremiah from MPEG tranport streams and have had no problems till this build i do my first pass and have my 2nd pass set to "594121" to accumalte a 121 meg ac3 audio track but it only creates a 360 meg avi?

help!

:)

peaudepailles

29th January 2003, 18:36

Hi,

I had sometimes the same problem with older builds 24012003 and 03012003. (particulary with very dark movies) If you used bframes, try to disable it, thats help a lot (for me ...)

And you can also used MPEG quantization type if not already done,
and no resizing filter.

Hope this help.

Peaudepailles.

@Koepi : Thx in advance for the new build. Not tested yet but according to all, thats a great job !

Bravo ! (as we tell in france ;))

NuclearFusi0n

29th January 2003, 19:21

Originally posted by sam_b
This new build has got be be breaking the laws of thermodynamics or entropy or something :D Scary quality. Fastastic job all you devels.I honestly thought I oversized it, 2pass had a bug, or i had put in an extra zero in the size box. I couldn't believe my eyes. I had to double check the filesize, and make sure i was looking at the right file - i was amazed.
Originally posted by sam_b
How are you all viewing the output, ffdshow, xvid.ax, envivio, 3ivx.....?I'm using ffdshow in ZoomPlayer with "Use Xvid" checked ON (xvid.dll) because of qpel smearing, resize to my screen resolution, and aspect ratio correction for my Anamorphic encodes.

NuclearFusi0n

29th January 2003, 19:39

Originally posted by kayman
ive been encoding a few episodes of jeremiah from MPEG tranport streams and have had no problems till this build i do my first pass and have my 2nd pass set to "594121" to accumalte a 121 meg ac3 audio track but it only creates a 360 meg avi?

help!

:) that means it's "maxing out" the quality. try increasing the resolution (if you are decreasing it, but dont go higher than the original resolution) or try disabling bframes.
:)

Didée

29th January 2003, 23:14

Originally posted by NuclearFusi0n
[...] resize to my screen resolution, and aspect ratio correction for my Anamorphic encodes Seems so many people get fanatic about anamprphic encoding these days (see also several threads in the "New A/V Formats" forum ...).

LOL.

Anamorphic encoding is intended for 16:9 displays. Or, more precisely, for offering the best compromise when the target display AR is unknown.
See, we're usually compressing the video down to the bone, more or less. Where is the sense in wasting bits in additional resolution, introducing some additional artefacts, when you reduce the resolution again on playback anyway? Making the artefacts smaller, that you wouldn't have had without anamorphic?

Or are you making some kind of "backwards anamorphic" encoding (not raising Y, but reducing X) to lighten the overall resolution? If so, then please accept my apologies ;)

Didée

NuclearFusi0n

29th January 2003, 23:48

Originally posted by Didée
Seems so many people get fanatic about anamprphic encoding these days (see also several threads in the "New A/V Formats" forum ...).

LOL.

Anamorphic encoding is intended for 16:9 displays. Or, more precisely, for offering the best compromise when the target display AR is unknown.
See, we're usually compressing the video down to the bone, more or less. Where is the sense in wasting bits in additional resolution, introducing some additional artefacts, when you reduce the resolution again on playback anyway? Making the artefacts smaller, that you wouldn't have had without anamorphic?

Or are you making some kind of "backwards anamorphic" encoding (not raising Y, but reducing X) to lighten the overall resolution? If so, then please accept my apologies ;)

Didée
anamorphic encoding is intended to increase vertical resolution so that you dont waste resolution on "black bars."
"Or, more precisely, for offering the best compromise when the target display AR is unknown. " no, it's specifically designed to lower resolution "wastage" on widescreen material.

"Where is the sense in wasting bits in additional resolution, introducing some additional artefacts, when you reduce the resolution again on playback anyway?"
I'm not reducing resolution on playback.

think about this:
the actual video is 720 x 480
When resizing for proper aspect ratio, most users reduce vertical resolution (example, resize to 720 x 395)
what anamorphic encodes do, is stretch horizontally, to keep full vertical resolution (880 x 480 for example)
http://gregl.net/videophile/anamorphic.htm

example of the anamorpic difference: http://www.thedigitalbits.com/articles/anamorphic/anamorphic185demo.html

ookzDVD

30th January 2003, 05:06

Originally posted by Nic
Just as something to do, I uploaded a new build with a new DShow filter.

The DShow may still have the same old problems, or it may be working ok. Its hard for me to say. Seems ok though :)

http://nic.dnsalias.com

-Nic

ps
Mine won't have Koepi's oversize fix.

@Nic,

I can confirm that your DS Filter is still have problem while seeking.

Gazza

30th January 2003, 07:28

To all the developers and testers - the latest build is very very nice. I've always stuck with xvid and now there is absolutely no reason on earth to go elsewhere. Many thanks for a truly impressive effort.

Just a question - I'm interested in finding out if anyone still uses convolution3d, filters, what resize method, etc? I'm wondering if using these is actually going to remove quality from what xvid is doing now?

Teegedeck

30th January 2003, 09:31

Well... Every attempt at filtering will make the output look less similar to the original. And XviD compresses very well with little side-effects. So there are IMHO only two reasons that justify filtering:

1) Increase compressiblity: You're not able to put it onto two CDs otherwise or not willing to use more than 1 CD for that movie
2) The original source looks like shite (Tv-capture) so you don't have to do it just for compressibility but also to make it watchable

As -h said, noisefiltering generally helps MPEG4, so theoretically it's a good idea to use as much as is possible without a subjective reduction of quality. Problem is, if you're a cineast, you won't want to soften a superbly looking picture at all. So you have to compare what looks better to you; strongly quantized, unfiltered image; less quantized de-noised image; filtered or unfiltered anamorphous image; or smaller resolution with less quantization. For my personal taste, if I have to filter I prefer MPEG2DEC3's postprocessing with everything except for luminance deringing (too strong softening effect) to get the size down and perhaps fluxsmooth if it's still to large. Smaller res looks better than a picture that's too soft. Also I feel that clean sources may look better if you keep them anamorphous (resized if neccessary - I go for Lanczos) but compressibility has to be above 50%, so it's still a rare occasion... ;)

I guess I'm just repeating stuff that isn't new to anyone here, sorry. To put it short: XviD works pretty well on it's own; I wouldn't use filtering if I don't absolutely have to. Hope you find that yabber a useful in some way.

Aktan

30th January 2003, 10:27

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

30th January 2003, 10:34

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

30th January 2003, 11:21

@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

30th January 2003, 13:25

@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

30th January 2003, 14:37

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

30th January 2003, 14:39

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

iago

30th January 2003, 14:59

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

30th January 2003, 15:15

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

30th January 2003, 20:08

I always use c3d,unfilter and luma

CruNcher

30th January 2003, 20:50

@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

30th January 2003, 21:16

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

30th January 2003, 21:48

@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

30th January 2003, 21:56

@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

30th January 2003, 23:44

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

31st January 2003, 00:05

@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

31st January 2003, 02:17

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

31st January 2003, 02:42

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

31st January 2003, 02:55

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

31st January 2003, 05:24

make sure "use xvid" is checked in ffdshow configuration

kastro68

31st January 2003, 06:12

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

31st January 2003, 08:00

@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

31st January 2003, 11:14

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

31st January 2003, 12:13

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

31st January 2003, 13:05

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

31st January 2003, 14:28

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

31st January 2003, 14:51

"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

31st January 2003, 15:30

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

31st January 2003, 17:37

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

31st January 2003, 20:27

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

31st January 2003, 22:52

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

Space Hopper

31st January 2003, 23:22

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

1st February 2003, 09:06

@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

1st February 2003, 12:42

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

1st February 2003, 13:12

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

1st February 2003, 18:51

@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

1st February 2003, 20:14

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

2nd February 2003, 01:19

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

2nd February 2003, 02:35

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

2nd February 2003, 13:08

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

2nd February 2003, 13:41

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

2nd February 2003, 13:41

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

2nd February 2003, 14:14

@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

2nd February 2003, 14:52

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

2nd February 2003, 22:35

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

3rd February 2003, 03:20

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

3rd February 2003, 05:42

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

3rd February 2003, 06:00

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

3rd February 2003, 08:10

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

3rd February 2003, 12:15

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

3rd February 2003, 15:23

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

Valky

3rd February 2003, 15:35

to Nic: Well I amhappy to hear that. Btw, I have lost your homepage?

That http://nic.dnsalias.com/ on my bookmarks doesn't seem to work anymore?

iago

3rd February 2003, 19:28

Yep, 26012003-1 build and b-frames (3/100/200) 1st Pass output muxed with Ogg audio -> A/V asynch ;). Finally I have had this issue too! ;)

Nic

3rd February 2003, 20:02

@valky et al: My site is down at present, Swede, who runs it, is still on holiday (I think) and it will be back up as soon as he gets back im sure :)

-Nic

Koepi

3rd February 2003, 20:33

I have a proper fixed build on my HD (02022003-1) but i don't have the time to post it now since i need to write this reply...

XviD-02022003-1.exe (409kb)
Changelog:
- Fresh CVS checkout.
- Skal's GMC code.
- Implemented better 2pass fix as suggested by Foxer.

Hrhr :P

You know where to get it!

Regards,
Koepi

iago

3rd February 2003, 20:40

@Koepi,

Hehe, that's really nice, a new binary to play with ;).

Well, after all I don't care much about that A/V synch issue, since you can easily fix it (after a couple of tries at most :D) by adding a delay of 80ms or something to the audio track when muxing (like I did with my above mentioned rip ;)).

regards pal,
iago

Gazza

4th February 2003, 02:41

Thanks Koepi. I have started to test and will post results (probably in the new thread related to this latest build).

Cheers

iago

5th February 2003, 15:12

@Koepi

Hehe, go to the link below and see! You have become pretty famous here! ;)

It's the web site of one of the biggest ISPs in my country:

http://www.e-kolay.net/bilgisayar/kategori.asp?MainID=465&PID=471

Koepi

5th February 2003, 17:24

Originally posted by iago
@Koepi

Hehe, go to the link below and see! You have become pretty famous here! ;)

It's the web site of one of the biggest ISPs in my country:

http://www.e-kolay.net/bilgisayar/kategori.asp?MainID=465&PID=471

hey iago,

cool! but i think it makes it look as if it were my codec - but i just built/compiled it, it's clearly just "koepi's xvid binary" ;)

But thanks for pointing out that link!

Best regards,
serefe

Koepi

EDIT: btw., did you know that my turkish mates call me "atari türk"? ;) Came toi my mind when i read "Koepi'nin"... ;)