Jambo! (XviD-1.0-RC2-07022004)

[Koepi]

Ah, the good old yv12 stride bug.

It's fixed in CVS, fetch gamr's build and see if it helps :-) (non mod4 res. in yv12? sounds weird to me)

Regards
Koepi

[alky]

tried http://xvid.gamrdev.com/download.php/build/athlon/stamp/200402031210/XviD-athlon-200402031210.exe same thing but using mod 4 resolution helps, thanks!

[Leak]

Originally posted by Koepi
It's fixed in CVS, fetch gamr's build and see if it helps :-) (non mod4 res. in yv12? sounds weird to me)

Is it just me, or did Gamr's autobuilder go boom?

His last build is from the 3rd of February... :( (which, of course, means your RC2 is actually more current than his last build...)

np: Mouse On Mars - Funky Tiste (Glam)

[Selur]

same here :(

[Koepi]

Maybe i have to add a hidden "my most recent build" section, so that in such cases my latest build - working or not - is available for testing bugfixes.

...i'm thiking about a solution, maybe I'll come up with something fancy the next few days ;)

Regards
Koepi

[homersapien]

Xvid=All options at default, 2-pass encoding. 2nd pass file is fine when played by itself. However, when I mux it with an .ogg using OggMux 1.5.1 the resulting .ogm file has playback issues: lots of pixelation and 'smearing'. Yes, I know you'll say its OggMux's fault yada yada, however it has only done this with Jambo and whatever RC1. Does it with Xvid and ffdshow decoding.

[Selur]

Maybe i have to add a hidden "my most recent build" section, so that in such cases my latest build - working or not - is available for testing bugfixes.
Yup, a current bugfix builder would be nice so we would be able to grab it from yours and Gamr's site if everything runs fine ;)

Cu Selur

[Koepi]

homersapien:

this is indeed weird as it works correctly here:

- OggDS 0.9.9.5
- OggMux 0.9.5

Maybe you defined a mapping from xvid to divx in OggDS? Any other filters loaded (SubTitDS)?

Koepi

[_rEuTeL_]

no more flipped videos with this new release, great :)
keep it up

[Micro]

I am having a problem with RC1 & RC2 DS decoder !

Reported in this and RC1 thread previously,
20-30% of tried by me different XviD material
has stuttering problem.
Some data:
P4 3.0GHz, OS: WinXP SP1, DX9b, cpu usage is around 20%
ATI Radeon 9600Pro with latest drivers.
I am using not so well known but extremely powerful MV2Player.
The problem shows itself only when using overlay mixer.
With VMR7 or 9 I have no problem.
With 1.0 betas I had no such problem.

It seems, that audio/container has no influence on this problem.

Please consider this bugreport when preparing to 1.0 final.

XviD dev's, thank you for best encoder ever !

Micro

[_rEuTeL_]

hmmz, have to report a strange issue though
when I use min quantizer 1, the quantizers are really fluctuating (all the way up to 25 Ò.ô) with serious quality drops as a result (duh :) )

when using min quant 2, it doesnt fluctuate

[Koepi]

reutel:

do you talk about single pass (CBR) encoding?

[_rEuTeL_]

nope, happens in second pass

[Koepi]

That's most likely the result of the automatically increased overflow spreading for q1 occurences. I still think it's smart, but it must be tested and tuned a little more i fear.

Regards
Koepi

[celtic_druid]

If anyone wants to test the bug fixes then they are welcome to try:
http://celticdruid.no-ip.com/xvid.cvs.2004.02.13.rar

Download will probably be really slow though.

Ok, looks like gamr's instant builds are working again.

[sdsalsero]

I'd guess somehow ZoomPlayer is honoring the aspect ratio settings in the video file - try going to the "Aspect Ratio" tab in the "Level @ Profile" dialog (hit "more..." right next to it's combo box) and choose a 4:3 picture aspect ratioLeak,
Thanks for the suggestion but the problem seems to be on the decoding side of the equation -- with Beta3 I can correctly playback files encoded with both Beta3 and RC1. But RC1 and RC2 ignore ZP's 'request' to adjust the aspect-ratio. I have the same problem with "Xvid" files (of unknown origin or codec version) downloaded from P2P networks.

[erdie]

the jerky playback issue really is a pain in the ass.
the only workaround is not to use packet bitstream, compensate for b-frame lag while muxing, and using ffdshow for playback...

[temporance]

