XviD-19122002-1

[Koepi]

Hey folks,

since I got plenty mails requesting a newer build (why? To have more useless, buggy bitstreams?) I decided to put up a new build - without testing it for functionality (in fact, the test-run is needing some other 5 hours...)

As usual, ICL7, high optimized, ReferenceDivX' lumi masking code, Foxer's corrected 2pass.c (dealing with vdub1.4.13/delay frames), some additions I forgot, and now the real changelog:

- Fresh CVS checkout.
- More 3Dnow! Extended and XMM optimizations.
- Fixed VLC table size bug according to GomGom's proposal.
- other changes I forgot already...

Enjoy!

Regards
Koepi

[lighty]

Originally posted by Koepi
why? To have more useless, buggy bitstreams

Why not? It is always some kind of surprise waiting for us to blow in our faces. It gives some meaning to my life and make me feel alive... just to have new toy to play with. :p :p :p

[Sirber]

Yehoo! a new build!!! :D I'll test if those 3DNOW opt. give more speed.

Thanks for making this build Koepi :)

[edit]

Encoding at 18-22 FPS on a Athlon 2000+.

[NuclearFusi0n]

a tad faster :)
is there no more "dynamic hpel/qpel" box?

[wing1]

Just when you think it's safe to go into the water.....da duh da duh da duh....:D

something seems to be wrong....how come I am seeing debug infos during encoding using avs2avi? and the result constantly equals to 1/2 of what the actual time that the encoding sayz it is?

A new feature added to the codec ( yippy!!!!) finally post processing flags!!!!!

[Bulletproof]

Yikes when I try to decode a video with this build it shows a partial picture all messed up and green then crashes mplayer, and it even messes up my mouse pointer graphics in windows.

[Teegedeck]

Originally posted by Bulletproof
Yikes when I try to decode a video with this build it shows a partial picture all messed up and green then crashes mplayer, and it even messes up my mouse pointer graphics in windows.

You're only trying to scare us, huh?:p

Right?

[bond]

Originally posted by lighty
It gives some meaning to my life and make me feel alive...;)

"last night koepi saved my life..." :D

[ookzDVD]

Try to encode short Vanilla Sky's Trailer 2:50 minutes clip,
with 2-pass-int, B-frame (3/150/100), with Qpel & Chroma Motion enabled with no problem.

Playback use ffdshow 20021113 build with no problem.

[cabal]

i am always waiting for a new "koepi release" :) what are the 3dnow optimizations in detail ?? i think compiling with intel c7 automatically runs almost perfect on both cpu's ?!? ( according to germann magazin ct' )

greetings cabal

[NuclearFusi0n]

it works fairly well
when decoding with ffdshow, it works fine if i check "use xvid" it has splotchy color if "use xvid" is unchecked.
everything goes to hell if i disable ffdshow, and use the xvid ds filter, but everything works fine in virtualdub.

what does "use xvid" mean in ffdshow? (sorry, i dont want to wade through that monster ffdshow thread)

edit: I LOVE THE SPEED!!!!!!!!!!!!!!!!11 (athlon xp 2000+)

[Koepi]

@cabal:

Nice to see you posting here :)

This is quite off-topic, but who cares. Compilers _can't_ do wonders. Avery Lee has a very nice example up on his virtualdub homepage (http://www.virtualdub.org/docs_compiling) :
Isn't assembly language dead with modern compilers?

void add_pairs(float *dst, const float *src, int count) {
if (count) {
do {
float x = *src++;
float y = *src++;

*dst++ = x+y;
} while(--count);
}
}

F:\test>cl /c /O2ax /G6s fpu.cpp && dumpbin /disasm fpu.obj
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

fpu.cpp
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.


Dump of file fpu.obj

File Type: COFF OBJECT

?add_pairs@@YAXPAMPBMH@Z (void __cdecl add_pairs(float *,float const *,int)):
00000000: 8B 54 24 0C mov edx,dword ptr [esp+0Ch]
00000004: 85 D2 test edx,edx
00000006: 74 1F je 00000027
00000008: 8B 44 24 08 mov eax,dword ptr [esp+8]
0000000C: 8B 4C 24 04 mov ecx,dword ptr [esp+4]
00000010: D9 00 fld dword ptr [eax]
00000012: 83 C0 04 add eax,4
00000015: D9 00 fld dword ptr [eax]
00000017: 83 C0 04 add eax,4
0000001A: D8 C1 fadd st,st(1)
0000001C: 83 C1 04 add ecx,4
0000001F: 4A dec edx
00000020: D9 59 FC fstp dword ptr [ecx-4]
00000023: DD D8 fstp st(0)
00000025: 75 E9 jne 00000010
00000027: C3 ret
00000028: 90 nop
00000029: 90 nop
0000002A: 90 nop
0000002B: 90 nop
0000002C: 90 nop
0000002D: 90 nop
0000002E: 90 nop
0000002F: 90 nop


What was that again?

As you can see, handmade optimizations aren't beatable by a machine.

ICL can't produce 3dnow/3dnow extended code.

We now have a mem_transfer function in 3dnow extended. I didn't look into the code, but I believe it's faster than the pure mmx'ed function. in several other places some functions which were only mmx'ed (so: no xmm or sse/2) have now a 3dne counterpart, which should increase performance on athlons/durons a bit.

(Yet the most time critical function still has no 3dne version, according to syskin interpolate16x16 is mostly used...).

I hope this helps you understanding things a bit better.

Best regards
Koepi

[cabal]

yes , thx for the info :)


greetings cabal

[shirka]

I tried to encode a short passage of Star wars episode 2, but crash with 2nd pass. I attached some info files.
My system : Athlon XP 1800+, 256 DDR Ram, Windows XP Pro, Virtualdub 1.4.13

[Sirber]

@shirka

Look into the forum, there is 2 thread (is there a "h"?) about crash with VDub. No soluce yet. I'm using DVD2AVI by OGO and work #1. I use AutoDub for to get the right ratio (autodub crash on my computer also).

[MaTTeR]

Still getting the crashes here on 1st and 2nd passes too.

[JasonFly]

Is it good to use insta build in a more conventional way without usiong b-frame nor qpel?

I mean i m not interested in bframes yet but i see these optimizations for athlon and I'm wondering if the latest build are better than 04/10/2002 in this sector.

Thanks you for your work Koepi

[HarryM]

DS filter in last binaries is TOTALLY broken. And I dont know why...:mad:
Build 19122002 is most problematic!

Q-pel ON, B-frames = 3, chroma ME = ON, frame size 544x224 pixels

http://sgfan.ic.cz/download/544x224.jpg

Q-pel ON, B-frames = 3, chroma ME = ON, frame size 576x320 pixels

http://sgfan.ic.cz/download/576x320.jpg



I use Win98SE and ZoomPlayer 2.90 for playing.

When I playing AVI file (generally I use OGM, AVI I use for movies with AC3 audio), I see this "BROKEN B-FRAME, MISING REF FRAME". Ffdshow (without 'use xvid.dll' feature'!) playing this AVI correct. Above OGM's too.

[Bulletproof]

Originally posted by Teegedeck
You're only trying to scare us, huh?:p

Right?

Nope, i'm serious, it crashes my mplayer and really shows messed up video.

[cult]

found a "bug" (I think)-when trying to compress credits with more than 25/25 quant,you get a crash.Otherwise it works ok.SAme happens with insta build 20/12/02
using celeron@1ghz,w2k

[HarryM]

The newest build is really faster :), but the 'DS filter problem' hinder in regular use of XviD (only for my? You don't have problem with native DS filter?) :(

IMHO:
It is only my impression or q-pel feature is from build to build much and much bluring???

[fraatz]

hi!
i don't have a problem with the build in any way. dsahow is working flawlessly,too.
my only impression on qpel is that using them with bframes yields to some flickering macroblocks (luminance changes rapidly) on unicolor objects. but it produces a *very* sharp pcture here with hvsgood matrix and bilinear resize!! would be nice if someone could confirm the bug ;)
-f

[wing1]

Quality, playback and speed wise, the new build has no problem at my end. The only problem I am seeing so far is using the codec with avs2avi CL compressor. I am seeing debug information scrolling inside the dos window along with the normal program output; Furthermore, avs2avi reported 2x the encoding frame numbers that it had actually compressed...

[Sgt_Strider]

well I know I'll probably get flame for this but this build isn't mpeg4 iso compliant right? I encoded star wars episode 2 with b-frames, q-pel, and chroma. When I attempt to use MP4UI to mux the video and music file, it said not mpeg4 compatible...

[Sirber]

@Sgt_Strider

Why don't you use OggMux? It's always compatible :)

[celeron]

@HarryM
Yap you are rigth there is a DS filter problem, but only whit movies encoded whit old versions of xvid.
But the DS filter in decoding the sample made by this version works very good.

@Keopi
Great speed increse, 17/19 fps in a duron morgan 1.2ghz.:D

Ps: sorry bad english

[Gaia]

Originally posted by Bulletproof
Nope, i'm serious, it crashes my mplayer and really shows messed up video.

You are right, this happens to mee too. Video is totally messed up and it messes up the mouse pointer too. There's something wrong with this build. Decoder works fine with old movies too. I am using Duron 950.

[Koepi]

Originally posted by Sgt_Strider
well I know I'll probably get flame for this but this build isn't mpeg4 iso compliant right? I encoded star wars episode 2 with b-frames, q-pel, and chroma. When I attempt to use MP4UI to mux the video and music file, it said not mpeg4 compatible...

It should be standards compliant - dunno what went wrong on your side. Maybe you used one of the non-standard features like modulated quantization? If you use bframes, make sure to have "dx50 bvop compat." checked, don't use packed bitstream.

Else switch to stable tree, those features definatly comply with mpeg4 standards.

Koepi

[JimiK]

@fraatz
I can confirm this problem (at least I think it's the same you're referring to). In my opinion it has nothing to do with QPel, but with Bframes (what is sad, because I like Bframes much better). On unicolor planes it looks like there are small things, rushing over the plane, right? I viewed it in VDub and like you said, it's macroblocks that get lighter and darker. The problem is drastically reduced when you prefilter your picture with Conv3d. I also noticed an increase of this problem with the newer builds. Oldest build I tested was Koepi-1411.
Now I have another question about Bframes and Bf-offset. The Bf-quant is calculated with the average quant from previous and next P-quant. Is this a "maximum" quant or should this quant always be used. In debugview on 2nd-pass I had the following output: 3 Bframes max, Ratio 150%, P2-B3-B2-B3-P2. That's strange enough because I think there should not be a Bframe with quant 2. Now when I raise the offset to 400, nothing changes. Nobody else wrote about this, so I think it's correct. All I want to know, why is this so?
Best regards,
JimiK

[Sgt_Strider]

Originally posted by Koepi
It should be standards compliant - dunno what went wrong on your side. Maybe you used one of the non-standard features like modulated quantization? If you use bframes, make sure to have "dx50 bvop compat." checked, don't use packed bitstream.

Else switch to stable tree, those features definatly comply with mpeg4 standards.

Koepi

For quantization type, I use mpeg on the first and 2nd pass. Can you tell me which feature is possibly not mp4 compliant? That will really help me find out what's my problem.

[HarryM]

I am mad from last xvid builds. :mad:

Do exist any users, using win98SE and with FULLY FUNCTIONAL DS filter (xvid.ax)?

I test 19122002 build at another PC's (PC's of my friends) with win98SE and xvid.ax is NOWHERE O.K.

[Trahald]

(why? To have more useless, buggy bitstreams?)

hey.. you guys know your taking chances.. hehe... the stable release from april is still available for the faint of heart ;)

i havent used xvids dshow in ages.. ive been happy with ffdshows output with the streams i get with the unstable builds

[fraatz]

@HarryM: "I am mad from last xvid builds. " Then use the STABLE TREE!!
@JimiK : Yes. That's exactly what I mean. Anyone of the developers know about the problem? I saw a post of Syskin who said it's a decoding problem, but it's definately not! I can mail anyone interested a 760 kb clip which shows the problem quite well..

[sysKin]

Originally posted by JimiK
[B]Now I have another question about Bframes and Bf-offset. The Bf-quant is calculated with the average quant from previous and next P-quant. Is this a "maximum" quant or should this quant always be used. In debugview on 2nd-pass I had the following output: 3 Bframes max, Ratio 150%, P2-B3-B2-B3-P2. That's strange enough because I think there should not be a Bframe with quant 2. Now when I raise the offset to 400, nothing changes. Nobody else wrote about this, so I think it's correct. All I want to know, why is this so?
Codec actually asks the core for a specified quant, and prints this quant to debug view - but it doesn't matter. This quant value will be ignored for b-frames.
It would be nice if xvid.dll didn't print this value at all. It should also be ignored in the statistics...
Yes. That's exactly what I mean. Anyone of the developers know about the problem? I saw a post of Syskin who said it's a decoding problem, but it's definately not! I can mail anyone interested a 760 kb clip which shows the problem quite well..That's true, it's not a decoding problem. It might be an mpeg-4 artifact simply caused by compression (related to high quantizer and the way b-frames are compressed), but I think this is a bug.
I don't know what causes it...

Radek

[Didée]

