Hola! XviD-1.0-RC4 05.04.2004

[Koepi]

Hola!

I finally found the time to compile and upload a binary of it.

Changelog:

XviD-1.0-RC4-05042004 (Hola!):
- Improved bitrate calculator
- Decoder clips motion to valid range, so that it doesn't crash if bitstream is broken
- Decoder supplies quantizer information for external postprocessing (used by ffdshow)
- Decoder fixes in GMC - DivX5 GMC-ed clips weren't decoded right, also 2-point GMC
- Fixed problems caused by wrong cooperation of bframes and frame dropping code
- VfW GUI looks better on asian windows now
- Memory leak when using multiple instances fixed
- Minor fixes for VfW GUI

Find it on my page.

Regards
Koepi

[daldrum]

This is good news, indeed.
Many Thanks from an ex-divx-now-happy-xvid-user. :-)

[Dams]

Great work, good speed updating !

[Koepi]

I forgot to mention that the installer has been updated, too:

vidc.cleaner gets executed after installation if you don't untick the option in the last setup screen. This will hopefully help the cases where people experience problems with xvid not showing up after installation.

Enjoy this release!

Regards,
Koepi

[Sharktooth]

Doh! i just finished backing up a whole lot of animes with RC3...

[sysKin]

Originally posted by Sharktooth
Doh! i just finished backing up a whole lot of animes with RC3... As you can see from changelog, there is no quality improvement in RC4 :) so don't worry.

I really expect this version to become 1.0.0 final. Soon. But if you see some serious bug say now.

Radek

[Sharktooth]

Good, so RC3 and 4 should be "safe" for making final backups.
Thats indeed a great news coz i have a lot of DVD encodes made with RC3 and i always thought i had to redo the job if future builds will come with quality improvements.

[xixi2000]

greatgreatgreatgreatgreat
:D :D :D :D :D

[fl0]

thanks for the binary :)

can i ask which compiler did you use ?

icl 7 or 8 ?

i know plenty of discussion has done about this issue but as a hyperthreading enabled p4 2.4c user i still prefer icl 8; well at least pyschologically makes me feel faster :D

thanks anyway

[Koepi]

Sorry, but the "major" slowdown of ICL8 vs. ICL7 for everyone but P4 HT users (which have max. 1% more speed if at all with ICL8) made the decision simple - hands off from ICL8. :)

Regards
Koepi

[fl0]

well at least it seems it's not just pyschological thing; %1 is %1 lol :)

do we hope for an icl8 binary option for the final ?

[Kaspof]

I have a problem.
With XViD 1.0 RC3, jerky playback was completely fixed.
I have just encoded a video and when there's motion it's a little jerky :(
I used the following settings to encode the video:
2 pass
encoding settings by default
advanced options: motion search: 6
VHQ 4
chroma motion and turbo
maximum i-frame interval: 230
all other settings by default.

Everything was done on a clean WXP SP1 with all updates.
I cannot give you further details about the problem, i hope you'll look at this.
Regards

[sillKotscha]

Originally posted by sysKin
Current FAQ, valid for RC4
- may contain shreded peanuts and possibly whole coconuts
- is like 1.0.0 final, but with extra cautiousness added. And extra peanuts.

Hmmmm peanuts ~~~~~~~

...this is so funny :D

/useless post _ sorry

[ps2uk]

hi guys when i do a 2 pass encode with Koepi's XviD Codec 1.0 RC4 Build 05042004 the second pass takes much longer is this normal or do i have a option set wrong

System

Windows XP Professional 5.1.2600 Service Pack 1
Intel Pentium IV @ 2604.62 MHz Intel(R)
512mb Corsair TwinX 3200LLPT
MSI NVIDIA GeForce FX 5900XT
Adaptec 39160 Controller
Seagate Cheetah 10k6 SCSI HDDs

Settings used

AS @ L5
Motion Search Precision 6 ultra high
VHQ Mode 1 Mode Decision
Use Chroma Motion


First Pass 27 mins
Second Pass 57 mins

Thanks in advance guys

[Teegedeck]

Hi,

what do you mean by 'normal'? If you mean 'compared to second pass in RC3' this would be interesting. If you mean 'compared to first pass' then you've actually just discovered that first pass is faster than second pass (has been introduced some time ago, don't remember when exactly - it's called 'fast first pass'), not vice versa. So it's more like '1st pass is faster than normal'. ;)