Just discovered a little problem with the GUI. If lauched from a command line application, the status window appears, but it's just grey with no controls. It disappears at the end of encoding. HTH.

[Maurizio]

@Temporance
I have the same problem.
I usually work with avs2avi, started from a batch file.
If I enable the status window, all I see is a gray window,
that becomes white if I cover and uncover it with another window.

[Koepi]

That issue is within the calling applications.

They don't pass through windows messages - thus the controls of that staus windows can't be build up and actualised.

Head to the author's homepages and ask them to add support for windows message passing, and you're done :)

Regards
Koepi

[vlada]

Hi,
I would like to see the constant quality setting back. If I choose onepass, there is a selection of constant bitrate and constant quantizer. What about to add constant quality, which would give the same result (quality) as twopass but with unpredictable size. I would like to use it for temporal TV recordings, which I won't burn on CDs or DVDs. Is it possible? I think it should be. Thanx, Vlada

[Leak]

Originally posted by vlada
I would like to see the constant quality setting back. If I choose onepass, there is a selection of constant bitrate and constant quantizer. What about to add constant quality, which would give the same result (quality) as twopass but with unpredictable size. I would like to use it for temporal TV recordings, which I won't burn on CDs or DVDs. Is it possible? I think it should be.

You do realize that the "Quality Mode" percentage wasn't ever used for anything other than calculating a fixed quantizer?

IIRC, it was something like

(1-quality/100)*(max_quant-min_quant)+min_quant

i.e usually

(1-quality/100)*29+2

when using the default quant ranges (2-31), so quality 100% would give you a constant quant 2, 0% a constant quant 31 and non-integer quant values made the encoder alternate between the nearest integer quants, which is exactly why you can use floating point numbers as a quantizer in fixed quantizer mode now.

I doubt the developers will add another way of specifying a fixed quant if it won't do anything but add further confusion... :)

(Also, I'm not quite clear why you're comparing quality mode to two pass encoding since they could hardly be much more different, as two pass mode will give you fixed size or average bitrate, but not constant quality...)

np: Mr. Lif - Heavy Artillery (Emergency Rations)

[temporance]

Originally posted by Koepi
That issue is within the calling applications.

They don't pass through windows messages - thus the controls of that staus windows can't be build up and actualised.

Head to the author's homepages and ask them to add support for windows message passing, and you're done :)

Regards
Koepi Aha. The DivX status display works fine in my app: could there be a workaround within xvid?

[dimzon]

yes, please return back quality mode. I understand that this mode is equal to constant quantizer but quality mode (with percentage) is more comfortable for me :)

[free666]

Hi
a problem has occured in my ripps...since Xvid RC1 a have problem with motion estimatimation in my avis...motions time to time look snatchy...i tried several Xvid settings but none of combinations I´ve tried solved this...æan anybody advise me what to do? thanx in advance

[vlada]

Leak: I know that Quality used to be a constant quantizer (but not always an integer). I was asking to implement a new way of deciding for the right quantizer, which would allow a constant quality for the whole movie. I don'd think, that constant quantizer will give a constant quality. But I don't know if it is possible to do it in one pass. I belive it should be. This is what I was talking about.
(Also, I'm not quite clear why you're comparing quality mode to two pass encoding since they could hardly be much more different, as two pass mode will give you fixed size or average bitrate, but not constant quality...)
I always belived, that two pass should give the best possible quality to all scenes, while targeting a specified average bitrate or size. I would call this a constant quality.
Vlada
P.S. Sorry for my english

[Koepi]

Since you can set fractional quantiser, it is a perfect match for "quality". Set it to i.e. quant 3.5 and see for yourself.

regards
Koepi

[chemmajik]

Yeah its a shame people have to know how to calculate setting to set a 1pass hq setting within XVid, in the beginning it worked just fine when there used to be a HQ 1pass setting for dummies! Until its fixed divx5 will continue to dominate on the alt.binaries forums... people have better things to do then 2 pass...

[kilg0r3]

@ vlada

constant quantzier = constant image quality

IMO a constant quantizer compresses every image by the same amount, i.e., it withdraws the same amount of image information, i.e, it reduces the image quality by the same amount. So, IMHO there is no difference between Divx' quality mode and Xvid's constant quantizer.

What you might want - just my interpretation - is an encoding mode that acts a bit like a second pass without first pass (roughly an ABR mode). There it would be possible to specify a given target bitrate but still take advantage of VBR features plus psycho visual decision algos that selct higher quantizers in where you don't easily notice bad image quality.