The problem of "flickering blocks" was already a topic some weeks ago, in this pretty long thread (http://forum.doom9.org/showthread.php?s=&threadid=38074) - somewhat later in the thread, from page 6 on, or so.
The problem was described and confirmed, but alas, nobody has come up with a solution yet.
To note it once again: at least on my side, this problem only occured since the core was able to perform qpel together with b-frames (but it's not caused by the use of qpel).
By that time, some little bug seems to have introduced. The former builds, that could not use qpel along with b-frames, didn't have this problem.
So is "bleeding-edge-technology" ;)

... and you should appreciate the work of the XviD developpers each and every time you use XviD.
It is awesome work.

[edit]
Oops - hi Syskin. Seems I was typing very slowly ...

[HarryM]

@fraantz:
This problem of xvid.ax, not encoder (xvid.dll).
Encoder is O.K.
When I use vdubmod (e.g.) for editing and triming of video, all is great O.K. No problem.
But problem is, if I use newest builds for DECODING (via xvid.ax). Not only for my newest encoded videos (encoded by unstable builds), but this is problematic for my any months(!) old regular xvid movies (full DivX4 compatible) too.

In last weeks is in xvid.ax something, what make impossible decoding of XviD into OVERLAY correct.
When I forbid 'YUV transformation' in 'Video Renderer', video is O.K. But this is'nt solution!

Any errors in color conversion at xvid.ax possible?

[BoNz1]

Ok, I have searched the forums a lot about this but I can't get xvid to run as fast as I would like. Now I am not complaining or anything but I have noticed that other people have posted that they can get like 15-17fps, I can only get maybe 8-9fps on a p4 1.6ghz w/ 512MB DDR. I used dvd2avi 1.76 to make a .dv2 file. Then I used avisynth2.5 to save it as a avs script using a lanczos resize to 640 by 256. I used the mpeg2dec3 as well as vdubmod set to fast recompress. The xvid settings I used were as follows motion search precision 6, quantization mpeg, 4c XVID, Max I frame 300, Min I frame 1, lumi masking on, chroma motion on, 1/4 pixel on, B-frames 3 150 100, DX50 B-VOP Compatibility on, Min I quantizer 2, Max I quantizer 31, Min P quantizer 2, Max P quantizer 31, I-frame boost % 20, Below I-frame distance 10, I-frame reduction % 30, High 0, Low 0, use alt cc off, bitrate playback delay 250, Payback with bias on. Now I realize that the settings that I used are going to make it quite slow but surely there must be another way that I can make it go a bit more faster, I am encoding LOTR it is going to take me 8hrs to do each pass. If anybody has any suggestions on how to speed this process up a little more I would be very grateful, thanks.:) Oh and BTW I am using the latest build Koepi's 19122002-1.

[HarryM]

Yes.
I have right. Bug in xvid.ax.

Problem is exactly between 'xvid.ax' and 'video renderer' in Win98SE.

I keep in memory, that BSplayer use your (own) video renderer - bsrendv.dll.
I test BSplayer for playing and... all is O.K.!

I laborate next. In ZoomPlayer I enable 'Force overlay mixer'. Now I have

'xvid.ax' > 'overlay mixer' > 'video renderer'.

Any videos is O.K. now, but not all :( Videos with height mod32 are defected at playing (green-screen, see my older post and linked jpgs!!! ). Videos with height mod16 are O.K.
Interest, generally is mod32 more compatible than mod16, but mod32 is defected, mod16 is O.K...:rolleyes:

I laborate next. I forced DirectVobSub, I set it 'Load always' feature enable...

'xvid.ax' > 'dvobsub.ax' > 'overlay mixer' > 'video renderer'

All videos are O.K. at playing now!!!


I think, that this bug is any stupidity in xvid.ax
Can anyone correct this bug, please???
Windows XP use another 'video renderer' as Windows 98(SE). I don't test on WinXP (maybe without problems), I use Win98SE only. Many peoples use Windows98SE for now (20-30%?).

[cjv]

@HarryM:

Relax, man I don't understand why you are so mad that xvid.ax does not work. Yes, there may be a bug and I'm sure this "stupidity" :confused: will eventually fixed. This is a developer build...and I doubt getting the decoder fixed is the highest priority right now, seeing as most people use ffdshow anyways.

You say that the problem is only with Win98 and xvid.ax. Upgrade to Win2k/XP/Linux or try using ffdshow and see if the problem persists.

cjv

[MoonWalker]

Originally posted by sysKin
It would be nice if xvid.dll didn't print this value at all. It should also be ignored in the statistics...

You mean we shouldn't take the quant's of b-frames for statistics(eg avg quant)??.. Is there any other way to calculate the "true" quant of the b-frame?

Thanks,
MoonWalker

[HarryM]

I study 2-pass (and debugview list) at b-frames. P-frames are always smaller than at quant=2 (it is normal, right), but B-frames are generally bigger than at quant=2...

E.g.:

...
1478 P-frame stats1=11547 actual=8745
1479 B-frame stats1=1478 actual=1508 (actual b-frame is bigger than stats1?)
1480 B-frame stats1=1254 actual=1358 (actual b-frame is bigger than stats1?)
1481 P-frame stats1=8794 actual=5478
...

It is normal???

[CruNcher]

@ all
ok the newest xvid.ax is badly damaged everybody knows that know and ffdshow has also problems with anamorphic content so the best is you all use XviD-03122002-1.exe "xvid.ax" it is stable and everything is fine for me :) it will be fixed im sure but it takes time

[NuclearFusi0n]

I'm still suffering from the problem shown here (http://forum.doom9.org/showthread.php?s=&threadid=40714).

Settings for XviD ()
Mode: 2 Pass - 2nd pass Int.
Dummy 2nd Pass: OFF
Desired Size: 1064099KB
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: OFF
Chroma Motion: ON
Max B-frames: 2
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,

Desired Size: 1064099KB
1st pass: 791,116 KB
2nd pass: 790,382 KB

I also have decoding problems. The video looks OK when loaded in VirtualDubMod, but when i try to decode with ffdshow + "Use XviD", i cant decode it. THe program i'm using just goes *poof* and closes. Zoom Player, Windows Media Player 6.4, they both just close themselves. When i uncheck "Use XviD" the programs will open and start playing, but everything looks pretty bad (the video looks quite a bit cleaner in virtualdub) when i disable ffdshow, everything goes to hell.

The video looks pretty good with QPEL only, no bframes, and it matches my desired size to a few KB.

edit: i'll be glad to cut a clip out and upload it to anybody that needs to reproduce the issue.

[cjv]

If you look at your first pass vs. second pass size, you will see that they are almost the same. This means you are maxing out the bitrate when you use b-frames. You say that it comes out to the right size when you don't use b-frames. Thus, there is nothing wrong with XviD. You could try a larger resolution, but I would personally just burn the encode withouth b-frames and be done with it.

cjv

[NuclearFusi0n]

Originally posted by cjv
If you look at your first pass vs. second pass size, you will see that they are almost the same. This means you are maxing out the bitrate when you use b-frames. You say that it comes out to the right size when you don't use b-frames. Thus, there is nothing wrong with XviD. You could try a larger resolution, but I would personally just burn the encode withouth b-frames and be done with it.

cjv
The quality leaves quite a bit to be desired though. :(

[Trahald]

finished first pass with new build.. b-frames and chroma motion only.. looks great.. pass 2 tonite

[HarryM]

Originally posted by NuclearFusi0n
I'm still suffering from the problem shown here (http://forum.doom9.org/showthread.php?s=&threadid=40714).

I also have decoding problems. The video looks OK when loaded in VirtualDubMod, but when i try to decode with ffdshow + "Use XviD", i cant decode it. THe program i'm using just goes *poof* and closes. Zoom Player, Windows Media Player 6.4, they both just close themselves. When i uncheck "Use XviD" the programs will open and start playing, but everything looks pretty bad (the video looks quite a bit cleaner in virtualdub) when i disable ffdshow, everything goes to hell.

The video looks pretty good with QPEL only, no bframes, and it matches my desired size to a few KB.

edit: i'll be glad to cut a clip out and upload it to anybody that needs to reproduce the issue.

I have same experiences too (build 19122002). Exactly. I can't use ffdshow + 'use Xvid.dll for decoding' feature. Windows totally freezes :(
Actually usable for me is only pure ffdshow. But quality of q-pelled videos with pure ffdshow isn't 100% :(

[Koepi]

Stop whining!

We're tracking down the playback issues, I hope this afternoon (after I return from work) I can compile something new.

And now _finally_ get the point - 2nd pass can't be bigger than 1st pass, it's not meant to be that way. If you saturate the codec, use different settings. E.g. set bframes to: 3 / 100 / 100 instead of the default values.

Or set bframes to -1.

That'll all increase quality - and if the quality still doesn't satisfy you, use the stable build which is called that way because it isn't "code in progress", which tends to be buggy. Reminds me that I wrote that initially, that I note that on my site (UNSTABLE),...

You know what you get, why do you always forget about that?

Regards
Koepi

[Teegedeck]

Well, I don't know what's all the compainin' about, either.

Of course we should use the unstable build for experimenting only - but when I compare the results I get with all the unstable features - I just couldn't get near that with the stable build at the low bitrates I'm currently using. Looks great.

Just remember that this thing doesn't come with a warranty and enjoy what already has been accomplished at this point.

[gino25]

Still Hinted me doesn' t work in this version. Do you know when (and if) it will be reactived with no bugs?

[Northern Strider]

When using this newest build with credits encoding at fixed quant 20, vdubmod crashes during credits encoding at 1st pass

[sysKin]

Originally posted by MoonWalker
You mean we shouldn't take the quant's of b-frames for statistics(eg avg quant)?? Not the quant which is printed in debug string - this quant is just something that bitrate control would like to see, but has no control of, so it's not real.Is there any other way to calculate the "true" quant of the b-frame? Sure :) just find both next and previous P-frame (or I if it's closer) and apply the quant formula... No other way...

Radek

[Koke]

I`m not complaining about this release.
No way.
Just want to report it does not work
with it`s decoder and with ffdshow too.
It is all "greenish".
I like it, though :)).

[cult]

@ Northern Strider
already mentioned it>Go with desired % rate for credits.It works this way

[Snakeisthestuff]

with the risk to make you angry Koepi, i have to make an bug report:

i had to do an chroma shift(-2) on an anime iam currently encoding,
so i tried CNR and Flaxens VHS Filter with VirtualDub 1.4.13, they both work fine with, divx 502 and divx311, but here the strange thing, if i use xvid, it looks like the filter is totally ignored!
no chroma shifting is done! i tried the following Xvid builds from Koepi:
Xvid-04092002
Xvid-04102002(The Stable Build)
Xvid-09122002
Xvid-19122002
with all builds the same result, the filter is ignored! even with the stable version of xvid. i dont know if this prob was reported before, but i think its important so i posted it.
here some infos, that are maybe needed:
AVS-script used:
#####################################################################
LoadPlugin("D:\avisynth\mpeg2dec.dll")
LoadPlugin("D:\avisynth\mpeg2dec3.dll")
LoadPlugin("D:\avisynth\IVTC.dll")
LoadPlugin("D:\avisynth\decomb.dll")
LoadPlugin("E:\SONSTI~1\RIPP-T~1\AUTOMA~1\AUTODUB\SOFTS\AVSFILE\LANCZOS3.DLL")
mpeg2source("F:\Mononoke hime\mononoke.d2v")


ivtc(44,11,95)
FieldDeinterlace(chroma=true)
crop(24,22,672,434)
Lanczos3Resize(656,352)
#####################################################################
Xvid setting:
after every install of an new build for testing i hit load defaults.
1-pass CBR
4000 kbit/s
Motion Search Precision - 6
Quant Type: H.262
min i-fram quant: 2
max i-fram quant: 6
min p-fram quant: 2
max p-fram quant: 6
all the other settings unchanged from default settings.
no special features like bframes, or qpel etc... were used.
#####################################################################
VirtualDub 1_4_13 was used.
2 filters:
TextSub 2.22
Flaxens VHS Filter
(all options without chroma shifting unchecked, horizontal: 2, Neg. checked, Shift Chroma I and Shift Chroma Q checked.)

for a second test run chroma noise reduction 1.11 was used.
(chroma shift left -2)
Avisynth 2.07 + DVD2AVI 1.76 for frame-serving.
machine for encoding:
Win98 SE, CPU: 1600 XP
#####################################################################

i hope this helps you for finding the problem...

[iago]

I have just finished a pretty tough encode with this build.

U-Turn (~2hr) 1CD with 0.001q Ogg
h263/h263 and only b-frames 3/100/200

-----------------------------------------------
LoadPlugin("D:\FILTERS-YV12\mpeg2dec3.dll")
LoadPlugin("D:\FILTERS-YV12\UnDot.dll")
LoadPlugin("D:\FILTERS-YV12\UnFilter.dll")
LoadPlugin("D:\FILTERS-YV12\FluxSmooth-2.5.dll")
mpeg2source("D:\DVD_VIDEO\VIDEO_TS\U-TURN.d2v")
crop(16,10,-16,-16)
LumaFilter(-2)
FluxSmooth(10,10)
BicubicResize(512,288,0.333,0.333)
UnDot()
UnFilter(5,5)
Limiter()
------------------------------------------------

The quality is pleasing to my eyes and very acceptable considering the difficulty of putting this movie on 1CD and I don't see anything "greenish" or any weird problems when decoding with ffdshow/libavcodec.

regards,
iago

[Emp3r0r]

@iago: I appreciate you posting your settings for that encode. I was wondering if you could give an explination of the filters you used, and why. I assume some people may not have time to keep pace with the avisynth forum so a brief description of what, why and maybe how it improves the overall quality of compressing a difficult source with XviD. For example:

LumaFilter : I use this filter to darken the already dark areas of the video to combat the common macroblocking found in these areas.

Thanks in advance, Emp

[ookzDVD]

I did new test last night with Stuart Little 2, 77 minutes long movie.
with 2-pass-int, B-frame 3/150/100, QPel & Chroma motion enabled.
The first pass was fail.

Switch back to 09122002 build.

Ps. Using Win2k, Sp3, Athlon XP+ 1800

[Sgt_Strider]

Originally posted by ookzDVD
I did new test last night with Stuart Little 2, 77 minutes long movie.
with 2-pass-int, B-frame 3/150/100, QPel & Chroma motion enabled.
The first pass was fail.

Switch back to 09122002 build.

Using the same settings above, the video that I made looked great. Not sure if it look as good as w/o b-frames but I really can't tell which one is which. The only bad thing is that it took some 13 hours to encode the movie.

[Koepi]

Originally posted by Emp3r0r
@iago: I appreciate you posting your settings for that encode. I was wondering if you could give an explination of the filters you used,[...]
Thanks in advance, Emp

I'd appreciate if this thread wouldn't be abused for descriptions of avisynth-scripts.

Empe, we have plenty discussions about those scripts over at the avisynth forum, why don't you use the search function and enter each filter which you don't know much about? The results are to find in 5 minutes - as long as it takes iago to give a brief description ("smoothers a bit. sharpens a bit. darkens a bit." - quite useless descriptions btw %) ).

Be nice and save other people from the work which you are too lazy to do for yourself - you should know better than that!

Koepi

[Nic]

(just thought id mention)
New version up on my site: http://nic.dnsalias.com

The DShow now shouldnt be outputting garbage...

Cheers,
-Nic

[celeron]

Fixed

see below!

[Nic]

Doh, cheers for that celeron, ill go fix that now :)

-Nic

[iago]

Hello again,

Well, to be honest, that encode I mentioned above is of course far from being perfect due to "high average quantizers" and the real hard-to-compress nature of the source, and it really needs some post-processing and noise with ffdshow; but what I wanted to mention was that the quality problem is NOT due to codec or that specific build producing garbage or greenish/shit frames, etc. Though, I still find going with only "b-frames" (when it's necessary) and "chroma motion" much safer than using qpel.

Also, I use ffdshow (10/10) libavcodec (that is without "Use XviD") to decode my XviD encodes and I have no problems with that.

Regarding what each avisynth filter does, I agree with Koepi that it would be much better and more useful (than my explanations here) to refer to the avisynth forum.

regards,
iago

[CruNcher]

strange have no problems with b-frames decoding but problems with red color decoding causeing a staircase effect previous decoder builds do not have this problem also ffdshow doesn't could you check that please thx for this new build

also it looks like that constant quantization doesn't work in this build

[Nic]

If you've downloaded the old build, re-download it, as it has the new filter that decodes b-frames without that error. Thanks again celeron.

Gotta run,
-Nic

ps
Just read cruncher's post, hmmm, not getting that, but I did get the bframe error...you could try downloading again & doing a computer restart before installing & see if that helps ??

[iago]

@Nic,

Thanks for the new build man! :) Btw, as usual, I have the problem of downloading the most recent build from your site. Each time I download, what I get is the build dated 25/11! :confused:

regards,
iago

[Swede]

Originally posted by iago
Each time I download, what I get is the build dated 25/11! :confused: Strange! I've got his site here and (just checked) there are no files at all with that date.?. Can you pls. try to access his files through http://leffe.dnsalias.com/~nic/

[iago]

@Swede

Thank you very much for your help. It's OK now :). I will use this address from now on to reach and to download from Nic's site.

best regards,
iago

[Swede]

Strange... I'm glad it helped you but you do in fact get to the same dir... Well, at least it works for you :D

[celeron]

@Nic
All good now thks for the new build. :)
And no need to thks we are here for that, to test ;)

[CruNcher]

@ Nic
Compared your Builds speed against Koepis Build you are not useing Refdivx Lumamasking code aren't you ?

[Snakeisthestuff]

some post's before i wrote an Bug report depending on chroma shifting, after getting no reaction on it, i want to know if this is an prob that only occurs on my machine, or if someone else has experienced something like this too?

hoping for some answers....

[Nic]

Its just a dev3 build. I dont know whether refdivx's code made it to the cvs yet. Due to cvs changes & my pre-christmas workload I kinda loss track of precise changes to the cvs. I can look into it more this christmas... I just wanted to make an update today so the build on my site is at least relevant & the dshow working :)

Cheers,
-Nic

[Koepi]

referencedivx' lumi masking code isn't in cvs yet.

snakeisthestuff: please read forum rule 12 again - and to answer your question - i don't experience that problem here.

Regards
Koepi

[kilg0r3]

This is just an impression, and, i am currently not able to to make screenshots in ffdshow to give you examples. yet i have got the impression that the above mentioned stepping effect still persists and is also present in purely blue frames.

i suspect that this is probabely related to a problem mentioned by matter, which he relates to yv12 color space (avisynth forum; fluxsmooth thread). this would mean however that we are dealing with an _en_coding problem rather than a decoding problem.

cheers to everyone

[MaTTeR]

kilg0r3,

