Niltze! (XviD-1.0-RC1-26012004)

[Koepi]

Heya folks,

it's a whole month of hidden work, but here we are:

We proudly announce the release of XviD 1.0 Release Candidate 1, Codename "Niltze"! Before anyone asks - it's no nazi german, it's Aztec.

Changelog:

XviD-1.0-RC1-25012004 (Niltze):
- Cleaned up VfW-GUI
- Colour space assignment fixes (dshow)
- Weight zones fixed
- Overhauled VfW status window in general
- Bugfixes in the plugin system
- Statsfile existence gets checked now on 2nd pass
- Postprocessing fix
- Faster first pass QPel gets disabled as well now
- Installer deletes old XviD configuration (no need for "Load defaults" after install)

Regards,
Koepi

[Human_USB]

Cool beans..... testing now.


*Edit*

I love the new status window. Great job Xvid team. So far so good.

[DAvenger]

Good work. Thanks ;)

[Swede]

I like the new status look. :) Thanks for keeping XVID alive!

One quick question: What kind of frame is S? (amongst the 'internals' in the status-window)

[Koepi]

S is a S-Vop - a frame where GMC gets used :)

Regards
Koepi

[aaar9800]

Big thanks go to the whole development team!!!

One question though: Why is AS @ L5 chosen by default?

[Human_USB]

Oh, one thing. Can you tell us what each color is on the status window.

And for Xvid 1.0 it would be nice if we could save the status window information into a text file.

-Thanks
Jason

[aaar9800]

I think that

red = i-frame
blue = p-frame
green = b-frame

[Swede]

S-VOP. Aha.. /me learns new stuff everyday. :)

(The colors are Red=I, Blue=P and Green=B)

[mikeX]

dammit, just when i got my first gamr build and thought i'd be a few steps ahead of the masses... :mad: , oh well :rolleyes:
(my comments about the revised gui and status window are already posted -yes they are good :D -)

[mf]

Nice work on the status. It still lacks the curve-graphic (ala nandub) that me and suxen discussed, but it's certainly improving :).

[seewen]

Profile "AS@L5" is used by default. Does it mean that Rate Control's working correctly ?
(I know that it's written that "XviD RC will not respect these value" ).

[CiNcH]

S is a S-Vop - a frame where GMC gets used

Does XviD's GMC support 4 warppoints?

[Alxemi]

Big thanks to all XviD development team!!
Here it is a mirror (http://138.100.51.162/~alxemi/XviD-1.0-RC1-25012004.exe) for those who having problems with wget, downloads managers or whatever.

[Heini011]

Hi,

@Koepi & other devs: thanks a lot for your great work!

but again: please, make the fast first pass only be active, when the 'discard first pass' option is selected. i had already 2 times forgotten to deactivate the quant 2 zone in the second pass.
i use the first pass result to check the avisynth filter settings and for a size estimation.

i have a beta3 first pass ready (20h processing time, no weight zones). can i keep the stat file for RC1 ?

greetings, Heini011.

[Koepi]

Heini:

yupp, you could use that statsfile. Just remember to setup everything like it was again, now after installing my build XviD sets everything to the defaults :)

Regards
Koepi

[Human_USB]

With the new Xvid I'm having problems keeping the size down. Even at 2000kbps it's make a 40 minute video about 500-650 MBs. It's still encoding but I'm at 135MBs at 13600 frams of 65504. Maybe it's because the Weight system is fixed. Would 1000kbps look dvd like and remain small in the new RC? Each new xvid is so great but different.

[Mr_Khyron]

Originally posted by CiNcH
Does XviD's GMC also support 4 warppoints?

no 3 warppoints

[Leak]

Originally posted by Koepi
We proudly announce the release of XviD 1.0 Release Candidate 1, Codename "Niltze"! Before anyone asks - it's no nazi german, it's Aztec.

Rats! And I thought you spelled "Schnitzel" totally wrong... ;)

np: Autechre - 777 (LP5)

[cretin]

Hey. I installed the the new build and the first thing that i spot is that the Min I P and B Frame Quantizer defaults are 1 instead of 2.

It was known that quant 1 has some problems, like they are not working well(?), or even if they are working they dont have any effect on quality they just increase size. I would like to know if this is fixed or improved by now or is there any change there at all ? Is there a point in using minimal quant 1, ll that result in higher quality or anything ?

Thank for your answers.

[Human_USB]

I tested what cretin said and I changed the Min I, P, and B to 2 and the size different is big.


I loaded up a 30 second video and set the Kbps to 10000 and encoded. Below is what I got;


Min I, P, B 1 - Video size 9.46MB, 403Kbps
Min I, P, B 2 - Video size 2.53MB, 108Kbps


Both look good... it's just funny how changing one thing throws the size off by 6.93MB and 295Kbps.

[communist]

Cool :)
I like the new status-window. Great job XviD team.

[Topaz]

There seems to be a problem. After I installed this new codec when I play back an xvid file using ffdshows libavcodec the colors are all distorted.

Using xvid own playback works though.

