XviD-19122002-1

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