Your correct, the color stepping problem is definitely not related to decoding at all. Unfortunately, I've yet to find any MPEG4 codec that doesn't display this problem during the encode. I have confirmed the artifact is _much_ more exagerated in the YV12 color space compared to YUY2. FWIW, linear curve compression in XviD seems to make the artifact more obvious as well; so I stick with my (Acaila's) 20hi/20low bitrate setting for now.

Bach mentioned that the artifact could be caused by the codec seeing the frame with the "Image Quality Priority" set too low. Can one of the developers confirm this? I wonder if we could compensate for this with curve compression some how?

I'll attach this JPEG file showing the artifact. I used SansGrip's BlockBuster filter with the "show" parameter to give you a better idea of whats happening. Notice all the rings and contours?
Edit- The attached image is not filtered at all, only resized in AVS; clip captured in Vdub.

[wing1]

something interesting regarding both koepi's and nic's builds. There is no I-frame(keyframe) reported. Quality is good and so are the speed, but no keyframe...at least I can't see it at all.

[cjv]

On the first page of this thread, some people (MaTTeR...etc) were experiencing "crashing" on first/second pass. By "crashing", do you mean VDub crashed, or do you mean your entire system crashed?

The latest XviD(Nic, Koepi)/CVS builds are unuseable on my Athlon Tbird 1400. I get BSODs within minutes under both XP SP1 and Win2k SP3.

I tried unchecking 3dnow optimizations, but the crashes still occur. I've tried both VDub and avs2avi. This is really weird because everything works flawlessly on a P4 1.4. You would think if it's an invalid opcode, it wouldn't cause a BSOD on NT especially running with Guest privs. Mabye I can trap this with MSVC debugger?
Any suggestions?

cjv

[MaTTeR]

Originally posted by cjv
By "crashing", do you mean VDub crashed, or do you mean your entire system crashed? My crashes mostly came during the first pass of encoding and ony came when encoding to YV12, not YUY2. By crashes I mean Vdub would either throw an exception at me or would just vanish, never had a BSOD on Win2k.

[Pasqui]

@MaTTer
I experience the same problem as yours. During first pass, VD simply vanishes. I haven't been able to see so far if it was due to AVS 2.5 alpha 17/12/02 or to the new ASM optimized code submitted by Isibaar (I own an old Athlon 500MHz).

Pasqui.

[wotef]

hi, i'm unable to randomly seek/jump to frames when using nic's build when using b-frames - no b-frames is OK

ffdshow also borks for me unless "use xvid" is unchecked - anyone else confirm?

[HarryM]

@Nic:

Great! Your newest DS filter (23122002) is GREAT! It is functional... :cool:

Only ONE thing... Your DS filter sabotage DirectVobSub filter. I don't see subtitles. :mad:

OGM or AVI..., same result = no subtitles seeing. I use Zoomplayer, Win98 SE, XviD video is b-frames=3, q-pel = ON.

DirectVobSub is active, but don't rendere subtitles. If I use ffdshow or older xvid.ax, all is O.K.

[iago]

@wotef

I can confirm the problem you mention about seeking with b-frame encodes.

regards,
iago

[NuclearFusi0n]

@wotef
What exactly happens to you when "use xvid" is checked? For me, the program i'm using to play (Zoom Player, or WMP 6.4) just closes itself

[wotef]

"borked" = just closes itself, insta-crash'n'burn!

[HarryM]

Sabotaging DVobSub and seeking problem have the same cause (I think).

I registered one problem too.

Red areas decoding problem

When I study any red areas in videos, I see shaked (assorted) little bands instead compact areas.

[Koepi]

People, I asked you hundred times, this is the last time before starting a big striking-Xmas-special-session.

YOU KNOW THAT YOU DOWNLOADED UNTESTED BETA CODE.

Thanks for the reports, but now coming with hard feelings and bad emotions is WAY too much from you (XviD sabotage damn subtitle filters? get a life man!).

All of you who are complaining in that very bad way (almost 75% of you that means) should go back toi stable tree. Not much to whine around, and outstanding quality. No danger, no risk, no fun.

...and MUCH less work for us as you DO complain in a unpleasant way that your used UNSTABLE DEVELOPER BINARY produced something which you didn't expect - THINK, THINK, THINK my mates, use your brain, i can't tell this as every answer here! Keep that in mind. I have to seriously consider to not distribute any developer binary anymore, since you simply don't understand it. But it's sooooo easy?

If you would PLEASE move over and use nice words for SERIOUS bug reports ("your fucking xvid crap crashed. i never use that *peep* anymore, i go to DivX , it's faster" is NO proper bug report) it would be very much appreciated.

In that sense,

merry Xmas

Koepi

[HarryM]

@Koepi:

My knowledge of english language isn't big. From time to time I use words, which exactly don't express what I want to say. Maybe somebody offended... :( , I know.

I don't have this diplomatic power (understandably) as in my native language.

Programming of code isn't simple, I know. Debugging is even more complicated. I don't devalvate work of XviD makers. And I don't migrate to DivX... :D

[Nic]

Thanks for the feedback anyhow, im going to go look into the crashing now...

Cheers,
-Nic

[NuclearFusi0n]

perhaps we should have a standard form for bug reports? It will be a little detailed and might help you guys out! :)

-Fusi0n

[Koepi]

@Nic,

I think the credits handling stuff is broken. I dn't know if the latest changes in vfw/codec.c or 2pass.c are responsible, i think it's the later one.

Good luck with that! :) (I messaged to foxer already but he seems to sleep or just be away)

Best regards
Koepi

[unplugged]

I'm experiencing Vdub crashes too, but only in credits zone.
I haven't red the whole post (!), what I can say is that the problem is however not related with credits (by test), but with high (I have used 31) quantizers, maybe in combo with B-Frames...
(mine are: BF=3 factor=125% offset=50%).

(Athlon XP 2100+)

[fraatz]

Hey ppl.
Remember what happened to Nandub?
Nando gave up working on it , surely somehow caused by all the users bitching around little bugs.
seems to me like all the users want the newest features as fast as possible whithout accepting the possibillity of bugs. guys - this is done in SPARE TIME!! Think about that. If you are not satisfied - look into the sources and bugfix them by yourself. If you can't do that - learn it. If you don't want that - be satisfied with what you get (for free, btw).

Btw: Happy Christmas and a happy new year!! ;) :D

Frank

[unplugged]

Originally posted by fraatz
Hey ppl.
Remember what happened to Nandub?
Nando gave up working on it , surely somehow caused by all the users bitching around little bugs.
seems to me like all the users want the newest features as fast as possible whithout accepting the possibillity of bugs. guys - this is done in SPARE TIME!! Think about that. If you are not satisfied - look into the sources and bugfix them by yourself. If you can't do that - learn it. If you don't want that - be satisfied with what you get (for free, btw).

Btw: Happy Christmas and a happy new year!! ;) :D

Frank
Who are you point to?

I'm only signaling the problem where I (hope) to have seen it. (high quant. encoding with BF)
I think our tone is pretty calm, we aren't expecting and aren't pushing nobody.

?

[Nic]

My computer just kinda broke on me & so I didnt get chance to debug...grrr waste of a day.
(in the end I took out my capture cards & one of my sound cards...and now all is better...v. strange though)

-Nic

[BoNz1]

First of all I would like to congradulate everyone on the xvid team for the excellent codec that they have made. I think I speak for many when I say that I am very appreciative of the hard work you guys do providing us all with a great free and open source video codec. I have tested Keopi's new build 19122002-1 and indeed it does crash when encoding the credits at a desired percentage in my case 35%. So, I switched back to an older build and no more crashes. Then yesterday, I installed Nic's new build and encoded the same movie over again and there were no more crashes using exactly the same settings. Hopefully, this helps to isolate the problem. My settings were defaults with chroma motion, 1/4 pixel, and luma masking on. And b-frames at 3, 150, 100. Aiming for a size of 1506304Kbytes. Somepeople have also reported a problem with xvid.ax not decoding b-frames, it does seem to skip them every once and a while from what I can see, but not that often. As for seeking problems with b-frames, I am getting that too but it does seek it just takes a lot longer than one might think it would. Thank you again to everyone and Merry Christmas! :)

[Snakeisthestuff]

@Koepi
i read forum rule 12 again, sorry if it was annoying but after one day nobody does intend to do a reply or something and the forum was on another site, but i wanted to make sure you dont overread my bug-report, cause it is no Dev-Build bug, its an generous Xvid-Bug from version 04092002 -> 19122002. so please forgive me if i did something wrong, cause i respect you and your work here.

merry christmas to all :)

[Koepi]

YES, it's Christmas, and I have a present for all of you:

XviD-24122002-1:
- Christmas edition ;)
- RefDivX' HVS based lumi masking code (a bit slow though).
- Including Nic's latest standalone decoder (23122002).

Hopefully this fixes some of the issues reported here (most hopefully the credits-crashing bug). It's a plain CVS checkout with only refdivx' lumi masking code added, replacing two test-files of syskin (code which should be in CVS now as the changelog mentions it - should be cleaner that way and might have caused those issues). I added another small switch to my compiler options which shouldn't break anything but might give a homeopathic speed-up ;)

HO HO HO!

Koepi

[Selur]

HAR HAR that's christmas how I like it!
Thx!!

[Mango Madness]

Tis the best kind of present! You da man Koepi. I just started encoding First Contact on a 1.3ghz duron (133/133) PC133 256meg and i'm seeing about a 1-2 frame increase in speed which is a large percentage considering i only do about 8fps average.

[Bulletproof]

Ok, there seems to be a problem somewhere. I seem to be getting chroma stairstepping with this version, however I'm not sure whether it's from the decoder or encoder. It seems like some colors just bleed out in lines from objects and you see alot of stairstepping artifacts on curved objects. I'm pretty sure I didn't see this with the build before the last one. Also, sometimes video playback comes out black and white, but if you switch to fullscreen it comes out color.

EDIT:

Ok, I did some more testing, it's definitely the decoder. I just went back and changed the FourCC to use the DivX 5 decoder and all the problems were gone.

BTW, is there a way to implement custom quantizer matrix's for B-frames? You can change them for I and P frames only in the dialog right now.

[sysKin]

Originally posted by Bulletproof
BTW, is there a way to implement custom quantizer matrix's for B-frames? You can change them for I and P frames only in the dialog right now. What you say is not fully true. There are two matrices - one for intra BLOCKS (ie macroblocks which are created without any reference) and inter BLOCKS - macroblocks which are created by altering a motion compensated block.
In intra frame, all macroblocks are intra;
In P frame, most macroblocks are usually inter, while some can be intra;
In B-frame all macroblocks are always inter.

Radek

[iago]

With Koepi's Christmas gift ;):

* no problems with randomly seeking to frames in b-frame encodes.
* a few more fps, which is really precious on my machine ;).

Ta, man! ;)

[Koepi]

The crashing problems may derive from high quantizers - it seems that i.e. quant 20 (for credits) and higher make the codec/vdub crash.

Try using fixed quant 19 (may take some hours for my current encoding to reach the credits, so I can't tell for sure yet).

@iago:
it looks faster for me, too :)

Best regards
Koepi

[iago]

Have just finished a full two pass encode with Koepi's Christmas build using the script below:

---------------------------------------
LoadPlugin("C:\FILTERS\mpeg2dec2.dll")
LoadPlugin("C:\FILTERS\FluxSmooth.dll")
mpeg2source("D:\RIP\RIP.d2v")
crop(12,20,696,536)
BicubicResize(576,304,0,0.5)
FluxSmooth()
---------------------------------------

tools for encoding/muxing/decoding:
-----------------------------------
* AviSynth 2.07 (as can be seen from the mpeg2dec version in the script too ;))
* VirtualDub 1.4.13
* AVIMux_GUI (to mux the video and ac3 audio streams)
* Media Player Classic 6.4.02.00
* ffdshow 14/10 (libavcodec)

encoding parameters:
--------------------
Motion search: 6
Quantization: h263/h263
only b-frames: 4/100/200
FourCC: XVID
DX50 B-VOP Compatibility
Min-Max I-P: 2-6/2-12
Payback with bias / 250
Internal Linear Curve Scaling
no special credits treatment

results:
--------
* No A/V synch problems
* No decoding problems
* No frame seeking problems
* A perfectly clean encode ;)


best regards,
iago

[unplugged]

Originally posted by Koepi
The crashing problems may derive from high quantizers - it seems that i.e. quant 20 (for credits) and higher make the codec/vdub crash.
High q. + BF,
without BF I have no problems.

[Stainless]

Originally posted by unplugged
High q. + BF,
without BF I have no problems.

Yes i can confirm that ! Using only Qpel + Chroma i have no crashes no matter how high the quantizers [credits] are

[Nic]

Ill be damned if I can fix my filter, im going to try & do it from scratch again...im working on it though..

-Nic

[cjv]

Is anyone here using an old Athlon Tbird 1400 or so? I cannot use any XviD builds (Koepi, Nic, CVS, mine) after the 3dnow optimizations went it, even if I deselect those options in vfw.

I even did a full reformat (because my system was misbehaving), but I still experience BSODs in Win2k every encode, which is really really rare. It could be that my system is just going to die, and encoding puts too much stress on the CPU and subsystems..but I'm hoping its the 3dnow optimizations (although I do want a new computer :))

Would somebody be so kind as to send me Koepi's build one prior to 19122002. Just PM me and I will give my email.

Thanks and Merry Christmas!

cjv

[kilg0r3]

@cjv

this may sound stupid butcheck your temps; cpu, nothbridge, hd and ram. try more conservative settings in the bios. especially the famous t1 for the ram might cause a bunch of probs.

merry chrismas anyway :)

[athos]

Nic's latest (XVID - 231202) and Koepis previous build (XviD-19122002-1) crashes my mediaplayers with some xvid files, when using ffdshow with "use xvid".

Koepi's latest (XviD-24122002-1) does not crash, but does not seem to decode b-frames correctly (choppy playback).

XviD-09122002-1 decodes like a charm.

[TheXung]

Is anyone here using an old Athlon Tbird 1400 or so? I cannot use any XviD builds (Koepi, Nic, CVS, mine) after the 3dnow optimizations went it, even if I deselect those options in vfw.

I'm using that processor. Everything has worked fine for me, though I will admit that I didn't notice the 3dnow optimizations doing much for speed though.

@koepi
Is there other code in your build? With a fresh cvs checkout, I get 3.06 mb for a test clip using my compile but yours gets 3.01 mb. This is without using lumimasking.

[cjv]

OK. I apologize, my sytem just BSOD with CCE as well. I guess I know what I'm doing this Christmas vacation (tearing apart my system) :)

The weird thing is that I haven't changed a thing on my system for months, not even installed a new major program or anything. Oh well..

cjv

[NuclearFusi0n]

@cjv

dust on heatsink = hell to diagnose
clean the sink, see if that fixes it

[sungey]

hmm im using XviD-24122002-1 from Koepi ... and i got a weird output ...

Encoding settings

Motion search - 6
Quant = h.263
FourCC = DX50
All checkbox in Global settings are turned off ( No gmc/qpel... etc)

B-frame settings ..

2 200/100
DX50 compatible enabled

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

in DX50 playback filter ... some frames has errors like those seen
when we use MPEG quant with DX50 playback ..

any idea waht is the reason behind this ...?
as far as i know ... earlier version of Koepi's (with b-frame) dont have this problem ... =(

Playback are fine in ffdshow and xvid filter..

[sungey]

hmm ok i found a way to fix it ....

last time i encoded at 640x360 (height mod 8)

but now at 640x352 (height mod 16) the errors
disappeared .... hmm anyone has any idea about this ^_^ ?

[drebel]

Koepi's latest build still crashes VdubMod(vanishes) when using fixed quant 31 on credits(sorry Koepi,i didnt test with q=19).

Image quality: excellent(i'm seeing less flashing pixels but,perhaps it's just an eye game
Decoding: xvid.ax(nic's),ffdshow latest alpha(crashes with "use xvid" option...BUT other builds(more then two months old) seem to like that option

Duron 1GHZ,win2ksp3,avisynth 2.5 latest alpha...

regards,
george

[Koepi]

I have my own xvid.ax fixed (stupid bug: you need to define BFRAMES in the project sources...) so it works standalone (well, linked to xvid.dll) and as "use xvid" in ffdshow.

Syskin tracked the high-quant issue down to some new code (quant4_inter[xmm|3dne] asm) which i can deactivate and should produce a working binary with that.

I'm checking this first, so expect some results in ~8 hours from now (yes, my machine is really slow. I wonder why AMD or Intel don't sponsor me a new one ;) MoBo, processor+heatsink and memory would suffice ;) ).

In first tests this seemed to work, but i want to be sure this time.

Best regards
Koepi

[Trahald]

I'm checking this first, so expect some results in ~8 hours from now (yes, my machine is really slow. I wonder why AMD or Intel don't sponsor me a new one MoBo, processor+heatsink and memory would suffice ).

nice try.. hehe.. i guess we all cant get a 3.06GHz Pentium 4 with HyperThreading Technology like mr. lee got.. hehe.. oh well.. doesnt hurt to ask :D

[Koepi]

Stupid things happening - i tested the DSF and it decodes IP-only encodes well, but with bframes the old "green frame" issue is still present. I have no clue what to do about it :-/

Best regards
Koepi

[Nic]