[ps2uk]

Originally posted by Teegedeck
Hi,

what do you mean by 'normal'? If you mean 'compared to second pass in RC3' this would be interesting. If you mean 'compared to first pass' then you've actually just discovered that first pass is faster than second pass (has been introduced some time ago, don't remember when exactly - it's called 'fast first pass'), not vice versa. So it's more like '1st pass is faster than normal'. ;)

hi Teegedeck RC3 was the same for me too it takes much longer for the second pass
for me first pass is much faster than the second one

[mikeX]

@ps2uk

http://www.vslcatena.nl/~ronald/docs/xvidfaq.html

still the time difference looks too big since you didn't use any settings such as QPEL or GMC.
You may wanna try the first pass again with 'Full quality first pass' checked and see if it's around 57 minutes too...

[ps2uk]

Originally posted by mikeX
@ps2uk

http://www.vslcatena.nl/~ronald/docs/xvidfaq.html

still the time difference looks too big since you didn't use any settings such as QPEL or GMC.
You may wanna try the first pass again with 'Full quality first pass' checked and see if it's around 57 minutes too...


i tested it on Full Quality and got these results

First Pass - 46 mins

Second Pass - 42 mins

[Schrade]

Huh. Anyone have a mirror for the new binary? Nic's site scripts are preventing me from downloading the installer.

I'm using Mozilla Firefox so it shouldn't be a problem.

I'm also behind a Wireless Router using NAT. Have turned its simple firewall protection off and tested.. no go.

Anyone have a suggestion around the overzealous script?

EDIT: Nevermind. Just ssh'd to my shell account and used Lynx to download it there. Pretty silly that I'd have to do that but oh well!

[mikeX]

@ps2uk

Well there you go: The time difference isn't there with full quality first pass so this was the normal difference between a 'fast' and a 'normal' pass... :)

[Spitfire_x86]

Hi Kopei!

You should upgrade to latest Inno Setup version (and ISTool). Newer Inno Setup version has built-in LZMA compression and doesn't require external LZMA compression by ISTool

[Spitfire_x86]

Originally posted by daldrum
Many Thanks from an ex-divx-now-happy-xvid-user. :-)
Same here!

[sdsalsero]

Is it expected that one would need to use Compatibility Renderer to playback most (if not all) Xvid .AVIs on Windows? I got tired of testing which pre-RC3 files played OK without Compatibility enabled (none did) so I've left it enabled. But doesn't this defeat the purpose of whatever new features the non-Compatibility Renderer includes?
_________________

I just checked again and maybe my problems are all related to Zoom Player, i.e., Media Player Classic seemed to work with or without Compatibility Renderer.

[Assault]

@ sdsalsero

I think I have the same problem as you. Zoom Player won't work with the standard renderer for me if I use overlay mixer AND if I force RGB32 as output colourspace in xvid's directshow filter. If I use VMR9 instead of overlay mixer in Zoom Player, it will work.
Furthermore if I force RGB24, xvid's directshow filter isn't even used anymore no matter what player I use for playback. :confused:

Assault

[theuser86]

I have one problem with the XviD 1.0 line, all versions from RC1 to RC4 drop ONE/TWO frames when I encode. I have not had any other problems with previous versions of the xvid codec.

For example, my source of my last encode was 40748 frames, but the AVI (2-pass) encoded with XviD 1.0 RC1/2/3/4 is 40747 frames. All the settings in the codec are left as default except for the target size set on the 2nd pass. Everything else is the same, but I still have this problem. Each new version that is released I hope that problem is fixed, but I get the problem each time.

Right now I must resort to using "XviD-04102002-1.exe" which does not have the problem. I used to use the latest "unstable" release of the XviD codec but I can't find it anymore. The quality is better in XviD 1.0 than previous versions and I must credit everyone who has worked on the codec. Thanks a lot :) Hopefully someone can help me solve my problem.

