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:

[Assault]

I've just tested gam3r's latest build and the PAR feature still works there. As gam3r compiles from cvs HEAD, the experimental PAR code seems to be part of the 1.1 tree already. So just use his builds if you really need this feature.

Assault

[Neo Neko]

Originally posted by sysKin
Thanks 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.

Koepi is known for putting in some experimental code from time to time. But syskin I have to say I found the feature extremly usefull and quite stable. "I LOVED IT!" And now I am sad. :( Is there any known issue for which it is not being included? The feature worked perfectly with Xvid and 3ivx. I could find no problems with it. It just rocked! I want to use RC4 and 1.0. But this is the sorta thing that could keep me using RC3 till 1.1. That is unless koepi would be kind enough to compile experimental RC4 binaries for us PAR/DAR junkies.

[symonjfox]

I read the topic but I didn't understand 2 things?

1- What is the difference between RC3 and RC4, talking about AR settings?

2- If the RC4 is MPEG4 compilant, why doesn't the 3ivX decoder use this new AR correctly? Has it to be implemented?

When I have some time, I'll try to reencode something to RC3 and 4 to see if I wrong something or not (but I use Xvid since years, and I usually make few changes from the default settings, so ... I think to be right)

[kilg0r3]

Originally posted by Neo Neko
But syskin I have to say I found the feature extremly usefull and quite stable. "I LOVED IT!" BTW, If I am not mistaken, Mosu's mkvmerge even reads this value from an avi file if you don't specify a value.

[SiXXGuNNZ]

Originally posted by sysKin
Thanks 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.

dang, that's a shame, it was working like a champ here in rc3, well, now I am eager for 1.1

[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.
No idea why it stopped.

[/B]

You speak like you've experienced this same problem. I've tried two/three versions of VDub so far. I've tried the newest VDub and VDubMod, both have problems only with the XviD 1.0 line, any other XviD codec does not drop ONE frame. It is weird and rather annoying that 1 frame is removed.

XviD 1.0 has done this to all my sources; DVD, TV captures, etc. No other version has. I can't explain it. I use the newest AviSynth to frameserver my sources to VDub, but I doubt its AS as its only w/ this 1.0 line.

Any suggestions anyone?

[theuser86]

Originally posted by kilg0r3
@ theuser86

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.


I am not using DVD2AVI for this project. This is the exact situation I'm dealing with at the moment.

Capture Video w/ Lossless codec (Huffyuv). Frameserve the AVI w/ AviSynth 2.54 to VDub. Only filter used: is the decomb filter for de-interlace. Encode the video w/ 2-pass XVID 1.0. Plus like I said it does not drop frames with previous versions of the xvid codec. If I were using a the unfixed DVD2AVI + DLL, any version of the xvid codec would drop frames, not just the XviD 1.0 line. Thanks for the help, got any other suggestions?

[Leak]

Originally posted by theuser86
You speak like you've experienced this same problem. I've tried two/three versions of VDub so far. I've tried the newest VDub and VDubMod, both have problems only with the XviD 1.0 line, any other XviD codec does not drop ONE frame. It is weird and rather annoying that 1 frame is removed.

The problem here is that it's not XviD screwing this up but VirtualDub. IIRC, VirtualDub has a workaround that'll compensate for this problem (the codec not getting enough frames so that the last frame is a P or I frame, as B-frames can't just hang in the air and the codec can't make extra frames up as it can only ever return one output frame for one input frame) by serving extra (duplicated) last frames to the codec until it gets a P- or I-frame, but it doesn't recognize the newest versions of XviD anymore (probably because the code for the workaround hasn't been updated for some time).

It's VirtualDub that needs to be fixed (probably by adding the new XviD version string somewhere), not XviD.

np: Ulrich Schnauss - Crazy For You (Blue Skied An' Clear comp.)

[theuser86]

Originally posted by Leak
The problem here is that it's not XviD screwing this up but VirtualDub. IIRC, VirtualDub has a workaround that'll compensate for this problem (the codec not getting enough frames so that the last frame is a P or I frame, as B-frames can't just hang in the air and the codec can't make extra frames up as it can only ever return one output frame for one input frame) by serving extra (duplicated) last frames to the codec until it gets a P- or I-frame, but it doesn't recognize the newest versions of XviD anymore (probably because the code for the workaround hasn't been updated for some time).

It's VirtualDub that needs to be fixed (probably by adding the new XviD version string somewhere), not XviD.

np: Ulrich Schnauss - Crazy For You (Blue Skied An' Clear comp.)

I hope you are right cause I really do prefer XviD 1.0 over the previous versions. However, how come no one else is experiencing this problem? Can you tell me the version of VDub that you use if you do not experience the problem I do. Thanks :)

[Leak]

Originally posted by theuser86
I hope you are right cause I really do prefer XviD 1.0 over the previous versions. However, how come no one else is experiencing this problem? Can you tell me the version of VDub that you use if you do not experience the problem I do. Thanks :)

I guess it's quite different - at least with the stuff I encode (anime episodes mostly), the end usually consists of a few black frames, which I couldn't care less about if they go missing.

I guess that's why nobody notices it or cares much about this... :)