lol, thats the least of my worries, just cant get my head around the reason why it goes black & white. very odd. Probably have fixed the other problems. Didn't realise that xvid_decore could be called & m_frame not go through any image_output (when using b-frames, i know its obvious but I missed it). If I hadnt put all the exception handling in the dshow would have probably just crashed....

-Nic

[Bulletproof]

Here are some screenshots of the chroma stairstepping I've been expierecing also:

http://www.boomspeed.com/boya/xvid.png

Changed FourCC:

http://www.boomspeed.com/boya/dx50.png

(No postprocessing in either image, very basic default settings)

[Nic]

Thanks for the pics, this helps me search for what im looking for, I think you said you get the black&white problem too, which means your decoding with yuy2 (which also helps :) )

Cheers,
-Nic

[wing1]

Did anyone see an issue with I/key frame being missing with their encoded result? builds from 19122002 to the xmas build from both Koepi and Nic exhibited this behavior. Perhaps, it is my own setting that is causing this issue; However, Koepi's build 09122002-1 works fine using the settings below:

1-pass CBR @ 1090 data rate
ms=6, H.263, DX50, 120/1 max/min I/key frame, 4/150/0 Bframe, chroma motion, B-VOP compatible.
CBR setting = 12/30/30
Quant setting = 2/4 inter 2/4 intra

The first frame is the only I/Key frame that I can observed and the rest are all B and P.

[NuclearFusi0n]

Settings for XviD ()
Mode: 2 Pass - 2nd pass Int.
Dummy 2nd Pass: OFF
Desired Size: 1064099KB
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: OFF
Chroma Motion: ON
Max B-frames: 2
B-frames Quantizer Ratio: 100%
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 firstpass avi plays fine with the latest DSF, but the 2nd pass (only a few kb smaller, i maxed out quality) keeps flashing
Warning: nothing to output
bframe decoder lag

and

broken b-frame, missing ref frames

am i doing something wrong, or is this a decoding bug?


i see koepi's post about the green frame issue, but it still confuses me as to why the first pass plays fine, but the second pass doesn't....

to all the devs: the quality i'm seeing when checking out the encode in virtualdub is ABSOLUTELY STUNNING!!!
I think I speak for almost everybody here when I say all of your work is greatly appreciated!!

[Nic]

Yeah, those errors that come up on screen can be quite fun. In my own build im working on they dont come up & B-Frames decode ok (apart from with packed mode turned on, which I thought was fixed ? must be fault).

@syskin or anyone: the DPRINTF function thats in use, or any other text output function. Could you please try and use stdout instead of stderr if at all possible. I know stderr is the correct place to output, but there are instances where windows does not give a stderr pipe (& hence when stderr is used, the program crashes)...

Cheers,
-Nic

[Koepi]

Use ffdshow for playback, Nuclearfusion.
Nic's DSF produces the same error here (unfortunately) - but simply using ffdshow for decoding suffices :)

@all:
Unfortunately my tests with the 3dne/xmm code crashing the codec went bad - still got a crash (this time not just a boring dead lock) for credits at quant 19, even with that code disabled.

Regards
Koepi

[Siku]

Well, I got crash in VirtualDubMod with Koepi's latest build. I was doing the 1st pass of my rip with VDubMod. It crashed when it was around 80% done of the 1st pass. I had no problems with Koepi's 19122002, so I solved my problem by downgrading my XviD to Koepi's 19122002 :).

Anyway, my XviD settings were something like this:
Quarterpel: ON
Chroma Motion: ON
Max B-frames: 3
B-frames Quantizer Ratio: 150%
B-frames Quantizer Offset: 100
DX50 B-VOP Compatibility: ON
Motion Search Precision: 6 - Ultra
Quantization Type: H.263
FourCC Used: DX50
Max I-frame Interval: 300, Min I-frame Interval: 5
Min I-frame Quantizer: 2, Max I-frame Quantizer: 6
Min P-frame Quantizer: 2, Max P-frame Quantizer: 16
Start Credits: ON, End Credits: ON
I-framen quatizer & P-frame quatizer both: 20

Regards,
Siku

[Didée]

Not sure if this already was mentioned somewhere - at least I can't remember:

CBR encoding is not "aware" of B-frames, thusly producing way too low bitrates. For example, with B-frame settings 3-125-150, CBR @ 1600kbps, I get ~720kbps. (Oops!)

Quality based encoding seems to have a similar problem - its behaviour is a little funny with activated B-frames.

I don't mind too much, due to my seldom useage of those features, and there are easy ways to workaround.
I just thought it should be mentioned.

[cooper99]

Originally posted by Siku
Well, I got crash in VirtualDubMod with Koepi's latest build. I was doing the 1st pass of my rip with VDubMod. It crashed when it was around 80% done of the 1st pass. I had no problems with Koepi's 19122002, so I solved my problem by downgrading my XviD to Koepi's 19122002 :).

Anyway, my XviD settings were something like this:
Quarterpel: ON
Chroma Motion: ON
Max B-frames: 3
B-frames Quantizer Ratio: 150%
B-frames Quantizer Offset: 100
DX50 B-VOP Compatibility: ON
Motion Search Precision: 6 - Ultra
Quantization Type: H.263
FourCC Used: DX50
Max I-frame Interval: 300, Min I-frame Interval: 5
Min I-frame Quantizer: 2, Max I-frame Quantizer: 6
Min P-frame Quantizer: 2, Max P-frame Quantizer: 16
Start Credits: ON, End Credits: ON
I-framen quatizer & P-frame quatizer both: 20

Regards,
Siku


Hi Siku,

Do you happen to know where I can download Koepi's 191202 xvid codec?

Thanks,
cooper99

[cjv]

I encoded 2 movies last night (with Koepi's latest), using q19 for credits. No crahses, and no problems seeking..no problems with I-frames..no problems at all! They always get decoded with ffdshow or mplayer, and they look great. Maybe my luck has turned.

cjv

[kilg0r3]

@all

is it sure that chroma stepping is a decoding-only problemß

[iago]

Stairstepping is more a problem of YV12 colorspace (as Koepi had also mentioned several times) than decoding, though decoding process might also be amplifying it somehow.

[kilg0r3]

whoops! i thought that encoding in yv12 would not only give speed but also quality improvent because of skipped colorspace conversion.

[NuclearFusi0n]

Originally posted by kilg0r3
whoops! i thought that encoding in yv12 would not only give speed but also quality improvent because of skipped colorspace conversion.
that's what i thought too :confused:

[MaTTeR]

Well generally speaking it certainly is IMHO. However, a color contour/stepping artifact seems to be more obvious in the YV12 color space; typically you won't seem them so much except for dark movies.

@Koepi,

Did you see my post in this thread about Bach saying that it could be related to the encoder decision of Image Quality Priority? I was just curious of your thoughts on the subject.

[kilg0r3]

i have got little image here, which is a detail from 2001. here, the stepping is definitely in the encoded material since for the decoding dvix5 has been used. yet i am not entirley sure how much responsibility is due to divx and how much to the source dvd, which is not available atm. i remeber faintly however that some of the effect was also visible when watching in the movie from the dvd; not that strong however.

[TheXung]

have got little image here, which is a detail from 2001. here, the stepping is definitely in the encoded material since for the decoding dvix5 has been used

I might be going blind or something, but can you point out where in that image is the stair stepping problem, because I do not see it.

[Koepi]

new unstable XviD binary available:

XviD-28122002-1.exe (402kb)
Changelog:
- RefDivX' HVS based lumi masking code (a bit slow though).
- Removed Nic's latest standalone decoder again.
- Jaan Kalda sent me a fixed quant4_inter_xmm - crashes with quant > 19 should be fixed.

please test it!

[Kyo]

Testing... with the credits at I=25 B=20...

[Edit] No, No, this build also kill Vdub at the credits start :eek:

I hope this bug will be erased in short time :(

thanks Koepi for your efforts!

[Koepi]

Thanks for the test - damn, the result is so odd and frustrating.

Well, let's see what we find the next days...

Best regards,
Koepi

[HarryM]

I don't use fixed credits quant, last months I use procentual part of bitrate (20%) = for better final file size aiming.
I test it too.

[kilg0r3]

@ xung

lokk at the red section and compare the edges to the whitish part where there is nearly no chroma info.

[Swede]

I can confirm that vDub dies when it reaches the credits. (I think this is the first time I've experienced a crash using Xvid, I've been lucky.)

[Koepi]

*sigh* a last try to narrow down the problem:

XviD-29122002-1:
- Fresh CVS checkout.
- Disabled quant4_inter_xmm|3dne - let's see if this fixes the crashes.
- Included Nic's latest standalone decoder, it works properly again.

(disabled that stuff by forcing it to use the mmx'ed version which is known to work correctly AFAIK).

Please report results!

Best regards
Koepi

[Swede]

Same settings, same crash. :(

It only occurs using B-frames if that could be of any help. (And I've got a P4)

[Koepi]

That's of big help indeed, because 3dne extensions don't get used on a P4 (or that would be a _real_ bad bug ;) ).

Thanks for the report!

Best regards
Koepi

[Kyo]

Umaniac's 29.12.2002 also crash with b-frames + quant>19, Athlon XP here :(

[Emp3r0r]

I finally got a 1st pass to not crash. I have a P4 and I was using Keopi's with
Settings for XviD (12/28/2002 11:56:50 AM)
Mode: 2 Pass - 2nd pass Int.
Dummy 2nd Pass: OFF
Desired Size: 757864KB
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: H.263
FourCC Used: XVID
Max I-frame Interval: 240, Min I-frame Interval: 1
Lumimasking: OFF
Interlacing: OFF
Greyscale: OFF
Quarterpel: ON
Global Motion Compensation: OFF
Chroma Motion: ON
Max B-frames: 3
B-frames Quantizer Ratio: 175%
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: 8
Min P-frame Quantizer: 2, Max P-frame Quantizer: 20
Max Bitrate: 14000kbps, Max Overflow Improvement: 60%, Max Overflow Degradation: 60%
Start Credits: OFF, End Credits: 142952-148731
Encode credits in greyscale: ON
Credits I-frame Quantizer: 16, Credits P-frame Quantizer: 12
1st pass looked great, I don't see the smearing walls problem anymore when using Qpel and B-frames. I'm doing 2nd Pass now and so far so good.

[Swede]

Are you sure that was a 1:st pass? Because it says: Mode: 2 Pass - 2nd pass Int.

[miha]

Just did some checking the cvs and did find that there is new fiture called reduce resolution (idd_global). Is these fiture test ready or is it not working ?

[Koepi]

@miha: rrv even is added to vfw gui, you just have to enable the elements ;)

@swede:

I was confused first myself, but then i read again:
I finally got a 1st pass to not crash. I have a P4 and I was using Keopi's with
[...]
1st pass looked great, I don't see the smearing walls problem anymore when using Qpel and B-frames. I'm doing 2nd Pass now and so far so good.

Which means he's on 2nd pass and uses that settings for it :)

Best regards
Koepi

PS: it seems that h263 does _not_ crash. mpeg quant and mpeg cust. do. if you want to, you can workaround the bug that way.

[Swede]

Duh, of course! My fault. :)

Originally posted by Koepi
PS: it seems that h263 does _not_ crash. mpeg quant and mpeg cust. do. if you want to, you can workaround the bug that way. I am using H.263 :(

[shirka]

Settings for XviD :
Mode: 2 Pass - 2nd pass Int.
Dummy 2nd Pass: OFF
Desired Size: 33523KB
I-frame Boost: 0%
Below I-frame Distance: 10%
I-frame Bitrate Reduction: 30%
Curve Compression: Payback proportionally, 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: H.263
FourCC Used: XVID
Max I-frame Interval: 300, Min I-frame Interval: 1
Lumimasking: ON
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: 6
Min P-frame Quantizer: 2, Max P-frame Quantizer: 14
Max Bitrate: 10000kbps, Max Overflow Improvement: 60%, Max Overflow Degradation: 60%
Start Credits: OFF, End Credits: OFF

vdub crash in the second pass when using a build > 9/12/2002. And today with Koepi's build (28/12/2002) : I found when it appens : when Max I-frame Quantizer and Max P-frame Quantizer are too high. (with these settings no problem but with 2/6/2/15 or 2/31/2/14 it crashes). I have an Athlon XP 1800+ and Windows XP

[Swede]

Right, you're on to it! I can do the 1st pass with Endcredits at 12 or lower but not 13 or higher! (Still only WITH B-frames of course, without everything is ok)

[drebel]

Using the following avisynth yv12 script and the same filters always for the movie The Bandits,i had the following results:

1. divx3.11 : 58% @640x272 2cds(nandub!!)

2. xvid(default with chromaME) : 54.2% (vdubmod)

3. xvid(chroma+qpel) : 55.6%

4. xvid(chroma+3bframes) : 62.4%

5. xvid(chroma+3bframes+qpel) : 62.8%

And now the script:

# Created with Gordian Knot
# PLUGINS
LoadPlugin("F:\PROGRA~1\GORDIA~1\mpeg2dec3.dll")
#LoadPlugin("F:\PROGRA~1\GORDIA~1\decomb.dll")
#LoadPlugin("F:\PROGRA~1\GORDIA~1\IVTC.dll")
#LoadPlugin("F:\PROGRA~1\GORDIA~1\Avisynth_Spatial.dll")
#LoadPlugin("F:\PROGRA~1\GORDIA~1\GreedyHMA.dll")
LoadPlugin("F:\PROGRA~1\GORDIA~1\FluxSmooth-2.5.dll")
LoadPlugin("F:\PROGRA~1\GORDIA~1\Undot.dll")
#LoadPlugin("F:\PROGRA~1\GORDIA~1\SimpleResize.dll")
#
# SOURCE
mpeg2source("C:\Movies\Bandits\band.d2v",cpu2="ooooxx")
# CROPPING
crop(8,70,704,436)
#
# DENOISING: choose one combination (or none)
#
Undot()
#
FluxSmooth(5,2)
#
# RESIZING
LanczosResize(640,272)
# COMPRESSIBILITY CHECK
# !!!!Snip Size now has to be 14 for use in GKnot!
SelectRangeEvery(1400,14)
#

Of course,no special treatment in credits... and no crashes

regards,
george

[nexus]

Workaround doesn't work. I'm getting a crash , b-frames + H.263 at the credits (fixed quant 20). :-(

[Emp3r0r]

Doh! I got the crash at the end of my 2nd pass, I'm guessing it was near the credits because last I checked it was 90% done. Settings I used were above (I'm on WinXP btw), I'm going to try my luck with 12-29-2002 build this time around.

[TheXung]

Is everyone talking about the same crash bug?

Seems that some people are describing an issue where it crashes in mid encode or during the 1st pass. Whereas others may be pointing out to the issue where 2nd pass stops because the number of frames in the 2nd and 1st pass aren't the same. I've gotten that crash before but just assumed it was a 2-pass bug, not a codec bug.

I have never gotten a mid encode crash in either my or koepi compiles. Though I don't encode credits. I use qpel, 8 bframes, chroma ME, h263/mpeg/modulated, and lumi-masking sometimes. Using a tbird 1.4 ghz.

[iago]

Peh, forget about it! Was just a stupid idea about those crashes, etc. :confused:

iago

[vinetu]

Hi!

about Nic's DS decoder filter :
1 file - 2 decoders (the .png files are saved as image sequence from VDub - source is avs - __"DirectShowSource("file.avi",fps=23.97)__ ... but it's the same in Media Player Classic or WMP):

http://www.freewebs.com/vinetu/NIC_DS_decoder.png
http://www.freewebs.com/vinetu/ffdshow_decoder.png

Best Regards!

vinetu

Edit:
in Media Players the ffdshow looks perfect - may my there is some additional antialiasing by Radeon drivers or so - in same case Nic's
decoder looks even worst :(

Edit2:
Nic's decoder is from lates koepi's build - XviD-29122002-1.exe
ffdshow version - ffdshow-20021213.exe

[Emp3r0r]

Ok, I can confirm the crash still exists with todays build. It happened at the end of the encode.

[iago]

XviD-29122002-1 :)

I just wanted to point out that "Quarterpel" (together with B-frames in my case) still produces a very visible smearing effect, and imho should be avoided at the moment; however, B-frames alone gives really good results and no decoding problems with ffdshow libavcodec and for quite some time I definitely don't go without b-frames for 1CD encodes, unless the movie is extremely compressible.

best regards,
and thanks for all the good work,
iago


edit: btw, I still haven't got a crash with the recent builds, maybe because I do not go higher than I/P -> 16/16 for credits.

[Lazy_Ranma]

I think I've found the source of crashes (or freezes in my case).
If you are trying to encode with qants > 16 (credits) and iSSE optimizations turned on, XviD freezes on some frames. :( If you disable iSSE (you can leave MMX,SSE,3DNOW,3DNOWEX checked) everything works perfectly.

Tested with latest cvs snapshot (my build).
6 - ultra
MPEG quant
lumi masking off
croma motion on
qpel on
GMC off
b-frames off

BTW, XviD doesn't save CPU settings. Why? :confused:

[Koepi]

lazy,

if you'd followed the last posts (10-20) here you'd know that we're aware of the "source"...

but thanks anyways, nice to see that you try to help where you can :)

Best regards
Koepi

[Mango Madness]

hey emperor, i'm going to UA this fall ;) ROLL TIDE.

Anyways, just here to give a little moral support. Keep up the excellent work on the excellent software.

[HarryM]

I registered higher (more visible) smearing effect with q-pel=ON in lastdays builds too. Mainly at special situations - sky, moving monocolour background, etc.

I stopping next testing until XviD decoder will be OK for me. I can't to identify exactly, if is problem on side of encoder or on side of DS filter.

[Lazy_Ranma]

Originally posted by Koepi
if you'd followed the last posts (10-20) here you'd know that we're aware of the "source"...

Oh, sorry. I've missed your new build. :confused:

What about saving CPU settings?

[Koepi]

Will never happen - CPU features get detected on codec instantiation.

Regards
Koepi

[ChronoReverse]

Trying out the Christmas build with an anime movie (Macross Plus).

Utilizing:

mpeg2dec.dll
IVTC (Decomb, Telecide, Decimate)
Convolution3D using the preset AnimeLQ (my dvd is noisy and it looks nicer this way)
Levels adjusted Gamma = 1.2
Lanczos resized it to 512x384 (will try 640x480 afterwards, I'm convinced it'll still look great)


Following Iago's Two-Pass document after hitting Load Defaults.

First pass h.253 then New Modulated HQ for the second pass.

No credits treatment.

I'm about 51% percent into the second pass right now (slow proc =( 850MHz OC'ed Celeron) and am looking at the window of DebugView right now.

Wow. All I can see are Quant:2 and Quant:3 with the rare Quant:4. Combining XviD and Convolution3D is really working wonders. The trial clip I did early of a High-Motion scene looked great. I'm 100% sure this will turn out awesome too. Gonna try it at 640x480 after this.

Good work!


Oh yeah, no crashes so far. I'll try a 1CD rip later with B-frames enabled after this as well. Will try the credits with Quant > 19 when I do.


My encode's done!
Q:2:36901
Q:3:126972
Q:4:661
XDA doesn't seem to be working for thism oh well. I wanted to know the compressibility too =\
I asked for 1320000KB and I got 1320096KB. Nice!

[manono]

Hi-

Average Quant=2.780=71.95%
Happy New Year!

My new version of the StatsFileAnalyzer doesn't seem to be working either. Gotta do it by hand these days. :(

[((( atom )))]

i've been trying to watch my latest encode under linux using mplayer and it doens't manage to play it correctly at all. ffdshow under windows does. objects stay where they are until next i-frame comes and there are actually all artifacts i have ever seen so far present at once.

i actually understood, that xvid is supposed to be fully mpeg4-compliant, so now i am afraid, that using xvid might put me onto a very incompatible side (at least when using features like b-frames or qpel..).

could anybody bring some light into this thought?

[Koepi]

atom:

i repeat it for you, as you didn't find the search button (forum rule 1) it seems:

xvid unstable developer binary.

Look into the releasenotes of the binary.

I clearly state that the new features may produce buggy bitstreams (and they are likely to).

Koepi

[cjv]

Originally posted by ((( atom )))
i've been trying to watch my latest encode under linux using mplayer and it doens't manage to play it correctly at all. ffdshow under windows does. objects stay where they are until next i-frame comes and there are actually all artifacts i have ever seen so far present at once.

i actually understood, that xvid is supposed to be fully mpeg4-compliant, so now i am afraid, that using xvid might put me onto a very incompatible side (at least when using features like b-frames or qpel..).

could anybody bring some light into this thought?
XviD is fine. The ffmpeg decoder doesn't like XviD's b-frames.
Try this:

mplayer -lavdopts bug=16 movie.avi

cjv

[sysKin]

Originally posted by ((( atom )))
i've been trying to watch my latest encode under linux using mplayer and it doens't manage to play it correctly at all. ffdshow under windows does. objects stay where they are until next i-frame comes and there are actually all artifacts i have ever seen so far present at once. Disable error detection in mplayer. I don't rememeber what switch did that - I don't use linux - but there was one. Disable it.

I hope that helps.

[wing1]

I know that most of the folks here use 2pass encoding, hence 1pass CBR mode is unimportant to mention. However, I have been using the 1pass CBR mode since xvid came about, and I have followed it to this date (firm believer in this codec). I am noticing that B-frame and xvid builds since 12-19-2002 are not posting I/keyframe as specified if B-frame is activated. Disabling B-frame and everything is kosher. I know the codec is in alpha stage and it is unstable, but there is a feature within the codec that is not working so I thought i'd mention it. 12-9-2002 build is working fine with CBR mode + Bframe.

[drebel]

Because of the broken(?) credits treatment of the latest builds,i was "forced" to go back to good old GordianKnot trim method and create 2 different avs scripts(movie+end credits) and then to encode them separetely
That's why i'm using now constant q Only for credits.I noticed that Q can't go over 16 in my system(crashes vdubmod on my Duron win2000) whan b-frames are activated(5/150/150).I'm saying that not as a complaint but to point out that specific number :)
When decoding those credits,ffdshow reports the use of quant ~25 for b-frames.So if ,somehow, we could manage to get const q=25 to work,what would be the max q for b-frames?(sorry in advance for asking such a newbie question,i only ment if there is an up limit to the famous equation... )
Anyway,even with this way,xvid is doing miracles...:)

regards,
george

[((( atom )))]

@koepi: i was aware of that i am using a devel.-build when i was posting.
my question actually was if xvid (in its actual specs) will be fully compliant or not. sorry, if you got that wrong.. also there were helpfull answers, so i guess my question was ok, after all.
i don't have any problems with devel.-builds, since i am also using linux, and practically every interresting software is actively being developped and used during that period. that leads to ideas in many cases and here is one right away:

(i don't really know, if you are the man to ask, but since i understood, that you are also involved into development, i guess so..)

- when i encoded fightclub several times now and also recently did being j. malkovich, i realized, that some movies tend to saturate the codec and this will be getting even more common once b-frames and qpel are fully integrated.

my idea is, to add a small menu to the codec-settings, that will /not/ discard the first pass, when it stays under a certain filesize. this way one can decide to simply keep this one, since the filesize will be known until a certain limit is passed. that would save a lot of time, especially, when it comes to heavy filtering and/or slow machines. the way it is now, i don't even know the actual filesize, before the second pass has started if i enabled "discard first pass". simply disabling it is also not an option, because the file might become to large and blow the disc.

what do you think of it?

[Koepi]

Hm, that should be a possible switch, but it's prone to errors if I code it %)

Would be "keep only XXXMB of first pass" be ok? then i could do a lazy-man implementation and stop writing to the file at a certain point (I have to look at the sources for that, it's pure speculation that switching the appropiate variable would have this effect ;) ).

I didn't mean to insult you btw., it just sounded to me as if you weren't aware "of the obvious".

Best regards
Koepi

[bilu]

I think "Keep 1st pass if smaller than XXXMB" would be a good idea :D

[Teegedeck]

Originally posted by Koepi
Would be "keep only XXXMB of first pass" be ok?

I like that! BTW, a happy new year, everyone!:)

[At long last I got enough HD space to encode, again.:D ]

[((( atom )))]

Would be "keep only XXXMB of first pass" be ok? that would do the job..

thx! regards!...! :)!

[HarryM]

Umaniacs (dev.) binaries are down? The download page is empty...:confused:

[Swede]

Yes they are. Let's hope his scripts come back. In the meantime I've restored this mornings backup.

[Kyo]

Well after umaniac's back... test with 01-01-2003 build and a 1pass with b-frames + credits > quants > 19(i'm not tested minor values)
virtual crash again :(

Just to report the sad news :confused:

PD: Just after the test with VirtualDubMod I tested the same script + same values with avs2avi and guess what they dont kill the program...(at least in the 2pass-1stpass) very strange, I remember had tested the 29 and 30 buil with avs2avi and they crash... weird weird :eek: :confused: :( ...

PD2:When the 2pass-2ndpass come to the credits stage the compressor die, so is not only a problem with Virtual... but strange that avs2avi pass the 1st stage :eek:

/me wait for the next alpha release ;) :)

PD3: my test was only 6000 frames so is a short clip

[alx]

Hi, i recently tried latest Koepi´s version (29-12-02) with Qpel, Croma Motion and B-Frames and with small videos had no problems, but when i tried to use it with a full movie, virtualdub(MOD) always crash.....
Tried the same with latest Umaniac´s build and works fine with everything ON.......and i always do credits at 25% and never had a crash....
Don´t know what else to say, sorry.
Alx

[Bulletproof]

I haven't recieved any crashes from either Umaniac or Koepi builds during encoding with latest build. However Umaniac build uses a less compatible or broken(?) decoder which does cause my media player to crash to playback files.

[Kyo]

@Bulletproof

in your test you have used the credits>19 + b-frames?

[Koepi]

XviD-03012003-1:
- Fresh CVS checkout.
- some problems with missing EMMS fixed.
- dshow now compiled with directx9 sdk.

Btw., the crashing problem seems to be related to vdub/vdubmod only, cruncher reported that avs2avi CLI encoder doesn't crash with the other binaries.

Let's hope these missing EMMS instructions help it with the other programs!

Best regards
Koepi

[Swede]

I hate to be the bearer of bad news but... Still getting it. :( And still at credits Q13, 12 is ok but 13 and up....

[Kyo]

Hiya Swede :D

Have you tested with avs2avi?... sorry for being OT...

[Selur]

Little question:
I just started my first avs2avi encode and I get lesse than half the framerate I normally get with VirtualDubMod (on my Dual Athlom Mp 1800+), chroma motion, Quarterpel and Motion Seach 6 selected.

I used the avsGUI, loaded my old .avs file, choose a destination file, selected Two pass encoding, pressed on Encode, selected Xvid 1stPass, selected Xvid 2ndPass and so it started.

So my question is: is it more likely to be the fault of avs2avi or is something really slowing down encoding with this new build?
(get something like 12.3-13fps; normally I get 25+fps)

Cu Selur

Ps.: Cpu usage looks normal 73-85% on each CPU.

/edit: my avs script:
LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\decombYv12.dll")
mpeg2source("E:\FTP\DVD\Futurama\ep9\ep9.d2v")
FieldDeinterlace()
crop(8,2,706,570)
LanczosResize(736,544) # I know this is big, but it keeps the file from beeing undersized ;)

"dshow now compiled with directx9 sdk."
ehmm, do I may be have to install DirectX9 ? :D

edit/

[JagPanzer]

Hello everybody! My first post here.

I tried encoding with Vdub, VdubMod and AVS2AVI (the latest Koepi's build) and I still get a crash at credits (Q20). Then I changed credits to Q12 and everything was OK.

[Selur]

Argh,.. installed DirectX9 did a reboot and did the exact same encode,.. didn't get faster, so I stopped the encode during first pass and tried VirtualDubMod to see if it's avsavi's vault,.. but in VirtualDubMod encodeing wasn't faster.

So is this slowdown something that's kind of ment to be with this build or ... ?

Cu Selur

Ps.: Would be nice to see some feedback from other users if this speedbreakdown is just happening to me,...

[Bulletproof]

I did do an encode before with Q19 for Starting and Ending credits and I didn't get a crash, and thats with the earlier build, not today's build (Jan 3rd), and I was using YV12 VD too.

[CruNcher]

XviD-03012003-1

Stairstepping Bug is gone @ decoding :)

[Mango Madness]

crash with vidomi on 2nd pass with Jan 3rd Koepi Build.

Motions Estimation 6
Modulation HQ
Xvid CC
Lumi Masking
Chroma
B Frame (2/150/100)
No credits treatment

Keep up the great work and the best of new years : )

[((( atom )))]

@cjv. thx for the hint - it worked!

[HarryM]

I tested xvid.ax from last Koepi's 03012003 build.

I observe any positive changes in functionality from last builds! :cool:
xvid.ax works (still don't work with 'xvid.dll' feature at ffdshow) now!!!
I see only few stupid frames with text message at beginning, anything about '...B-FRAMES LAG...NOT-DECODED...'(???):p

[alx]

Okay, I know that this a beta build, that B-Frames are still experimental and all related to the warnings that koepi said.....
I made 3 movies with 04-10-02 build and in the first pass, the size of the avi were around 1 gb. (i don´t discard the first pass avi)so, the desired size of 640 mb were reached without any effort, but when i tried the latest builds from koepi and umaniac, the size of this 3 movies in its first pass never were above 500 mb. I mean, the quality is very good, but something is not right.
I tried to lower quant. to 2-6, 2-16 just like IAGO says in its document without any luck....
The movies were around 1h 45m, 640x272 or 640x352 and the builds that i tried were
koepi 19-12
koepi 24-12
koepi 29-12
koepi 03-01
umaniacs 01-01

Any comments???
Thanks a lot
Alx

[alx]

Opps, i forgot...........i´ve have this problems with Chroma Motion activated and 1, 2 or 3 B-Frames ........other settings are default
Alx

[Selur]

@alx: How is yout speed with the latest build ?

[Koepi]

alx,

the stable tree is missing features like bframes, which helps compressability with the default settings a lot. You can gain higher first pass size with disabling bframes or setting the values different, like 3/100/100.

..and all the usual other stuff that helps increasing the file size:
- mpeg quant type
- lanczos resize
- ...

Regards
Koepi

[Selur]

hmm,.. strange the speed Problem must have somethign to do with my system,.. damn,.. have to search what's broken now,.. sorry, for the bugging,... (some folk over at flaskmpeg.info said speed didn't change for him,...)

Cu Selur

[Koepi]

Speed didn't change for me either, but then i don't have a SMP system.

Regards
Koepi

[MaTTeR]

@Selur

No speed change here on a dualie AMD 1600 box thats agressively tweaked. About 49fps and peaking at 71fps with the following script using MPEG quants,quant 2 and the slower chroma motion option-
mpeg2source("Z:\Test Clips\cell.d2v",idct=3)
crop(8,58,710,360)
TemporalSoften(1,3,5)
BicubicResize(640,272,0,0.5)
Limiter()

Edit- This was a YV12 encode.

[Selur]

@matter: Thx,.. maybe it's the Quater Pixel Setting,.. that's slowing me down,.. or maybe my hdd is just too fragmentated (got about 200GB on the disk (Raid 1) of 240GB)

Speed seems to be back at 25+fps if I disable QuaterPixel, did some test with earlier versions and my system, seems like this version kind of slows down the encoding a bit more than earlier versions, even after cleaning my hdd a bit encoding is a bit slower with this build.

But it's okay,.. Speed isn't so important, if the quality fits. :)

Cu Selur

[iago]

Just a couple of short tests, and I haven't observed any speed decrease with Koepi's 03012003-1 build either.

regards,
iago


edit: @Selur and all,

Imho, using Quarterpel (with or without B-frames) only has disadvantages for the time being, not only regarding the "speed" but also regarding the "quality" of your encodes.

[wotef]

Iago, aside from the speed, can you give some examples to show why q-pel with no b-frames is currently not so good? What should we look for? I'm still using koepi's build 09/12 + qpel with very nice results

[Koepi]

Hm, I think qpel is very nice in fact :P

It adds a bit of noise, and with the current builds that's become less IMO. (I'm wondering how my current local build will perform, no smearing since sysKin found some weird things - and an experimental motion_est... but I have to test it first here before I make that version public).

So, to answer what you should look for:

- overall noise in the picture
- in faces, some color "misfits" ( I think).

Or do you mean something else, iago?

Serefe,
Koepi

EDIT: wrong alarm with smearing - it still occurs, but now at least with xvid _and_ ffdshow as decoder ;)

[MaTTeR]

wotef,

A bug still exists, Qpel gives somewhat of a smearing effect on quite a few scenes. The artifact is real easy to see on most clips but oddly enough Qpel looks great on a select few movies I've done such as Monsters Inc. It will be very nice once the bug has been found, think sysKin is looking into it.

Edit- hrm...Koepi you might be right, just ran quick Qpel test with your 12-03 build and I didn't notice the artifact smearing problem:) Could it be fixed? I need to run a few more tests.

[((( atom )))]

this is funny! now my third encode in a row maxes out, this one (the pledge) at around 800mb. i remember the days of starting to use two-pass encoding with nandub very well - now i seem to be back to single-pass, lol.

that is what i call development!

[HarryM]

I compare 'with q-pel' (using b-frames=3) versus 'without q-pel' (using b-frames=3). It is quality comparable now(?).
Sharp-look (typical for q-pel in older builds, aka 13/10/2002, etc.) is lost.
Only one positive effect for q-pel using actually = better compressibility.

xvid.ax works! Ohhh... Finally. I can burn my waiting videos.

[iago]

Well, I've been observing the smearing problem with Qpel (with or without b-frames) with all the recent builds, including Koepi's latest (XviD-03012002-1).

@Matt,

Which one is that "12-03" build you mention in your post? ;)


@Koepi,

Can you please send me your local build, if it's possible, for a short Qpel smearing test?

Also, do I need to install DirectX9 to view the encodes done with your 03012002-1 binary?

[HarryM]

Originally posted by iago

Also, do I need to install DirectX9 to view the encodes done with your 03012002-1 binary?

I use 03/01/2003 build now and decoder is O.K. finally, I using DX 8.1 still.

[iago]

@HarryM

Same here, I still have DX 8.1 and I'm currently doing some short test encodes with the 03012003-1 build, but I just wanted to make sure to avoid some possible misguiding info.

[MaTTeR]

iago,

you got me! LOL

I meant the XviD-03012002-1...uhm shouldn't that say 2003 on the end?;)

[iago]

@Matt,

Hehe, I edited my above post very quickly and corrected my mistake:

03012002-1 -> 03012003-1

:D

[iago]

FULL EDIT:

MPEG quantization - constant quant 2 - Qpel - no b-frames

with the below script:
------------------------------------------------
LoadPlugin("C:\FILTERS-YV12\mpeg2dec3.dll")
mpeg2source("D:\MOVIE\movie.d2v")
crop(4,0,704,480)
Trim(2600,2850)
LanczosResize(512,384)
------------------------------------------------

ZoomPlayer/MPC

ffdshow-20021213 libavcodec -> smearing is still there! ;)

ffdshow-20021213 "Use XviD" -> smearing is gone! :D

Finally!!! Great!!! :)

[Teegedeck]

I'm all for qpel! :)

I do look pretty close, but I can't find that qpel's side-effects are disturbing or anything. On the contrary, the gain in crispness is very noticeable. Never before XviD gave such a terrific picture. Thanks, devels!

I don't quite see what lumi-masking does at the moment, tho. AFAIK coefficient-removal? It doesn't decrease filesize and it doesn't seem to help perceived quality even at higher quants? Hm. :confused:

[iago]

Originally posted by iago
FULL EDIT:

MPEG quantization - constant quant 2 - Qpel - no b-frames

with the below script:
------------------------------------------------
LoadPlugin("C:\FILTERS-YV12\mpeg2dec3.dll")
mpeg2source("D:\MOVIE\movie.d2v")
crop(4,0,704,480)
Trim(2600,2850)
LanczosResize(512,384)
------------------------------------------------

ZoomPlayer/MPC

ffdshow-20021213 libavcodec -> smearing is still there! ;)

ffdshow-20021213 "Use XviD" -> smearing is gone! :D

Finally!!! Great!!! :) :)

[MaTTeR]

Originally posted by iago
ffdshow-20021213 "Use XviD" -> smearing is gone! :D

Finally!!! Great!!! :) Indeed:D I just finished viewing 4 different Qpel clips on TV and they looked fabulous. Great works guys.

Time to do a full 2pass now to make sure.

[iago]

But:

"Qpel + b-frames"

ffdshow-20021213 "Use XviD" -> crash!

XviD decoder -> indescribable decoding problem worse than crash! :D

[-=Stan=-]

I dont know if its a known issue but XVID's latest builds aren't producing too many keyframes ,ie, they do not oblige to the input max I-frame interval as 300 .
Even manual keyframing on two pass is not working .

Just to present the facts , i encoded a half an hour long movie just to get 25 keyframes , the fps was 25 so according to the input setting it shud have given me 30*60*25/300=150 key frames at least .

I wonder if anybody else noticed .

[Koepi]

@stan:

it's known.

@iago:

Unfortunately the decoder was "broken" for some days. it should work again since ~29.12.02 as suxendrol then commited the necessary changes to dshow/dev-api-3 which correspond to the core changes (it was affecting YV12 and YUV only - RGB should work well).

Try the latest decoder (my 03012003-1 binary) and see that it does decoder correctly. It doesn't fix the ffdshow "use xvid" crash though.

Could you send me an eMail so i have your address again? I lost it during my *caugh* winXP installation (which I'm soon to fdisk again and make it a proper win2k+sp3).

Best regards
Koepi

[Pasqui]

@-=Stan=-
It is a known issue when using B Frames: they are not taken into account with the max I Frames interval

[iago]

@Koepi,

The decoder from the 03012003-1 build causes some weird decoding problems for me. Almost half of the screen, the bottom part, is greyed out and the upper part is somewhat grey and also masked with some horizontal lines, etc.

Can it be a DirectX problem?

(WinXP Pro SP1 + DirectX 8.1 + Celeron900 ;))


edit: I'll PM you my e-mail address now.

[mfluder]

Originally posted by iago
ffdshow-20021213 libavcodec -> smearing is still there! ;)

ffdshow-20021213 "Use XviD" -> smearing is gone! :D

Finally!!! Great!!! :)
There is a very simple explanation for this. Qpel is currently not spec compliant because there is some problem with rounding, hence the smearing effect with libavcodec. I spoked about this problem with sysKin about a month ago and he confirmed the problem but he can't fix it so he posted about this on xvid-devel mailing list and Isibaar said that he can reproduce the problem but currently doesn't have time to fix it. Here is a quote:
I also quickly checked with ms fdam and the clip is decoded with similar artifacts than what ffdshow does. Obviously we (and DivX btw) have a compliance problem. Since the problem is not clearly visible (before decoding 100 frames), I suppose it could be a rounding (?) problem int the low-pass filtering code. I'll dig into this when I'll have some time again...
I can also confirm this. The image quality gets degraded until next keyframe and in some scenes there is that smearing effect you are all talking about. I tested this with many MPEG-4 decoders but most importantly I also tested this with msfdam and like Isibaar said artifacts are similar to ffdshow so it's definitely XviD's fault. So if you want spec compliant streams which you can play with any MPEG-4 decoder in the future I advice you not to use qpel until this is fixed. Of course, you can always include xvid.dll which you used for encode on your CD and install it whenever you watch that specific movie.

And about the quality you get when using qpel I can only say wow, as this is the feature that has the most impact on visual quality and plus it has a smaller filesize when using fixed quant. Also, when it's used together with bframes you can make some amazing 1 CD rips and I have to agree here with Teegedeck that XviD never had that terrific picture. Simply amazing. My thanks goes to all the devels working on this piece of art.

I hope I cleared things a bit about this qpel smearing but I would like if sysKin could just confirm this because after all he is working on XviD and he knows these things much better than I do. I don't want to be wrong like last time ;)

Regards,
mfluder

[gino25]

hinted me doesn' t work. When will it be ok?

[iago]

Latest ffdshow (03/01) doesn't crash decoding XviD-03012002-1 encoded clips when "Use XviD" is checked! :)

[Swede]

@gino25: It's been answered many times before. When the developers has nothing else to do. Right now there are more important issues! :devil:

[sam_b]

Just a quick question to add on to stan's comment above: is there a workaround for the I-frames issue? I have just encoded a half-hour episode of "The Office" (DVB) and the first five minutes contained only 2 I-frames. Inserting frames using statsreader did not work. It's not too much of a problem as it looks fine but seeking is a bit impractical. If anyone knows of a workaround it would still be very useful though. Thanks.

Oh, this may be well known, but the quant-range settings have no effect for me. Doesn't bother me though.

[Teegedeck]

Originally posted by mfluder
So if you want spec compliant streams which you can play with any MPEG-4 decoder in the future I advice you not to use qpel until this is fixed. Of course, you can always include xvid.dll which you used for encode on your CD and install it whenever you watch that specific movie.


Thanx for the reminder: We're having a lot of fun encoding, right now, but we all do know that it possibly doesn't make a lot of sense keeping the results (except if we do as mfluder wrote above).

[iago]

Originally posted by iago
Latest ffdshow (03/01) doesn't crash decoding XviD-03012002-1 encoded clips when "Use XviD" is checked! :) ... but unfortunately still causes a lot problems as simultaneously discussed in the related thread :D.

[iago]

Just a few final comments:

* Currently the most reliable and backwards compatible decoding method is using ffdshow libavcodec. After all, it will decode all your XviD encoded movies without neeeding the specific xvid.dll and xvid.ax, as long as your encodes are spec-compliant, which means, for the time being, no Quarterpel and no GMC is used in your encodes! ;)

* and vica versa: do not use Quarterpel and GMC in your XviD encodes (currently -except for testing-) and decode your movies with ffdshow libavcodec, and be happy with the magic of only b-frames (of course if your source is especially hard to compress and requires the use of b-frames to increase compressibility)! ;)

At least that's what "I" prefer to do (when encoding for archiving purposes)! ;)


best regards,
iago


edit: Ah, of course for the time being... until the issues with these options are resolved! ;)

edit2: Koepi, I got your e-mail. Thank you very much! ;)

[cjv]

Originally posted by Koepi
...during my *caugh* winXP installation (which I'm soon to fdisk again and make it a proper win2k+sp3)
:D

[alx]

OK, just finished the first pass with Star Wars Episode II.......an 2h15m movie, throwing a 978mb. avi file so i don´t expect the second pass will be bigger than that.........and i am targeting to 1217mb. mmmmmmmmm
the "problem" is that two weeks ago, when i made it with build 04-10 (i know it doesn´t have BF) the first pass throw almost 1.6 Gb. file, soooooooooo......BF can reduce the size in 700 mb?????? i don´t believe that..........too good to be true!!!

no Qpel, only Chroma Motion and BF=1,100,100

[MaTTeR]

SW EpII has virtually no noise due to it being almost entirely digital and not film. So if I had to guess I would think that it compressed pretty well but your numbers due seem to be on the high side. I'd be interested in hearing how the visual quality compares to your older stable encode.

[HarryM]

@alx:

SW II (Clone war) has very, very good compressibility.
Movie is noiseless. I use q-pel, b-frames=3, chroma ME, 640x272 px, Lanczos resize. Next, original AC3 sound (448 kbps) and fit to 2CD. I get compressibility at 81%!

It is very good...

[HarryM]

I tested Koepi's build 03/01/2003 and observe crashing effect at credits encoding (higher quants crashing).

Setings:
q-pel = ON
chroma ME = ON
b-frames = 3
other = default


I encode end-credits separately (I dont want waiting for full movies encoding) to AVI. Without sound, of course. I use SelectRangeEvery(1000,100) function from Avisynth too.

Here my result:

a) MIB 2 (1028 frames of end credits, 576x320 px - AVS script for Avisynth2.5)
quant2 = 12 498 944 bytes
quant10 = 1 947 648 bytes
quant11 = 1 730 560 bytes
quant12 = 1 515 520 bytes
quant13 = 1 415 168 bytes
quant14 = 1 169 408 bytes
quant15 = 1 126 400 bytes
quant16 = 16 777 216 bytes - crashing after few frames, final AVI is broken = meaningless AVI

b) Scorpion King (1000 frames of end credits, 544x240 px - AVS script for Avisynth2.5)
quant2 = 9 277 440 bytes
quant7 = 2 963 456 bytes
quant8 = 2 547 712 bytes
quant9 = 1 189 888 bytes (smaller than half of quant8!!! Interest...)
quant10 = 16 777 216 bytes - crashing after few frames, final AVI is broken = meaningless AVI


Final conclusion:
Crashing effect is depend on video (size of frames, maybe content too, etc.), don't exists any exact quant>x formula for prediction of crash. Maybe crash at quant>=16, for other movies at quant>=10, for other...?

Interesting:
ad a) size diference between quant13 and quant14
ad b) size diference between quant8 and quant9...

I recommend:
use only quant 2-8 for I, P frames
for start and end credits >>> maybe good choice const. quantizer=8 for I, P frames

[Koepi]

Don't use quantizer restrictions.

And, jarry, you forgot one thing in your recommendation:

Maybe you used different bframe settings?

i.e. with the default (x/150/100) at quant 12 for the i/p frames, the bframes have quant 19 (will not crash). Setting credits fixed quant to 13 with that bframe quant settings will crash.
And so on.

Regards
Koepi

[HarryM]

Originally posted by Koepi
Don't use quantizer restrictions.

And, jarry, you forgot one thing in your recommendation:

Maybe you used different bframe settings?

i.e. with the default (x/150/100) at quant 12 for the i/p frames, the bframes have quant 19 (will not crash). Setting credits fixed quant to 13 with that bframe quant settings will crash.
And so on.

Regards
Koepi

B-frames may have higher quants than I/P frames, you have right. But when I restricted I/P frames, I restricted indirect B-frames too.
I don't know, how by another way can I this resolve.

[Assault]

@ HarryM
I think it depends on what your b-frame setting are. If your b-frame settings are 150/100 you can choose I/P frame quantizer of 12 as Koepi said. If your b-frame settings are 100/200 for example you can choose I/P frame quantizer of 17...
Please correct me if I'm wrong.

Regards
Assault

[compunerd632]

I have some info to contribute for the b-frames/credits problem. I have tried with Koepi's builds from 01-03 and 12-24. I keep getting crashes with the credits no matter what. I have tried q12, q19, 20%, none of them work. The q-modes crash the first pass, and the percentage crashes on the second. This is with b-frames set on 3 and everything else set at defaults. The resolution of the video is 256x112 because I'm experimenting with putting the file on one of those thumb drive things. I thought maybe that had something to do with it since everyone else seems to get by with credits at q12.

[HarryM]

Quant=20 for credits encoding is unusable (crashing). I use quant=8. It reduces bitrate to 20-30%.
I have another problem. Keyframe inserting is broken(?). I see only keyframes from SCD, but forced inserted keyframes (default interval=300) don't!

[HarryM]

Originally posted by compunerd632
I have some info to contribute for the b-frames/credits problem. I have tried with Koepi's builds from 01-03 and 12-24. I keep getting crashes with the credits no matter what. I have tried q12, q19, 20%, none of them work. The q-modes crash the first pass, and the percentage crashes on the second. This is with b-frames set on 3 and everything else set at defaults. The resolution of the video is 256x112 because I'm experimenting with putting the file on one of those thumb drive things. I thought maybe that had something to do with it since everyone else seems to get by with credits at q12.


Set quant=8 for credits encoding. From time to time is also quant=10 too much (see my post above).
I encode with my recommended settings and all is O.K. (only keyframe inserting is 'little' problematic, mainly at end credits - here SCD works bad as per usual, forced keyframes don't exists(?) with latest build).

[Koepi]

We found the error which was causing the "too few iframes" issue: someone changed our signed integer for the iframe enforcement into a unsigned int - it's as easy as that sometimes (and try to find that...).

Regards
Koepi

[NuclearFusi0n]

Originally posted by Koepi
We found the error which was causing the "too few iframes" issue: someone changed our signed integer for the iframe enforcement into a unsigned int - it's as easy as that sometimes (and try to find that...).

Regards
Koepi
lol, ain't that a bitch ;)

as always, thanks to you Koepi and the rest of the developers. :)

[HarryM]

Originally posted by Koepi
We found the error which was causing the "too few iframes" issue: someone changed our signed integer for the iframe enforcement into a unsigned int - it's as easy as that sometimes (and try to find that...).

Regards
Koepi

Very good news! Can you get into your site new build (without 'too few I-frames' bug), please?:)

[sysKin]

If anyone is interested, an update:

1. This 'unsigned mode' thingy was a bug, but due to problems in main encoder functions (which really waren't meant for bframes) max keyframe interval still doesn't work. I'll tell Koepi (and anyone else who asks me on IRC) how to make this maximum really working (by making encoder functions even worse, mind you). This hack will have to do until we make a real clenup.

2. P-frames shouldn't crash at high quants and mpeg quant type anymore. Everyone who experienced a deadlock with the settings and quant > 19 shouldn't have any problems anymore.

3. But high quants still don't work with B-frames. Not deadlock, access violation this time. I'll trace it tommorow. This is not related to the problem above - there were two sources of "high quant evilness" and only one of them has been squashed.

Thanks for all your testing effords,

Radek

[sam_b]

Cheers syskin. These updates of yours really are very helpful, especially with a thread this long.

[wing1]

I don't know if this is relevant to what has been found for I/Keyframe small issue, but I am seeing some sort of I/Keyframe being posted when encoding with a P3 but for an AMDxp there are none that I can observed. The observation is made using the same clip on both CPU's with the same setting in CBR mode. Furthermore, upto 12-23-2002 uManiac's build the P3 produced 14 keyframes out of a 30sec clip @24fps with Max/Min I-frame set at 120/1, while the 12-24-2002 uManiac's build up to the present build the P3 produced 10 keyframes. As far as for the AMDxp, no I/keyframe is being posted after the first frame encoded.

[sam_b]

interesting... got AXP myself and problems. Can probably have a go a P3 it it's gonna help diagnose.

[MaTTeR]

Dual Athlon XPs here and I've never seen these keyframe problems at all. I always snatch Koepi's latest builds. Is this a CBR specific issue for you guys?

Edit- I've been running a few Quant 2 tests on my favorite clips using Koepi's XviD-03012003-1 build. Seems as though using lumi-masking increases the file size. Maybe it's not tuned for single pass quants yet?

[sam_b]

Always Koepi's latest, and happens in all modes (not tried CBR). Never had any problems w/o b-frames though. Just to clarify it is not the 'count excludes b-frames issue'. It never produces extra I-frames, regardless of the settings.

[wing1]

@MaTTer

are you using B-frame? I am only seeing this issue when B-frame is activated, otherwise, everything is kosher for both CPUs. I preferred CBR for my encoding but I am seeing this problem with 2-pass as well. My options are : 1-pass CBR, Ultra, H263, DX50, 120/1, Chroma ME, 4/150/0, B-Vop compatible, and default for the rest.

@sam_b

As stated by @Koepi earlier post regarding the b-frame issue on these latest builds, I am only providing 'if relevant' feed back as to what I am seeing during my tests on the 'latest and greatest'. I used a P3 at work but i don't own any at home :D. (so don't go out and buy one :D). As far as using for my real encoding purpose, I use Koepi's 09122002-1 build (no b-frame problem in that build for both CPU).

[MaTTeR]

@wing1

I typically don't have a need to use B-Frames but I just ran a few short tests with them on. According to VdubMod the clip was 17323 frames (12mins 02secs) and had a total of 1085 keyframes. This particular clip is mostly high action, opening scenes from Pitch Black. I encoded using Chroma Motion, B-Frames 1/125/100, B-VOP Compatability using a fixed MPEG quantizer of 2. I've never really used the CBR option to be honest, mostly 2-pass and fixed quant settings. Does this help you at all?

[duartix]

I'm sorry to bother with such a small thing but I found this one with Koepi's version date 2002/12/9:
I'm not able to test a newer version now because I'm in the middle of a lengthy encode so I ask anyone to quickly verify this:

When I go to the last frame of the movie I can go down to the status bar of VDubMod and copy the frame number.
Then when I go to the XVid configuration dialog, if try to paste that number into the credits begin/end frame, it takes it but doesn't remember it when I close the configuration dialog. If I just type the number, it works fine.
Looks like the paste command is not changing the status of the dialog.

[drebel]

Tried latest Koepi's build.Decoding yv12 avi is without probs in standard video rendener,but when connecting to VMR9, decoding speed is awful(vmr reports ~19 fps),but the quality is great! :)
Is it because i'm not using directx9 compliant drivers?Should we just wait for new detonators for Gforce,or is it something else involved?
From what i know,Nvidia still hasnt announced those drivers...

Duron @933,Gforce2MX,win2ksp3,directx9 here

regards,
george

[kilg0r3]

@duartix

make sure the pasted string does not contain a space character. if you get the string by double clicking the number in the status line, it usually will contain a space character at the end.

It's the details that wil kill us in the end :D

[drebel]

Decoding speed improved dramatically from ~19 fps to ~24,x fps(pal) using VMR9 ,xvid.ax and the latest detonators (42.01 uncertified and directx9 compatible) but still produces some framedropping ...Seems like the filter is still heavy enough for my Duron @933

regards,
george

[duartix]

Thanks kilg0r3!
:o :o :o

[kilg0r3]

i love to make people blush :D

[MaTTeR]

@Koepi,

Indeed it seems you were right, Qpel alone is working much better with your 03012003 build. I'm still seeing a slight noise smearing problem on a few scenes when you have a moving object in the foreground while having a solid colored background. If your not looking for it then most people might not see it though. Kudos to you, SysKin and the rest of the Developer crew!

I think I brought this up before but I was wondering if it was possible for XviD to output the Qpel frame info to DebugView. Just wondering what your thoughts are on the subject.

@iago,

Youv'e been quite lately :-) Have you been able to do any more tests with Qpel?

[serbersan]

@Matter

I have had the same results you've obtained more or less, the quality is outstanding, only a little neearly invisible smearing and maybe a little color displacement all when watched with ffdshow, but without problem with the xvid decoder.

For me this feature is the best nor bframes or other features. Bframes are good but I can't improve nearly dvd quality rips with them but I can with qpel... it's totally amazing.

Good luck for developers, really a authentic prefessional developers. I haven't seen such a good programers in any of my jobs and I'm a programmer too.

[iago]

Originally posted by MaTTeR
@iago,

Youv'e been quite lately :-) Have you been able to do any more tests with Qpel? Matt,

I have burnt my motherboard! I'm writing on another PC now! I'm totally f****d up these days! :mad:

[mikeson]

@all XviD developers:

Acording to this part of changelog

11.1.2003 21:40:
U xvidcore/src/decoder.c (rev.1.37.) chl:
- decode GMC blockbased (speedup)

11.1.2003 21:00:
U xvidcore/src/decoder.c (rev.1.37.) chl:
- Cleanup GMC, bugfix GMC+QPel
U xvidcore/src/encoder.c (rev.1.76.) chl:
- Cleanup GMC, bugfix GMC+QPel
U xvidcore/src/bitstream/bitstream.c (rev.1.28.) chl:
- Bugfix new GMC + Qpel

11.1.2003 19:00:
U xvidcore/src/motion/motion_est.c (rev.1.44.) chl:
- bugfix PMV_CHROMA vs. XVID_GMC

11.1.2003 17:40:
U xvidcore/src/motion/motion_est.c (rev.1.44.) chl:
- minor changes in GME, removed typo in calculation of meany