Back to my problem, it seems that this ONE/TWO frames dropped are from the beginning of the video. The audio is slightly out of sync if the frames are dropped however when encoding with the latest "stable" version the total frames of the source and avi file are identical and I have no problems with the audio.

[DarkWave]

hi,

i just made an encoding with rc4 from a (lossless) tv-cap of stargate sg-1 (pal, non-interlaced, undot as the only filter, using gknot for the whole episode). the source is nearly hq, no problems here.

i attached a short clip using rc4. have a look at the wall in the background. it seems like it´s "pulsing" - sometimes noisy, then clean vid (using xvid decoder, ffdshow, mplayer classic,...)

http://home.t-online.de/home/darkwave3d/sg1/sg1pic.jpg
just for orientation, where to look...

i encoded the same clip with rc3 (gknot again) - no problems.

i used the same settings for both.
is it a bug?

how can i solve this?

you can dl the clip here... (http://home.t-online.de/home/darkwave3d/sg1/sg1xvidrc4b.avi)

thx in advance for your help and sorry for my terrible english ;)

DarkWave

[SiXXGuNNZ]

PAR 16:9 NTSC isn't working in wmp9 or mpc anymore, worked fine in RC3.

[sysKin]

Originally posted by DarkWave
i attached a short clip using rc4. have a look at the wall in the background. it seems like it´s "pulsing" - sometimes noisy, then clean vid (using xvid decoder, ffdshow, mplayer classic,...)It is a known problem of ffdshow's postprocessing. Nothing to do with XviD, clip is fine and xvid decodes it without any pulsing (even with deblocker).
Originally posted by SiXXGuNNZ
PAR 16:9 NTSC isn't working in wmp9 or mpc anymore, worked fine in RC3.What do you mean? How can you tell it's not working anymore? - by mplayer's text output? by some bitstream analyzer?
Originally posted by theuser86
I have one problem with the XviD 1.0 line, all versions from RC1 to RC4 drop ONE/TWO frames when I encode. I have not had any other problems with previous versions of the xvid codec.XviD cannot drop frames even if it wanted to. It's virtualdub's AVI workaround that doesn't kick in - normally, Vdub drops xvid's (or divx's) delay frames, and makes a workaround for the missing frames by repeating last frame until everything matches.
No idea why it stopped.

Radek

[SiXXGuNNZ]

easy to see when it isn't working

in wmp9 and mpc the video does not resize to 16:9

I will run another test encode, but it hasn't worked on the last 5 with RC4

edit: just ran a test on chapter29 of the two towers se disc1, reset codec settings to default then set all my options again, including PAR 16:9 NTSC, wmp9 and mpc do not resize them to 16:9 anymore

[sysKin]

Originally posted by SiXXGuNNZ
easy to see when it isn't working

in wmp9 and mpc the video does not resize to 16:9
Two things:
- neither RC3 nor RC4 nor any other xvid will resize. You must have used another decoder before, go back to that decoder. (nerodigital probably...)
- you actually used "16:9 NTSC" PAR? Looks weird, pixels are 40:33... how did you calculate your resolution to match? Okay, doesn't really matter.

[el divx]

This may sound irrelevant for this thread but after having gam3r's latest build I get a dshow decoder with brightness slider enabled and working. Does he modified it or just enabled code xvid devs decided to disable from rc4? Anyway, when I put koepi's one, the dshow filter looked like if the brightness slider had just never been there(could it be a miscompilation?).

[celtic_druid]

@el divx, already covered, but gam3r's are from a different CVS branch and the brightness slider can't be implimented for 1.0 because it requires an API change.

Did some HEAD compiles myself, decoder works fine, but I must admit I have not had time to try encoding anything.

[kitvirus]

In XviD-RC4,
Reset button does not reset FourCC support items and
Apply button is not enabled inspite that item values are changed.

[DarkWave]

Originally posted by sysKin
It is a known problem of ffdshow's postprocessing. Nothing to do with XviD, clip is fine and xvid decodes it without any pulsing (even with deblocker).

hi,

maybe you didn´t see, but i wrote, this pulsing happened with the "normal" xvid decoder as well as with ffdshow, so it has to be a xvid-problem.

DarkWave

[kilg0r3]

@ theuser86

Originally posted by sysKin
XviD cannot drop frames even if it wanted to. It's virtualdub's AVI workaround that doesn't kick in - normally, Vdub drops xvid's (or divx's) delay frames, and makes a workaround for the missing frames by repeating last frame until everything matches.
Could also be problem with the 'oroginal' DVD2AVI version which also likes to drop some frames.

Please use the combo of the fixed version of Dvd2Avi and Mpeg2Dec3 by Donald Graft.

@ DarkWave

Please check if ffdshow is loaded as postprocessor of for 'Raw Video'

[Arlong]

Well, many thanks Koepi! :)

[el divx]

Originally posted by celtic_druid
@el divx, already covered, but gam3r's are from a different CVS branch and the brightness slider can't be implimented for 1.0 because it requires an API change.

Did some HEAD compiles myself, decoder works fine, but I must admit I have not had time to try encoding anything.

Well, sorry for my curiosity, but could you be more specific(is it from i.e. the dev-api-3, the 1.0 or the 1.1 branch)?

[maciek_m]

many thanks, although i havaent' had the chance to try it out yet

One minor suggestion/question for the bitrate calculator:

When you set the audio format to ogg and then switch from "average bitrate" to "size" and click on the "..." button to indicate the file you want to use, the calculator suggests that the audio file you should look for is either an mp3 or an ac3-type file. You have to select "all files" in order to see an ogg file. I guess it can be "fine-tuned"?

Regards

[DarkWave]

Originally posted by kilg0r3
@ DarkWave

Please check if ffdshow is loaded as postprocessor of for 'Raw Video'

hi again ;)