(You wouldn't happen to have the "Change so video and audio durations match" selected in VirtualDub's Frame Rate dialog? I never use it, but if you do that might cause the audio to go out of sync; I'm only using VirtualDub's audio features to mux an MP3 track with my video that I prepared using BeSweet, and if the audio happens to be a fraction of a second longer than the video it'll probably get cut off when the file is played or so...)

np: Future 3 - Stuff (Blue Skied An' Clear comp.)

[theuser86]

Originally posted by Leak
I guess it's quite different - at least with the stuff I encode (anime episodes mostly), the end usually consists of a few black frames, which I couldn't care less about if they go missing.

I guess that's why nobody notices it or cares much about this... :)

(You wouldn't happen to have the "Change so video and audio durations match" selected in VirtualDub's Frame Rate dialog? I never use it, but if you do that might cause the audio to go out of sync; I'm only using VirtualDub's audio features to mux an MP3 track with my video that I prepared using BeSweet, and if the audio happens to be a fraction of a second longer than the video it'll probably get cut off when the file is played or so...)

np: Future 3 - Stuff (Blue Skied An' Clear comp.)

I do not use that option in VDub, it actually changes the framerate which I do not do.

For some reason I think it drops a frame from the beginning of the video. Reason is if I use a non-1.0 codec and all the frames are preserved, the audio is fine. However, if I use the 1.0 codec and ONE frame is lost, the audio is slightly out of sync. The only reason I can come up with as I prepare my MP3 audio track exactly the way you do w/ BeSweet, is that one frame is removed from the beginning of the video. It is really weird, I have no clue why it does that.

BTW, can anyone else confirm that w/ XviD 1.0 one frame is dropped from the source? Or everyone's source and encoded AVI have the exact same amount of frames and its just my settings (even tho they are practically the default settins.) Thanks.

[mikeX]

@theusers86

This issue has been discussed before in some beta* or rc* thread, here in the xvid forum, you might find usefull stuff if you search...
IIRC u can use avs2avi (small command line encoding application) without encountering this problem...Look for it in here in doom9 (in some thread, can't remember which one...)

ps: I also experience missed frames from time to time (usually at the end of the clip and usually as much as my max b-frame setting)
If your first frame was dropped you would most likely encounter a serious lag since all following p/b frames would be un-decodable...

[sysKin]

Originally posted by Neo Neko
But syskin I have to say I found the feature extremly usefull and quite stable. "I LOVED IT!" And now I am sad. :( Is there any known issue for which it is not being included? The feature worked perfectly with Xvid and 3ivx. I could find no problems with it. It just rocked! I want to use RC4 and 1.0. But this is the sorta thing that could keep me using RC3 till 1.1. That is unless koepi would be kind enough to compile experimental RC4 binaries for us PAR/DAR junkies. Okay you might like to hear that: 1.0 as well as 1.1 do *decode* such PAR correctly. This means that you can encode with 1.1 (or rc3...) and give the clip to a person with 1.0 and he'll see a good PAR.

As for problems with it - it's highly nonstandard, my own solution that simply (ab)uses AVI header. It is not supported by anything (3vix must have read mpeg-4 PAR, not this funny PAR). The information dissapears when stream is remuxed to ogm and might dissapear if it's remuxed to another avi. And it was never tested right, either.

What you can do: use xvid.dll from RC3 and the other two libraries from RC4. Or wait a couple of hours, I'll compile RC4 xvid.dll with this code enabled.

It was supposed to be a surprise in 1.1 ;_;

[silver_cpu]

Well, I know this is slightly off-topic, but I thought I'd mention it anyway. I noticed that the only link that is easy to see is the direct link to Koepi's web site. Now, while I'm sure that Koepi has paid for excellent bandwidth to provide us with easy downloads of his newest build, it occurred to me that this might eat up quite a bit of bandwidth. Koepi, have you ever thought about offering an ed2k link, to allow edonkey P2P users to share your binaries? It's safe to use as the file cannot be changed and recieve the same hash mark, and those of us using programs like emule can save you some bandwidth, no?

[Prettz]

Originally posted by 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.
Not only would that be great, but it would also be awesome if there was an option to write the second pass log to a file rather than (or just in addition to) having to capture the debug output. If you write the log to a text file, it should also put all the encoding parameters at the top of the file, and some of simpler overall-statistics at the bottom (not necessarily all the stuff that xvid-analyzer gives you, but just some basic overall stuff).

[begu]

Originally posted by theuser86
I do not use that option in VDub, it actually changes the framerate which I do not do.

For some reason I think it drops a frame from the beginning of the video. Reason is if I use a non-1.0 codec and all the frames are preserved, the audio is fine. However, if I use the 1.0 codec and ONE frame is lost, the audio is slightly out of sync. The only reason I can come up with as I prepare my MP3 audio track exactly the way you do w/ BeSweet, is that one frame is removed from the beginning of the video. It is really weird, I have no clue why it does that.

BTW, can anyone else confirm that w/ XviD 1.0 one frame is dropped from the source? Or everyone's source and encoded AVI have the exact same amount of frames and its just my settings (even tho they are practically the default settins.) Thanks.
Hmmm..
this is very interesting. And it might explain my observations of very slight AV desync, I'm experiencing.

So, now this is important: does this happen only when b-frames are turned on? Or does this frame drop happen every time (not dependent on the b-frame settings)??

Maybe we could 'trim' the AV-sync with interleaving values. So, if the first frame is missing, I guess that delaying audio by 40 ms (for PAL 25fps file) would compensate, right?

I have been doing TV captures using virtual dub sync (mod) as capture program. It syncs the audio with the video using PLL techniques and resamples the audio to match the video. So no frame dops. Now, I have used xvid RC-x codecs to capture video. And to compensate at re-compress, I should apply a 80 ms of delay to audio, right? (One frame for capture and one for re-encode) Or maybe I'm wrong. Note: I don't use b-frames anywhere in the process.

This is very confusing, someone says the frames drop from the end and vice versa. But indeed there might be something to look up. And it sounds like virtual dub problem. But it is important to know if this issue affects only when using b-frames or not.

edit: and I don't use AVIsynth either. Direct AVI file open in virtual dub file menu.

[Koepi]

Nowerdays asynch problems most likely arise because we have _no_ decoding lag(packed bitstream...). So if your audio was -80ms from dvd, correct it to 0 ms in besweet and everything should be fine.

You can very simply verify it when unchecking packed bitstream, reencode and mux the audio. If it's synch now, we found the reason for the asynch audio IMO.

The dropped frames are at the end. You can verify this when creating an artificial avi which consists of the sequential number for each frame (produce the video i.e. with avisynth). There you'll see how many frames you have and can see the dropped ones when stepping frame-per-frame through the encoded file with vdub.

Koepi

[begu]

Originally posted by Koepi
Nowerdays asynch problems most likely arise because we have _no_ decoding lag(packed bitstream...). So if your audio was -80ms from dvd, correct it to 0 ms in besweet and everything should be fine.

You can very simply verify it when unchecking packed bitstream, reencode and mux the audio. If it's synch now, we found the reason for the asynch audio IMO.

The dropped frames are at the end. You can verify this when creating an artificial avi which consists of the sequential number for each frame (produce the video i.e. with avisynth). There you'll see how many frames you have and can see the dropped ones when stepping frame-per-frame through the encoded file with vdub.

Koepi
Thanks Koepi.

The actual question (sorry for bad english, maybe I was mis understood) is:
- will there be a lag (drop) of one frame if I don't use b-frames, when using virtual dub of 1.5.4 ?

And considering my suggestion of 80 ms delay (it was not DVD). I meant something like this:
1. capture to AVI using Xvid RC4 (or other 1.0)["interlaced encoding" = "on"] and WAV 44.1 kHz audiowith virtual dub sync (mod)
2. re-encode the captured AVI with same xvid codec [ilace = on] to AVI with CBR MP3 (fraunh.) using some filtering

So if on frame is dropped in each encoding step, a delay of 40 ms will have to be used for each encoding step. Now I have two steps of svid encoding, so I have to delay the audio in re-encoding process by 80 ms to compensate the frame drop in each encoding process.

NOTE: if this frame drop thing does not affect original I- and P-frame encoding, my slight AV-syc problem source is elsewhere.

And I'm sorry if I'm confusing something here, but I just saw this post about frame drop and it sounds like the problem I have too.

[swalker]

Is there any hope of getting windows xp manifests packaged with or inside of the ax and the vfw dll (others?) so that themed widgets are shown instead of classic widgets?

[HeadlessCow]

With RC4 I'm having trouble with xvid's decoding of Divx5 that wasn't occuring before.

I've got a short clip that will display the problem I'm talking about here (http://www.rit.edu/~ncg2558/Files/doom9/xvid-problem/blocky-rc4.avi).

There's also a couple of screenshots that show the problem I'm talking about.
At the top right (http://www.rit.edu/~ncg2558/Files/doom9/xvid-problem/top-right.png)
At the bottom left (http://www.rit.edu/~ncg2558/Files/doom9/xvid-problem/bottom-left.png)
Along both sides (http://www.rit.edu/~ncg2558/Files/doom9/xvid-problem/both-sides.png)

Using RC3 or ffdshow to decode the clip doesn't show any of the blockiness that I'm seeing with RC4.

[theuser86]

Originally posted by mikeX
@theusers86

This issue has been discussed before in some beta* or rc* thread, here in the xvid forum, you might find usefull stuff if you search...
IIRC u can use avs2avi (small command line encoding application) without encountering this problem...Look for it in here in doom9 (in some thread, can't remember which one...)

ps: I also experience missed frames from time to time (usually at the end of the clip and usually as much as my max b-frame setting)
If your first frame was dropped you would most likely encounter a serious lag since all following p/b frames would be un-decodable...

Thanks mikeX! You have fixed my one frame drop problem. avs2avi encodes the avi from the source very nicely and keeps all the frames when using XviD 1.0 RC4.

@Koepi

Thanks for the suggestion. I have encoded the source twice, once using packed bitstream, once with that option unchecked. I will soon mux w/ audio and test the 2 to see if one results in audio which is perfectly synch. I'll post the results when I get time to test that.

[iradic]

ENCODING:
Resolution: 352x288
Pixel Aspect Ratio: PAL 4:3
XviD ver: RC3 & RC4

MUXING:
3ivX muxer

PLAYBACK:
rc3.avi rc3.mp4 rc4.avi rc4.mp4
rc3-dec 384x288 352x288 352x288 352x288
rc4-dec 384x288 352x288 352x288 352x288
3ivx-dec 384x288 384x288
ffdshow 352x288 314x288 352x288 314x288


I love this game...

EDIT: mplayer plays all files at 384x288

[sysKin]

Originally posted by HeadlessCow
With RC4 I'm having trouble with xvid's decoding of Divx5 that wasn't occuring before.

I've got a short clip that will display the problem I'm talking about here (http://www.rit.edu/~ncg2558/Files/doom9/xvid-problem/blocky-rc4.avi).
Okay. The only decoder change between rc3 and rc4 is motion-clipping which is supposed to prevent crashes with damaged bitstream.
Obviously I b0rked something *again* :(

[HeadlessCow]

Awww....I still love you anyways syskin :devil:

[begu]

Originally posted by theuser86
Thanks mikeX! You have fixed my one frame drop problem. avs2avi encodes the avi from the source very nicely and keeps all the frames when using XviD 1.0 RC4.

@Koepi

Thanks for the suggestion. I have encoded the source twice, once using packed bitstream, once with that option unchecked. I will soon mux w/ audio and test the 2 to see if one results in audio which is perfectly synch. I'll post the results when I get time to test that.

theuser86:
Could You please try tests without b-frames?
This is the only thing I need to know: does the frames drop ONLY when using b-frames?

[dapipa]

hi ya'all!i cannot confirm the 1_FRAME_MISSING bug,my setup is:latest AviSynth,VDM1.5.4.1 & RC4 and encoded stream has exactly the same number of frames as source stream...
p.s.my BVOP settings are 1/1/1...

[virus]

ok, I reported back this on the 3vix thread, but it's really difficult to identify the culprit...
I'm having trouble when seeking XviD video demuxed from an MP4 file.
I'm using the 3vix splitter for that, and the 3vix decoder allows seeking without problems, but both RC3 & RC4 decoders gave problems. Often the video is frozen (MPC, WMP, ZoomPlayer, ViPlay), sometimes I get a crash in xvidcore (MPC). The AAC audio plays fine, always.
Tried that with a couple of clips (made with RC1 & RC3, no packed bitstream). I've also tested libavcodec as decoder... seems to only work with ZP, with ViPlay seeking is ok but the player crashes when exiting, with MPC my system hangs opening the file (!).
Normal playback (i.e. without seeking) is usually fine.
I can stick with the 3vix decoder for now, but I'd like to use the XviD decoder for XviD video... any idea?

[bond]

Originally posted by virus
I'm having trouble when seeking XviD video demuxed from an MP4 file.with "demuxed from mp4", you mean avi -> mp4 -> avi files?
if yes how did you demux the video stream? mp4ui seems to be buggy for that

Often the video is frozen (MPC, WMP, ZoomPlayer, ViPlay), sometimes I get a crash in xvidcore (MPC). The AAC audio plays fine, always.
Tried that with a couple of clips (made with RC1 & RC3, no packed bitstream). I've also tested libavcodec as decoder... seems to only work with ZP, with ViPlay seeking is ok but the player crashes when exiting, with MPC my system hangs opening the file (!)for testing files always use graphedit for playback, to ensure that no bugs in the players kick in!

[intermezzo]

A nice feature in the next RC would be a quick-updater which checks the website for updates. If it finds a new version, it provides the offer of installing it directly from the web instead of downloading it. Sound good?

[virus]

Originally posted by bond
with "demuxed from mp4", you mean avi -> mp4 -> avi files?
if yes how did you demux the video stream? mp4ui seems to be buggy for that
no, just playing an MP4 created from an XviD AVI and an AAC track, built with graphedit and the 3vix muxer. The DS filter chain is .mp4 -> 3vix splitter -> xvid decoder -> overlay mixer2, checked with GSpot.
(I read carefully your guide :D)

[bond]

i noticed the following problems with the xvid decoder (together with mp4 files muxed and splitted with 3ivx tools)
i didnt use om2 but compatibility renderer, and the splitter with frame accurate seeking enabled (tested both in graphedit and bsplayer)

- nero digital streams with b-frames crash in xvidcore (not without b-frames)
- 3ivx streams (simple profile) show colorful artifacts for a short time after seeking
- sorenson streams are decoded full of colorful artifacts

divx5 streams (with/without b-frames), ffvfw (default settings) and xvid (with/without b-vops) worked fine here


ffdshow has no problems (with exception of the ND problem)
3ivx has no problems, except ND again

i tested different samples, but small ones, so it might not cover problems which might be there

[bond]

Originally posted by virus
I'm having trouble when seeking XviD video demuxed from an MP4 file.
I'm using the 3vix splitter for that, and the 3vix decoder allows seeking without problems, but both RC3 & RC4 decoders gave problems. Often the video is frozen (MPC, WMP, ZoomPlayer, ViPlay), sometimes I get a crash in xvidcore (MPC).
Tried that with a couple of clips (made with RC1 & RC3, no packed bitstream). I've also tested libavcodec as decoder... seems to only work with ZP, with ViPlay seeking is ok but the player crashes when exiting, with MPC my system hangs opening the file (!).
Normal playback (i.e. without seeking) is usually fine.yes there are problems with the xvid decoder
i now tried it with a longer clip. on my side i dont get crashes, freezes or anything like that, but i get wird colorful artifacts after seeking (without seeking everything works fine)
also i dont get these things with ffdshow, 3ivx and divx5 decoder (they work fine)

as i said i tested this with graphedit and bsplayer
the test encode was rc3 and used 2 b-frames, qpel, trellis, h.263

[Chainmax]

I searched for answers in the forum but found none, so here's my question:

Is the standalone decoder still needed?

[mikeX]

@ Chainmax

The standalone decoder is not needed!
It was introduced in one of the beta versions and became obsolete on the very next one iirc
The file structure of the current RC releases (the way they are provided by Koepi) is as follows:

xvidcore.dll (encoder/decoder)
xvidvfw.dll (vfw frontend for configuring encoder/decoder)
xvid.ax (directshow decoder [previously standalone])

all of which come packaged in the current installer!

[In general each of these files is compiled independantly, with 'xvidcore.dll' being the primary library needed and all other being optional]

[symonjfox]

Originally posted by intermezzo
A nice feature in the next RC would be a quick-updater which checks the website for updates. If it finds a new version, it provides the offer of installing it directly from the web instead of downloading it. Sound good?
It sounds really good, but there's a big big problem: Xvid is officially released as Source Code and it's often updated, so you should update it daily (or use Gamr's instabuild).
Instead if you're talking about Koepi's builds, well, check this forum once a week and you surely find something, right? :D

[Koepi]

In fact, i was thinking about taht feature all the time. But I fear it would have bad side effects:

- people would start thinking i make xvid.
- i could change my homepage location sometime near in the future (you know, getting a real contract, moving out of the dormitory,... - which all means i have to change servers)
- it would give xvid binaries an official touch. We can't do that as I can't afford to pay licenses(25.000$ max per year is still way more than i earn, even if i'm not a student anymore). XviD is and will stay educational.
- increased traffic for "nothing", and the bad reputation you get when your program/... connects to the internet (even if requested).

Consider this just an excerpt(?) of the reasons i found to _not_ write a tool which would do that. Though I added the links in the start menu to the respective homepages... I hoped this would be a good trade-off between "hit & run updater" and self-education.

Maybe I need some opinions from lawyers, if any are around. :)

Regards
Koepi

[mikeX]

Originally posted by intermezzo
A nice feature in the next RC would be a quick-updater which checks the website for updates. If it finds a new version, it provides the offer of installing it directly from the web instead of downloading it. Sound good?

I find it a really bad idea, mostly because of all the reasons Koepi himself mentioned
The links in the start menu should suffice to the average user looking for updates, and for someone really clueless an updater wouldn't help since he would probably install xvid from codec packs etc...

[Soulhunter]

Hmm, still no "save statistics to file" option like in DivX & ffvfw... :(

[john27]

When I load defaults from 2-pass GUI is partelly disabled(xvid1.0 RC4
on win2000 and win98).
You may delete dering from decoder GUI (encoder->decoder options)

sorry for my english

[el divx]

@Koepi:Then how about a guide to set up instabuilds, for those users in the crowd that want to always have the latest CVS code in their machines, compiled and running? From what I've understood till now the code gets better optimisation if it's compiled on the user's pc than on another person's pc e.g. if I compile it myself on my system, I'll get better performance than if I just go and grab the binaries, won't I?

[Koepi]

el divx:

wow, i wonder where you did hear that, scientifically it's totally wrong. There are only certain compiler optimisations which allow for certain different compile results, but there's nothing like "system setup specific compiletime optimization" :)

So bottom line, you can just use what's out there as binaries. It's not possible to adopt the binary further than compiling it specifically for a certain processor architecture.

Regards
Koepi

[el divx]

Ok, my mistake.

[lordadmira]

Originally posted by Leak
The problem here is that it's not XviD screwing this up but VirtualDub. IIRC, VirtualDub has a workaround that'll compensate for this problem (the codec not getting enough frames so that the last frame is a P or I frame, as B-frames can't just hang in the air and the codec can't make extra frames up as it can only ever return one output frame for one input frame) by serving extra (duplicated) last frames to the codec until it gets a P- or I-frame, but it doesn't recognize the newest versions of XviD anymore (probably because the code for the workaround hasn't been updated for some time).

I just encoded a file with RC4 from an SVCD source file using VirtualDubMod build 2439 and the number of frames in the output avi file was correct. 97933 in, 97933 out. Granted the end of the video is a fade out so I can't be sure if it kept the original final frame or replaced it with a dummy one. I had Bmax = 8 and Bsens = 80.

[theuser86]

Originally posted by begu
theuser86:
Could You please try tests without b-frames?
This is the only thing I need to know: does the frames drop ONLY when using b-frames?

@begu

I did one test with no b-frames (unchecked the option for B-VOPs in the encoder setup) and the one lost frame still occured.

But anyways, just use AVS2AVI v1.35, all the frames from the source and seen in the encoded avi.

[john27]

When I load defaults from Twopass, GUI is partially disabled(xvid1.0 RC4 on win2000 and win98).[IMG]c:/Xvid.jpg[IMG]

[Dragon Shenron]

Happy Easter everyone.

I had a problem with XviD decoder crashing when trying to decode a clip which does not start with an I-frame, but it starts with a P-frame. The clip was encoded with DivX 4 (muxed in avi) and it was badly cut (from me, ofcourse) from a larger clip long time ago. RC4 is the only XviD version I tested it with. Libavcodec decodes the clip fine, except the first few frames are grey, and MPC and VirtualDubMod crash when I try to use XviD as a decoder for DivX 4 through ffdshow (build 19.3.2004).
This is what I extracted from the crashinfo.txt form VDubMod:
Crash reason: Integer Divide-by-Zero
Crash context: An integer division by zero occurred in module 'xvidcore'... ...while decompressing video frame 0 with "XviD MPEG-4 Codec" [biCompression=58564944] (VideoSource.cpp:1823).

I hope this can be fixed so XviD can decode this "bad" clips.

[sysKin]

[ About broken DX50 decoding, spotted by HeadlessCow ]
Originally posted by sysKin
Okay. The only decoder change between rc3 and rc4 is motion-clipping which is supposed to prevent crashes with damaged bitstream.
Obviously I b0rked something *again* :( Heh look, it was only supposed to work on damaged bitstreams... but DX50 bitstream also has motion out of range (!) so it's concidered damaged.

Evilness.

I just commited a fix. It's still safe, and doesn't break DX50.

:)
Radek

[sysKin]

Originally posted by Dragon Shenron
I had a problem with XviD decoder crashing when trying to decode a clip which does not start with an I-frame, but it starts with a P-frame. The clip was encoded with DivX 4 (muxed in avi) and it was badly cut (from me, ofcourse) from a larger clip long time ago. RC4 is the only XviD version I tested it with. Libavcodec decodes the clip fine, except the first few frames are grey, and MPC and VirtualDubMod crash when I try to use XviD as a decoder for DivX 4 through ffdshow (build 19.3.2004).Could you please upload some small version of a clip like that? I'd like to fix it, but it will be so much easier if I could reproduce the crash here :)

Radek

[Dragon Shenron]

Originally posted by sysKin
Could you please upload some small version of a clip like that? I'd like to fix it, but it will be so much easier if I could reproduce the crash here :)

Radek

I uploaded the clip here (http://www.geocities.com/dragonballhr/divx_clip.avi)

[sysKin]

Originally posted by Dragon Shenron
I uploaded the clip here (http://www.geocities.com/dragonballhr/divx_clip.avi) We're sorry, but this page is currently unavailable for viewing. :(

[celtic_druid]

Works fine for me. 110KB's.

[dragongodz]

sysKin - use "save target as" for that link and it downloads fine.

[lordadmira]

Nope. It just saves an avi file with the error page in it.

[dragongodz]

worked ok for me, 110k avi(and yes i viewed it to make sure it really was intact and correct).

maybe try a different browser or a download manager.

[Koepi]

They have a referer checker.

1) copy the link and paste it into a new browser window / tab.
2) ignore the "file not found" page and copy the link into the browser adress line again and hit enter.
3) enjoy the file open/save dialog.

Koepi

[Dragon Shenron]

Originally posted by celtic_druid
Works fine for me. 110KB's.
Do you mean the avi works fine in VDubMod or the download works fine?

@all
Sorry for the download problems, but I don't have any other hosts to upload files for free.
I use FlashGet so I paste the link directly in there so I have no problems downloading it.

[Leak]

Originally posted by Koepi
They have a referer checker.

4) If you happen to be using Mozilla or Firesomething, install the Prefbar and just remove the checkbox before "Referrer" in the Prefbar before clicking the link... :)

(Dragging the link to the end to the tab bar will work as well...)

np: Vladislav Delay - Anima (Anima)

[sysKin]

Before you post any more on this - I have the file (thx Koepi) and I already know why it crashes. More - tommorow.

:D

[bob0r]

Mirror :D
http://66.246.16.28/prosac_upload/tmp/divx_clip.avi

It crashes media player 6.4, I have not read all replies, just figured i mirror the file, so everything gets done to make the next RC build even better :p

[lamer_de]

I experience an annoying behaviour when using the bitrate calculator:
Usually, i use the "file" option for audio to calculate the size my audio will need. However, if I added the mp3 (only use that, but I guess it's the same for all other kinds a of audio formats/containers) via streams-> stream list already, I get a msg box:
Error. Could not get filesize

Fairly annoying. It works if I set up the codec first and then add the audio, so it's prolly vdubmod that causes this problem by locking the file. I don't know if it's possible to fix that easily in xvid (maybe read-only access the file, I don't know), but if it is, please do so ;)

TIA,
lamer_de

[Wildfire]

Installed RC4, encoded a few DS9 episodes, then quickly went back to 24062003_1 ALPHA. Filesizes of the rips varied wildly, whereas with 24062003_1 ALPHA I always got a nice 560mb rip (video only) just as I wanted it.

(yes, I uninstalled the old XVid first and yes, I'm using GordianKnot 0.28.8)

[communist]

Originally posted by Wildfire
Installed RC4, encoded a few DS9 episodes, then quickly went back to 24062003_1 ALPHA. Filesizes of the rips varied wildly, whereas with 24062003_1 ALPHA I always got a nice 560mb rip (video only) just as I wanted it.

(yes, I uninstalled the old XVid first and yes, I'm using GordianKnot 0.28.8)
Did you use Gknot for the whole encoding process or only to setup the avs?
If its the first there is nothing wrong that it didn hit filesize because (as has been said several times) GKnot doesnt work (correctly) XviD 1.0 Beta * / RC*. This is not a XviD bug.
Just encode with VDub / VDubMod :|

[Wildfire]

Originally posted by communist
Did you use Gknot for the whole encoding process or only to setup the avs?
If its the first there is nothing wrong that it didn hit filesize because (as has been said several times) GKnot doesnt work (correctly) XviD 1.0 Beta * / RC*. This is not a XviD bug.
Just encode with VDub / VDubMod :|

GordianKnot takes care of everything for me. I set up the job in GordianKnot, press Encode and there it goes.

I especially installed GordianKnot 0.28.8, as it was supposed to have XVid 1.0 support. But if I understand you correctly, no (correct) support for the beta / release candidates?

[zettai]

Originally posted by Wildfire
GordianKnot takes care of everything for me.

It doesn't take care of everything if it doesn't produce encodes you want.

If you can verify that this encoding problem occurs when you process video manually (loading an avs file you wrote and setting the options by hand) then yes, it might be a bug - otherwise it's impossible to tell if it's the encoder at fault or the settings that gknot is feeding into it.

[Sirber]

Hi

I'm currently trying this build with "The Godfather Part 1" at 2.9mbps for DVD-R backup. Been a while since I touched XviD :D. Might post some screens :D

[Soulhunter]

Originally posted by Sirber
Might post some screens :D I'll do too !!!

Just done another Reloaded encode n' this time with my own custom matrix... Quality is simply superb !!!

[haibane]

Here is the screen shots of the problem:
http://www-personal.umich.edu/~liusu/bug/trellis_ON_DS.png
http://www-personal.umich.edu/~liusu/bug/trellis_ON_VFW.png
http://www-personal.umich.edu/~liusu/bug/trellis_OFF_DS.png
http://www-personal.umich.edu/~liusu/bug/trellis_OFF_VFW.png

My xvid setting is:
All off in profile tab except b-vops(3/100/100), packed bitstream and closed GOV.

Motion precision is 6, VHQ is 4, chroma motion on, turbo off, quant restriction is from 1 to 31 for all.

On the zone setting i restrict the quant to 1 to show the effect, and chroma optimizer is on.

I use the RC2 matrix for the encoding, and of course I'm using Xvid RC4.

The problem I encountered is that when using very high bitrate with trellis quantization, the quality of the p frame seems to drop, turning trellis off seems to solve the problem.

I took screen shots of the file rendered by ffdshow with xvid4 decoder and shots of it rendered in virtualdubmod. They show identical problem.

You may not see it immediately, but if you flip backward and forth between the one with trellis and the on without, the difference is obivous.

In addition, b-frames are not effect by this, so during play back, the picture is flickering.

[BoNz1]

You may not see it immediately, but if you flip backward and forth between the one with trellis and the on without, the difference is obivous.

Yes, there is somewhat of a difference between the letters with trellis on and off. The letters are more blurry with it on for sure and the last two seem to sort of bleed into the rest of the picture. In fact someone noticed a bug in trellis code today which was fixed, so test it out with one of GaM3R's latest to see if there is any improvement.
EDIT: Doesn't look like it is there yet http://xvid.gamrdev.com anyway you are looking for a build with changes to mbtransquant.c and xvid.h. Actually you will might have to wait since GomGom probably will wait a little to merge the 1.0 branch changes with HEAD.

[sysKin]

Actually don't use Gam3R's builds right now, HEAD is broken.
I'll compile most recent 1.0 code and post it here, ok? Just give me two hours.

Radek

[JasonFly]

Originally posted by Soulhunter
I'll do too !!!

Just done another Reloaded encode n' this time with my own custom matrix... Quality is simply superb !!!

As you are talking of Reloaded, I have a little question. I 've done an encode of this movie osme time ago and I had some problems I a particular scene(the scene in the begininng of the movie when neo fly before the moon, 10min59sec in the PAL version). The result, even in constant quant 1(just to see the visual result), wasn't very good and I had some "black blocks".I used defaut parameters of xvid(or almost the same) with an hvsbest custom matrix.

I've reduced this effect with some "blockbuster" in avisynth, but this wasn't perfect.

Does your own matrix also show something similar in this particular scene?

[virus]

From sysKin's signature
- directshow decoder: missing first frame; memory leak when decoding currently-disabled 4CCs.

may this affect playback of video with mp4v 4CC? (...that problem with seeking, mentioned some posts ago...)
If so, I can give it a try.

virus

[kurt]

Originally posted by sysKin
Okay you might like to hear that: 1.0 as well as 1.1 do *decode* such PAR correctly. This means that you can encode with 1.1 (or rc3...) and give the clip to a person with 1.0 and he'll see a good PAR.

As for problems with it - it's highly nonstandard, my own solution that simply (ab)uses AVI header. It is not supported by anything (3vix must have read mpeg-4 PAR, not this funny PAR). The information dissapears when stream is remuxed to ogm and might dissapear if it's remuxed to another avi. And it was never tested right, either.

What you can do: use xvid.dll from RC3 and the other two libraries from RC4. Or wait a couple of hours, I'll compile RC4 xvid.dll with this code enabled.

It was supposed to be a surprise in 1.1 ;_;

I donwloaded latest build (200404152010) from gamrdev.com, but the picture AR flag will not decode correctly yet (ffdshow is uninstalled, wich was my problem of the RC3)... so i go back to RC3 ... will you fix this in the near future, syskin?

thx

[Soulhunter]

Originally posted by JasonFly
As you are talking of Reloaded, I have a little question. I 've done an encode of this movie osme time ago and I had some problems I a particular scene(the scene in the begininng of the movie when neo fly before the moon, 10min59sec in the PAL version). The result, even in constant quant 1(just to see the visual result), wasn't very good and I had some "black blocks".I used defaut parameters of xvid(or almost the same) with an hvsbest custom matrix.

I've reduced this effect with some "blockbuster" in avisynth, but this wasn't perfect.

Does your own matrix also show something similar in this particular scene?
IIRC, it already looks this bad on the DVD... :sly:

In that case blockbuster wont help much as its only prevents introducing new blocks !!!

Maybe BlindPP or a "flat" smoother would help with this... :rolleyes:


Bye

[niamh]

hhhmmm, on a completely non-technical note :D.......do we know what the final release will be called? :)

Indirect, subtle, curious-making links work best...
yes they do ... lol . I HAD to go there and check it out :)

for the rest i have nothing to say as i find Hola works great for me, i find it fast, gives me a great output, and have found no issue. By the way, i use gknot and my output size is extremely reliable, the usual with xvid, ever so slightly undersized. I have not had a single problem with the new gordian knot.Great job all round.

----Cant wait for the final release and the ensuing party!!!!:D :D :D ---- weeeeeeeeeeeeeeeeeeeeeeeeeeeeee :cool:

[Soulhunter]

Btw, here (http://forum.doom9.org/showthread.php?s=&threadid=74477) are the promised screenshots... ;)


Bye

[yaz]

Originally posted by sysKin
Actually don't use Gam3R's builds right now, HEAD is broken. sorry for butting in, but ... what does it mean xactly ? sg's building heavily on gam3r's site. so, what's that ?
Originally posted by sysKin
I'll compile most recent 1.0 code and post it here, ok? Just give me two hours. & where from would we expect this debug-release ?
thx
y

[sysKin]

Originally posted by yaz
where from would we expect this debug-release ? Right... Look how lazy I am, I didn't even keep that promise (on time).

So, a newest set of binaries can be downloaded from http://syskin.is.dreaming.org/xvid1.0rc4b.rar

It's the files alone, I don't even know how to make an installer. Just replace your older files in windows\system32. No registration neccessary if older files were registered.

Changes:

VfW: calculator can open audio files that are already opened.

Dshow: memory leak fixed, *might* fix the problem with DIVX files crashing explorer.exe if DIVX support was disabled. Also, will display first video frame correctly.

Core: Certain DivX5 files were decoded incorrectly with RC4 due to "wrong" clipping of out-of-range motion vectors. Also, a lame bug made encoding slower with vhq(2..4)+qpel.

I hope I haven't forgotten about anything. It's been compiled with MSVC6 so it's probably not as fast as Koepi's.

Have fun,
Radek

[Sharro]

My admired Friends,

I've been wondering on one of two possibilites if they are not too complicated to implement (and somebody is willing to do it):

-at the end of each encode to issue a "alt+PrtScr" (print screen for active window) for Xvid Status Window and write the corresponding jpeg
-at the end of each encode to write a txt with the data present on xvid status window.

For the vfw on the debug... a small check box in the debug window... "write txt at end of encode"

When I batch a few encodes I can only see the data for the last encode :-(. If I shut down computer in the end... than I have no way of checking even the last encode.

If it's complicated, forget this post. Xvid is turning out so good... that sometimes... it just better to look at visuals and forget the numbers....

Just my 5 cents.

All the best

Sharro
AKA Xvid Tribalist Fan

[kassandro]

Just gave xvid another try. Unfortunately black&white movies are still getting partially colored pinq. At least the green coloring seems to be gone. I wonder, that this very old bug cannot be fixed.

The user interface has improved.

[lordadmira]

Originally posted by kassandro
Just gave xvid another try. Unfortunately black&white movies are still getting partially colored pinq. At least the green coloring seems to be gone.

I have also experienced this when I set the zone option to grayscale. I thought I screwed up somewhere. :D Speaking of bugs the tooltips are all borked up. Some are missing and others disappear after a second. Still others make no sense.

[lordadmira]

Originally posted by Soulhunter
You mean this scene ???
IIRC, it already looks this bad on the DVD... :sly: In that case blockbuster wont help much as its only prevents introducing new blocks !!! Not to mention the fact that the moon is *in the wrong place*. :readfaq: MoonFAQ that is.

[Heini011]

Hi,

@Sharro - Xvid Status Window:

You can use my very little command line tool to get statistics from an xvid-first-pass .pass file. (works now even with file sizes > 4 gb).

Copy this tools to your windows directory and type for example xdstat c:\video.pass > c:\xvid.txt

http://www.veganismus.com/reina/pc-site/XDstat.EXE

greetings, heini011.

[Sharro]

For that I have good old Koepi's xvid stats reader :-)

For second pass.... I got nothing ... If I have another encode after or I turn off my pc :-)

All the best,

Sharro

[niamh]

By the way, i use gknot and my output size is extremely reliable, the usual with xvid, ever so slightly undersized.

i HAD to open my big mouth...sigh...i just got an oversized file with gknot and the new xvid. I had been tinkering with the start menu options in the start menu to do tests....so i guess this overrides gknot options somehow. They would need to be reset...will try now, and off for another round :devil:

[mikeX]

Originally posted by kassandro
Just gave xvid another try. Unfortunately black&white movies are still getting partially colored pinq. At least the green coloring seems to be gone. I wonder, that this very old bug cannot be fixed.

The user interface has improved.
I also get this with b/w movies, but it doesn't have anything to do with greyscale as lordadmira says, at least I get it even when I don't use greyscale!
I'm also getting very noticeable green slimes but only when I use the default colourspace (YUY2) with my (2) nvidia cards, so I suspect it has something to do with them and/or their drivers (CruNcher (ATI) and sysKin could not reproduce my green slimes, only the pink ones)(, which also indicates a decoding issue, rather than an encoding one?).
For the record ffdshow (latest alpha by Milan) also produced slimes...
Under Linux with Mplayer (1.0pre3try2) I can't make out any green slimes (at least not as noticeable) with every output driver I try, either with ffmpeg or xvid as decoders, but the pinks ones are still there : P

[Leak]

On the 2nd pass configuration page, it says "Overlflow treatment" - that's one "l" too many (and I don't mean that in the "Overlfow" sense... ;))

np: Man'sbestfriend - Little Bank Anthem (The New Human Is Illegal)

[sysKin]

Originally posted by Leak
On the 2nd pass configuration page, it says "Overlflow treatment" - that's one "l" too many (and I don't mean that in the "Overlfow" sense... ;))Hah! Thanks Leak :D

[haibane]

Originally posted by sysKin
Right... Look how lazy I am, I didn't even keep that promise (on time).

So, a newest set of binaries can be downloaded from http://syskin.is.dreaming.org/xvid1.0rc4b.rar

It's the files alone, I don't even know how to make an installer. Just replace your older files in windows\system32. No registration neccessary if older files were registered.

Changes:

VfW: calculator can open audio files that are already opened.

Dshow: memory leak fixed, *might* fix the problem with DIVX files crashing explorer.exe if DIVX support was disabled. Also, will display first video frame correctly.

Core: Certain DivX5 files were decoded incorrectly with RC4 due to "wrong" clipping of out-of-range motion vectors. Also, a lame bug made encoding slower with vhq(2..4)+qpel.

I hope I haven't forgotten about anything. It's been compiled with MSVC6 so it's probably not as fast as Koepi's.

Have fun,
Radek

hi sysKin,
I tried the version you posted, it still suffers the same problem from rc4. Turing trellis off would solve the problem.

[Tingletangle Bob]

Originally posted by niamh
i HAD to open my big mouth...sigh...i just got an oversized file with gknot and the new xvid. I had been tinkering with the start menu options in the start menu to do tests....so i guess this overrides gknot options somehow. They would need to be reset...will try now, and off for another round :devil:

I just ran into a similar problem. One Episode of the X-Files Season 7 always gets oversized (over 950 MB, I wanted 740).

First pass runs fine; during the second pass, XviD uses only Quants of 1 and 2. The average bitrate is over 3000, but should be around 2200 (I hope the numbers are correct; I'm not at home right now).

I just read in the Unofficial XviD FAQ (Section D3) that there have already been problems with a minimum Quantisizer of 1. I will try to set the minimum Quant to 2 and give you an update.

My XviD Settings:
Defaults, then BVOPs disabled, QuarterPixel enabled.

[kassandro]

I have now run several test encodes with RC4 and VirtualDubMod (1 pass fixed quantizer) and all the resulting Matroska and Avi files are seconds out of a/v sync right from the start. If I encode the same avs scripts with divx 5.1.1 instead everything is fine. What do I make wrong?

[Sirber]

Gidfather Part 1 turned out very good with some noise reduction at 2.9mbps at DVD rez. I'm quite surprised (in the good way) about how XviD evolved. There is no visible artefact! :D

Settings:
MPEG Quant
B-Frames max 3 @ 150
QPEL

Results:
I: 1-2
P: 1-3
B: 2-6

Most frames in 2-3.

http://www.webernic.com/sites/sirber/GFP1.jpg

[CruNcher]

huh did i hear right and you just gave kudos to a lowertec codec then RV10 *impressed* looks @ the calendar hmm nope not christmas ;)

[Teegedeck]

I'm happy that more and more people seem to be interested in transparent (indistinguishable from the original - well, except for denoising perhaps...) encodings at anamorphic DVD-resolution. See also the Matrix HQ encoding thread. DVD+/-Rs got a lot to do with that, I believe. I for one enjoy XviD more than ever now that owning a DVD+R writer gives me some freedom choosing a bitrate. For some time now, MPEG-4 is usable for high-quality encodings and not only those 640x272 1-CDs with softening-filters and h.263 quantization we used to do a long time ago.

[Koepi]

Hm. I feel bad now, I still don't own a DVD burner (wherefore? My CD burner works just fine, _I_ get very satisfying 1 CD quality :P ). Also, Taking the pressure away to produce nice quality at low bitrates is not what I consider a good development. :)

But that's quite OT now :)

Regards
Koepi

[Teegedeck]

Oh; sorry. Didn't want to take something away from anywhere. :) Don't feel bad.

I, too, still do 1-CDs. I test at pretty much any bitrate just in order to see how well it works. And I back up my classical concerts and b/w movies onto 1 CD.

DVD-resolution and transparency at 2 Mbps is quite a demanding task for a codec, too, BTW.

BTW (2) I couldn't resist including a DVD-burner when I put together a PC for my girlfriend. A NEC 1100A (4x) sold for 69 Euros at amazon - that's not so much pricier than a good CD recorder. So I have to correct myself - I do not really 'own' a DVD+R. :p

[JasonFly]

I don't own a DVD writer now but my feeling about this is that putting only one movie on it is a waste.Altough Xvid Anamorphic encoding at 1024 resolution seems to be amazing, there is no gain(beside the fact that you loose all the interactivity with DVD player...). It's just my opinion, but I prefer to put more movies at DVD resolution on one DVD than only one movie with higher resolution.

But it's just a matter of taste, like many other debates on this forum(What quantization matrix to use?, what's best resolution? what are the best parameters...)

BTW, RC4 is good for me. No problems with it, keep going XviD team!!!, I hope you're proud of what you have done.

[Sirber]

I usualy do 2-language rip, english and french. Audio size usualy goes from 800MB to 1100MB in AC3. DVD-R are welcome :D

[Teegedeck]

For me, 2 movies per DVD+R seem to make sense. 2 CD-Rs would cost me 60 cents, half a DVD is worth 50 cents.

[SeeMoreDigital]

Originally posted by JasonFly
...Altough Xvid Anamorphic encoding at 1024 resolution seems to be amazing, there is no gain(beside the fact that you loose all the interactivity with DVD player...). It's just my opinion, but I prefer to put more movies at DVD resolution on one DVD than only one movie with higher resolution. If your experimenting generating encodes at 1024x576 pixels, please note that this is not an 'anamorphic' frame size, it is a 'true 16:9 frame' size!

DVD's and DV taped images are stored 'anamorphicly' ie: 720x480 (1.50:1) or 720x576 (1.25:1).

Cheers

[Soulhunter]

Originally posted by JasonFly
I don't own a DVD writer now but my feeling about this is that putting only one movie on it is a waste.Altough Xvid Anamorphic encoding at 1024 resolution seems to be amazing, there is no gain(beside the fact that you loose all the interactivity with DVD player...). It's just my opinion, but I prefer to put more movies at DVD resolution on one DVD than only one movie with higher resolution.

But it's just a matter of taste, like many other debates on this forum(What quantization matrix to use?, what's best resolution? what are the best parameters...)

BTW, RC4 is good for me. No problems with it, keep going XviD team!!!, I hope you're proud of what you have done.
:goodpost:

- Maybe 1x DVD-R encodes are not good to test your encoding skills !!!

- Maybe 1x DVD-R encodes are not good for development as Koepi said !!!


But on the other hand...

DivX is not able to produce such a magnificent quality as XviD !!!

So also this way of encoding is another proof of XviD's superiority... :p


Bye

[Sirber]

Originally posted by Soulhunter
- Maybe 1x DVD-R encodes are not good to test your encoding skills !!!

- Maybe 1x DVD-R encodes are not good for development as Koepi said !!!Maybe 1x DVD-R encodes are good to watch :D

[dandragonrage]

I get corruption in some areas when XviD decodes DivX. One of the files I have trouble with is DivX 5.02, the others are either 5.02 or 5.05. Sometimes I just get strange colored blocks. Sometimes it results in mega smearing-something will move and it will just make a really ugly trail across the screen.

I can take screenshots later this evening if needed. I'd have to uninstall DivX to do it and DivX is busy decoding right now.

[Soulhunter]

Originally posted by Sirber
Maybe 1x DVD-R encodes are good to watch :D
Of course they are... :p


Bye

[poochie2]

I was wondering if it would be so pointless the idea of a checkbox that, if enabled, allows the codec to write a very small text file in the selected directory that collects all the info such as set encode parameters and statistics (like the ones present in the status window).

Let me know, Poochie

[beezle]

My RJ1500 divx player does not support the new rc3/rc4 versions of xvid. It does however support the previous versions of the xvid codec. This sucks.

I can't believe the codec is so different that my player says "codec not supported"

I also can't believe that my player is already obsolete.

In a separate issue, when I open the avi in virtual dub, I get a message on the screen about b-frames and possible lag. If I am just using virtualdub (in conjunction with an audio decompressor) to change the mp3 audio from VBR to CBR, will my video be affected at all. I am guessing it shouldn't since I just have video set to direct stream. I saw some of the previously posted issues with virtual dub in this thread, but those seem to be related to encoding problems.

****Updated****

After further testing, it looks like the problem does not lie with the xvid rc3 codec after all. I will update as I find out more info

[beezle]

This person also seems to be having a problem with the new xvid codec on his divx player.

http://forum.doom9.org/showthread.php?s=&threadid=74752

[mikeX]

beezle:
The issue you mention with VirtualDub is a known one and should not worry you at all. The video does not get affected in any way, it's just a vfw limitation (?)
You can find more about it in previous threads...

About your standalone issue, what settings are you using with XviD?
The defaults (2 max b-frames e.g.) have changed since earlier versions of the codec. Tweak your settings in order to make your encode more DivX compatible (e.g. 1 max b-frame) and try if that's playable.
You may also find useful information in older threads and/or in the 'Hardware Players' section of this forum.
Don't underestimate the power of the 'search' button :)

[poochie2]

About the compatibility issue, I think it's something related to the codec itself. The change should have occoured between the last 1.0 beta and the RC1, as since then ffdshow had to be updated in order to correctly decode the video, and my ps2 movie player won't read them anymore... I'm about to bou a Kiss dvdplayer and I'm a king of worried about this issue :'(

[beezle]

I have read a suggestion that using 4cc to change headers might help if the standalone player is not recognizing rc3 or rc4 because of an unknown header. Is there a new header associated with the xvid codecs?

If so, what header changes would be suggested for best compliance?

Using nic's fourcc, I see there are two options, used codec and dscription code. Should I just change the description code to divx? Do I have to change the used codec to divx as well?

[lordadmira]

Originally posted by beezle
[B]My RJ1500 divx player does not support the new rc3/rc4 versions of xvid. It does however support the previous versions of the xvid codec. This sucks. You can upgrade the firmware. Check their website In a separate issue, when I open the avi in virtual dub, I get a message on the screen about b-frames and possible lag. If I am just using virtualdub (in conjunction with an audio decompressor) to change the mp3 audio from VBR to CBR, will my video be affected at all. I doubt the message had anything to do with B frames. Vdub can't process VBR MP3 audio. Even in direct stream copy. Split the audio, process the video with VDub like normal, then mux in the audio with NanDub. If u don't want to do that then ur gonna have to jettison avi altogether and use ogm or matroska. It's not a limitation of VFW per se, but the avi file container and specifically the RIFF header.

[RadicalEd]

Originally posted by lordadmira
I doubt the message had anything to do with B frames. Vdub can't process VBR MP3 audio. Even in direct stream copy. Split the audio, process the video with VDub like normal, then mux in the audio with NanDub. If u don't want to do that then ur gonna have to jettison avi altogether and use ogm or matroska. It's not a limitation of VFW per se, but the avi file container and specifically the RIFF header.

Er.. actually, xvid always displays this message (B-frame lag) when packed bitstream is off and the video is being read in through the vfw decoder :/

[dandragonrage]

No, there is a B-Frame lag message when you open files with B-frames in Vdub. It's not a popup, it is simply on the first frame of the video. It's the VfW decoder that does that. It means nothing, really.

Edit: Whoops, didn't see that we made a new page. I've been beaten to the point.

[RustyNails]

After upgrading to Hola! XviD-1.0-RC4 05.04.2004 I only get audio NO VIDEO!

Previously used version with no problem.
XviD [Koepi's build 24/June/2003] [Encoding]
XviD [Koepi's build 24/June/2003] [Decoding]



Have tried all settings (?) but still only audio.

What am I doing wrong?

[lordadmira]

I want to relate that I too have now experienced the "chops last few frames" bug/feature. I encoded a short clip with VDubMod and no filters or sound. 1824 frames on input became 1818 frames in the file. And again 2280 frames became 2275 in the output file. I can understand temporal filters eating frames but this is a vanilla encode eating frames. Anybody see this with other encoding apps?


LA

PS Just for giggles I reencoded the 2280 frame clip with MS-MPEG v3 and whadaya know. 2280 frames out. So it appears that in fact RC4 is eating frames all by itself. :devil:

[Koepi]

lordadmira:

i get the impression that you dislike reading. that point has been tracked down (several times on this very thread) to be related to the usage of a buggy vdub(mod) version (=user error). Stick with avs2avi or vdub(mod) versions 1.5.4.1 or earlier (the bug is: delay frames don't get properly interpreted in those higher vdub(mod) versions and thus to little frames get served to xvid and written back to the file).

Koepi

[lordadmira]

Ahh. Thanks. I did read back 1 page cuz I remembered that it came up but I didn't see anything about a resolution to it. The last I read it was unverified. We can't read everything each time we think our memory is working. :)

PS I went back and reread the whole thread from the beginning. There is in fact a serpentine explanation waaay back at the beginning of April. Far too long ago and nebulous to stick to my brain. :)

[bond]

latest virtualdub(mod) versions drop 1 frame when 2 b-frames are set, 2 frames with 3b aso...

lordadmira,
i assume you used a very high number of b-frames, right?

and yes avery leed knows about this problem, next vd should include a fix

[lordadmira]

Well I haven't seen a real correspondance between Bmax and the number of frames dropped. I've had Bmax set to 8 and 10 and the number of missing frames has been from 2 to 5.

[beezle]

Update

Earlier in this thread, I thought my standalone divx player had a problem with movies encoded in the new rc3/rc4 codec. I need to qualify that a little bit because I found out that some things encoded in the new codec play fine without any problems. As it turns out, it is only certain things which I think have too many b frames. It is only those things which give me the b frame lag error in virtual dub that are giving me problems on my standalone player. Here are some of the problems:

1) Won't play at all and says codec not supported (with QPEL, it specifically says QPEL not supported, so QPEL is NOT the issue)

2) Wrong colors. For example, everything has a blue shade and/or blue color

3) Garbled colors and shapes (picture not clearly shown). This is just too difficult to explain. I would have to post a sample, which I can't do at the moment, but let me know if you want to see a sample and I can put up a still image in a reply.

Everytime I see that b-frame lag error in virtual dub, it is guaranteed that I will have a problem on my standalone.

Somebody stated earlier that using one b frame is more likely to be compatible.

Is anyone else seeing this problem on their standalone?

How can I tell how many b frames were used to encode a particular backup file?

[mikeX]

beezle:
well if that's your backup you are talking about it's fairly easy if you remember which settings u used (for example, if you didn't mess with any BVOP settings then you should have 2 max consecutive B-frames.

If you can't remember, you might wanna try using ffdshow for decoding and turn on the OSD (specifically the part that displays the type of frame). You should then try and see if you can catch 2 B-frames in a row (I know this sounds stupid and there has to be another way, but I just can't think of one atm :rolleyes: )

You should experiment with small clips and various settings to see which ones work good with your standalone.
IIRC a setting of max 1 BVOP along with 'Packed bitstream' should be DivX compatible (regarding b-frames of cource)

[Koepi]

If you're having troubles if vdub shows the bframe lag message, then use "packed bitstream". It's the cure for your problem.

Koepi

[21_already]

Hello. Sorry it's a late reply but i had problems with my computer since before release candidate 4 came out and then i've been having exams since then. To make a long story short i wanted to notify who ever it is i should that the problem i seemed to have with RC3 (i was having some problem with first pass files containing nothin causing explorer crashes), seem to be resolved with RC4 and i cannot replicate the problem anymore. What's more, those old files no longer crash my explorer (they turn up as a green blank thumbnail now). In the end it may have been due to something else on my system, i just thought i should say something seen as i just read that Xvid may go final very soon :)

[amango]

@Koepi

"XviD 1.0.0 now ready?"-thread was closed. You wrote that you wanted to offer a new built from the final xvid 1.0.0-core within a few hours in this thread. That was two days ago... :(

[Koepi]

amango:

stop whining.

as long as there is no official announcement I can't release a final binary, simple as that.

[Latexxx]

Originally posted by amango
@Koepi

"XviD 1.0.0 now ready?"-thread was closed. You wrote that you wanted to offer a new built from the final xvid 1.0.0-core within a few hours in this thread. That was two days ago... :(

Compile it from sources by yourself! :D

[amango]

I already asked how to compile XVid with MS Visual C++ Toolkit 2003 (free edition, only command prompt), but nobody answered. In the XVID-FAQ only MS VisualDev 6 is mentioned. I am sorry, but I am not used to this. The free C++ toolkit edition from Microsoft is just 30 MB long and should compile it fine, I think - but I don't know how.

If someone want to test this compiler, you can download it here (http://msdn.microsoft.com/visualc/vctoolkit2003/).

[DeeGee]

How to Compile XviD with Microsoft Visual C++ 6.0 (http://www.discdude.net/xvid/compile.html)

I used that to help me compile xvid 1.0... Of course I have just started learning to programming so I have no clue how to optimize it's performance. So my compile probably isn't as fast as Koepi's.

[Latexxx]

I managed to compile Xvid using Mingw about a year ago. There are makefiles for this free compiler somewhere in the source tree.

[Arcon]

Originally posted by Koepi
as long as there is no official announcement I can't release a final binary, simple as that.
i don't know much about the internal structure of the xvid team, so what announcement has to be made before a release of the binary is allowed? and why is this announcement still in progress nearly a week after the 1.0.0 tagging?

this is not meant as pushing, whining or bitching, i'll wait patiently as long as i have to, but i'd really like to know this :)

[Koepi]

We just are nice guys and respect each other, so we behave nice amongst us. It's called etiquette. ;)
And then we had some disussion on how to properly release the "official" milestones, and this is the result of it (the first release candidates were "rushed" by me and the team didn't like that).

Regards
Koepi

[gatormac]

The final is going to basically be the same as RC4....if they were making any significant changes they would release an RC5. So don't worry about compiling it...you already have it.

[lordadmira]

Came up with a work around for that bug in the later Virtual Dubs where some final frames are dropped. If the video has n frames, create a zone in Xvid starting at frame n-1 and check Start With Keyframe. That way the video will always end with a valid GOP.

LA

[bond]

Originally posted by lordadmira
Came up with a work around for that bug in the later Virtual Dubs where some final frames are dropped. If the video has n frames, create a zone in Xvid starting at frame n-1 and check Start With Keyframe. That way the video will always end with a valid GOPgood idea :)

[RexManning]

Yes! It's there!

Be praised, XviD team!

[Nibor]

What? Where? How? Who?
:D


RexManning, what are you talking about? :)

[RexManning]

BEHOLD! (http://www.xvid.org/modules.php?op=modload&name=News&file=index&catid=&topic=6) :-)

[Nibor]

I checked xvid.org when you wrote your post but it wasn't there then!
Well, now it is!!.. :)

Congratulations, XviD team =)
and ... thank you!!!
For giving us the best MPEG-4 codec there is :D

Regards,
nibor

[RexManning]

Yeah, it's freaking awesome *jumps around happily*

Let's just hope Koepi & friends have time to compile the binaries for the few XviD users among us that are less technically skillful ;-)

[Edit:] Damn, that was fast! Thanks Koepi!!!

[Nibor]

Oh, that was very fast :)

Hey RexManning, seems we are the only ones who are happy about it ;)