But wait isn't that already implemented in the form of CBR together with the three parameters Reaction Delay Factor, Averaging Period, Smoother?

Cheers

[sysKin]

Originally posted by kilg0r3
IMO a constant quantizer compresses every image by the same amount, i.e., it withdraws the same amount of image information, i.e, it reduces the image quality by the same amount. So, IMHO there is no difference between Divx' quality mode and Xvid's constant quantizer.Good conclusion, bad argument :devil:

Constant quantizer does not mean constant quality. Higher quantizer means lower quality and vice versa, but only if you concider one frame. In different frame, same quantizer will give different quality.

*Real* constant quality encoding is a very difficult, multi-pass thing to do and involving *adaptive* quantization (so quantizer is not constant, contrary). I'm not aware of any encoder ever trying that.

Divx, xvd and any mpeg1/2 encoder I've ever heard of use constant quantizer in their "constant quality" mode. It's just an easy thing to do.

:)
Radek

[dimzon]

Originally posted by Koepi
Since you can set fractional quantiser, it is a perfect match for "quality". Set it to i.e. quant 3.5 and see for yourself.
Yes, I understand that. But quality mode is more understandable :)
I think it's very easy to add quality mode in XviD 1, you must ONLY change XviD setting's GUI, just add "quality in % mode" and internally convert %-s into quantizer using well-known formula. I.E. "quality in % mode" will be just "shortcut" for constant quantizer

[kilg0r3]

Good conclusion, bad argument:devil:
Yeah .. erm .. Ouups, I did it again. :o

[Philippe734]

hmm, personnaly i don't want install RC2, cause i am entierely satisfy about RC1, higly quality, no problem while encode, no bugs, satisfy about interface configuration, i have nice control about parameters, all my encoded are in my hopefully (~). actually i think about speed encode, to fast to bad, so be patient. and i patient. i stay with RC1.

[springl]

A wish: a first pass at quantizer N (N = 2,3,4,...) as fast as the "regular" first pass.
Will it remain only a wish?
:)
Thanks for the great Xvid
Sorry for my poor english

[Danzel]

@springl
The whole point of Fast First Pass is that it is faster because it doesnt do full motion estimation and encoding, so sadly your request will never be forfilled. (well, in theory it could but the results would be of less quality than a normal fixed quant encode.)

Danzel.

[sysKin]

Originally posted by Danzel
@springl
The whole point of Fast First Pass is that it is faster because it doesnt do full motion estimation and encoding, so sadly your request will never be forfilled. (well, in theory it could but the results would be of less quality than a normal fixed quant encode.)Huh? No, quite contrary. 1st pass *should* be done at quants 3 or 4 or 5 - and yes, should be as fast as possible.

It's an easy thing to do, already on TODO after 1.0 final is out.

:)
Radek

[Joe Fenton]

I've noticed that the backwards compatibility of RC2 is even lower than RC1. Where RC1 would play most pre 1.0 XviD streams (but not all), RC2 plays even fewer old XviD streams. Something needs to be done in the decoder to handle old XviD streams. I have hundreds of encodes I made with the older XviD that now require me to uninstall the 1.0 and reinstall the older XviD, then back again to play new XviD streams.

Edit: more info - if I switch from overlay mode 1 to VMR-9 mode, they play fine. Maybe something in the colorspace code is whacked. I'm not too sure how the codec colorspace handling meshes with the overlay mode used by player programs. In the meantime, I can at least watch the stuff in the other mode, so it's not so bad anymore. :)

[chemmajik]

I asked for the source code to xvid 2yrs ago, that includes filters when I understood programming, now I bitch & get warnings from doom forums today because of the reason I bitched about live video 1pass capturing! I will prob get banned for 30days for my gripe but I griped 2yrs ago why? bec they wouldnt release the code under gpl, when the code was gpl... so I lost interest... So now xvid is fkd... useless codec except 2pass.... joke not Anyways fine ban me the truth be told peace...

[Danzel]

@syskin
woops, misread the post, hahahaha, yes that will be kool :D

@chemmajik
im not sure what your on about, the source for xvid can easily be fetched from www.xvid.org (I have done so myself).
and anyone reading your post will probally discard you as an idiot.
(Can we please not get anyone more responding to his post so that we keep this thread in control).

Danzel.

[Joe Fenton]

Koepi also puts the source he uses on his site right below the binary as well. Finding source to XviD is EASY!

[m0rtal]

Joe Fenton
Koepi also puts the source he uses on his site right below the binary as well. Finding source to XviD is EASY!
Easiest than finding binaries! :)

[springl]

@sysKin
thanks for your answer :)

springl

[Ranma-kun]

I think Xvid is very near of 1.0 version, and it works almost perfect for me, the only bug I have found is this.
When I push the 'Load Defaults' button, if the Encoding type wasn't 'Single pass', it doesn't reset all the items.

Thanks to all Xvid team for your work, you are the best.
And sorry for my bad english.

PS: Koepi, there is a newer Nic's Fourcc changer in Nic's dev-api3 build (it supports drag and drop). Could you include it in your next build?

[Koepi]

Ranma-Kun:

I'll try to d/l it (or ask Nic to send it to me). Nice idea to update that software as well ;) Also, i could throw out the "usual" avi calculator of Nic's as we have one in XviD itself now. (Unfortunately I didn't find the time to extend it to OGM yet, I could throw away OGMCalc then as well).

Regards
Koepi

[Leak]

Originally posted by Koepi
Also, i could throw out the "usual" avi calculator of Nic's as we have one in XviD itself now. (Unfortunately I didn't find the time to extend it to OGM yet, I could throw away OGMCalc then as well).

Seems good to me. :)

By the way - since the bitrate calc is now more or less integrated into the VfW codec, I'd have an idea to make it even better:

How about adding a mode (I guess a checkbox in the calc window should do) where the bitrate calculator automatically fills in the target size field for every file in the second pass when the encoding starts?

That way, you could feed it several episodes of a series that are roughly the same length but still differ by a few seconds or even minutes (last episodes or episodes with a recap at the beginning can do this to you) and still get files of exactly the same size.

The codec both knows the number of frames (which in the worst case it could get from the first pass) and the frame rate (which in the worst case is set in the bitrate calc dialogue), so it knows the total running time of the video *and* it knows the size of the audio (at least if it's constant bitrate, but if your aiming for an AVI file variable bitrate is a pain anyway), so it could automatically adjust the video size for the second pass so that all files really hit the target size. (Which would be especially nice if you're encoding a series and want to fit all episodes on a single DVD-/+R without having to use the bitrate calc for every single file...)

What do you think?

np: Future Sound Of London - Max (Dead Cities)

[Heini011]

Hi,

@devs:

here were no comments to the (at least for me) most important point: stuttering playback with the standard windows-overlay mixer. [windows xp has vmr7 as default]

what is the problem here ? can't you reproduce the problem or don't you know how to fix this ?

greetings, Heini011.

[sysKin]

Originally posted by Heini011
what is the problem here ? can't you reproduce the problem or don't you know how to fix this ?Can't reproduce. I use overlay mixer all the time and have no problems. Also, no related code changed beteen rc1 and rc2.

The bottom line is that we couldn't make it b0rk with overlay mixer even if we wanted to - xvid just decodes frames and pushes them to output pin, it doesn't care if there's an overlay mixer on VMR. Code is in fact so simplistic that I can't see where it can be broken.

[gotaserena]

It is probably not relevant, nor it is an actual XviD issue, but I feel like informing everybody anyways:

Wine doesn't like the new installer -- at least the newest version in redhat. I can't get RC2 to install so I can encode using vdub in wine.

Of course I *can* install xvid by compiling the source (if I could manage to re-compile mencoder too I would be a happy camper). But it would be nice to have a GUI interface (I'm a windows n00b). Well, this is for everybody's information, in case anybody else is trying to do this. Please don't bash me.

[Koepi]

gotasarena:

this is weird. Gamr today made the setup compiler work on wine and was very fast with it, so I doubt there were any difficulties. And as long as you can compile it you should be able to use it as well.

Maybe you should uninstall your current RPM and compile wine from CVS yourself - or get a precompiled, more recent RPM build. Maybe this helps.

Regards
Koepi

[gotaserena]

Koepi:

That's what I did, downloaded the newest CVS (20040121) from winehq and compiled it in my machine. I'm not close to the machine right now, so I can't give the exact error message to you.

Having read what you wrote, I feel that maybe I did not dig deep enough into the problem to solve it -- as anything in linux asks. Thanks for the help anyways, now I know that it is supposed to work.