Ciao! (XviD-1.0-Beta2-05122003)

[Manao]

nanji : I think you're right ( and I don't know how I came to think one could enter a 2GB+ filesize in the interface, since the size is in KB :rolleyes: )

koepi, P0l1m0rph1c, zettai : effectively, I was totally wrong ( one more time :p ). I compared the two first pass stats, and there were far more differences than I could have thought ( 250 more keyframes, 7000 less p-frames, 7 more b-frames ). So thanks for avoiding me to lose 8 more hours on this encoding :)

[GolovachLena]

If you haven't considered yet a name for Beta 3, i can give you my version: "Privet". It's the same as "Aloha" but in russian :D

[jarthel]

I must include that with my problem, I was able to successfully complete 2-pass encoding with the vob using 17-july-2003 Nic's Xvid binary. So it can't be a corrupted vob.

[Tuning]

Thanks XviD developement team for the speed and quality improvements in XviD 1.0 betas.

One problem, Every time when I open XviD encoded content ( Both XviD dev-api-3 and dev-api-4 ) in virtualdub(1.5.10) the B-frame decoder lag warning is shown. This started showing only after installing beta2. Eventhough there is no problem other than this, can anyone explain why this warning is shown, please... Sorry if this has been explained before.

Thanks.:)

[Manao]

Tuning : The warning has been here since dev-api-3. Due to avi limitations ( I think, but I may be wrong ), when you use b-frames, you have to introduce a lag if you want to keep audio and video synchronized. What happened is that before you installed beta 1.0, the decoding was made by another decoder ( FFDShow, DivX5 ? ) than XviD's one, which is the only one to show that it introduce a black frame at the beginning. But it's normal, look here (http://forum.doom9.org/showthread.php?s=&postid=408450&highlight=DECODER+LAG#post408450)

Jarthel : for a long time ( a month ), almost every encode I made with dev-api-3 was crashing at the last frame, but the output file was however correct. It was due to memory problems ( hardware ), so perhaps you could check that way. It was very subtle ( the ram did pass RAMtests with success ), but as soon as I changed it, there was no more crashes.

[Tuning]

Thanks Manao,
Oh! it was told before, i didn't looked to it in depth. :D
Currently I'm reading the aloha thread and understand situations. After that I might get time to read ciao thread.;)

Thanks for the info.:)
Edit:
So are you saying if I use mkv/ogm this warning will go off ?

[mazzo]

I can't use xvid because there is no place where I can put in how big I want my file to be. The Button for this is grayed out in the encoder. What can be wrong?

[Tuning]

Mazzo ,

Are you using first pass of 2-pass to put size ?

[Manao]

Tuning : ... ( /me is testing ... ) ... No, you'll have the same problem, so perhaps avi wasn't so guilty this time ( but perhaps it is, I don't know how an avi is muxed inside a mkv / ogm ). I think this also implies some restriction of the VFW Api ...

Well, I'll stop trying to remember. A search gave me that (http://forum.doom9.org/showthread.php?s=&threadid=59933&highlight=directshow+lag+decoder) Look for the first post of Tommy Carrot.

[birdy]

The problem I have is that after installing Beta1 AND Beta2 GordianKnot is no longer able to open ANY avi files that I captured using Xvid codec (No matter if the files are compressed with the older codecs or the 2 latest betas)!

I personally capture a lot of Avi's from tv directly to XVID and then sometimes resize them or recompress again. Too bad I can't open them anymore in Gknot :(

The Error I get when trying to open a AVI file is: "File is not a valid dvd2avi project, Avi or avs file!

[sysKin]

If you don't like the "decoder lag" thingy, just use "packed bitstream" option and it's gone.
I would make it default, but ffdshow doesn't seem to decode that well :( I've already posted the problem to ffdshow forum but there is no answer.

Anyway, if the packed-bitsream file is opened in virtualdub, all strange problems are gone.
There is no known bugs about packed bitstream - if you find something, tell us.

Radek

[AgeOfPanic]

Some feedback from my part. I have encoded an entire movie with the beta-2 Koepi build. Compared to the latest Koepi-build of dev3 it was 100 MB smaller (581 instead of 681, both encodes are saturated, because the target filesize was 1000MB). Also the codec is faster, 8-10fps, to 4-6fps in dev3).
My settings were to enable almost anything, GMC (not that slow at all), adaptive quantization, B-frames, Qpel, chroma-optimizer, MPEG, Motion Search 6, VHQ 4, Trellis.
The result looks great. Thanks for all your work.

[Tuning]

Manao, I was testing too, I could conclude the same. Mkv also has the same warning.
Btw I tried some clips in FFDshow (athos latest) and i could see the warning persists.
As, this thread is not related to this topic, lets stop our discussion on the decoder lag.
Thanks for your help. :)
Edit:
Syskin thanks for explanation.
:thanks:

[Koepi]

Tuning: it's no problem at all, it's a warning message. Don't draw wrong conclusions. (It's useful i.e. if you do PSNR comparisons - don't forget to chop the first frame...)

Packed Bitsream can be found by using a simple search (make sure to not just search the last 30 days because the explanations for that are rather old (but still valid)).

Koepi

[Tuning]

Thanks koepi, I will :search: on that.
Thanks.

[Assault]

@ sysKin

I just tried a "packed bitstream" encode and you're right the message about "b-frame decoder lag" doesn't appear in VDub. BUT when I open the file with the xvid directshow filter there appears something like "broken b-frame, mising ref frame". The last word could also be something else because I can't see the end of it. What does this message mean?

Assault

[Alxemi]

Here (http://138.100.51.162/~alxemi/XviD-1.0-Beta2-05122003.exe) is a mirror of this new release.
Thanks to all the developers.

[mf]

Originally posted by LigH
Well - I cannot imagine any relation between those 3 numbers, and any of the edit fields of the XviD codec. Where may I e.g. insert numbers around 30.000?
The gray thing isn't my recommended settings :eek:! That's just my sigcounter. My recommended settings say: "Current recommended XviD settings: Being revised due to XviD1.0b1 release." Meaning there aren't any at the moment.
Originally posted by sysKin
If you don't like the "decoder lag" thingy, just use "packed bitstream" option and it's gone.
I would make it default, but ffdshow doesn't seem to decode that well :( I've already posted the problem to ffdshow forum but there is no answer.

Anyway, if the packed-bitsream file is opened in virtualdub, all strange problems are gone.
There is no known bugs about packed bitstream - if you find something, tell us.

Radek
Actually, in both vdub and ffdshow packed bitstream files stutter like hell. Guess it wasn't made for anything more than 1 consecutive B-frame, or else the frame decoding times get screwed up.

[jarthel]

any reply on my problem? Thanks

I just tried the following (based on previous settings):

- disabling gmc
- no gmc and no closed GOV
- no cartoon mode and no gmc

I'm still getting errors. Any ideas?

jayel

[Koepi]

jarthel:

I can't reproduce that problem here at all. That's why at least i can't answer that question (why does vdubmod crash on the last frame on 2nd pass).

Regards
Koepi

[jarthel]

thanks Koepi for trying. It's quite weird as my P4 box is not giving me the error. Only my AthlonXP box.

[mazzo]

Tuning

Sorry, I wrote this too early - I found out myself what you are suggesting in your answer.

Birdy

I couldn't open them either before I changed to libavcodec in ffdshow.

[philtre]

Some usability issues.

I was looking at the new interface and, frankly, I found it very confusing. I know it's not final or anything, but keep in mind for the final release, that it would be very nice to design the interface, so all the options are accessible on one page (no tabs).
Also, a wizard for newbies based on recommended settings would be nice.

I never figured out why the codec can't do both passes by itself. Why do you need to first use it for first pass, and then again for second. Is there a special reason for that? As far as I know, you usually don't change any settings between passes.

I'd also like to know, Koepi, what has to work before you release the final version? Will it have to be playable on standalones, and such?

thanks,
philtre

[Manao]

jarthel : if you can, try swapping ram between computers.so all the options are accessible on one page (no tabs).You're kidding ? Did you count the number of parameters ?Never figured out why the codec can't do both passes by itselfI would guess "because of the VFW API"Will it have to be playable on standalones, and such?Depends of the standalone, depends of the settings, that is why you have 'profiles' in the new GUI.

[jarthel]

Originally posted by Manao
jarthel : if you can, try swapping ram between computers.

Well, the AthlonXP box has been encoding xvid using july-2003 and earlier versions for months now. So I really doubt it's the RAM.

[philtre]

Originally posted by Manao
Did you count the number of parameters?

Yes, I have, and they don't fit in such a small window. But if you make the window larger and apply some creative interface design, you can fit even more parameters.
Usability is a big issue and it can make or break the product, so if you can streamline the interface, it will be more useful to users and save a lot of their time.

philtre

[HarryM]

Originally posted by sysKin
If you don't like the "decoder lag" thingy, just use "packed bitstream" option and it's gone.
I would make it default, but ffdshow doesn't seem to decode that well :( I've already posted the problem to ffdshow forum but there is no answer.

Anyway, if the packed-bitsream file is opened in virtualdub, all strange problems are gone.
There is no known bugs about packed bitstream - if you find something, tell us.

Radek

I have the simplest solution of "decoder lag message" and etc. thingy. Deactivate this message for user choice.

Add one checkbox into VFW (with default set up ON) -
"Dont display internal in-frame messages"

:cool:

[sysKin]

Originally posted by HarryM
I have the simplest solution of "decoder lag message" and etc. thingy. Deactivate this message for user choice.

Add one checkbox into VFW (with default set up ON) -
"Dont display internal in-frame messages"Unfortunately, API is not supposed to change anymore - and decoder does not have such flag in its API.
Originally posted by philtre
Never figured out why the codec can't do both passes by itself
Codec just encodes, it can't do even a single pass by itself! It's up to external encoding application to give it all the frames, how do you expect a codec to force external application to start over again 'by itself'?
I was looking at the new interface and, frankly, I found it very confusing. I know it's not final or anything, but keep in mind for the final release, that it would be very nice to design the interface, so all the options are accessible on one page (no tabs).
Also, a wizard for newbies based on recommended settings would be nice.You are absolutely welcome to write it for us. There is not a single XviD developer who can and is willing to rewrite the gui (I wish I could, but I can't).

@jarthel: several people reported that. However, I can't reproduce that and I can't see how can this happen :( In other words: we have a problem.
Your screenshot didn't help at all, do you think you could paste/pm/email me what the "advanced" part of Vdub crash dialog told you?
Also, could you take a look at 1st pass stats file and tell me if there's something interesting at the end of it?

As for 'packed bitstream' decoding, it appears I have to find/download our dshow decoder ;)) and see how it works.

Radek

[kastro68]

Can you call the next build "Sayonara"?

[jarthel]

Originally posted by sysKin

@jarthel: several people reported that. However, I can't reproduce that and I can't see how can this happen :( In other words: we have a problem.
Your screenshot didn't help at all, do you think you could paste/pm/email me what the "advanced" part of Vdub crash dialog told you?
Also, could you take a look at 1st pass stats file and tell me if there's something interesting at the end of it?
Radek

check you're email. I've looked at stats and seems normal to me. I'll attach that as well. As for the vdub crash dialog, I save the text to a text file. You should expect that as well.

Thanks syskin.

jayel

ps. what's your email? I can paste the crash info here but it's too long. :)

[bob0r]

Originally posted by mf

Edit: oh and next beta, do name it "Ahoy", I specially came to #xvid to ask that. :D

#xvid on what irc server would that be?



.. keep up the good work, i can not wait untill xvid 1.0 will be the new video standard!

[jarthel]

Originally posted by bob0r
#xvid on what irc server would that be?



.. keep up the good work, i can not wait untill xvid 1.0 will be the new video standard!

look at syskin sig. should be there.

[philtre]

Originally posted by sysKin
You are absolutely welcome to write it for us. There is not a single XviD developer who can and is willing to rewrite the gui (I wish I could, but I can't).[/B]

I'll try to figure out how it can be optimized and then send in some suggestions. But since i'm not really a programmer, I'll ask one of my programmer friends to help me write it, or something.

As for the "two-pass" question, I don't know how the encoding process actually works. I always thought there's some kind of 2-way communication between the codec and the app, hence the silly question.

philtre

[jarthel]

just tried encoding the last 4500+ frames of the vobs. It's around 36000+ in total. Well I was able to complete both passes. Increasing no of frames now to 16000+ frames.

[Tuning]

Originally posted by philtre
As for the "two-pass" question, I don't know how the encoding process actually works. I always thought there's some kind of 2-way communication between the codec and the app...

I think it is the time for you to check Doom9 XviD Guide based on GK and Vdub (http://www.doom9.org/xvid.htm)

[Leak]

By the way - there's one thing I've been thinking about: why does the statfile default to "\video.pass"?

Wouldn't ".\video.pass" (or just "video.pass") be a more sensible location, as it should go right next to the video and thus be writable in any case, preventing people getting an error because the root of their drive happens to be unwriteable?

Oh, and one more thing... is the minimum I-frame distance going to make a comeback, or is removing the option and keeping it at 1 a permanent solution?

Just wondering... :)

np: Monolake - Linear (Momentum)

[P0l1m0rph1c]

@Leak: look at the 2 pass 2nd pass configuration. There is a box that says "I frames closer that ... frames" and below "are reduced by ... %". With these options we dont need "minimum I frames interval" anymore.

[amango]

@Koepi

Won't there be a 1-Pass qualitybased mode anymore in the new builts? All codecs like WMV9 and DIVX are offering this feature, too.

I liked this feature, because it's saving time. Size doesn't matter.

[Blight]

What I find odd is that the "Default Settings" are a far-off cry from being very good as a starting point. Quite a few helpful features are turned off by default. Things which are beneficial and don't cause any stability issues should be on by default as a lot of newbies won't know what they are and may be afraid to enable them.

[P0l1m0rph1c]

Just finished making some tests. The source was Matrix Reloaded trailer, 1000×540, @ 3000 kbps. Used 2 pass for all codecs. I didn't use adaptive quant.

Results:

3ivX 4.5

Overall PSNR: 42.5432
Average SSIM: 0.969915

DivX 5.1.1

Overall PSNR: 43.9748
Average SSIM: 0.975774

On2 Vp6

Overall PSNR: 43.5583
Average SSIM: 0.974484

XviD 1.0 beta 2

Overall PSNR: 44.1614
Average SSIM: 0.976664

Nice works guys! :D

[Bulletproof]

Is reduced resolution supposed to be working? I seem to be getting some weird artifacts when enabling it or it just crashes sometimes when decoding.

BTW polymorphic, what's interesting about that test is that VP6 has the lowest VQM, I think lower VQM value means better quality, when you took a look at both of them which one looked better to you?

[P0l1m0rph1c]

@Bulletproof: Both of them are very good indeed, but as far as i saw, vp6 tended to blur a bit the image, compared to XviD. Maybe that's the explanation to the lower VQM value, who knows?

[Hylas]

Originally posted by amango
Won't there be a 1-Pass qualitybased mode anymore in the new builts?
It is still there. Click on a zone and choose a quantizer (you can use non-integer values too, which is exactly what the quality rating was doing). I think, it is a lot more transparent this way and not as unpredictable as the old "constant quality" setting that relied on max and min quantizer settings.

[phrentec]

#xvid on freenode(i.e. leguin.freenode.net)

[haibane]

There is something strange occured when i am encoding with the beta2 from koepi's site.
During 2nd pass, the b frame quantizers seems to not follow what i used in the b-frame setting(3/1.00/1.00), the following is part of the debugview capture:
[4044] [ 691] type=P Q: 5 length: 4983
[4044] [ 692] type=B Q: 5 length: 1933
[4044] [ 693] type=B Q: 4 length: 4114
[4044] [ 694] type=P Q: 5 length: 4866
[4044] [ 695] type=B Q: 5 length: 1909
[4044] [ 696] type=B Q: 5 length: 2077
[4044] [ 697] type=P Q: 5 length: 5002
[4044] [ 698] type=B Q: 4 length: 3810
[4044] [ 699] type=B Q: 5 length: 2045
[4044] [ 700] type=P Q: 5 length: 4925
[4044] [ 701] type=B Q: 5 length: 1993
[4044] [ 702] type=B Q: 5 length: 2034
[4044] [ 703] type=P Q: 5 length: 4900
[4044] [ 704] type=B Q: 4 length: 3768
[4044] [ 705] type=B Q: 5 length: 2026
[4044] [ 706] type=P Q: 5 length: 4942
notice that the b-frame has the same or higher quantizer than the p frames. The result has much worse PSNR than my previous encode, which is a intro of an animation. Is this getting better psnr on other types of material?


edit:
i'm sorry for bring up a false repoprt......
after carefull examination.........
i mistakenly enter that wrong quantizer setting......
instead use 2/5 for p frame quantizer, i somehow entered 5/5.......
that is causing the problem........

[Koepi]

haibane:
nope, the formula changed quite a bit. To get the results you'd like to see try an offset of 1.5 (if that doesn't work out try ratio 1.5).

Regards
Koepi

[Hoschi]

Unfortunately we don't have something useful as ffdshow -automatic bitstream & workaround detection- in our xvid decoder (yet). There are plans to add something like that, but they don't seem to be high on the "urgent to do" list.


OK, thanks for the answer. ffdshow does work. Anyway, that means further working with the file does not work, as VD/VDM only use ffdshow for preview (with ddraw enabled), but not for transcode etc. Thats the second time for me I can't decode files done with earlier versions without tricks. So xvid seems not to be archive ready :(

Anyway Ciao still produces files smaller than targeted. It is slightly faster then Aloha. Is it possible the size is caused by adding a zone with lower weight (credits @ 0,30 ) ?

[Manao]

Originally posted by Hoschi
as VD/VDM only use ffdshow for preview (with ddraw enabled) What ??? Since when ? ( that's wrong, DDraw doesn't mean DirectShow ) Anyway, that means further working with the file does not workNo, you can discard the first frame easily, by selecting ranges with VD/VDMAnyway Ciao still produces files smaller than targetedPlease provide data, since nobody else reported that behaviorSo xvid seems not to be archive readyWhy ? Because of the frame diplayed at the beginning of a video ?

@Koepi : When did the formula change ( is this formula (http://forum.doom9.org/showthread.php?s=&threadid=59649&highlight=bframes+formula) still correct ? )

[homersapien]

These new xvid codecs really don't like me...

2-Pass encoding
All options default except VHQ=6 and B-Frames=2
Latest VDubMod
Latest AviSynth 2.5

Problem #1: On large files 1.5+ gigs, video gets largely out of synch after ~the 1 hour mark. Playback is not a hardware problem on my part (tried 3 different machines.) Anyone else do a ~2gig file with b-frames and have this problem?

Problem #2: I sometimes can't run avs files. Even with: avisource(c:...) and all codec settings at default. Both jobs run like normal, except each pass lasts for less than a second.

[cipher]

@Manao
The formula of bframe quantizer given by your link is NOT right.
B frame qaunt. equation has never used that equation if I remember correctly :)

I'm wondering why mf and sysKin didn't correct that formula in the thread, maybe they just didn't pay too much attention on the formula? :)

bframe, by its name - bidirectional frame, should reference previous AND future frames, how could its formula use only the previous p frame only ? :)

and bframe has been using this equation by now:

bvop= ((previous vop Q. + future vop Q.)/2)*ratio + offset

bye