Niltze! (XviD-1.0-RC1-26012004)

[BlackMetal]

Hi, I'm still using XviD-24062003-1.exe, but am gonna switch to RC1 soon. I just wanna say something about the sometimes choppy playback, cause I recognize that, even if I haven't tested XviD 1.0 yet. I don't think it's an XviD problem.
Cause when I use MPC and have Overlay Mixer activated and an XviD with b-frames and vobsub activated, the playback is choppy. With VMR9 it runs smoothly. BUT with vobsub deactivated and Overlay Mixer turned on it runs smoothly. So maybe it's not an XviD bug, I don't know if it's the same in XviD 1.0, just wanted to fill in with some info. :)

Keep up the good work with XviD!

[crusty]

seewen:And XviD ALWAYS reached the correct size
Jaw3000:, I too am getting oversized files. I've tried encoding some DVD Backups of Italian Job and Tomb Raider 2 as well as a TV show I've captured, and have gotten oversized files (of about 2GB when I set it to 698MB) with both beta 3 and RC1.
Now this is getting really odd...

We have one person stating he has no oversized files problem with the RC1 build, and another person saying he gets oversized files with both beta 3 AND RC1 builds. And then we have seewen stating that he sometimes has the problem.

@seewen, ark & Jaw3000: could you please state as much information as possible, including used avisynth & virtualdub(mod) version, avisynth script, wheter or not you used Gknot, Xvid settings?

Please try using the same version of these tools and only RC1, and try to see if the problem can be nailed down to a certain option-combination.
Using a small clip of 10.000 frames will give us results a bit faster.

Also, remember, the RC1-installer will load the default values for you, but if you go back to beta 3 you have to hit the 'load defaults' button again.
Ark:
but, with other little tests with some DV footage captured I got heavy oversized files, something like 150%-175% of a 2-31Q encode with same settings...
Hmm... was the DV-capture interlaced? What was the target file-size and result filesize?

Also: is anyone testing RC1 with some other tool than virtualdub(mod)?
Does he also get oversized files?
Change the overflow treatment values to something like 10/20/20, leaving the quant ranges at the defaults 1-31, and do your second pass again. You'll see that you hit your target size accurately, the only difference being the use of quant 1 frames in your encode.
Could someone please verify this? Ark, Jaw3000?

[Koepi]

We're still thinking about automatic overflow settings for q1 stuff - that is a _known_ issue :)

Regards
Koepi

[Jaw3000]

That's so odd! I was getting oversized files with both beta 3 and RC1, but this time I got undersized files. All of the below have been encoded using RC1, GK 0.28.7.2, VirtualDubMod 1.5.10.1, and I set it to encode to two cd's at 698MB a piece:

Tomb Raider: The Cradle of Life with default XviD settings and AC3 audio:

This was really strange. I know the compression is better, but? :) How could a 117 minute movie 896MB (375MB of it being sound) and still be the best quality capable by the codec. This is when I set it at 1396MB or two cd's.
Full movie w/o sound: 516MB
Full movie /w sound: 896MB
AC3 audio file: 375MB

Italian Job with default settings and AC3 Audio:

I also got undersized files on this one. Full movie with sound being 896 MB (375 MB being AC3) when set to 1396MB or two cd's. In addition to encoding using the default settings, I also encoded it two more times with different settings and got results at the same size as the default settings (give or take a few bytes). I tried it with "Discard First Pass" off and everything else default. And I tried changing Quant to 2 with all of the rest default.
Full movie w/o sound: 517MB
Full movie /w sound: 875MB
AC3 audio file: 354MB

The odd thing is both of the two movies I tried came out at basically the same size (516 and 517MB)! What do you think could be causing the under-sized files now? Any ideas to try?

Next up: A 45 min AVI I've captured. This was coming out at 2GB when it should be under 600MB. I'll post the results when it's finished.

-Jaws

[Ark]

Ark:

Hmm... was the DV-capture interlaced? What was the target file-size and result filesize?

Also: is anyone testing RC1 with some other tool than virtualdub(mod)?
Does he also get oversized files?

Could someone please verify this? Ark, Jaw3000?

My system is an Athlon 2000+, WinXP Pro, 1gb RAM, HD 7.200 rpm

- The DV capture was PAL, 25 fps, 720x576 interlaced.
- My Avisynth is v.2.5.3
- VirtualdubMod is v.1.5.10.1
no other software used (so no GK)

With a little Avisynth script I converted the AVI to a smaller size:

source = AVISource("C:\....\clip.avi")
return source.Separatefields().SelectEven().BicubicResize(384,288,0,0.5).Crop(8,8,-8,-8)

..resulting in a 368x272, 25 fps, progressive AVI.

I encoded only the first 1500 frames of this video (1:00 minute), aiming for 5mb only for various compression tests, and I got:

- 1 file of 3,65 mb (with q. range 2-31)
- 1 file of 7,54 mb (with q. range 1-31)

The quality was good on the fisrt file and way better on the second, but the size...!

The Xvid settings was:

--Main settings------------------------
Profile @ Level = AS @ L5

--Profile------------------------------
Adaptive Quantization
Quarter Pixel
B-VOPs (default) 2/1.50/1.00
Packed Bitstream
Closed GOV

--Motion-------------------------------
Motion Search Precision 6
VHQ 1
Chroma Motion
Maximum I-frame interval 250

Intra-frame, overflow and Curve compression for 2nd pass at default values.
ALL the rest at default values.

That's should be all I think!

Sorry I can't verify using other softwares (for now..)...

[Koepi]

Originally posted by Jaw3000
That's so odd![...] this time I got undersized files.
All of the below have been encoded using RC1, GK 0.28.7.2, VirtualDubMod 1.5.10.1, and I set it to encode to two cd's at 698MB a piece:
-Jaws

I am tempted strike you for not at all reading this forum but just posting your problems - are you too lazy to search, don't want to invest that small amount of time, but waste time for other people?

- Don't use automated tools like gknot with XviD-1.0-* - those tools aren't yet adopted so they don't work peroperly with it!

- VDub(mod) > 1.5.4(.1) are buggy as hell. Use Vdub(mod)1.5.4(.1) instead.

- A simple search on "undersize" or "codec saturation" would give you the answers you need to know.

All this is written many times in this very thread. I don't get how you fail to read it.

Koepi

[Ark]

Originally posted by Koepi
- VDub(mod) > 1.5.4(.1) are buggy as hell. Use Vdub(mod)1.5.4(.1) instead.

This is my fault too, sorry.

I'll get VDubMod v1.5.4 as soon as possible and see if the oversize problem still happen.

[Koepi]

The oversize problem is another thing - it's the restrictive overflow handling. If you use quant1 in the quantizer range and a quant1 frame gets used, it produces so much overflow that it may get impossible to compensate for.

But then again, like posted earlier, we're thinking about some graceful solutions currently which will get incorporated into RC2.

Regards
Koepi

[Jaw3000]

Originally posted by Koepi
- Don't use automated tools like gknot with XviD-1.0-* - those tools aren't yet adopted so they don't work peroperly with it!
- VDub(mod) > 1.5.4(.1) are buggy as hell. Use Vdub(mod)1.5.4(.1) instead.
- A simple search on "undersize" or "codec saturation" would give you the answers you need to know.


I'm sorry! I truly am, but I'm a newbie trying to figure all of this out. I'm trying to learn, but it's confusing. Yes, I should have searched for "undersize," but as far as codec saturation, that would never occur to me as I don't know what it means. I know GK doesn't work "correctly" with XviD 1.0. Some times it works, and some times it doesn't. I happened to have used it that time. But I have also used just VDubMod for the encoding and the same things happened (oversized and undersized). As far as the VDubMod version, I didn't know that. I'm only using the version that came with GK. I also didn't think I was wasting anyone's time becouse I thought we were talking about GK at the time of my post. Earlier in this thread we were talking about GK not working correctly, and I thought we still were in that post. BTW, someone asked me to post my results in relation to GK (or so I thought). Again, I'm sorry!

I truly am sorry!
-Jaws

[Koepi]

Nah, I'm sorry to have gotten that upset. Sometimes this happens if I read (the same) things too often. My apologies.

Just make sure to use gknot only for setting up the avisynth scriptfile and encode that manually with the older vdubmod version. Also take a look at the first pass filesize (it's shown in the status window, if you closed it too early, use the statsreader that ships with my build). You can subtract ~10% from the first pass size (our first pass files get a bit larger due to the fast firstpass we implemented) - if that size then is below your desired size you're dealing with codec saturation.

Regards
Koepi

[Jaw3000]

Koepi: Thanks for your advice! :)

-Jaws

[stook]

Sorry about annoying... but back to overlay problem!!!
As I posted before (pg.6), I din't used vobsub and I got choppy playback with overlay active but only with xvid RC1 decoder, with all others decoders, playback goes just fine!!!
It's not a packed/bframes problem because I didn't use it...
(read my last post in pg.6)

[Koepi]

stook:

it's really an overlay problem you're having. Chane the renderer from/to vmr9/native overlay in i.e. BSPlayer or zoomplayer. You'll see that it gets solved therewith.

Also, sysKin is coding a lot on the dshow filter now and it might have been fixed yet (some wmp9 issues are solved for example).

Regards
Koepi

[stook]

I tested in Zoomplayer 3.30 (same with MPC 6.4.7.6) and with VMR9 playback is fine!!!
I only became confuse because in overlay, the playback is choppy only with all options off. The least I can do is make some more tests to know what option is making smooth playback with overlay!!!
Give me 10minutes :)

[iago]

Originally posted by Koepi
But then again, like posted earlier, we're thinking about some graceful solutions currently which will get incorporated into RC2.Great! :)

[stook]

I got the result... Strange... :)
In overlay, with Quarter Pixel and BVOPs on (only these) playback is smooth. If I turn off any of these two options, playback is choppy!!!
All other options doesn't modify anything in playback...
It's the only thing I figured out!!!
I hope it helps...

[SeeMoreDigital]

Hi guys,

The 'Niltze' version of XviD generates seriously good looking 2pass encodes. I've never seen Mpeg4 look so good... excellent work!

Being able to set the aspect ratio of anamorphic encodes is a very useful idea. Shame there are'nt many software players that support this feature yet (come on MPC!)

One thing I would really like to see.... Many moons ago DivX5.0.2 (excuse my language) incorporated an 'DivX MP4 Creator' (ie DivX.avi in - DivX.mp4 out) I found this little tool to be very useful.... Is there any likelihood of seeing such a tool incorporated into the XviD GUI?

Cheers

[thren]

thanks for the great work. i tested rc1 with vdmod 1.5.10.1 build 2424 and it worked perfectly. besides the quality is awesome.
thanks again

greetings

[tb2496]

I have the same problem with xvid's playback being choppy when using overlay. it plays fine when using divx's decoder for xvid files in overlay though...

[m0rtal]

I've got some strangeness...
I've noticed that in my last encoding I-frames are smaller than P-frames and even B-frames (i.e., in BPI row B is Q3 and 4.654b, P is Q2 and 11.806b, and I is Q2, 8.747b, following P and B frames are larger again).

also, sometimes instead of IPBP sequence there is IBP row... is it normal? I thought that B frames are based on two P-frames...

[split710it]

Hi friends

I proposed it in a new post, someone suggested me to pu it here, I sill have oversize problem unsolved

Tried new xvid codec RC1

I suffer this problem (my enigmatic always problems)

Source: VCD, MPG1 1.164.220 KB interlacedm 29.97 NTSC 352x240

IVTC to 23.976 + filters used Deinterlace, no crop because not copped the source (black screen was on the movie, I receive a terrific aspect ratio if I crop), used virtualdubmod 1.4.13, all without audio (source and destination)


I setted codec for two pass changing some values on zone (like for example quantizer to 1,40), Bframes 1, 1.00, 0.00

My request final size was 1.300.100

but Real size done is 1.750.516

WHY???

I don't understund this emblematic thing:

Is it not the TARGET SIZE deciding the "maximum" size possible indipendently to the codec setting????? (I can understund Undersize... I don't understund Oversize, I always wrongly thought target size will reduce automaticatly setting choosing better one to have right side after showing first pass datas)

To the end my final question is:

whitch is right way to have right size If is not target size deciding it???

ciao

[Koepi]

If you set encoding to use fixed zones (i.e. quant zones), in those areas the bitrate isn't modulated but the quant you choose gets used.

So guess what happens if you enter 2.000TB as desired size...

At fixed quant the filesize is fixed. Simple as that. Change your quant zone to a weight zone and you're done.

Koepi

[dapipa]

Originally posted by thren
thanks for the great work. i tested rc1 with vdmod 1.5.10.1 build 2424 and it worked perfectly. besides the quality is awesome.
thanks again

greetings

hi!what settings did you use?i'm experimentig with the same SW config as you(VDM1.5.10.1 build 2424&RC1),i've tried a lot of various settings for RC1(starting with those for newbies,and aplying tips found it this forum),but my encodes still look worse than the DivX5.1.1 ones:-(but DX is SOOOOO SLOOOOOW...
p.s.my source was SOLARIS/R2,which,i think,is a quite good source:very little grain,dark,low motion...

[cma]

Hello,

I've been comparing RC1 and beta3 build with koepi's build from 26.6.2003 by encoding the same movie with the same settings (lanczos resize, h263, chroma motion, vhq1, b-frames 1/1.5/1, decoded by ffdshow 23.5.2003, xvid idct).

Newer builds' quality is great and the speed difference is huge... the only thing that bothers me is that the "floating walls" problem seems to be a bit worse than with the older build. (i mean the problem where background textures in low detail areas tend to move together with foreground objects when they shouldn't).

I uploaded a short clip (http://kotisivu.mtv3.fi/kmm/tmp/sample.zip) to show the difference between rc1 and the 26.6 build. You can see it's not a huge difference, but enough to be annoying imho (look at the wall behind Michael Douglas's head). I guess this is only a minor issue since nobody's complaining about it but still, i'd love to see it fixed in the final release since Xvid is nearing perfection otherwise!


Also, I sometimes get both quant4 and 5 b-frames between quant2 and 3 p-frames with setting 1/1.5/1, is this normal?

[HarryM]

I tested RC1 few and explore, that q-pel isn't so powerfull as at older builds.
Videos is less sharp, much soft, I think.

???

[dimzon]

Yesterday when I setting up my DVD Rip I make mistate.
I set 516*396 output resolution instead 512*384. After encoding complete I got VERY corrupted playback :(

I think it will be better to show such warning message box when compression starts:

"width is not not mod32, result maybe broken"
"height is not not mod16, result maybe broken"

I think it may be optional feature cotrolled by checkbox in UI (checked ON by default)

sorry for my poor english

[sysKin]

Originally posted by dimzon
I set 516*396 output resolution instead 512*384. After encoding complete I got VERY corrupted playback :(I just tried 516x396, plays back perfectly with xvid and ffdshow.
What decoder did you use?

[dimzon]

Originally posted by sysKin
I just tried 516x396, plays back perfectly with xvid and ffdshow.
What decoder did you use?

DivX 5.1.1 beta 1 (my favorite decoder for DivX and XviD bcz it's PP)
XviD RC1

I can send screenshots tomorrow :)

[Seimour]

What is it for?
Does it decrease time/quality in the encoding process?
If not, can I use it also on the second pass or just only in the first one?
Well that's all (I hope)
Bye fellas.. ;)

[Koepi]

Seimor:

once again a warning: use the search. Go to some pages back, there it was already explained (well, or even better, in the Selam thread it was).

The turbo option enables some faster ME for qpel and/or bframes. A little quality loss for the sake of increased speed.

Koepi

[alucard83]

Sorry for the late reply, but this thing rocks! I encoded some several anime clips and everything came out smoothly! Packed Bitstream sucks though! As syskin mentioned, ffdshow has problems playing clips that have these, but I think a better option would be to leave it unchecked by default for the next release...or maybe an update to ffdshow? Doesn't matter to me, keep up the good work, Xvid developers
:)

[mikeson]

@alucard83:

Be careful when saying that something 'sucks', it shows disrespect to dev's work, especially here.

[alucard83]

lol, didn't mean it that way...the "sucks" was aimed at the dissatisfaction with my encode with PB. I guess it was the wrong vernacular?

Don't take it the wrong way Koepi and co.

[sysKin]

As for packed bitstream, both settings cause troubles. Have you ever counted the "what is b-frame decoder lag" questions? We removed these questions completely and added new ffdshow problems, but *at least* it's not xvid's fault anymore. N00bs will not complain if they see that xvid's decoder is fine... the most n00bish n00bs won't even try ffdshow.

We know how to disable it if we want to, and that is fine - while less expirenced users won't freak out.

Radek

[alucard83]

Yea I've seen those questions, and I realized it was the B-frames causing that while to eliminate that msg, PB will remedy it, but it turn, create its own share of probs. Personally, I really don't mind about that, and doesn't bother me a bit. I hardly ever need to re-encode something, and if I do, I'll just do another 2-pass:D

[Philippe734]

i encoded a film (dvd) using (just 1 pass) beta3 then using RC1 on following setting :

film 1h48 ; vdubmod 1.4.13 ; single pass
Objective 1 - One cd (700Mo - 805kbs video and 96kbs sound)
Objective 2 - testing differences in the load default values

***for beta3
load default then
--Main settings------------------------
Profile @ Level = AS @ L5
single pass
target bitrate: 805kbs

--Profile------------------------------
not use adaptive quantization
Quarter Pixel
B-VOPs (not default) 3/1.50/1.00
Closed GOV

--Motion-------------------------------
Motion Search Precision 6
VHQ 1
Chroma Motion
Maximum I-frame interval 250

**for RC1 (!!! not like setting that beta3 because load default before)
load default then
--Main settings------------------------
Profile @ Level = AS @ L5
single pass
target bitrate: 805kbs

--Profile------------------------------
not use adaptive quantization
Quarter Pixel
B-VOPs (not default) 3/1.50/1.00
Closed GOV

--Motion-------------------------------
Motion Search Precision 6
VHQ 1
Chroma Motion
Maximum I-frame interval 250


results :

**beta3
video file size : 531Mo mean about 317kbs
**RC1
video file size : 621Mo mean about 805kbs <- objective 1 reached

i precise the film content very dark scenes, rarely colours scenes and rarely fast motion scenes. As you can see, there is a big different beetween beta3 and RC1 in this config. I encoded other films in like setting, single pass, and i see rarely the same results. So in my opinion, about other setting of quantizer, quant... the load default values in RC1 are most adaptive for my encodes. I rather RC1 a lot. And about the quality, i highly appreciate the result of encoded with RC1. Actually, i will not need to update xvid in the futur, cause i entirely satisfied about RC1 !

:D