How come ?`

:confused:

[Koepi]

Topaz:

In ffdshow config under Misc., set IDCT to XviD (or Walken). SimpleIDCT (ffdshow's default) produces colour mismatches - if you use QPel, the effect is even worse.

Regards
Koepi

[_rEuTeL_]

I keep getting a flipped video when playing back any xvid file with this build
the "flip video" option works, but it won't "stick": when I close the file and I play it again, it's flipped again

[Topaz]

Originally posted by Koepi
Topaz:

In ffdshow config under Misc., set IDCT to XviD (or Walken). SimpleIDCT (ffdshow's default) produces colour mismatches - if you use QPel, the effect is even worse.

Regards
Koepi

Thanks!

Thought I was high there for a while :rolleyes:

[mikeX]

@ _rEuTeL_

are you sure your problem isn't the same as the one discussed in the 'Selam' (previous release: xvid beta 3) thread? (namely: directvobsub changing the colorspase)

--: edit :--some additions --: edit :--
i see the decoder supports matroska AR, nice...:D

[communist]

Is it a bug or is it supposed to be like this : the brightness slider is greyed out.

[Blue_MiSfit]

it's probably still not implimented, like in beta 3

[bob0r]

@koepi

When i uninstall beta 3, i can play xvid (dont ask me what plays it, probably divx 5.1.1)
Then i install RC1, i get no video, only audio, i uninstall RC1 i get video again, i install beta 3, and beta 3 plays the video for me.

Windows 2000 Professional, Service Pack 4 (5.0 - 2195) is my OS

This is obviously a "bug"

This goes for movies, tv rips and even my own caps, so i can safely say "for all xvid"


Hope its fixable soon!


(P.S. is the 2 pass filesize bug gone now? default xvid settings, just pick 1pass and then 2pass with the size, end result is a too big file.)

[Emp3r0r]

I am getting choppy playback with the newest build but only when using ffdshow, nero decoder, or VLC. The xvid decoder plays back smooth. This was not an issue prior to RC1. Anyone else have this problem? BTW, xvid is giving me outstanding results, keep up the good work!

[sysKin]

Originally posted by _rEuTeL_
the "flip video" option works, but it won't "stick": when I close the file and I play it again, it's flipped again Bug confirmed and fixed. Thanks!

Waiting for more,
Radek

[Velsk]

Originally posted by Emp3r0r
I am getting choppy playback with the newest build but only when using ffdshow, nero decoder, or VLC. The xvid decoder plays back smooth. This was not an issue prior to RC1. Anyone else have this problem? BTW, xvid is giving me outstanding results, keep up the good work!


Was the file encoded using packed bitstream?

[Koepi]

bob0r:

Something's wrong with your system/setup. Don't blame XviD - you're the only one to report this, so you can be sure it's your system (after so many downloads püeople would have loud screemed here already in plenty of posts that they can't playback xvid).

Try a registry cleaning software or something to completely get rid of superflous stuff. Do you configure ffdshow so it uses xvid.dll for decoding content? If yes, set ffdshow xvid playback to "disabled", XviD has no xvid.dll anymore.

Empe:

Please read sysKin's signature.

Regards
Koepi

[Zerox20]

When I installed the Rc1, it does not show up in my Virtual Dub Compression! I've tried uninstalling/reinstalling and it will not show up.

[Kb_cruncher]

Would it be possible to add a save to file option for the "show me the internals" output in a future release.

I realise i can do this with debugview but it would be nice to be able to do it all internally.

RC1 is awsome, i love the new status box(way better than the divx one, it uses too many cpu cycles and makes capturing impossible).With fetures like these evey man and his dog will be using xvid before long:D

[Alvy]

On my system RC 1 playback is jerky. I tried my primary and my recovery win2k installation (both SP4, DirectX 8.1). Switching back to beta 3 makes playback smooth again.

However since I own a Matrox G400 playback of dev 4 encoded stuff with usage of ffdshow is choppy too (divx and dev 3 not).

:( :(

Shall I switch back to nvidia for use of xvid?

Thanks

Alvy

System: Athlon 2400+, SiS 735, 768 MB PC2100, Matrox G400.

[N-Bomb]

So... I dunno if it's my setup or what, the new status window (which I love, BTW) needs to be enlarged or something... the quant fields on the graph go 1|2|3|4|5|6|7|8|9|0|1|2|3... etc. Not enough room to draw the 1x , 2x, or 3x.

Only cosmetic, but just thought I'd mention.

[virus]

Got some very minor problems installing RC1. Looks like Beta3 uninstaller did not finish the job completely and the new installer got stuck trying to delete what was left. I deleted my \Programs\XviD dir manually and everything went smoothly. Don't know, it may just be my system (some files in use not released, or similar).

Tried weight zones extensively: the output is fine :)
But I'm experiencing an incredible problem with the GUI.
I set the slider to 1.15, but when releasing it, it jumps to 1.13! If you hit OK, the main dialog shows "W 1.12" (!!!).
Same problems for the neighbouring values (1.14, 1.16). They're rounded down automatically. Entering the value directly doesn't help, just hit OK and you get a wrong value in the Zones listings :(
But setting 1.12 or 1.17 works fine (!!).
Other values work fine, that's really incredible :eek:
Are these values you cannot use?

Overall, GUI is improved, but trying to navigate between the options using the TAB button results in "random" jumps from here to there, in almost all windows. Also, some tooltips have been updated, but some are still missing. Yeah, I know, this is not high in your priority list ;)
You're right. Just don't forget that for 1.0-final :)

The "show me internals!" options is cool, but what's the practical use? The numbers move too fast to really understand something :D :D

[bond]

Originally posted by _rEuTeL_
I keep getting a flipped video when playing back any xvid file withyes i also get my old xvid encodes flipped
its not caused by dvobsub but by bsplayer (with the overlay1 option enabled) it seems, cause when i play the files in graphedit or mpc, they are not flipped

do you also use bsplayer? if yes, than set it to use "overlay mode 2"

[xixi2000]

great Koepi :D

[communist]

Originally posted by Kb_cruncher
i love the new status box(way better than the divx one, it uses too many cpu cycles and makes capturing impossible).
You can always disable it for capturing :)

[_rEuTeL_]

Originally posted by bond
do you also use bsplayer? if yes, than set it to use "overlay mode 2" yes it's only with bsplayer, winmediaplayer (:D) doesn't flip the image
and yes overlay mode 2 does the trick, but playback is a little choppy that way


edit: I can't find a "flip video" setting in regedit, maybe there just isn't a REG_DWORD included and you need to add it yourself?

[crusty]

@virus:

Did you reboot before installing RC1?

[virus]

Originally posted by crusty
Did you reboot before installing RC1?

IIRC yes (I always tend to use the uninstall-reboot-install procedure, it should be safer ;)). I've had no problems with the Beta2->Beta3 switch. Anyway, manual deletion worked fine. Don't know :rolleyes:

[K-Dash]

Good work XviD Team, love ya:)

[Heini011]

I have also a choppy playback with the newest build. This was not the case prior to RC1 and it is not related to b-frames. i have to further examine this...

my system: athlon xp@1800 mhz, nforce 3, radeon 9100

greetings, Heini011.

[cretin]

Human_USB: Then this means that the size difference between quant 1 and Quant 2 is like 300% ??? And did worth it ? Because if not then it means that it wasnt a too good decision to leave Quant 1 for default since its usage is not recommended then.

[acrespo]

I can't find xvid.dll anymore in RC1. Now I saw two files: xvidvfw.dll and xvidcore.dll. Which is the old xvid.dll?

I am using this DLL to decode my YV12 Avisynth files (VIDC.YV12 in register). I put xvidvfw.dll in register and it's function but I don't have sure about it.

[Alvy]

Hello,
after un- an reinstalling all video-related codecs playback seems to work fine :)

Xvid 1.0 is magnific

Thank you !!!!

Alvy

[amango]

I had no problem installing the codec.

I use a newer version of ffdshow - idct is checked to "auto". Playback is usually smooth on all files I tested.

[mikeX]

@ Zerox20
maybe that's your solution:
http://forum.doom9.org/showthread.php?s=&threadid=67648&perpage=20&pagenumber=2

@ acrespo

xvidvfw.dll should be right...

[Soulhunter]

- THX -

Bye

[split710it]

Thank's Koepi for this new aztec release :)

I hava a question (I had same problem with beta 3 also)

what I have to do use the brightness cursour?????

On latest beta 3 I could shift right and left but with no change image, now with rc1 I canot move it ???

ciao

[Blue_MiSfit]

read the threads man, it's not implimented so they disabled the slider...

[gizmotech]

A note on current 2 pass encoding.

Using default settings, adjusting vhq to 3, and enabling cartoon mode, XviD was unable to hit target size w/ quant 1 enabled.

The file had a target size set @ 200mb , and after encoding file size arrived at 254mb. Setting quants back to 2-31 enabled proper bitrate control again (well it was oversaturated but that's beside the point).

Could this be related to overflow control? It's currently set to 20 and I wonder if this is perhaps not powerful enough?

Gizmo

[Smiff]

Originally posted by Alvy
However since I own a Matrox G400 playback of dev 4 encoded stuff with usage of ffdshow is choppy too (divx and dev 3 not).


I'm curious why having a G400 makes playback jerky? I have a G400 on 1 machine and don't want to replace it any time soon...

[Chainmax]

Originally posted by Koepi:
Do you configure ffdshow so it uses xvid.dll for decoding content? If yes, set ffdshow xvid playback to "disabled", XviD has no xvid.dll anymore.
So, now the options are to either use ffdshow or the xvid standalone decoder? Why?

[george_zhu]

why the "dering" in decoding setting is always gray and not available to choose. Does that means it is always on?

Do we still need the decoder 1.0beta3 with 1.0RC1?

[mikeX]

@ acrespo:

i tested it, it's definately xvidvfw.dll
if you have ffdshow installed you could use that as a YV12 decoder, ('Codecs --> Raw Video --> YV12') and you won't have to mess with the registry each time you install/uninstall something (+ see below)

@ george_zhu:

i believe it's currently broken (on beta3 dec also)
no...

@ all

i notice a rise of ~10% on cpu usage when using xvid to decode compared to ffdshow (with no pp options set):: tested on clips with b-frames & q-pel as well as on raw video (avs script)
is this a general/known issue?

(btw can anyone give me the function name to call the decoder's option menu through rundll32?)

[stook]

I reencode a movie with about 1:30h to fit in 300mb (without sound), to test very low bitrates, using xvid RC1!The image is good but I have choppy playback!The playback of original file (encoded with xvid beta 3) using xvid RC1 is fine!Why the difereces?!? I noted that xvid used quant 1 sometimes!In very low bitrates it shouldn't happen!!!

Used VirtualDubMod 1.5.10.1 build 2389
XviD settings for both files (original(785Mb) and final(347Mb):
2pass encoding
AS@L5
H263
Adaptive Quantization
Quarter Pixel
GMC
BVops(bframes)is 1 (not 2 by default)
Packed Bitstream
Closed GOV
Motion precision 6
VHQ 4
Chroma Motion
Turbo Mode
Trellis Quantization

Original File (785Mb with sound) and final file (347Mb with sound) are OGM files with ogg audio (49Mb).

By the way, keep up the good work!!! I'm very impressed with xvid evolution! I changed from Divx Pro 5.1.1 to XVID :)
Sorry about the bad english but I'm Portuguese!!!

[Gazza]

I noticed that Packed Bitstream is on and bframes is set to 2 as default. I have read in the xvid faq that Packed Bitstream causes problems and is not really a preferred setting (especially if bframes is > 1).

Is Packed Bitstream fixed now?

My best wishes to the developers for this latest release. I am very impressed. I wonder if Lenox will update his AutoGK now to include your excellant work?

Cheers

Gazza

[ookzDVD]

Wow wow... RC1 :)
getting closer to Final one! :)

I'm always enjoy looking the syskin's signature :)

Keep good working for all xvid's dev. team!

PS. Is it save now to use Anamorphic encoding with XviD for Matroska ?
I always use RV9 to enjoy the Anamorphic encoding, wanna try with XviD.

[stook]

As I said, bframe is set to 1 and not 2. I used the same settings for both files so I don't understand why the diferences in playback!
Is there a problem with the decoder in low bitrates?it does not make sense!!!
Why xvid use quant 1 in extreme low bitrate?!? It's a waste of precious bytes...

PS - I think in original file min quant used is 2 but not sure...

[JJ2335]

I want to report Flipped Videos occuring in OGM container files when using the RC1 decoder. AVI files are displayed correctly but my XVID B3 encodes are flipped.

Does anyone else have flipped picture OGM issues with previous versions?

I'm using media player classic under windows XP. Koepi has mentioned this ogm container issue in the past however, I just want to inquire again on this bug.

Thanks and keep up the great work!

[Human_USB]

I have flipped MKVs using XVID beta 3 videos. I have not tested to see if RC 1 is flipped too.

[JJ2335]

I made an intresting accidental discovery after uninstalling the matroska playback pack. My beta3 matroska and ogm files are no longer flipped because it also uninstalled direct VOBSUB. Reinstalled vobsub got flip.

VOBSUB+OGM+XVIDB3-RC1 = FLIP
Please let me know if you have similiar results.

[Alxemi]

No flips with beta3+ffdshow+ogm here. RC1 still untested (hope tonight...)

[pcsakura]

@Koepi
Thanks Your NiCE Work.....
Does XviD RC2 Support To Automatic Drop Duplicate Frames in VDM/VD , Like some Japanese 120Fps Hybrid Anime(The Stupid thing):D

[Koepi]

No flipped video with OGM here. It's definatly a dvobsub issue.

Regards
Koepi

[jkwarras]

Hi,

Just tested the new build and find out an strange behaviour. I've run a 2-pass encode (MPEG-quant, adaptative quant, 3 bframes, motionsearch-6, chroma opt, chroma motion, and a zone set to q10.00 for the end credits). I encode it with latest virtualdubmod. First pass abort at the very end (like 10 frames from end). It also happens with beta3, but installing new virtualdubmod and a posterior CVS version resolve this crashes at the end of the fisrt pass.

So, maybe this is the wrong part, but, as it crash at +-10 frames from the end, i decided to run the 2º pass anyway. The status windows show me that the it was being encode between quants 1-5, not 1-31 as defaults. So, i abort it and run the second pass three times, resulting in different status windows: encoding with quant betwen 1-3, or 2-5 but but never 1-31.

So, i finally decided to run the encode again. I start again the 2 pass. I will see if this strange behaviour was due to the video.pass not being complete (because first pass was aborted before really ending).

Regards

[Koepi]

Hell, you don't want the quants to be spread from 1 to 31! It's just the range where quantizers shall be capped! You would want something like a const. quant 2 encode. Read the doom9 guides on nandub and mpeg4 ripping in general again to get an idea about that.

And - as stated really often now, newest vdub(mod) versions are buggy as hell. Stick with vdub(mod) 1.5.4(.1), that's safe to use.

Koepi

[jkwarras]

Originally posted by Koepi
Hell, you don't want the quants to be spread from 1 to 31! It's just the range where quantizers shall be capped! You would want something like a const. quant 2 encode.

I know that Koepi, i was talking about the fact that all the quants were spread into the 1-5 range. Not a single one were out of this range because it was specified in the status windows (under the total min and max), and if I remember well, it has to specify 1 to 31. With this behaviour the size targeted wasn't reached, when you see the projected size (and average bitrate under the status windows) it was something out of the 680 MB I was specifiyng (1100 kbps vs. 787 kbps wanted). I obviously wait a little to see if this values went dow (because sometimes this orientations are just wrong as hell) but as the beggining of the movie was almost black with text and the avg bitrate was around 1500 kbps, that was suffisent to me to suppose that something was wrong.

I'm not saying this is XviD problem, maybe is just my encode. Just reporting to see if other people has experienced that.

And - as stated really often now, newest vdub(mod) versions are buggy as hell. Stick with vdub(mod) 1.5.4(.1), that's safe to use.[/quote]

Ok. I will.

Regards.

[sysKin]

Originally posted by jkwarras
I know that Koepi, i was talking about the fact that all the quants were spread into the 1-5 range. Not a single one were out of this range because it was specified in the status windows (under the total min and max)But this is very good, this is exactly what you need. In fact we're pround that this is happeningand if I remember well, it has to specify 1 to 31.What? Where did that come from? The strangest thing I've ever heard.
With this behaviour the size targeted wasn't reached, when you see the projected size (and average bitrate under the status windows) it was something out of the 680 MB I was specifiyng (1100 kbps vs. 787 kbps wanted). I obviously wait a little to see if this values went dow (because sometimes this orientations are just wrong as hell) but as the beggining of the movie was almost black with text and the avg bitrate was around 1500 kbps, that was suffisent to me to suppose that something was wrong.What you're doing is totally wrong. This not CBR, the beginning can - and often is - 1500kbps or more. I don't know where your ideas come from.
I'm not saying this is XviD problem, maybe is just my encode. Just reporting to see if other people has experienced that.This was a perfectly good start for a perfectly good encoding session, or at least that's all I can tell from what you said.

Don't confuse people with posts like that. Finish your move and if it is wrong, oversized or something, *then* tell us.

Radek

[fccHandler]

Using the DivX 5.1.1 decoder, I get very choppy playback of files created by RC1 when "packed bitstream" is enabled. I posted the same complaint about Beta3 somewhere, but it still seems broken. Note that older packed bitstream encodes made with Koepi's XviD-24062003-1 play fine.

[communist]

Originally posted by fccHandler
Using the DivX 5.1.1 decoder, I get very choppy playback of files created by RC1 when "packed bitstream" is enabled. I posted the same complaint about Beta3 somewhere, but it still seems broken. Note that older packed bitstream encodes made with Koepi's XviD-24062003-1 play fine.
Its not a XviD problem :devil:
from sysKin's sig
- if you keep packed bitstream ON and use more than one b-frame, ffdshow will have problems
DivX 5.x decoder has the same problem / limitation as ffdshow.
Xvids decoder seems to be the only being able to play files with more than 2 consecutive b-frames and packed bitstream enabled.

[Koepi]

fccHandler:

and, as in the Beta3 thread, here is the same answer:

DivX can just cope with 1 consecutive bframe. ffdshow can also just cope with 1 bframe in packed mode.

Bug those develoeprs, don't nag here if you're not willing to read and understand the answer. :P

Regards
Koepi

[george_zhu]

I guess this is because when the minimum quantizer set to 1, the bitrate is blow up and pretty unpredictable. I tried mine with the default setting 1-31 at 2-pass. I encoding tow clips at target 1200kps. The final result is one at 1400kps while other is 1100kps.


That is my guess. Please confirm me about it.


Originally posted by jkwarras
I know that Koepi, i was talking about the fact that all the quants were spread into the 1-5 range. Not a single one were out of this range because it was specified in the status windows (under the total min and max), and if I remember well, it has to specify 1 to 31. With this behaviour the size targeted wasn't reached, when you see the projected size (and average bitrate under the status windows) it was something out of the 680 MB I was specifiyng (1100 kbps vs. 787 kbps wanted). I obviously wait a little to see if this values went dow (because sometimes this orientations are just wrong as hell) but as the beggining of the movie was almost black with text and the avg bitrate was around 1500 kbps, that was suffisent to me to suppose that something was wrong.

I'm not saying this is XviD problem, maybe is just my encode. Just reporting to see if other people has experienced that.

And - as stated really often now, newest vdub(mod) versions are buggy as hell. Stick with vdub(mod) 1.5.4(.1), that's safe to use.

Ok. I will.

Regards. [/QUOTE]

[Teegedeck]

Originally posted by george_zhu
I guess this is because when the minimum quantizer set to 1, the bitrate is blow up and pretty unpredictable. I tried mine with the default setting 1-31 at 2-pass. I encoding tow clips at target 1200kps. The final result is one at 1400kps while other is 1100kps.
Just a sidenote: Could we perhaps all agree on not using kbps as size-indicator? XviD does give target-filesizes in kbytes and how bad or well it keeps that target-size should be measured in kbytes.

[iago]

Great work! :)

The new XviD Status window definitely rocks and I'm really really impressed by the quality improvements!

Still, there is one thing that I wonder: Isn't it possible to hardcode the three "overflow treatment" values (and even hide them from user access ;)) in such a way that XviD hits the specified target size accurately again (as it did in the past) regardless of how long the clip is and regardless of how you cap the quantizers (1-31/2-31/etc.)? (except cases of saturation of course...)

Many thanks to all developers for the great codec that you have created!

best regards,
iago

[Assault]

@ iago

I'm not entirely sure but AFAIK:
The higher "the three overflow treatment values" are the better XviD hits the target size. But the XviD developers like the current quant distribution (the quality is more constant than before) very much although the target size isn't hit perfectly. That's the reason why the defaults (5;5;5) aren't hard coded. Everyone should be able to change them if he isn't content with the rate control.
I hope that explanation is right. I'm sure sysKin or Koepi will correct me otherwise. ;)

Assault

[mf]

Originally posted by iago
(and even hide them from user access ;))
Never hide things. Expose it all and have the n00bs go @__@ when they see it.

[fccHandler]

Originally posted by Koepi
DivX can just cope with 1 consecutive bframe. ffdshow can also just cope with 1 bframe in packed mode.

Bug those develoeprs, don't nag here if you're not willing to read and understand the answer. :P

Sorry to nag, but I'm only using one consecutive b-frame, so that answer doesn't apply in my case. (I guess I should have made that clear.) Anyhow it isn't a huge problem and I could work around it. But what I really don't understand is why the 24062003 version produces smooth playing video and the RC1 version doesn't. Is there anyone who can reproduce that, or explain it?

I could bug the DivX people, but I have a feeling they'll say the same thing ("It's not a DivX problem.") :D

[Koepi]

1 consecutive bframe, packed mode, and ffdshow and divx mess up?

Damn.

Someting to think about, and sorry to judge that post "too early" without understanding what you meant.

Regards
Koepi

[Gazza]

Koepi,
Not another nag but if you hit 'Restore Defaults' then packed bitstream and 2 consecutive bframes are set as the default.

Cheers

Gazza

[KpeX]

1 Bframe and packed bitstream are decoding fine for me with FFDShow (5/23/03) and have been for the entire 1.0 beta/RC tree.

[Koepi]

Gazza:

sure, those are our defaults. What's that post supposed to express?

KpeX:

Thanks for the report. So it's newer ffdshow versions which mess up with 1 cc bframe in packed mode. So for fcchandler this means to go back to an older ffdshow build :)

Regards
Koepi

[Gazza]

Koepi,
If the combination of packed bitstream and more than one consecutive bframe is going to cause problems then should not the default settings be packed bitstream and 1 bframe (not 2 bframes)?

Gazza

[KpeX]

Originally posted by Gazza
Koepi,
If the combination of packed bitstream and more than one consecutive bframe is going to cause problems then should not the default settings be packed bitstream and 1 bframe (not 2 bframes)?

Gazza No, I don't think XviD needs to change its defaults simply because decoders don't handle it correctly. Packed bitstream is just a tool to put MPEG-4 in AVI anyways, if you want something that's more compliant mux your video into MP4.

[iago]

Regarding overflow treatment:

@Assault,

I'm not talking about the current defaults (5/5/5) but more all-purpose values such as (10/20/20) being hardcoded or at least being set as the default values!.. ;)

Imho, with the current default overflow treatment values (5/5/5), using quantizer 1 in the second pass (to compensate for the undersized first-pass, in other words, when your target file size is larger than the first-pass size) is quite useless, because the result is always a hugely oversized file (whether it's a short clip or not).

OK. Below are the results of a couple of very short tests with a very compressible source (which are also confirmed by a full two-pass encode of the same source with similar results - multiply the numbers below by 100 if you like ;)):

Everything default except packed bitstream unticked.

First pass size: 5mb (StatsReader 2.1)

Target size: 4000 kbytes
------------------------
(usual scenario - 2nd pass smaller than 1st pass)

Overflow treatment values: default (5/5/5)
Resuting file size: 4066kbytes

Overflow treatment values: (10/20/20)
Resuting file size: 4016kbytes


Target size: 6000 kbytes
------------------------
(unusual scenario ;) - 2nd pass larger than 1st pass - requires the use of quant 1 frames to reach the target size)

Overflow treatment values: default (5/5/5)
Resuting file size: 8410 kbytes (!)

Overflow treatment values: (10/20/20)
Resuting file size: 6012 kbytes


Results are pretty self-explaining I guess, but of course if you wanna make new beginners go @___@ as mf suggests, that's another point ;)...

best regards,
iago


edit: Btw, I'm not much a fan of using quant 1 and/or reaching second-pass sizes larger than first pass; but since we have that possibility now, I just wanted to share my opinions and suggest more all-purpose values. That's all. After all, size-predictability has always been one of XviD's most precious qualities! :)

[fccHandler]

@Koepi:
Actually, I've never used ffdshow; my problem is with the DivX 5.1.1 decoder and RC1. Just to clarify one last time, the DivX 5.1.1 decoder plays my old XviD-24062003-1 packed bitstream content just fine, but newer content encoded with XviD-RC1 packed bitstream plays very choppy. I never use more than one b-frame in sequence.

I hope I'm not the only one seeing this behavior, and thank you for addressing the issue. I'll look for a workaround in the meantime.

Regards
fccHandler

[GrEEk_OuTcAsT]

I didn't played match with the new xvid, but with the older ones I was getting awesome quality in my 1.30-2.00 hour movies in 1 CD with 128mp3.

I had already done compression in Divx5.11 of a Live of Dimmu Borgir band in Standard speed with only bidirectional enabled. I was about happy with the result.

Once the RC1 Xvid was released I decided to do the exactly same thing, in same size with same resize method, but just with xvidrc1 instead of the divx511. As I usually did with all the Xvid1 Betas, I use default settings, and only enabled Adaptive and Trellis quantization (over the default). It was 2 pass encode as usual. I don't know what happened but the quality was terrible in the new xvid.

The Live was 90 minutes. In the Divx5.11 I used vbrmp3128 and in XvidRC1 I used cbr128mp3 which means that xvid also had more videosize. They were both 700mb Total.

Did any settings got changed from the defaults in the new xvid? Or is it the Live Concept and the On-Off of the lights in the stage a problem for xvid? or a problem in the new version? Unfortunately I deleted the xvid file by the time I saw that quality. I should had uploaded some pics. Generally in every lighting change on the stage of the band everything became extremely blocky.

[Gazza]

KpeX,
Thanks for your reply. In the end the choice will be up to the user as to what they want to do.

Cheers

Gazza

[fccHandler]

Sorry, me again. :p

I just disabled the DivX 5.1.1 decoder and tested with the XviD decoder. RC1 content is still playing choppy. It's not the video, because it decodes smoothly in VirtualDub. CPU usage is only about 10% (the video is a low bitrate 320 x 240 encode). At this point I'm tempted to tear into the 24062003 and RC1 streams and try to find out what the heck's different about them. Unfortunately I know very little about the MPEG-4 video spec...

[Jaw3000]

Newbie Alert: I've looked throughout this thread and others to see if the "files too large" bug has been fixed with RC1 and I can't find a conclusive answer. When I first installed RC1, the first few encodings went fine and produced the correct size file. Compressibility check also worked fine. But, w/o changing any settings, the next few encodings produced way too large of a file (about 2GB a CD when 698MB for 2 CD's was set) and the compressibility check didn't work (it ran but didn't produce stats file or show up in GK). I un-installed everything (Xvid, GK, DivX) and deleted any registry keys I could find. I re-installed GK 0.28.7.2 and Xvid RC1 and the problems continue. So, since it worked fine once, any idea how to fix the problems?

Thanks!

BTW, off-topic but are there any known interference issues between Nero Digital codec and Xvid with encoding or decoding?

[stook]

I wrote before that Xvid RC1 decoder as a problem in low bitrates... I'm wrong!!! I made some more tests and all files played choppy!!! Now I know where the problem is!!! When overlay mixer is used, playback is choppy but everything plays back smooth if VMR9 is used!!!
I tested it with Zoom Player 3.30 and with MPC 6.4.7.6...
I never noticed it before because when vobsub and overlay mixer is used this problem doesn't exist!!!
So, there is no problem in Xvid RC1 decoder with Packed Bitstream and 2 bframes, only with overlay mixer... :)

PS - with ffdshow and overlay mixer the problem doesn't exist so is a xvid decoder problem!!!

[crusty]

Looks like current bugs and/or other stuff to know about RC1 are:
-Filesize prediction goes out the window when using Quant 1
Solution: Don't use Quantizer 1 (Doh!)
-Brightness slider doesn't work -not implemented yet
-Flip video option doesn't stick - fixed for next version
-Filesize prediction 'might' be off for other situations as well.
-Xvid.dll doesn't exist anymore
-Flipped video? Check your filters, especially Vobsub.
+SysKin:
- First pass will not be mpeg-4 compiliant if you use qpel *and* use quant zones at the same time. Sorry everyone, it was never meant to be kept.
- if you keep packed bitstream ON and use more than one b-frame, ffdshow will have problems
- programs that automatically configure xvid might not work with 1.0 tree (like gknot)


Noted: Packed bitstream is basically only usefull when saving to avi.

Hey. I installed the the new build and the first thing that i spot is that the Min I P and B Frame Quantizer defaults are 1 instead of 2.
Haven't checked yet, not@home now, but could it be that this is an erroneous default? Shouldn't the default be 2?

@fcchandler, try using NO b-frames at all, or try a DivX-compliant profile (they're in there in the profile list). Please report the result.

@all: try encoding with the DivX-compliant profiles if you're having trouble with your encodes not playing in DivX 5.XX, Nero or ffdshow.
Also, when reporting bugs, please state the profile you use and if you use weight zones (with weights or quants).

@Jaw3000:
Try setting minimal Quantizer to 2 instead of 1 and see if that fixes filesize prediction.

@bob0r:
Open your Xvid files with Gspot and check what codecs present it reports at every different situation you describe (ie, With or without RC1, Beta3 or no Xvid installed). That should tell you a bit more about what's going on.

@Alvy:
Please try the option you yourself proposed (switching video cards) and tell us if it worked.
latest virtualdubmod. First pass abort
'nuff said. :)
No, I don't think XviD needs to change its defaults simply because decoders don't handle it correctly.
Perhaps the profiles should automate these kind of choices as well, especially the DivX-profile-complaint-profiles. ;)

[Human_USB]

Originally posted by Jaw3000
Newbie Alert: I've looked throughout this thread and others to see if the "files too large" bug has been fixed with RC1 and I can't find a conclusive answer. When I first installed RC1, the first few encodings went fine and produced the correct size file. Compressibility check also worked fine. But, w/o changing any settings, the next few encodings produced way too large of a file (about 2GB a CD when 698MB for 2 CD's was set) and the compressibility check didn't work (it ran but didn't produce stats file or show up in GK). I un-installed everything (Xvid, GK, DivX) and deleted any registry keys I could find. I re-installed GK 0.28.7.2 and Xvid RC1 and the problems continue. So, since it worked fine once, any idea how to fix the problems?

Thanks!

BTW, off-topic but are there any known interference issues between Nero Digital codec and Xvid with encoding or decoding?


GK does not work with the new XVID 1.0. And I know of no problems with Nero and Xvid.

[guilc]

Originally posted by Koepi
No flipped video with OGM here. It's definatly a dvobsub issue.

Regards
Koepi
Are you really shure ? the directshow build provided here : http://forum.doom9.org/showthread.php?s=&threadid=68117&perpage=20&pagenumber=2 corrects this bug...
And this bug was not present in XviD before beta3 (always with the same dvobsub version)

[fccHandler]

Originally posted by crusty
@fcchandler, try using NO b-frames at all, or try a DivX-compliant profile (they're in there in the profile list). Please report the result.
Not surprisingly, without b-frames the content plays perfectly with every decoder.

I do remember a build (maybe one of my own from CVS) which had DivX profiles like "Portable" and "Home Theater," but I don't see them in RC1.

For now I've worked around my problem by disabling DivX 5.1.1 for XviD content, and replacing the XviD-RC1 decoder with the one from Koepi's 24062003 build (by overwriting xvid.ax and adding xvid.dll). For some strange reason this decoder alone plays XviD-RC1 packed bitstreams smoothly.

I also examined files produced from both builds, but I saw no glaring differences (granted, I'm not entirely sure what to look for...)

[RadicalEd]

Originally posted by crusty
@all: try encoding with the DivX-compliant profiles if you're having trouble with your encodes not playing in DivX 5.XX, Nero or ffdshow.
Also, when reporting bugs, please state the profile you use and if you use weight zones (with weights or quants).

Actually the DivX profiles were removed after beta2, and the profiles themselves do nothing but set a few header flags (no effect on RC, vbv etc).

[sysKin]

I agree that defaults should be safe - overflow treatment should be 10/10/7 or more. It's power users that can lower it.

I'm a bit worried about quant-1 frames. They shouldn't happen if second pass is smaller, at all.
As Koepi noticed before, they hapen if second pass is not much smaller, and this is because 10% keyframe boost. It's still wrong, but at least I know the explaination.

I'll try to find a reason for q1 frames in lower bitrates.

BTW the default quantizer ranges changed to fight the most common n00bish question - saturation. It's a good solution, just 2pass2 has take care not to use them if there is no need.

Thanks for testing, everyone!

Radek

[Jaw3000]

Originally posted by Human_USB
GK does not work with the new XVID 1.0.
Originally posted by crusty
@Jaw3000:
Try setting minimal Quantizer to 2 instead of 1 and see if that fixes filesize prediction.

Ok, that's what I'm trying to find out! Some say Xvid 1.0 does work with GK and others say it doesn't. I don't know if it does or not. Above are two conflicting answers to my question. Maybe there are certain settings that don't work right. I know that it seems to work sometimes, since it was working fine (file sizes were correct and compression test worked) until something happened. What I'm trying to figure out is, since sometimes it obviously works, what settings might need to be changed? I haven't had a chance to try the above suggestion yet. Any definitive answer on this subject? Also, any idea when GK (and AutoGK) might be updated to work "better" with Xvid 1.0 (RC1)?

Thanks!
-Jaws

[stook]

As crusty said, "Packed bitstream is basically only usefull when saving to avi". So if OGM format is used, there are any advantages in using Packed bitstream???
Someone has choppy playback when overlay mixer is used or it's only in my system (XP SP1, P4 3.0GHz, DX9 & G4Ti4200)?!?

[crusty]

Not surprisingly, without b-frames the content plays perfectly with every decoder.
Have you tried using ogm or mkv, with b-frames and without packed bitstream?

Actually the DivX profiles were removed after beta2, and the profiles themselves do nothing but set a few header flags
Well I guess stuff like more-than-1-b-frame and GMC have to be turned off when using those types of profiles, if they ever come back.
You could also make an option called DivX-compatability-mode which would pop-up a reminder every time you did something non-divx-compliant (saying 'No !!! Don't do it!! Don't use DivX!! or something like that :D)
BTW the default quantizer ranges changed to fight the most common n00bish question - saturation.
Got it: - 'I get undersized files! What's wrong?' ;)
Some say Xvid 1.0 does work with GK and others say it doesn't. I don't know if it does or not. Above are two conflicting answers to my question.
I hardly call them conflicting...anyway you could better say:
GK does not work correctly with the new XVID 1.0.
That means sometimes it does, sometimes it doesn't.
Try to use GK only for the introductory stuff, let it create the avisynth script for you, and then do your own encoding.
Also, any idea when GK (and AutoGK) might be updated to work "better" with Xvid 1.0 (RC1)?
Try one forum up. Possibly two. :)

[GolovachLena]

Originally posted by stook
Someone has choppy playback when overlay mixer is used or it's only in my system (XP SP1, P4 3.0GHz, DX9 & G4Ti4200)?!?

I personally often had choppy playback after using packed bitstream, avi of course, different sources and settings. (Actually, not only me, my friends confirm the bug too). Think it's big no-no to use this feature. Sadly, devs don't listen and don't do anything about that.

[GolovachLena]

Originally posted by Koepi
1 consecutive bframe, packed mode, and ffdshow and divx mess up?
Damn.
Someting to think about, and sorry to judge that post "too early" without understanding what you meant.

How pathetic! You DIDN'T LISTEN when i told you THE SAME two days ago.
Any apologies? ;)

[fccHandler]

Originally posted by crusty
Have you tried using ogm or mkv, with b-frames and without packed bitstream?
Well, I just tried Matroska. The RC1 content plays fine without packed bitstream, but with packed bitstream it's still choppy. (Same results as with AVI container.) I'm truly at a loss to explain what's happening, but I've found a temporary workaround so I'm happy.

BTW, did I mention the quality of RC1 is fantastic? Great work! :cool:

[puschpull]

Thanx Koepi!

XviD 1.0 is excellent !!
:)

I Made Little Guides for Works and Setting XviD 1.0,
but in Czech Language.
:-))

brand-new:
http://puschpull.org/xvid_v.1.0.rc1_koepi.php

one month old:
http://puschpull.org/xvid_v.1.0.beta3_koepi.php

:p

[BoNz1]

Originally posted by GolovachLena
I personally often had choppy playback after using packed bitstream, avi of course, different sources and settings. (Actually, not only me, my friends confirm the bug too). Think it's big no-no to use this feature. Sadly, devs don't listen and don't do anything about that.

First of all, everybody is doing this on their own free time. Everyone knows it is a bug, but _not_ with xvid. The fix for this bad decoding is in the ffmpeg cvs so hopefully milan could update libavcodec in the ffdshow cvs. Then you will get a new ffdshow build and everything will be peachy.

Originally posted by GolovachLena
How pathetic! You DIDN'T LISTEN when i told you THE SAME two days ago.
Any apologies?

Huh, nobody will apologize to you if you have this kind of attitude I suggest you take a look at this http://forum.doom9.org/showthread.php?s=&threadid=52597 read it though carefully. And yes, shockingly people do make mistakes yes even the mods and yourself try to be aware of this and things will go a lot more smoother for you.

[GolovachLena]

Originally posted by BoNz1
Everyone knows it is a bug, but _not_ with xvid.

Oh really? Why then when Xvid simulates Divx work (1 consecutive bframe, packed) it produces wrong output?

Huh, nobody will apologize to you

It was kinda joke, i used a smile anyway.

[stook]

As I wrote, with or without packed bitstream, with all options off, the result is the same, choppy playback when overlay mixer is active, only when I change Video Render to VMR9, the problem is fixed... (It happens in Zoom Player 3.30 and MPC 6.4.7.6 and it doesn't happen with fddshow and Divx 5.1.1 decoder). Can anyone confirm that!!!
It's not a packed&bframesproblem...
By the way, I don't have problems with packed bitstream&bframes>1 because I use Xvid RC1 decoder...
I asked before too if there are any advantages in use packed bitstream when the output format is OGM!!!
Thanks to anyone who answer me...

[crusty]

Stook:
Packed bitstream is meant to fix avi's not handling frame order correctly when using b-frames. More modern formats don't need it.
I'm not 100% sure about Ogm, but you can bet it's not needed with mkv.

[stook]

Thanks crusty for your quick answer... :)
So, can anyone confirm the same problem I have with overlay mixer...

[Manao]

stook : are your video drivers up to date ? I also have a GF Ti 4200, and I've no problem at all with overlay mixer and xvid decoder.

[SanatClaus]

Hi all, thanks for all great Xvid-work :):).

I am replacing my VCR by doing recording on the fly, single pass (real time recording) with excellent results using Xvid on my AMD 2400+ (I am aware that I will get better result with 2 pass post processing).

Unfortunately RC1 yields a hanging recording application when I press stop recording, whereas Beta3 and all previous did not :(. Windows Task Manager says No Response in 3 apps I have tried (Leadtek expert WinPVR, iuVCR and VisualVCR). However, recording is done properly to the file. VitualDub (1.5.4.1 and 1.5.10) does not hang (can this be because it uses vfw-filters/drivers?). This happens with default settings and also if I reduce MSP to 5 and VHQ mode to 0 (to reduce CPU load).

I have no empty entries in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32

I have removed and reinstalled all video decoders responding to FourCC XVID. Gspot reports four codecs

XviD MPEG-4 Codec:
DSH Driver or Wrapper C:\WINDOWS\System32\qcap.dll

DivX Decoder Filter (5.1.1.1031 pro):
DSH Driver or Wrapper C:\WINDOWS\System32\divxdec.ax

XviD MPEG-4 Video Decoder:
DSH Driver or Wrapper C:\WINDOWS\System32\xvid.ax

DivX Decoder Filter (5.1.1.1031 pro):
DSH Driver or Wrapper C:\WINDOWS\System32\divxdec.ax

and renders video with divxdec.ax

Hope you lot can help me
/SantaClaus

[Aqa]

Originally posted by stook
As I wrote, with or [B]without packed bitstream, with all options off, the result is the same, choppy playback when overlay mixer is active, only when I change Video Render to VMR9, the problem is fixed... (It happens in Zoom Player 3.30 and MPC 6.4.7.6 and it doesn't happen with fddshow and Divx 5.1.1 decoder). Can anyone confirm that!!!

I’ve got exactly the same “Problem” there got to be an explanation for it, just haven’t figured it out yet!

[Koepi]

stook:

well, OggDS muxes the video frames directly from avi into OGM - so it has the same advantage as in .avi: there won't be a decoder lag. (The avi container doesn't know about "packed bitstream" and neither does OGM, so it's not possible yet to "unstrip" the packed frames and just timestamp them correctly).

@all:
If you have troubles with packed bitstream, can you please check as stook(i think) described, use another overlay mixer, en/disable dvobsub or any other weird filters during playback - and verify that the problem still exists after doing that?
I can't imagine yet what's wrong with the overlay as nothing should've changed in dshow affecting this - but wait, we do set aspect ratios now, maybe that's the catch?

Regards
Koepi

[stook]

Thanks for answers Koepi.
I verified that my nvidia drivers are up to date...
I made some more few tests with a movie(xvid RC1,ogg,no bframes and no packed bitstream) and the conclusion is:
-with overlay mixer:
Divx 5.1.1 or fddshow plays smooth
Xvid RC1 play very choppy
-with VMR9
all decoders play smooth

I tested in Zoom Player 3.30 and MPC 6.4.7.6
Windows Media Player 9 with Xvid RC1 decoder play smooth. I presume, but not sure, that WMP9 use VMR9.

I hope it helps...

PS1 - With VMR9 and packed bitstream and bframes-2 I have no choppy playback.
PS2 - In "Max consecutive BVOPs" I put 10 but it only used a maximum of 2! Anything wrong?!?

***EDIT (IMPORTANT)***

Now I'm really confused... I made some more tests... I reencode 30seconds at 600Kbps with all options on (packed, bframes-10 (it used a maximum of 2) and others) and with all options off.

Conclusion is:

In ZoomPlayer 3.30 Standart & MPC 6.4.7.6
With overlay & Xvid RC1 decoder
all on - play smooth
all off - play choppy

With overlay/VMR9 & fddshow
all on - play choppy (as I'm waiting)
all off - play smooth

With VMR9 & Xvid RC1 decoder
all on - play smooth
all off - play smooth

Can anyone confirm that?!?

[stereozulu]

first of all great work on rc1!

maybe someone can help me explain why the video is flipped only with bspayer in overlay mode 1, decoded by xvid.

i encoded a movie without bframes, without gmc, without qpel etc. and tested several playback scenarios:

- VLC and WMP play it back fine using ffdshow OR XviD decoder
- BSPlayer plays it back fine with ffdshow in overlay mode 1 or 2 OR xvid decoder only in overlay mode 2

has anyone tested it with zoomplayer?

So why does BSPlayer in overlay mode 1 decoded by XviD flip the video?
It seems to be a decoding issue, which has nothing to do with the encode itself. XviD 1.0 Beta3 didn't have this problem ...

So is this a BSPlayer issue or a xvid decoder issue?

[sapient]

I think I found a bug.
With the new RC1 (just this build) virtualdub crashes when I try to scan into or jump to a frame that belongs in a constant quantizer zone. Vistualdubmod and nandub give no error message, they just shut down. Virtualdub 1.5.10 reports the following:

An out-of-bounds memory access (access violation) occurred in module 'xvidcore'...
...while decompressing video frame 204339 with "XviD MPEG-4 Codec" [biCompression=44495658] (VideoSource.cpp:1772).

On the other hand, the whole file plays just fine with the latest version of media player classic.

[Assault]

@ sapient

It seems you are the third person that has found this bug within the last two days. Read those threads for further information. ;)

thread 1 (http://forum.doom9.org/showthread.php?s=&threadid=69582)
thread 2 (http://forum.doom9.org/showthread.php?s=&threadid=69728)

Assault

[nanga parbat]

Niltze!

Loking good here so far...

Just one small thing - I was running a second pass with no b-frames and not using quant 1. Quant ranges were 2-3 for i-frames and 2-4 for p-frames, so 2-4 in total.
Now status window showed sth. like 2.50 in avg quant for i-frames and 2.25 for p-frames - which both are right - whereas total avg quant reported was like 1.34 - which is wrong.
Sorry for not giving you exact values, 'auto-close window' was turned on.
Seems like it's calculating a wrong value for total average...
Surely not a problem, just that you know of it.

[edit] Also avg framesizes get calculated wrong: 27166 avg for i-frames, 11980 avg for p-frames and 6512 avg total.
Seems to me like quant 0 or framesize 0 for (not used) b-frames get somehow taken into account.

Guidance, nanga.

[jkwarras]

Originally posted by sysKin
This was a perfectly good start for a perfectly good encoding session, or at least that's all I can tell from what you said.

Next time i will keep my mouth closed. i've run the second pass again and turn just perfect and hit the exact target size. I really don't know where my ideas come from.

Don't confuse people with posts like that. Finish your move and if it is wrong, oversized or something, *then* tell us.

Sure. You're right. Sorry about that.

BTW. Excellent work! My encode looks really great with this build.

Just a suggestion: This would be nice if it was possible to adjust the film effect (in the decoder) like in ffdshow or DivX (a slider for ex.). Decode works good for me in MPC, for this 3 b-frames and packed bitstream enable encode (in an avi).

[crusty]

PS2 - In "Max consecutive BVOPs" I put 10 but it only used a maximum of 2! Anything wrong?!?

The codec makes an intelligent (ahum) decision about when to make a frame a b-frame or a p-frame.
You can basically tell it that it can use 1000 in a row if it wants to, but if it doesn't need more than 2 you won't get any more.

[Gazza]

Please below the results from my first test of XviD-1.0-RC1-25012004;

First I hit Load Defaults and then set the following;
Qpel on, Packed Bitstream Off, 2 Bframes, Mpeg, Chroma Motion, Turbo all other parameters are default.


Results;
Target file size 1,318,285 (2 cd's)
File size achieved 2,089,150

This represents a file over sized by 770,865. After the encode, I noticed that I had profile AS @ L5 set. This profile is set as a default.

I haven't had this problem with beta 1,2 or 3 with profile 'unrestricted', so I am assuming that the profile 'AS @ L5' is what is causing the file size blowout.

Testing again with the 'unrestricted' profile (can you make that the default?). Does anyone know if there is a problem with 'AS @ L5'?

Gazza

[Human_USB]

I don't think it's just AS @ L5. I had a large size differents when using Quant 2 and 1.


In my post on the second page;


I loaded up a 30 second video and set the Kbps to 10000 and encoded. Below is what I got;


Min I, P, B 1 - Video size 9.46MB, 403Kbps
Min I, P, B 2 - Video size 2.53MB, 108Kbps



I don't know if they want it to balloon so much or it's just a careless bug. I have yet to read pass page 5, so I don't know if the problem has been addressed yet.

-Jason

[Manao]

Gazza : Is it possible that you made a mistake while setting up the codec ?

If not, could you tell us the movie on which the test was made, its runlength, the resolution to which you encoded, and if you used different zones.

[Gazza]

@ Manano,
I checked back to the codec settings and they look good (except for using the profile AS @ L5). I don't think I made a mistake.

The test was 'Signs' which is quite a dark movie. Runlength is 1:42.08 (from the encoded avi), encoded resolution is 704*368. I used the default zones settings which where frame # = 0, Weight/Quant = W 1.00, no modifiers.

edit - I also had Turbo switched on

[Human_USB]

Just change the I, B, and P Quant to 2 and your video will encode fine.

[Gazza]

@ Human_USB,
Of course. I will test again. Can I suggest that the these settings ('unrestricted' profile, I, B, and P Quant set to 2) be the defaults in the future to prevent potential problems?

Thanks for your help here.
Gazza

[iago]

Gazza,

Read my previous post in this thread. I'm almost sure that your first pass size (you can check it out with StatsReader2.1 that comes with XviD) is lower than your target size. In other words: saturation!

In this case, quant 1 frames are used to compensate for the undersize and reach the target size, which produces hugely oversized files with the default overflow treatment values (5/5/5).

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.

It has got nothing to do with 'AS @ L5' profile.

regards,
iago


edit:

Human_USB,

If the problem is saturation in Gazza's case (I think he'll confirm it soon), capping quants 2-31 will only lead to an undersized file this time!

If not, there's something completely different going on then... ;)

[seewen]

Just to say that I always used AS @ L5 profile (don't know if it changes anything), 2/3 B-frames, Packet Bitstream, VHQ 1 or 4, Turbo, Adaptative quant or not, Chroma ME, Chroma Opt, Cartoon or not, Trellis or not, Min Quant 1 or 2, H.263 or HSV-better/good matrixs.

I tried with 1 Zone of W 1.00 or Differents Zones (With constant Quant, 0.5 W, etc.. ).

I often used the "Quant 2 Zone trick" for the first pass.

I aimed differents bitrate (between 500 and 2000 ).

And XviD ALWAYS reached the correct size (700 Mb, 1400Mb, 2000Mb).
(I tried with 10-12 differents movies. Not small clips. 1h30-3h00 long movies).
---------

I must add that my KISS DP-450 player played the content perfectly. Even with "unrestriced profile" (but again.. does it change anything?).
In fact with the new builds (RC1 & gamrdev builds) the FF/FR feature of the kiss works LIKE WITH DVD !! It's excellent !

I don't know why I had problems with Beta 3 and some movies.. I maybe used a damaged CD-RW or something.. :o


And bravo for the speed. With my P4C, it's not unusual to reach 70fps during 1st pass ;) ( 2-10x more than DivX 5.1.1, for a better result (smaller filesize, same/better quality)

[Gazza]

@Iago,
Thanks for the advice. I have set the overflow treatment values to 10/20/20 and reset the quant ranges back to the defaults of 1-31. I will have to do the first pass again as I had already started a retest with quant values 2-31 and the original stats file was overwritten.

I will let you know my results when finished (which takes about 9 or 10 hours with a 1GHz pentium)...

Cheers

Gazza

[DevilsChild]

Originally posted by crusty
The codec makes an intelligent (ahum) decision about when to make a frame a b-frame or a p-frame.
You can basically tell it that it can use 1000 in a row if it wants to, but if it doesn't need more than 2 you won't get any more.

Is this really true? I've always heard that you shouldn't use more than 3 or 4 max consecutive b-frames.

[sysKin]

Originally posted by DevilsChild
Is this really true? I've always heard that you shouldn't use more than 3 or 4 max consecutive b-frames. Crusty's "ahum" explains that. The decision is smart but not smart enough, you sometimes have to prevent stupid decisions by setting max to 2.

BTW if you want to have more b-frames, use b-frame sensitivity in zone settings. Try 10 or 20 and you'll get more b-frames (great for end credits).

Radek

[JJ2335]

Hi! Thought I might put in a request and share the latest finidngs on this issue.

Flip video occurs with XviD 1.0 RC1-B3 + Dvobsub 2.23. As stated the flipped video is limited to dvobsub usage regardless of container in question (avi, ogm, mkv). Versions prior to XviD 1.0 clearly had no flip issues. Bottom line check your filters; MPC can state filters loaded also look for the green arrow task tray icon.

I have graciously forwarded gabest, developer of vobsub of this issue but he has yet to reply. Many changes have been made in XviD 1.0. Is it possible a fix or workaround be made by the developers instead?


Keep up the great work!

[sapient]

@assault

I read the threads you quoted. Now, If *you* 've read my post you would see that the circumstances are completely different. So that's why I think this is a new one.

[Gazza]

@ iago,
I terminated the second pass as the finished file size reported by VDubMod was about 2300mb after 40 minutes into the second pass. For this test, I had returned the min/max quant's for I,P and B frames to 1-31 and set the following;

Overflow control strength (%) - 10 (default was 5)
Max overflow improvement (%) - 20 (default was 5)
Max overflow degradation (%) - 20 (default was 5)

There must be something else at play here. What other information can I give that could help finding the problem?

Gazza

[Koepi]

Gazza:

a second pass always reports weird things. You can stop it if you already have 1GB after 40% of the movie, but only because reported estimated filesize shows 2GB there isn't necessarily anything wrong.

So please finish the 2nd pass completely and see for yourself.

Another thing, did you set any quant zones by any chance? If you do a first pass at fixed quant 2 and forget to reset the zone to be a weight zone on 2nd pass, the file will be identlical to the first pass....

Regards
Koepi

[Gazza]

Hi Koepi,
I agree that the second pass can throw up some weird results. I tried un-installing RC1 and re-installing Beta 3. I ran this for about 30% and it seemed to be hitting the correct file size. The overflow controls where 5/5/5 (default) and the quants where capped at 2-31 (default for beta 3).
I then un-installed Beta 3 and re-installed RC1. This time the overflow controls where 5/5/5 (default) and I changed the quants to 2-31 (the default values are 1-31 for RC1). I have ran about 5% but these early observations are identical as to those I saw for the test with Beta 3. I will continue the test to see what the end result is but my gut feel is that is will be OK. Therefore (at this early stage) it looks as if quants capped at 1-31 will give you overlarge files and the default values should be 2-31.

[Ark]

Hi all!!

this is my first post in this great forum that helped me a lot of times, so thank you all for your great help!!

(and sorry for my so-so english :) )

I want to report that on my comp seems that the 1-31q oversize problem seems to exist only at times.

I've made a test with LOTR Extended Edition (of which i made a backup with every new beta release :) ),only the first disc, with the same settings:

- Default profile (AS @ L5)
- Adaptive quantization
- Qpel
- Default B-VOP (2/1.50/1.00)
-------
- some zones for start credits, and for the movie: Weight 1.00 (of curse :) )and Chroma Optimizer
- Motion Search Precision 6
- VHQ 4
- Chroma Motion
- Trellis Q

only changing the quantizer range at 1-31 for first encode and 2-31 for the second, aiming for a 795mb Xcd with Ogg vorbis audio @ 2.00q.

Overflow at default values.

The AVS used is very simple:

source = Mpeg2Source("C:/...../LOTR.avs)
return source.Crop(2,78,-2,-78).Lanczosresize(640,272).Undot()

The target video size is 747123 kbytes.

The result was:

1st encode (Q @ 1-31)= 747030 kbytes
2nd encode (Q @ 2-31)= 747024 kbytes

...so the target filesize is reached successfully on both encodes!

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

Sorry for the long post, I hope to be of any help for you developers, and keep up with the fantastic work on Xvid!!

[Jaw3000]

As I have posted before, 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. I used the standard default profile.

I've tried encoding the above movies again once with "Discard First Pass" off, and it seemed to produce undersized files. I'll now try the Italian Job again with both "discard first pass off" again and with Quant set to 2 instead of 1. Compressibility test did finally work when I turned of "Discard First Pass." I wonder what will happen if I use "Discard First Pass" off and Quant 2 or just quant 2? Maybe I have to run it twice for both settings! As a newbie, do I set every Quant that's currently 1 to 2? Anyway, I'll post the results tomorrow.

Btw, how does setting Quant from 1 to 2 affect the image quality?

Koepi: Have you (or the Xvid team) figured out what's causing this phenomenon yet? Has a definitive fix been found yet? I've seen things here and there on the forums (such as doing the above), but it's always nice to hear it from the source! :)
-Jaws

[Ark]

In my test of LOTR_SEE, the encode with quantizer range of 1-31 looked slightly better to my eyes, I mean a very very little less mosquito noise around edges and a bit less blockiness on backgrounds and on fast moving objects

[Assault]

@ sapient

Just wait for the next release or even better try gamer's (http://xvid.gamrdev.com/) latest build and report if your problem still exists.

Assault

[m0rtal]

about new bitrate calculator, embedded in xvid...
it's cool, thanks a lot, but why there is only avi and mp3?
what about mkv, ogm, ogg, mp4, etc...?

[bond]

Originally posted by m0rtal
about new bitrate calculator, embedded in xvid...
it's cool, thanks a lot, but why there is only avi and mp3?
what about mkv, ogm, ogg, mp4, etc...? because i guess it would bloat the whole thing, avi+mp3 is still the most widely used combination
it would be pretty much work if you want to calculate all possible combinations with avi, mkv, ogm, mp4 + possible audio formats: vorbis, aac, he-aac (mutlichannel maybe makes a difference), mp3, ac3 aso...

[Leak]

Originally posted by Assault
Just wait for the next release or even better try gamer's (http://xvid.gamrdev.com/) latest build and report if your problem still exists.

By the way - does the xvid.ax that comes with Gamr's builds work for anyone? It hasn't been working for me for a while now...

(I meant to say the installer reports "Unable to load xvid.ax", and regsvr32ing it manually does work, but at home ZoomPlayer then used the vfw wrapper for XviD and at work it just crashes... of course, installing sysKin's bugfixed version works, but I guess it wouldn't hurt if Gamr's builds would ship with a working decoder... :))

np: El-P - Deep Space 9mm (Fantastic Damage)

[sysKin]

Originally posted by m0rtal
about new bitrate calculator, embedded in xvid...
it's cool, thanks a lot, but why there is only avi and mp3?
what about mkv, ogm, ogg, mp4, etc...? Add it add it add it! :)

I wish I knew how to add it :(

[m0rtal]

bond ok than, maybe devs should allow us to enter audio stream size using "open existing file" option - right now I can insert mp3 files only :(
but I don't use mp3 at all, I use Ogg Vorbis only...

[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