11.1.2003 15:00:
U xvidcore/src/decoder.c (rev.1.37.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/decoder.h (rev.1.10.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/encoder.c (rev.1.76.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/encoder.h (rev.1.18.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/global.h (rev.1.13.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/portab.h (rev.1.26.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/xvid.h (rev.1.17.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/bitstream/bitstream.c (rev.1.28.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/bitstream/bitstream.h (rev.1.10.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/bitstream/mbcoding.c (rev.1.25.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/image/image.c (rev.1.20.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/motion/motion.h (rev.1.13.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/motion/motion_comp.c (rev.1.11.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/motion/motion_est.c (rev.1.44.) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/motion/motion_est.h (rev.1.1.2) chl:
- Major update: Support for GME/GMC with 2 warppoints
U xvidcore/src/utils/mbfunctions.h (rev.1.10.) chl:
- Major update: Support for GME/GMC with 2 warppoints

should we start testing encoding with GMC enabled now?

Thank you for clearing this up to me :)

[Koepi]

Thanks for posting the changelog, we sure don't know how to access it :P


And no. Gruel explicitly wrote that he wants the new code tested by developers only for at least a week before it makes it into a public release.

Unofrtunately i have no backup of my sources before that code addition and thus can't update my binary until next weekend.

Regards
Koepi

[mikeson]

@Koepi:

Thank you for explaining. :)

P.S. I've posted this part of changelog just because I want everybody to know what I'm refering to. ;)

[Pasqui]

@Koepi
As sysKin deactivated GMC in .rc file, maybe you could provide a new binary ? (I'm waiting for a version with new lumi code AND credits encoding fixed :D )
Thanks in advance if you agree on this,

Pasqui.

[ookzDVD]

Originally posted by Pasqui
@Koepi
As sysKin deactivated GMC in .rc file, maybe you could provide a new binary ? (I'm waiting for a version with new lumi code AND credits encoding fixed :D )
Thanks in advance if you agree on this,

Pasqui.

@Pasgui,
You can use the uManiac's latest build while waiting Koepi
releasing new build later.

[Teegedeck]

So; with gruel saying GMC could now use as many testers as possible, I guess that means the ban has been lifted? :)

[Koepi]

he wrote "if nobody finds errors in the next hours", not minutes Tee ;)

Regards
Koepi

[Teegedeck]

Sheesh, I thought I could pretend to live in a different time-zone.

[Koepi]

XviD-15012003-1:
- Fresh CVS checkout.
- Fixed I/P/B-decision - crash problem solved, iframes should be set correctly now.
- Added simple idct. QPel smearing bug will resolve with the next ffdshow/lavc version.
- Gruel's new 2-warppoint-GMC code (rc4) - doesn't work with chroma ME yet.

here you go, enjoy! ;)

And don't forget to report results.

Best regards,
Koepi

[ookzDVD]

@Koepi,

welcome back :)

[JagPanzer]

Koepi, thanks for a new build. ;)

[Teegedeck]

Thanks, Koepi! :cool:

I just ran another 1st pass on a piece of Japanese animation. The drop in encoding speed wasn't as radical as I'd thought - about 1/3.

Unfortunately, GMC only saved 0.89% on this one. :p

Possibly because I had to disable chroma ME whereas the orginal 1st pass of this video was with chroma.

I'll give it another go with chroma and GMC disabled to get a more accurate idea about GMC's effects. Visually it was great, though I can't tell whether it's been used on all pans because of some incompatibility with ffdshows 'decode using xvid', again. [EDIT: Oh, ffdshow alone decodes it correctly, so now I can tell a bit more: GMC seems to be used in zooms like it should be, but a lot of the time it isn't used on pans. Especially slow ones, as far as I can tell. I'm watching a slow vertical pan, now, where it does kick in only for one frame or so. Though - perhaps XviD's decision is that GMC wouldn't help here? Don't know enough about the theory, so...]

Thanks again to all the devels, it's unbelievable how good it's got already!

[bilu]

@koepi

- Added simple idct. QPel smearing bug will resolve with the next ffdshow/lavc version.

Why on next version? ffdshow already uses simple IDCT. does it need modifications?

[HarryM]

I tested GMC too. Mainly with few-days-older uManiacs builds (before syskin deactivated it). Today I will test the Koepi's newest build.

Effectivity of GMC is better with q-pel activated (relativelly). But compressibility improvement is very symbolic - about +1% - maybe +2% especial still. It is comparable to ChromaME improvement.


You have dilema: 'very symbolic compressibility improvement' vs 'relative grow CPU usage'?


My top of advanced features (at compressibility effect):

B-frames (from +10 to +30%)
Q-pel (from +2 to +5%)
GMC (from ? to ?)

[Teegedeck]

Sooo, for my 2nd try to get the net effect of GMC. I thought wrongly that chroma ME had reduced my filesize, the opposite was true. Comparing a no-chroma-ME, no-GMC encoding against a no-chroma-ME, GMC encoding (both with QPEL and B-frames), GMC yielded a filesize-reduction of 0.4% on this Anime.

[HarryM]

Originally posted by Teegedeck
Sooo, for my 2nd try to get the net effect of GMC. I thought wrongly that chroma ME had reduced my filesize, the opposite was true. Comparing a no-chroma-ME, no-GMC encoding against a no-chroma-ME, GMC encoding (both with QPEL and B-frames), GMC yielded a filesize-reduction of 0.4% on this Anime.


Hmmm.
But I look at credits encoding especially. This part is as created for GMC, right?
Regular, fullframed movement - vertical scrolling... it is (maybe) ideal situation for GMC aplication.

[Teegedeck]

Yes, but most of us already use very strong compression for the credits, not much to gain, here.

[Edit: Funny enough, no GMC at all in the credits over here.]

[sysKin]

Please note that if Koepi hasn't changed the code, GMC is disabled for clear camera panning. Such thing can easly be done using normal motion vectors, gmc doesn't improve it - that's why divx5's gmc is so poor.
Current gmc only gets enabled when zoom/rotation is detected.

The exact rules for enabling/disabling gmc are not created yet, and this is why current gmc doesn't perform good. Just wait some more :)

[Teegedeck]

That explains it, thank you, sysKin! :)

The essence of our tests so far: GMC does save space and it does look good!

[HarryM]

Originally posted by Teegedeck
That explains it, thank you, sysKin! :)

The essence of our tests so far: GMC does save space and it does look good!

Yes, save space. I agree.

@Syskin:

The precision of GMC feature is absolute or little macroblock ME deviations = 0, in favour of GMC?

[sysKin]

Hi, I just have some news:

1. there was an error in our code, and this Koepi's build is probably affected: ChromaME doesn't work at all. Flag's name has been changed in the core, but no change has been made in the VfW interface...
I just commited a fix, expect it at uManiac's first.

2. I just fixed ChromaME + GMC. They work together now, and when ChromaME is enabled it also helps GMC.

The precision of GMC feature is absolute or little macroblock ME deviations = 0, in favour of GMC?Sorry, I dont know what you mean ;)

Best regards,
Radek

[Teegedeck]

Koepi's build from the 3rd of January wasn't affected, was it?

ChromaME + GMC, here we go! :D

[mfluder]

I just wanted to confirm that using this build with qpel enabled and using latest libavcodec (compiled on linux) for decoding there is no more smearing and picture looks just like when decoded with XviD native decoder - perfect. So it looks like the key is to use simple idct. It would be great if this can be officialy supported by including it in CVS but I guess thats on developers to decide :)

Thanks Koepi for this new build,
mfluder

[cult]

with umaniac's instant build 15.1.2003 15:00:
a friend of mine said that whatever he did he was getting an oversized movie with this build.Same movie with koepi's XviD-03012003-1.exe was ok.
that made me wonder so I made a few tests.here are the results:
quant 2/size is(5.310.464 byte)
2pass same settings/target 4mb-final size 4,95 MB (5.191.680 byte)
2pass,same setting/target 1mb-final size 3,93 MB (4.122.624 byte)
all bframes(2),gmc+chroma,motion search 6
same 1000 frames encoded every time
I wish i did nothing wrong and set a false alarm...If that' so then excuse my ignorance,only trying to help

[ookzDVD]

I use latest Koepi's 15012003-1 and got over-sized problem.
B-Frame enabled, 3/100/200, no Qpel, no GMC, ChromaME enabled.

1st-pass : 23MB, Target size : 11MB, Final 2nd-pass : 15MB.

Add:
Second try with uManiac's latest build with syskin's update,
XviD.Alpha.15.01.2003.1500.exe
use B-fram enabled 3/100/200, Qpel, GMC, ChromaME all are enabled,
the result is Ok! _but_ still oversized,

1st-pass : 11MB, Target size : 5MB, Final 2nd-pass : 10MB. :(

Add:
I can confirm that the latest on target size is with uManiac's 13012003, after that date as like Matter said, it will oversized.

Thank you.

[MaTTeR]

Oversize problem here using B-frames alone (1/150/100) also, it started with the 1-14-2004 build from uManiac.

Qpel with B-Frames and Qpel alone look outstanding with this latest build though! The smearing problem does seem to be history. I just can't say enough about how detailed and crisp the images are with Qpel. Great work as always guys:)

[alx]

Same oversize problem here with latest Koepi´s (15/01) and Umaniac´s (15/01) builds.
1 pass=961 mb. // 2 pass=623 mb. // target=325 mb.

Looks like GMC + Chr.ME works fine now in Umaniac´s latest build.
Thanks a lot for your effort ppl.
Alx

Sorry, forgot to mention........B-Frames 3/100/200.
My mistake.

[ookzDVD]

Yes, I can confirm that, as I have post on other thread.

[Koepi]

Merged the threads: why opeing a new thread if the reports for that repeat already here?

Regards
Koepi

[Teegedeck]

Just to round it up; my 1st pass with GMC + chromaME (uManiac's build from 15th) gave me a 1.01% smaller filesize than my initial (chromaME) encode with Koepi's 03012003-build.

That's good. I mean, there's a limited amount of zooms in this Anime I encoded. Thx!

[Bulletproof]

Has anyone noticed smearing in the video when using high quantizers w/ Qpel? I set my credits to grayscale w/ quantizer 15, and when the credits are scrolling you can clearly see a very long trail.

[ookzDVD]

Just try the uManiac's 16012003,
I think B-frame + Qpel + ChromaME + GMC is broken again. The old one 15012003 build is working well.

PS. The oversized problem is still ongoing.

[scorchED]

Originally posted by Bulletproof
Has anyone noticed smearing in the video when using high quantizers w/ Qpel? I set my credits to grayscale w/ quantizer 15, and when the credits are scrolling you can clearly see a very long trail.

I think thats because of the high quantization. you can see the trail with or without QPel.

[mikeson]

Has anyone noticed smearing in the video when using high quantizers w/ Qpel? I set my credits to grayscale w/ quantizer 15, and when the credits are scrolling you can clearly see a very long trail.

Try to decrease Maximum I-frame interval to something like 30 instead of 300 (just for end credits of course, otherwise let codec decide to insert keyframe).

[Koepi]

<repeat mode on>

If you playback through ffdshow, it still uses an older libavcodec version. This version has a rounding-bug.
It's fixed in current CVS, but not available in binary form yet.

Next to that, use i.e. my newer builds (_after_ 03012003), our "old" idct has some interpolation troubles and thus can smear the result (setting ffdshow to use xvid idct should solve that issue then as well). But my new builds use simple idct which performs better in qpel quality wise.
<repeat mode off>

Koepi

[sysKin]

Originally posted by Koepi
Next to that, use i.e. my newer builds (_after_ 03012003), our "old" idct has some interpolation troubles and thus can smear the result (setting ffdshow to use xvid idct should solve that issue then as well). But my new builds use simple idct which performs better in qpel quality wise. Actually,using 'xvid' idct never solved the problem. However, make sure you _don't_ use 'xvid' idct anymore in ffdshow, it will be ugly. Use 'simple', as (as Koepi said), that's the one we use now.

[Franko30]

Hi and sorry I have to bring this up again.

I've also encountered the oversize problem (and now got back to the last unstable build working for me: Koepi's 03-12-2002 build). So I've only been lurking, as
others
already
mentioned
the problem
here.

But as nobody really discussed the topic I wanted to ask, whether the reason is found and people just don't have time to release new builds right now or whether nobody has a clue why the encodings with builds from Jan 14th onwards come out oversized?

Notice: I'm not demanding ;) - I'm perfectly happy with the December 03 build - just wondering why the problem has disappeared from this thread... :confused:

Cheers

Frank

[CruNcher]

@ Franko30
the devs know that this problem exists but their priorities are in other more important advanced simple profile problems like for example GMC the time to rewrite the whole 2 pass system would hold them up from doing that so we have to wait and see :)

[JasonFly]

I have tested 03/01/2003 build and I didn't notice that there was a problem with intra frames repartition.
I have done a first pass for a movie and I'm wondering if it will be necessary to do another 1 pass if I switch to another build.

BTW, I haven't test all the insta build, so I'm wondering what is the "best" build.Is the 29/12/2002 build ok?

Would it be possible to make something(a dedicated post?) to report insta build not to use(because of big problems) and insta build that are nearly ok?

[NiTroGen]

Using the StatsViewer program with a stats file created by Koepi's 15/1 build I found that there are LOTS of delay and skipped frames. What's wrong? Is there a new change to the nns.dd_v bits?

I attach a stats file and a StatsViewer report for example.

[cult]

@JasonFly
As far as I can tell by my tests.the oversized bug is not in 13 instand build.I have used for 2-3 movies.Everything looks good

[Aktan]

I got the oversized bug too, but I noticed in dbgview that for every bframe xvid encodes, the overflow doesn't change! This looks like the causing the oversize bug. Maybe?

[kilg0r3]

any news (verification or cause) about the impression that the lates keopi build has a less sharb image than umaniacs?

[HarryM]

Koepi's 15012003 and uManiacs newer than 13012003.1500 builds are buggy. Bug is in generate stats file (1st pass) with b-frames using.

Newest _good_ build is uManiacs 13.01.2003.15:00 (I have it)!

[iago]

Originally posted by HarryM
Newest _good_ build is uManiacs 13.01.2003.15:00 (I have it)! HarryM and all,

It still can be found on uManiac's site, btw ;).

iago

edit - just click "older build" link at the bottom of the page!

[R3g]

Sorry to ask that, but I've been away for a while, and there is so much to read... So, could anyone tell me which is the latest unstable build to be bug-free enough to be used in real life encodes ?

[ookzDVD]

Originally posted by R3g
Sorry to ask that, but I've been away for a while, and there is so much to read... So, could anyone tell me which is the latest unstable build to be bug-free enough to be used in real life encodes ?

You better use the uManiac's build 13.01.2003.15:00,
Note: GMC is disable, Qpel, B-frame and Chroma ME is OK!

Direct link : http://umaniac.leffe.dnsalias.com/alpha/XviD.Alpha.13.01.2003.1500.exe

Make sure use the FlashGet or GetRight, the site is slow :(

[Wormz]

Originally posted by ookzDVD
You better use the uManiac's build 13.01.2003.15:00,
Note: GMC is disable, Qpel, B-frame and Chroma ME is OK!

Is it ok to use Qpel and B-frames together on this build? It may sound like a stupid question to some, but I think I remember previous builds only being able to use one or the other so I want to make sure.

Thanks

[igor140]

Just in case you haven't found out yourself, yet

I just tried an encode with Umaniac's 13-1-03 build for first pass and Umaniac's 15-1-03 build for second pass with qpel and gmc enabled. Size was almost perfect and quality came out better than using the older build alone (and without gmc, of course)

[Wormz]

Originally posted by igor140
Just in case you haven't found out yourself, yet

I just tried an encode with Umaniac's 13-1-03 build for first pass and Umaniac's 15-1-03 build for second pass with qpel and gmc enabled. Size was almost perfect and quality came out better than using the older build alone (and without gmc, of course)

Is GMC definitely being used when you do this? If so, great job finding this temporary workaround until it is fixed.

Also, you didn't say if you were using B-frames or not. If you weren't I don't think it should have been oversized anyway.

[HarryM]

Originally posted by Wormz
Is GMC definitely being used when you do this? If so, great job finding this temporary workaround until it is fixed.

Also, you didn't say if you were using B-frames or not. If you weren't I don't think it should have been oversized anyway.


GMC is O.K., but have only minimal positive hold on compressibility, actually. Generallly is less than 1% (often about 0.2-0.3%!).

Accordinly I don't recommend for using GMC, for now.
I'm waiting (and champ) for the more improvement (powerful) GMC. :D

[kilg0r3]

as test clip for the functionality of gmc, i recommend the start titles of spiderman

[HarryM]

Originally posted by kilg0r3
as test clip for the functionality of gmc, i recommend the start titles of spiderman


Hmm, and why? It is 'born' for GMC?

[kilg0r3]

erm, ok, sorry for being a 'bit' unspecific. The clip simply contains a large amount of rather pure zooming and circular motion which afaik are that what gmc has been designed for.

[igor140]

@wormz

yes, I used b-frames, but I cannot tell with absolute certainty that GMC is actually used. How can you tell for sure?

[Tueurne]

report bug In cvs 15-16 /01

- 2nd pass int encode qant 2 on umaniac and Koepi's builds
- direct show filter freeze when i try to decode movies wheras others video filter are install. like ffds and divx. if i install it alone it's ok

[iago]

@igor140

Simply tick "OSD" and the "frame type" option of OSD in ffdshow.

[JasonFly]

It's my fist bframe encode that I analyse with XDA 0.18 and I found very surprising things.(I ve used 13/01/2003.1500 build from Umaniac)

First of all, it says that there are 66% of the movie encoded with bframeand I am wondering if that's a "good" value or if it's more than usual.
I have used 3/150/100 parameters for bframe.


Then, i have a lot of consecutive intra frames (1097)
Some times they are needed(I have watched the movie).Some parts are some "psychedelic effects". In one of those part, i have 72 consecutive intra frames.I can understand that, but there are other parts which are not very difficult to encode(a panning) with sometime between 10 and 20 consecutive intra frames.

I'm wondering if that's normal.Maybe It could be due to a good compressibility of the film(an anime to be precise:Metropolis) but the lenght is approximately 1h44 and the compressiblity is about 80% for the resolution i have choosen.

I was used not to have any consecutive intraframes using stable build, even for difficult movies, and that seems to me strange.

EDIT: i have also 3 skipped frames.

[MoonWalker]

Originally posted by JasonFly
EDIT: i have also 3 skipped frames.


The skipped frames are normal due to the 3 bframes you set..The VFW needs to buffer 3 frames for the bframes...If you have set 4bframes you whould get 4 skipped frames..

One more question..Do you see at the analyze.txt credits with quant2?? I think there is a bug in xda :)..

MoonWalker

[kilg0r3]

i can confirm that in the umaniac builds there is such a problem. the latest cvs build does not even respect a set minimum iframe interval. koepi03012003, however does; i think.

further more block flickering also persists in this build

[JasonFly]

Yes Moonwalker, there are some credit frames with quant 2 but not the major part(50 frames on 7000)

But there were also problems on iuntra frames somtimes in the credits.
Sometimes many intra and a few seconds later return to a normal repartition.All this was reproduce many times.
Very strange, No?

[kilg0r3]

just retested koepi's jan 3rd 2003 build (because of the size bug), and, it does not respect the minimum iframe intervall either. I got up to 79 (!!) consecutive iframes; analyzed stats file with xda. The iframe behavior seems to be exactly the same like when the min iframe interval is set to 1. Sum total ws 1179 consecutive iframes. Has anybody observed wether the bitrate reduction for consec iframes works?

BTW i plead for a new thread for every koepi build. one problem that arises in such huge threads, is that lazy people like me wont even start reading through the whole thread but ask their question right away. Please pretty please with sugar on top, make it real. :) And, some conventions on how to name/type things would make the forum much more searchable. sometimes there are a lot of variants e.g. iframe, i-frame, intra frame, intraframe, intra-frame, keyframe, key-frame, key frame.

[The Link]

@ kilg0r3

As a lazy forum reader you got my vote! :D
But seriously I think you´re right with that suggestion. Some threads just became multi-topic miles long monsters.

Regards,

The Link

[MaTTeR]

Originally posted by kilg0r3
BTW i plead for a new thread for every koepi build. Yes, it would be so much easier and organized to find information.

Oh, your right again about the flickering.

[kilg0r3]

Just for my orientation:

Issues with two latest Koepi Builds

koepi 03012002

+ too many consecutive iframes even in not stressy situations
+ not respecting minimal keyframe interval setting
+ bframe flicker; weak but visible; not sure if en- or decoding issue. does not show in vdub, i think.
+ qpel smearing (not an issue of the encoder actually but of libavcodec (?)
+ occasional crashes


koepi 15012002

+ all of the above (?) except the crashes
+ GMX not saving too many bits
+ rate control seems messed up -> too large files

is this correct so far?

One more thing: in my last encode (spiderman) setting bframe quantizer to 100% and bframe offset to 100 resulted in lower average quants of my bframes than those of my pframes.

Average P-Frames Quantizer Used for Movie : 3.367
Average B-Frames Quantizer Used for Movie : 2.860

btw i encoded the movie (116min) in 592x302 going for one xcd and the result iiiiis .... well .... simply amazing. with ffdshow noise set to 18 the bframe flicker and the qpe trails are invisible. thank you xvid(-team), thank you vorbis, thank you vlad59 (conv3), marcFD (mpeg2dec3(xxxxox) and SimpleBicubicResize)!

[sysKin]

Originally posted by kilg0r3
[b]Issues with two latest Koepi Builds

koepi 03012002

+ too many consecutive iframes even in not stressy situations
Known, fixed
+ not respecting minimal keyframe interval setting
yes, we know....
+ bframe flicker; weak but visible; not sure if en- or decoding issue. does not show in vdub, i think.
It should be in vdub as well, it's encoding probalem and a big mistery
+ qpel smearing (not an issue of the encoder actually but of libavcodec (?)
I can't wait for new ffdshow, it will be fixed then
+ occasional crashes
How? When? Really?? Oh my, not again.... Could you please provide with some more info?
+ GMX not saving too many bits
Sure, with current P_VOP/S_VOP decision it's amazing that it saves anything ;)
+ rate control seems messed up -> too large files
True. Only with bframes.
One more thing: in my last encode (spiderman) setting bframe quantizer to 100% and bframe offset to 100 resulted in lower average quants of my bframes than those of my pframes.

Average P-Frames Quantizer Used for Movie : 3.367
Average B-Frames Quantizer Used for Movie : 2.860
Where did you get the values from? It shouldn't be true.

It's good to make such summary from time to time.
It would really be great if we abandoned this thread. Really. :) How long can it be...

Thanks for testing, everyone.
Radek

[wotef]

how about a "currently known-issues" sticky? that only mods can update?

[mikeson]

@Koepi, sysKin:

May I dare to repeat my question I've posted several days ago why isn't refdivx' lumi masking code included in CVS? As Koepi has said it is better than old lumi masking code.

Or maybe it is already there and I'm dumb. ;)

[igor140]

I finally got round to checking if my workaround for the filesize bug actually uses GMC and I can tell for sure now - it does.

[Wormz]

@igor: I can confirm the workaround as well. Really doesn't seem to be saving much, but good job anyway.

Could someone explain Qpel to me a bit? In my tests, it actually seems to increase filesize quite a bit. Does it improve quality enough that it cancels out the extra bits it requires?

Also, in what build did the B-frame flicker first appear? I'd like to do some comparison tests.

[kilg0r3]

@syskin

-> bframe flicker: i am really am not sure but i think it is not visible in vdub. atleast it is far less visible than in any media player.

-> the crashes: this is something i have not experienced myself. i only 'felt' i read about it somplace/time read about. so regard this as false alarm until further notice :)

-> strange average bframe quant: the data is from xda analyzing the debug output. however, my log file contained 1st and 2nd pass data. so i had to edit it, and i am not sure if i did it right. just to make sure, what are the first debug lines that xvid gives at the beginnng of the second pass?

[MaTTeR]

Originally posted by kilg0r3
just to make sure, what are the first debug lines that xvid gives at the beginnng of the second pass? AFAIK it should be something like- [908] middle frame size for asymmetric curve compression: 6536

[MoonWalker]

Originally posted by kilg0r3
-> strange average bframe quant: the data is from xda analyzing the debug output. however, my log file contained 1st and 2nd pass data. so i had to edit it, and i am not sure if i did it right. just to make sure, what are the first debug lines that xvid gives at the beginnng of the second pass?

As syskin said :

Codec actually asks the core for a specified quant, and prints this quant to debug view - but it doesn't matter. This quant value will be ignored for b-frames.
It would be nice if xvid.dll didn't print this value at all. It should also be ignored in the statistics...

So the avg bframes are somehow wrong :)...There is a way to fix it in xda (apply the quant formula for bframes) and I intend to do it when I finish the exams..

MoonWalker

[ak]

I did sveral encodings few days ago, there were sync probs, some clips had lots of dropped frames.
I just did very short clip recently, and (according to VDub) amount of droped frames (at the beginning) depends on bframes settings used (e.g bf=5 -> d=5, bf=3 -> d=3). W/o bframes no drops occure.
Casual encodings (not capture), const quantizer, motion 6, H.263, chromaME, everything else disabled.
Happens with both uManiac's and Koepi's builds (15jan), prior builds were ok.

[NuclearFusi0n]

Originally posted by ak
I did sveral encodings few days ago, there were sync probs, some clips had lots of dropped frames.
I just did very short clip recently, and (according to VDub) amount of droped frames (at the beginning) depends on bframes settings used (e.g bf=5 -> d=5, bf=3 -> d=3). W/o bframes no drops occure.
Casual encodings (not capture), const quantizer, motion 6, H.263, chromaME, everything else disabled.
Happens with both uManiac's and Koepi's builds (15jan), prior builds were ok.
dude read the damn forum/thread.
that's normal.