i already uninstalled ffdshow completely, so mplayerc can´t use this dsfilter.
pulsing still remains :(

what you all didn´t see is the fact, that an encoding of the same episode using xvid rc3 didn´t have this effect, it only happens with rc4.
so - in my opinion - the new xvid decoder is buggy, or the encoding didn´t work correct...

DarkWave

[Assault]

@ el divx

The HEAD branch(the one gam3r's builds are compiled from) is used for 1.1 development. ;)

Assault

[maciek_m]

Would it be difficult/time consuming to have the encoder make a log file like the one BeeSweet makes? It would preserve the statistics of each encoding process it performs (like the name of the input and the output, settings, frames' quants and bitrate), so that one does not have to write them down for further analysis.

[SiXXGuNNZ]

Originally posted by sysKin
Two things:
- neither RC3 nor RC4 nor any other xvid will resize. You must have used another decoder before, go back to that decoder. (nerodigital probably...)
- you actually used "16:9 NTSC" PAR? Looks weird, pixels are 40:33... how did you calculate your resolution to match? Okay, doesn't really matter.

I didn't calculate the resolution, I cropped the black borders from raw dvd source and set the 16:9 NTSC flag in RC4, in RC3 this worked, while using xvid as decoder, not nero digital.

lagoon was the member who pointed out how to do this to me in this thread/post - http://forum.doom9.org/showthread.php?s=&postid=459641#post459641

before I started this post, I uninstalled rc4 and reinstalled rc3, I then encoded the same clip with rc3, set the PAR to 16:9 NTSC and wmp9 and mpc both resize this to 16:9 using the xvid decoder.

I then uninstalled the rc3 build, reinstalled the rc4 build and played the file made with rc3, it resizes correctly in the two players mentioned above.

I then encode the clip again with the rc4, set the PAR to 16:9 NTSC and the players do not change the aspect, yet the rc4 decoder resizes the rc3 clip.

I hope you follow what I am saying, I am just trying to figure out what is going on.

here are 2 8 second clips, direct streamed copied from the two encodes.

http://home.comcast.net/~sixxy01/rc3_8sec.zip

http://home.comcast.net/~sixxy01/rc4_8sec.zip

edit: this is how I am setting the aspect for rc3 and rc4, just in case I said anything wrong above

http://home.comcast.net/~sixxy01/aspect.jpg

[Didée]

DarkWave:

I decoded your clip with the DS's of RC3 & RC4, and with ffdshow as well.

In all three cases, everything looks stable, cannot spot anything like pulsing.

Seems like something else is buggy on your side.

- Didée

[DarkWave]

Originally posted by Didée
DarkWave:

I decoded your clip with the DS's of RC3 & RC4, and with ffdshow as well.

In all three cases, everything looks stable, cannot spot anything like pulsing.

Seems like something else is buggy on your side.

- Didée

thx for your efforts ;)

i began to uninstall all video-codecs/-filters a few minutes ago.
now, after cleaning up all codecs, i only installed xvid rc4.
you´re right, everything ssems to be ok.
then i added one codec/dsfilter after another

ffdshow - no problems (tested using xvid and ffdshow)
divx 5.1.1 - no problems ( -"- )
ac3filter - no problems ( -"- )
huffyuv - still no problems ( -"- )
nero - that´s it! after installing nero (6.3.1.16) and it´s filters the problem came back...

is there anyone who can say something about that?

DarkWave

[crusty]

Mirrored the file here (no bandwidth issues):
http://www.vslcatena.nl/~ronald/rar/XviD-1.0-RC4-05042004.exe
I'll update the FAQ asap to mention this version.
I think I should also include a question/answer about the april 1 version. :)

[symonjfox]

After reading other posts, I made a small test.

I recorded a short clip to 352*576 (4:3).
I encoded as usual in Xvid, unspecified profile, and I set the Pixel AR to 4:3 PAL.
Then I put the avi file into mp4.

I tried decoding it with 3ivX decoder but it is like 1:1 AR.

I made similar encodings hundreds of times but they were resized as well on playback.
I think it's a small issue, maybe in the header, don't know.

[bond]

Originally posted by symonjfox
I recorded a short clip to 352*576 (4:3).
I encoded as usual in Xvid, unspecified profile, and I set the Pixel AR to 4:3 PAL.
Then I put the avi file into mp4.
I tried decoding it with 3ivX decoder but it is like 1:1 AR.hm not here

i encoded an unresized pal dvd source with the 16:9 pal pixel ar option set in xvid
remuxed to mp4 with the 3ivx muxer
during playback (with the 3ivx decoder) it gets decoded with the right 16:9 ar, no problem here

Originally posted by SiXXGuNNZ
http://home.comcast.net/~sixxy01/rc3_8sec.ziphuh it really gets 16:9 resized during playback with the xvid decoder (not with ffdshow), i always thought this doesnt work

[cAEd]

Sorry if this is allready posted somewhere but i was wandering if i should change the 2nd pass settings in this latest release xvid from the default?

I know of the settings in the doom9 guide, but there are some different settings in xvid now.

I would like the best 2nd pass settings for doing a 1cd rip.

TIA c43d :]

[sysKin]

Originally posted by SiXXGuNNZ
here are 2 8 second clips, direct streamed copied from the two encodes.

http://home.comcast.net/~sixxy01/rc3_8sec.zip

http://home.comcast.net/~sixxy01/rc4_8sec.zipThanks for the clips. I checked the first one...

[2248] VIDEOINFOHEADER PAR: 40:33 -> AR 28480:11748

IF that was really real RC3, then Koepi must have made a mistake and included experimental PAR code. Yes, such code exists, but was not planned to be added until 1.1.

I myself have distribuited some xvid.dll's that contain it... and ths file *definitely* was encoded with it.

This is not a missed feature of RC4, RC3 should not have it either. It is expermental and will be part of 1.1 tree.

[Jawor]

The XviD MPEG-4 Decoder Filter from Koepi's RC3 works fine with anamorphic clips encoded with RC3 - I've even written a guide (http://www.divx.howto.pl/modules.php?name=Content&pa=showpage&pid=94) (in Polish ;) ) that explains how to encode anamorphic XviD clips. The decoder always brings back the right AR in AVI files containing anamorphic XviD streams. Will this "experimental" code be removed from 1.0.0 Final? I hope not :eek: