XviD-19122002-1

[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?:)