Selam! (XviD-1.0-Beta3-26122003)

[Koepi]

Merry Christmas everyone (...who celebrates it).

We have an christmas gift for you!

XviD-1.0-Beta3-26122003 (Selam):
- Large filesizes now work correctly in 2pass.
- Fixed possible out-of-bound-reads in 2pass.
- Bframe decoding fix - sometimes bframes were referencing wrong future macroblocks.
- Checking "use keyframe" in a zone now only makes the zone starting frame a keyframe.
- Internal pixel aspect ratio fixes - added display aspect ratio (for anamorphic encoding).
Currently you'll need mplayer, vlcplayer (or 3ivx/Nero DShow filters) for correct playback.
- Colour space fixes.
- Directshow updates: brightness slider, postprocessing, output colour space choosable.
- Some more sse2 optimization for P4s.
- 2pass ratecontrol overhauled, including fast first pass.
- User selectable turbo mode.

Known bugs (do not report them):
- Weight zones don't work properly - if you need zones, use quant zones instead.
...

Best regards
Koepi

[mikeson]

Thanks a lot, Koepi and Merry Christmas! ;)

[raz0r]

thanks koepi!
but what is "Turbo ;-)" and how does it work?

[mikeson]

@raz0r:
but what is "Turbo ;-)" and how does it work?
It is a feature that turns off some ME flags thus encoding is faster (roughly said).

[raz0r]

will the quality go down when using turbo mode?

[mikeson]

Test it and share your results... ;)

Honestly, I'm not sure about this.

[Koepi]

Turbo should give a very marginal (unnoticable) drop in quality (it enables fast flags in the xvid core) for a very noticable speed boost.

Regards
Koepi

[iago]

Selam, dostum!

What a fantastic name for the new beta! This one should be especially for me! I might even no longer upgrade and use this one for good! ;)

Thanks a lot,
iago

[Raptus]

The new decoder has performance problems when deblocking is activated. FPS drops on a XP2400+ :rolleyes: tested with a 704x304 clip.

the brightness slider has no effect in any of the possible colorspaces.

[Leak]

Originally posted by Raptus
The new decoder has performance problems when deblocking is activated. FPS drops on a XP2400+ :rolleyes: tested with a 704x304 clip.

the brightness slider has no effect in any of the possible colorspaces.

Whoa - I was just going to write almost the same, only that this happens here on a P4 2,4GHz... so it can't be CPU optimization-specific. :(

The clip in this case was 720x400.

Dering alone does work without slowing the video down, as does "Film Effect" (even though I don't know what it's supposed to do... :confused: :))

But then again, deblocking did work perfectly with Koepi's prerelease beta3 decoder, so a bug must have crept in there... :)

np: St. Germain - What's New? (Boulevard)

[Koepi]

Hm. The decoder is currently absolutely un-optimised, it doesn't compiler with any ICL anymore. Maybe i should tweak the settings for M$ compilers ... ;)

Regards
Koepi

[sysKin]

Oh, again?
I had problems with deblocker the first time I compiled it (on ICL8.. and yes, it worked *then*).

When I used deblocker the second time it was perfect - slower than ffdshow's of course, but imho it was the best deblocker I've ever seen. It was just so beautiful ^_^.

I'll try figuring out what makes it go fast/slow/fast etc all the time.

Radek

PS. Deringer is fast because it's not implemented ;)

[Leak]

Originally posted by Koepi
Hm. The decoder is currently absolutely un-optimised, it doesn't compiler with any ICL anymore. Maybe i should tweak the settings for M$ compilers ... ;)

Well, I don't really care much if encoding goes below 24 fps, but it *does* get a bit distracting when watching the result and having the video play half as fast as the sound... *wink* *wink* *nudge* *nudge* :p

And I really have to agree with Syskin - the deblocking of the prerelease beta3 decoder was superb.

(Also, wouldn't *not* using the Intel compiler slow down both Intel *and* AMD CPUs, given that the optimizer of the VS compiler is hardly worth anything?)

And to Syskin - I've only seen it go slow, without speeding up anywhere... :p

np: Jah Wobble & Deep Space - They Were Planning Murder (Largely Live At Hartlepool And Manchester)

[gino25]

I have problems to download this beta3.

I use mozilla and explorer and no download manager, but i have always a message of error

[bond]

i saw packed bitstream is now default! why that?

[raz0r]

made to quick tests, one with and one without Turbo. It wasnt any faster at all and quality was also same, so i think its (now) useless.
oh and it now plays on ESS players, thats very fine :)

[sysKin]

Originally posted by raz0r
made to quick tests, one with and one without Turbo. It wasnt any faster at all and quality was also same, so i think its (now) useless. All "turbo" optins are related to b-frames and qpel. It won't make Simple Profile faster.
It won't make any differnce in first pass either.

Radek

[raz0r]

ah ok then its clear, cuz i didnt use bframes/qpel/gmc

[Leak]

Originally posted by bond
i saw packed bitstream is now default! why that?

<conspiracy theory>
Probably to make people use and test the new DirectShow decoder instead of ffdshow which can't play packed bitstream correctly... ;)
</conspiracy theory>

Still, it's the first thing I turn off after a "Load defaults...".

np: Jah Wobble & Deep Space - Forgetting Myself (Largely Live In Hartlepool And Manchester)

[Koepi]

Ffdshow will be fixed soon I think. It's no xvid bug that ffdshow doesn't playback packed bitstream correctly. Head over to the ffdshow thread in new a/v formats(codecs) and file a request there :)

Regards
Koepi

[bond]

damn i dont like packed bitstream too ;)

[Leak]

Originally posted by Koepi
Ffdshow will be fixed soon I think. It's no xvid bug that ffdshow doesn't playback packed bitstream correctly. Head over to the ffdshow thread in new a/v formats(codecs) and file a request there :)

I'm not really sure that'll help - according to the statistics from SourceForge, it's been dead since sometime mid-October, according to the CVS mailing list:

http://sourceforge.net/mailarchive/forum.php?thread_id=3308307&forum_id=22740
(that's the last CVS checkin)

:(

np: Rechenzentrum - Slate (Director's Cut)

[jarthel]

I must say I'm terribly suprise on the encoding speed. It previously takes 1.5 to 2 hours. Now it's less than an hour. In fact it's about 40 minutes.

Thank you Xvid team.

jayel

ps. not using turbo. It must be the SSE2 optimizations.

[m99]

Why is XviD-Dec-1.0-Beta3.exe bigger than XviD-Dec-1.0-preBeta3.exe?

[mikeson]

@jarthel:
No, it is because FAST1PASS.

@m99:
Why shouldn't it be?

[Assault]

@ m99

What mikeson tried to say is that XviD-Dec-1.0-preBeta3.exe is not the xvid codec but only the directshow decoder. ;)

EDIT: Forget what I wrote....I just realized that you wrote XviD-Dec-1.0-Beta3.exe and not XviD-1.0-Beta3-26122003.exe. So both files are only the decoder.

[Koepi]

I previously UPXed the files - now I don't do that anymore (minimal speed impact). OTOH, as I wrote earlier, the dshow palyback filter isn't compile'able with ICL anymore and I didn't tune the M$ compiler flags for smaller binary/faster code.

Regards
Koepi

[symonjfox]

Wow. I just tried to encode a DVB capture using Xvid Beta 3 and Anamophic resolutions.

Here's my results:
Source MPEG2 352*575 progressive.

A simple AVS script:
Loadplugin(".../mpeg2dec3.dll")
Mpeg2source("dvb.mpv")

Reencoded using Bframes, Qpel, ... , 3:4 AR.

Results:

Perfectly muxed into MP4 container and Perfectly resized on playback!! I'm very very happy.

I'll remove one of my requests in my signature :) :D :D

[Koepi]

Silent binary update (both full installer and standalone decoder):
- recompiled dshow decoder with small optimizations - now it's smaller again, and faster of course.

Regards
Koepi

[PowerMacG4]

With low bitrates in 2-pass mode (200kbps target) I am getting some pretty obvious differences when there is a keyframe. I believe keyframes should be favored a little more so that they aren't such a harsh blocky transition all the time (for low bitrates). Is there a way to improve this sample?

http://s91752438.onlinehome.us/public/uglykeyframes.png

[Koepi]

There isn't much you can do except for 2 things which come to my mind:

- use iframe boost (10 or 20% for starters) and stay with bframes or
- use a matrix which produces nice iframes even at low bitrates (i.e. h263? hvs good picture?)

Regards
Koepi

[bond]

some guys on the german dvdboard.de (http://www.dvdboard.de/forum/showthread.php?s=&threadid=64112) reported problems with the packed bitstream option on the new mediatek chipset (which is said to be the best atm, can decode qpel, gmc), lets hope that this get fixed...

Originally posted by symonjfox
Reencoded using Bframes, Qpel, ... , 3:4 AR.

Perfectly muxed into MP4 container and Perfectly resized on playback!! I'm very very happy.note that you need to use the 3ivx mp4 muxer when muxing "packet bitstream" files into mp4 (pb is used in divx5 and now also is default in xvid), as the 3ivx muxer is the only one who can unpack them again

otherwise your mp4 files wouldnt be spec compliant (it should also work to untick packet bitstream in xvid to get "real" mpeg-4 streams)

[Zhnujm]

Originally posted by bond
some guys on the german dvdboard.de (http://www.dvdboard.de/forum/showthread.php?s=&threadid=64112) reported problems with the packed bitstream option on the new mediatek chipset (which is said to be the best atm, can decode qpel, gmc), lets hope that this get fixed...


Then it was a feature request by Sigma/ESS :D
The problems with packed bitstream and MediaTek are also there with older xvid builds, its not that it has changed in the latest beta.

[Isibaar]

Originally posted by sysKin
Oh, again?
I had problems with deblocker the first time I compiled it (on ICL8.. and yes, it worked *then*).


Hm, really? That's strange because I also have ICL8 installed and never experienced any problems when trying to compile the postprocessing sources. Also, for me there wasn't a huge speed difference between using the Intel or the Microsoft compiler for the deblocking code. Actually the deblock c-code is already pretty much optimized so it shouldn't rely that much on the quality of the compiler...

Originally posted by sysKin

When I used deblocker the second time it was perfect - slower than ffdshow's of course, but imho it was the best deblocker I've ever seen. It was just so beautiful ^_^.

I'll try figuring out what makes it go fast/slow/fast etc all the time.



The deblocker was mainly designed for quality, speed came second. So it's 'normal' if you experience a drop in decoding speed. From my experience, XviD with deblock enabled is decoded only at a little bit more than half the speed than without deblocking. However this should still be more than enough to conveniently watch a XviD clip on a modern CPU. So I have a cpu usage of about 12-15% when watching a 640xXXX clip on my P4 2.4 GHz. That's slow but now I at least know that it was a good investment to buy a faster CPU ;-)

BTW: I have an additional speed-up for the deblocker almost ready, however don't expect any wonders. XviD's deblock will _never_ become as fast as the ffdshow one...

Originally posted by sysKin
PS. Deringer is fast because it's not implemented ;) [/B]
;-) yeah, we have a slow deblocker but the fastest deringer in the whole world ;-))

[symonjfox]

Originally posted by bond
note that you need to use the 3ivx mp4 muxer when muxing "packet bitstream" files into mp4 (pb is used in divx5 and now also is default in xvid), as the 3ivx muxer is the only one who can unpack them again

otherwise your mp4 files wouldnt be spec compliant (it should also work to untick packet bitstream in xvid to get "real" mpeg-4 streams)
I forgot to say that I disabled "Packed Bitstream". Is it wrong?

AFAIK, the only issue that appends if I doesn't enable it is only the "B Frame Lag" at the beginning, but it's not a problem for me.
In second I have no standalone player, so I've no need to enable them.
PS: I mux it using MP4ip, I have never used 3ivX muxer because I'm not able to use graphedit ... :(

[cipher]

Because of avi's slight incompatibility with B-frame, I would say it's theoretically better in avi to enable the "Packed Bitstream". And I would even suggest alway enable this option :). The format MP4 wouldn't have such problem, so it's not necessary to check packed bitstream if u decide to contain the video stream in .mp4.

[Leak]

Originally posted by Koepi
Silent binary update (both full installer and standalone decoder):
- recompiled dshow decoder with small optimizations - now it's smaller again, and faster of course.


And quite a bit faster, let me add... :)

Playing back the clip I mentioned before now takes around 20% CPU without deblocking and takes up about another 10% for each deblocking option (i.e. 30% and 40% in total) - which means it's perfectly usable. :)

np: Kid606 - Total Recovery Is Possible (Kill Sound Before Sound Kills You)

[amango]

Originally posted by Zhnujm
Then it was a feature request by Sigma/ESS :D
The problems with packed bitstream and MediaTek are also there with older xvid builds, its not that it has changed in the latest beta.

The MediaTek based DIVX-Players just do the same like the old xvid decoders if you use packed bitstream: Playback is stuttering. Without packed bitstream the MediaTek-Players plays like FFDShow and the old decoders: Smooth. ;)

[Soulhunter]

Before doing unless stuff again... ;)

Has someone interest for some tests with XviD's cartoon-mode on some anime stuff ???

I thought I could use one chapter of Animatrix...

Is "World Record" good for testing purpose ???

Suggestions for the setup and the filter chain ???

Bye

[Leak]

I've noticed one thing about some post-beta2 versions (at least one build from gamr and this beta) - the second pass has problems hitting the size I set:

I've encoded the four episodes on the first DVD of Last Exile and wanted them to come out at 170 MB (so all 26 of them will fit on a DVD+R), and this worked really good with beta 2, where all files differed only ~32kB in size (alas, I didn't keep those files as the IVTC/deinterlacing was a bit lacking).

Now using beta3, file sizes in bytes were as follows:


Ep. First pass Second pass
1 213671936 178210816
2 180004864 166291456
3 244750336 178288640
4 187039744 171317248


which seems rather, uh, off target to me.

Settings used were Adaptive Quantization, H.263, 2 BVOPS (Ratio 1.5, Offset 0.75), Closed GOV, no level restriction, default 2nd pass settings, 1 zone with weight 1, Chroma Optimizer and BVOP sensitivity -15, MSP 6, VHQ4, Chroma Motion, Cartoon Mode, Trellis, no restricted quantizers. Target size was 150427 and all episodes are between 24:21 and 24:28 minutes long, and the audio was 128 kBit/sec CBR MP3, which should have roughly given 170MB all in all.

Has anybody else encountered this? *wonders*

np: Monolake - White II (Momentum)

[Chainmax]

What about making an avisynth filter out of the deblocker? Wouldn't that solve speed issues since the decoder wouldn't have to carry that extra burden?

[kadajawi]

uh, I don't see the reason in doing that. The CPU power used would be the same at the end, and I prefer watching the video just as it is and not through Avisynth.

[Chainmax]

What I mean is that such filter could be used in the encoding stage.

[Leak]

Originally posted by Chainmax
What I mean is that such filter could be used in the encoding stage.

Maybe if you want to reencode something, but you'd still need it in the decoder used for playback since it's meant to correct flaws in the encoded material which encoding itself generates.

Actually, using the DirectShow decoder in conjunction with DirectShowSource in AviSynth will already do what you want. I'd say using the postprocessor on a source that's not MPEG-4 is not very useful as I'm sure the postprocessor uses information from the stream that just isn't there in a simple sequence of decoded images (motion vectors, quantizer information and the like).

np: Ulrich Schnauss - On My Own (A Strangely Isolated Place)

[gldblade]

Target size was 150427 and all episodes are between 24:21 and 24:28 minutes long, and the audio was 128 kBit/sec CBR MP3, which should have roughly given 170MB all in all. I don't think you're taking into account the fact that the amount of space taken up by audio will also vary. Maybe this is why you're seeing variation in your final filesizes. How closely does the video portion of the encoding meet your target?

[knight_inferno]

Bug??

Installed XviD-1.0-Beta3-26122003, now everything plays upside down! :confused:

Went back to XviD-1.0-Beta2 and it's all fine again :p

Anyone else have anything like this?

I don't use Ffdshow ever, Only have the Gordian Knot Codec pack installed (untick ffdshow), and Divx 5.1.1

Besides that, I am very happy with all encoding results of the XviD 1.0 beta's, and want to say good work to the dev's :)

[gldblade]

Installed XviD-1.0-Beta3-26122003, now everything plays upside down! Haha, I have the same problem. You can flip it back to its original orientation in XviD's decoder properties.

But I'm wondering why it's suddenly happened. I've never had this problem before, even way back when with DivX 3.11.

[GolovachLena]

SSE2 rocks! Got more the two times speed boost comparing to beta2 with same settings.

[knight_inferno]

haha, odd :p

Well it's good that it is easily fixed :D, never even thought of looking in the decoder options to change it, since I hadn't needed to do so before :p

Ah well, "Tick" up the right way now :D kewl stuff

[Koepi]

leak: encode the audio later and mux it then, you'll see that xvid hits the size - and as far as i can tell, the encodes are staurated.

Always encode sound and video in separate steps. Then you can see what's to blame in such situations - and if you have the size of the soundtrack, you can calculate the video size you need to fill up exactly the file size you want.

. o O ( the very basics of ripping... )

@all:

The picture can be flipped because the output colour space changed. If you try different colour spaces you'll see that some are flipped, some others aren't. This is either a vga software or hardware error - try different vga drivers then or use the "flip image" option in the directshow filter.

Koepi

[happy_harry]

The flipped picture is caused by directvobsub, which is converting colorspaces, and this is bad, i guess... :D
You can test the colorspace change on a pure red picture (gets the stairs effect, i think) :(
You can play with directvobsub's colorspace in the options dialog of it.
Disable vobsub and you will get the proper picture.

[drebel]

Harry-harry you're absolutely right.
It's Vodsub that's causing the colorspace conversion to IYUV (or something IIRC).The solution is simple : either try the "flip picture" option from internal vobsub configuration (that way when vobsub isn't triggered image wont be upside-down) or select "force YV12" from xvid decoder and re-load the movie to secure the effect (once is enouph)

Of course there 's a speed and quality penalty with colorspace conversions

This happens also with VMR9 , so I think it's not an overlay issue (and perhaps not hardware related)

regards,
george

PS: maybe I missed something , but in Vdubmod compression tab there are two versions of the xvid encoder, one with fourcc code "xvid" and one with "YV12".I chose the second and it encodes fine.Any ideas?

[Koepi]

Yes, use the "xvid" labelled one. YV12 is just there for the colour space conversion routines - without that, vdub / vdubmod wouldn't be able to process an YV12 encoding chain.

regards
Koepi

[Leak]

Originally posted by Koepi
leak: encode the audio later and mux it then, you'll see that xvid hits the size - and as far as i can tell, the encodes are staurated.

Always encode sound and video in separate steps. Then you can see what's to blame in such situations - and if you have the size of the soundtrack, you can calculate the video size you need to fill up exactly the file size you want.

. o O ( the very basics of ripping... )


Not to mock you, but that's exactly what I do - all the audio tracks are constant bitrate MP3 files of almost the exact same size, namely between 24:21 min (22.838kB) and 24:28 min (22.945kB), which I created with HeadAC3he before encoding the video and which are muxed while encoding; and the size difference between the smallest and the biggest one is 107kB, but not several megabytes!

And as for saturation - the first pass files all *were* bigger than the 170MB I was aiming for (which included the audio data, as you can see by the value I set for second pass target size: 150.427kB), so the second pass should be able to hit the right size almost perfectly. And up to beta2 it did, as encoding 26 episodes of Noir showed, where all files were at most differing by a few 100kB in size, whereas here the difference between the second pass size for episode 1 and 2 were 12 *megabytes*, even though the MP3 files for both episodes have a size difference of 1kB.

And in case you're wondering, I'm not doing all of this by hand, but I'm using a collection of zsh scripts that do the most part of the work; it configures XviD by copying a VirtualDub.video.SetCompData(...) statement from 2 template files (for first and second pass) into the VirtualDub job files it generates and I've always redone these templates for each new version of the codec I've installed. I'm also muxing the audio into both the first and second pass and I'm keeping the first pass files as I don't bother doing the second pass if the first one comes out undersized and just use that, but that definitely didn't occur here.

Is that enough to convince you that I can't think of anything I've done wrong here? I do hope that using the B-Frame settings I've used until now (2, 1.5, 0.75, -15) don't suddenly make the bitrate scaling go whack...

np: Ulrich Schnauss - Blumenthal (A Strangely Isolated Place)

[Koepi]

Ok, I did all the math to correct your values to be like they have to be: always subtract 22.838kb ^= 23.386.112 bytes.

makes up for:

151.196 kb
139.556 kb
151.272 kb
144.464 kb

Target size was: 150.427kb.

So here several things work wrong - usual behaviour is that xvid beta3 produces slightly undersized files (~200kb smaller than desired for a "usual" 1cd 700mb rip).


As long as you use some scripts to do the encoding for you, you can't blame xvid for being errorenous. Do those 4 eps manually by hand (calculating the desired size values yourself, don't play around with vdub exports).

If you still reproduce these values, I'd take a closer look. But for now it seems to me that you have to fix your scripts (or do things manually to proove xvid is wrong).

Sorry,
Regards
Koepi

[Leak]

Originally posted by gldblade
I don't think you're taking into account the fact that the amount of space taken up by audio will also vary. Maybe this is why you're seeing variation in your final filesizes. How closely does the video portion of the encoding meet your target?

As you can read in my other post above, the video portion of episode 2 misses the target (150.427kB) by a long way...

The size of the audio is 22.839kB, the first pass is 175.786kB in size, so it's video portion is 175.786kB - 22.839kB = 152.946kB, which is almost there, but still a tad too big (i.e. the codec can't be saturated during the second pass).

But the second pass came out as 162.394kB, which means that the video part of the second pass is 139.555kB, and that's not exactly the target size.

Of course, I'm neglecting the overhead caused by the AVI container, but since that should be more or less the same over all 4 episodes it shouldn't cause a difference of several megabytes when comparing final file sizes.

np: Triosk Meets Jan Jelinek - Mis-Leader (1+3+1)

[Koepi]

I thought you just mux audio during 2nd pass.

Damn. your "bugreport" is too weird for my simple brain. please redo things properly (read: setup avs, vdubmod, xvid manually) and see if you can confirm the false results.

I'm more and more confident it's your scripts.

Koepi

[Leak]

Originally posted by Koepi
Damn. your "bugreport" is too weird for my simple brain. please redo things properly (read: setup avs, vdubmod, xvid manually) and see if you can confirm the false results.


Well, if you absolutely don't trust my scripts, here's what they produce for episode 2:

LastExile_02.avs:

source=MPEG2Source("e:\DVD\Last_Exile_1\VIDEO_TS\Video.d2v",cpu=0,iPP=true,idct=6)

Function KernelBob(clip a, int topFieldFirst, int kernelDeintThreshold)
{
a=((topFieldFirst == 1) ? a.AssumeTFF() : a.AssumeBFF())

b=separatefields(a).trim(1,0).weave()

a=a.kerneldeint(order=TopFieldFirst, sharp=false, threshold=KernelDeintThreshold)
b=b.kerneldeint(order=(1-TopFieldFirst), sharp=false, threshold=KernelDeintThreshold)

return interleave(a,b)
}

Function BlendBob(clip c, bool show)
{
a=c.AssumeFieldBased().Trim(1,0)
b=c.AssumeFieldBased()

global a1=a.SelectOdd()
global a2=a.SelectEven()

global b1=b.SelectOdd()
global b2=b.SelectEven()

global aw=a.Weave.BilinearResize(a.Width,a.Height)
global bw=b.Weave.BilinearResize(b.Width,b.Height)

global aw=(show == false ? aw : aw.Subtitle("a"))
global bw=(show == false ? bw : bw.Subtitle("b"))

result=ScriptClip(c.AssumeFPS(c.Framerate/2),"
ad=Subtract(a1,a2)
bd=Subtract(b1,b2)

global diff1=YPlaneMinMaxDifference(ad, 2)-YPlaneMinMaxDifference(bd, 2)
global diff2=YPlaneMinMaxDifference(ad, 5)-YPlaneMinMaxDifference(bd, 5)
global diff3=YPlaneMinMaxDifference(ad,10)-YPlaneMinMaxDifference(bd,10)
global diff4=YPlaneMinMaxDifference(ad,20)-YPlaneMinMaxDifference(bd,20)
global diff5=YPlaneMinMaxDifference(ad,50)-YPlaneMinMaxDifference(bd,50)

pos=0
neg=0

pos=pos+(diff1 >= 0 ? 1 : 0)
pos=pos+(diff2 >= 0 ? 1 : 0)
pos=pos+(diff3 >= 0 ? 1 : 0)
pos=pos+(diff4 >= 0 ? 1 : 0)
pos=pos+(diff5 >= 0 ? 1 : 0)

neg=neg+(diff1 < 0 ? 1 : 0)
neg=neg+(diff2 < 0 ? 1 : 0)
neg=neg+(diff3 < 0 ? 1 : 0)
neg=neg+(diff4 < 0 ? 1 : 0)
neg=neg+(diff5 < 0 ? 1 : 0)

(pos < neg ? aw : bw)

(" + String(show) + " == false ? last : \
Subtitle( chr(32) + chr(32) + chr(32) + chr(32) + String(diff1) + chr(32) + String(diff2) + chr(32) + String(diff3) + chr(32) + String(diff4) + chr(32) + String(diff5)))
")

return result
}


a=source

a=a.KernelBob(1,10)
a=a.Decimate(cycle=5)
a=BlendBob(a,false)


b=source

b=b.Telecide(order=1)
b=b.Decimate(cycle=5)
b=b.TomsMoComp(1,5,1)


a.BlankClip(length=35044) + \
a.Trim(35044,67197-1) + \
b.Trim(67197,69370-1) + \
a.Trim(69370,0)


Crop(4,4,712,474,align=true)

UnDot()
MipSmooth(preset="AnimeHQ",temporal=0,temporal_chroma=0)


a=last
b=last

a=a.LanczosResize(720,400)
b=b.BicubicResize(360,200,0.5,0.25).BicubicResize(720,400,0.5,0.25)

a.BlankClip(length=35044) + \
a.Trim(35044,36224-1) + \
b.Trim(36224,38631-1) + \
a.Trim(38631,67197-1) + \
b.Trim(67197,69370-1) + \
a.Trim(69370,0)


LastExile_02_Pass1.vcf:

VirtualDub.Open("e:/DVD/Last_Exile_1/LastExile_02/Data/LastExile_02.avs",0,0);
VirtualDub.RemoveInputStreams();
VirtualDub.stream[0].SetSource("e:/DVD/Last_Exile_1/VIDEO_TS/Audio_English.mp3",0x0202,0);
VirtualDub.stream[0].SetMode(0);
VirtualDub.stream[0].SetInterleave(1,500,1,0,0);
VirtualDub.stream[0].SetClipMode(1,1);
VirtualDub.stream[0].SetConversion(0,0,0,0,0);
VirtualDub.stream[0].SetVolume();
VirtualDub.stream[0].SetCompression();
VirtualDub.stream[0].EnableFilterGraph(0);
VirtualDub.stream[0].filters.Clear();
VirtualDub.video.SetDepth(24,24);
VirtualDub.video.SetMode(1);
VirtualDub.video.SetFrameRate(0,1);
VirtualDub.video.SetIVTC(0,0,-1,0);
VirtualDub.video.SetRange(0,0);
VirtualDub.video.SetCompression(0x64697678,0,10000,0);
VirtualDub.video.SetCompData(2960,"AQAAAJCyCACbSwIALlx2aWRlby5zdGF0cwBuZSVpX2ZyYW1lAAAAAHpvbmUlaV9tb2RlAHpvbmUlaV93ZWlnaHQAAAB6b25lJWlfcXVhbnQAAAAAem9uZSVpX3R5cGUAem9uZSVpX2dyZXlzY2FsZQAAAAB6b25lJWlfY2hyb21hX29wdAAAAHpvbmUlaV9idm9wX3RocmVzaG9sZAAAAFNvZnR3YXJlXEdOVVxYdmlEAAAAcW1hdHJpeF9pbnRyYQAAAHFtYXRyaXhfaW50ZXIAAABjb25maWcAAFNvZnR3YXJlXEdOVQAAAABYdmlEAAAAACUuMmYAAAAAJXgAADB4JXgAAAAAXG1hdHJpeAAAAAAAKHVucmVzdHJpY3RlZCkAAG1vZGUAAAAAYml0cmF0ZQBkZXNpcmVkX3NpemUAAAAAdXNlXzJwYXNzX2JpdHJhdGUAAABxdWFudF90eXBlAABsdW1fbWFza2luZwBpbnRlcmxhY2luZwBxcGVsAAAAAGdtYwByZWR1Y2VkX3Jlc29sdXRpb24AAHVzZV9idm9wAAAAAG1heF9iZnJhbWVzAGJxdWFudF9yYXRpbwAAAABicXVhbnRfb2Zmc2V0AAAAcGFja2VkAABjbG9zZWRfZ292AABhcl9tb2RlAGFzcGVjdF9yYXRpbwAAAABwYXJfeAAAAHBhcl95AAAAYXJfeAAAAAAOAAAAAAAAAAgREhMVFxkbERITFRcZGxwUFRYXGBocHhUWFxgaHB4gFhcYGhweICMXGBocHiAjJhkaHB4gIyYpGxweICMmKS0QERITFBUWFxESExQVFhcYEhMUFRYXGBkTFBUWFxgaGxQVFhcZGhscFRYXGBobHB4WFxgaGxweHxcYGRscHh8hAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAJYAAABLAAAAAAAAAAEAAAAAAAAABAAAAAMAAAABAAAAAQAAAAAAAAABAAAAAAAAAAAAAAAAAAAAZAAAAPQBAAAAAAAAAQAAAPH///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAGQAAABkAAAAAAAAAAAAAAABAAAAFAAAAAAAAAAAAAAABQAAAAUAAAAFAAAABgAAAAQAAAABAAAAAQAAAAAAAAAsAQAAAAAAAAIAAAAfAAAAAgAAAB8AAAACAAAAHwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA=");
VirtualDub.video.filters.Clear();
VirtualDub.subset.Clear();
VirtualDub.subset.AddRange(35044,35046);
VirtualDub.SaveAVI("e:/DVD/Last_Exile_1/LastExile_02/Data/LastExile_02_Pass1.avi");
VirtualDub.Close();


LastExile_02_Pass2.vcf:

VirtualDub.Open("e:/DVD/Last_Exile_1/LastExile_02/Data/LastExile_02.avs",0,0);
VirtualDub.RemoveInputStreams();
VirtualDub.stream[0].SetSource("e:/DVD/Last_Exile_1/VIDEO_TS/Audio_English.mp3",0x0202,0);
VirtualDub.stream[0].SetMode(0);
VirtualDub.stream[0].SetInterleave(1,500,1,0,0);
VirtualDub.stream[0].SetClipMode(1,1);
VirtualDub.stream[0].SetConversion(0,0,0,0,0);
VirtualDub.stream[0].SetVolume();
VirtualDub.stream[0].SetCompression();
VirtualDub.stream[0].EnableFilterGraph(0);
VirtualDub.stream[0].filters.Clear();
VirtualDub.video.SetDepth(24,24);
VirtualDub.video.SetMode(1);
VirtualDub.video.SetFrameRate(0,1);
VirtualDub.video.SetIVTC(0,0,-1,0);
VirtualDub.video.SetRange(0,0);
VirtualDub.video.SetCompression(0x64697678,0,10000,0);
VirtualDub.video.SetCompData(2960,"AgAAAJCyCACbSwIALlx2aWRlby5zdGF0cwBuZSVpX2ZyYW1lAAAAAHpvbmUlaV9tb2RlAHpvbmUlaV93ZWlnaHQAAAB6b25lJWlfcXVhbnQAAAAAem9uZSVpX3R5cGUAem9uZSVpX2dyZXlzY2FsZQAAAAB6b25lJWlfY2hyb21hX29wdAAAAHpvbmUlaV9idm9wX3RocmVzaG9sZAAAAFNvZnR3YXJlXEdOVVxYdmlEAAAAcW1hdHJpeF9pbnRyYQAAAHFtYXRyaXhfaW50ZXIAAABjb25maWcAAFNvZnR3YXJlXEdOVQAAAABYdmlEAAAAACUuMmYAAAAAJXgAADB4JXgAAAAAXG1hdHJpeAAAAAAAKHVucmVzdHJpY3RlZCkAAG1vZGUAAAAAYml0cmF0ZQBkZXNpcmVkX3NpemUAAAAAdXNlXzJwYXNzX2JpdHJhdGUAAABxdWFudF90eXBlAABsdW1fbWFza2luZwBpbnRlcmxhY2luZwBxcGVsAAAAAGdtYwByZWR1Y2VkX3Jlc29sdXRpb24AAHVzZV9idm9wAAAAAG1heF9iZnJhbWVzAGJxdWFudF9yYXRpbwAAAABicXVhbnRfb2Zmc2V0AAAAcGFja2VkAABjbG9zZWRfZ292AABhcl9tb2RlAGFzcGVjdF9yYXRpbwAAAABwYXJfeAAAAHBhcl95AAAAYXJfeAAAAAAOAAAAAAAAAAgREhMVFxkbERITFRcZGxwUFRYXGBocHhUWFxgaHB4gFhcYGhweICMXGBocHiAjJhkaHB4gIyYpGxweICMmKS0QERITFBUWFxESExQVFhcYEhMUFRYXGBkTFBUWFxgaGxQVFhcZGhscFRYXGBobHB4WFxgaGxweHxcYGRscHh8hAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAJYAAABLAAAAAAAAAAEAAAAAAAAABAAAAAMAAAABAAAAAQAAAAAAAAABAAAAAAAAAAAAAAAAAAAAZAAAAPQBAAAAAAAAAQAAAPH///8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAGQAAABkAAAAAAAAAAAAAAABAAAAFAAAAAAAAAAAAAAABQAAAAUAAAAFAAAABgAAAAQAAAABAAAAAQAAAAAAAAAsAQAAAAAAAAIAAAAfAAAAAgAAAB8AAAACAAAAHwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAA8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA=");
VirtualDub.video.filters.Clear();
VirtualDub.subset.Clear();
VirtualDub.subset.AddRange(35044,35046);
VirtualDub.SaveAVI("e:/DVD/Last_Exile_1/LastExile_02/Data/LastExile_02.avi");
VirtualDub.Close();


All my zshell scripts do in the end is call VirtualDubMod with these 2 job files, which in turn uses the AviSynth script. All the AviSynth script was set up by hand, as were the SetCompData lines in the job files, and everything else is just straightforward what I'd have to do if I did everything by hand. (Actually, I'd rather trust myself to screw up something when doing it by hand than having it done by my tried and tested scripts.)

If you want to reproduce my XviD settings, just delete all lines from the job files but those starting with VirtualDub.video.SetComp* and load those into VirtualDubMod.

And in case you're wondering, that BlendBob function is something I'm currently experimenting with as a Deinterlacer, but it still stays the same for first and second pass.

Anyway, I'm off to go shopping now...

np: Triosk Meets Jan Jelinek - Theme From Trioskinek (1+3+1)

[Koepi]

Please, please, pretty please (with sugar on top):
do these 4 eps manually and see if you can confirm the results. I haven't got the time to just use your vcf files and debug them - I'd prefer to do that only if you verified that this happens if you do it the "usual" way.

Regards
Koepi

[GolovachLena]

I just made some encoding (2 h 22 m movie)... No avisynth filters just Crop and LanczosResize. The first pass gone pretty fast at 35-40 fps and took 1 h 30 m (i have P-4 and i think such amazing speed was due to sse2 optimization). But the second pass encoding speed lowered to approx 16 fps and it took more than 3 hours to finish. Turbo option was set on. Why such difference between passes?
Btw, ffdshow version 20031128 plays beta3 movie a bit jerky!

[Heini011]

@Koepi: thanks a lot for this christmas gift!

but some problems:


the quantizer-bars in the statistic-window are still not shown properly under win me and virtualdubmod. (same as with last 2 betas)


in my first try virtualdobmod failed with 2 passes in batch mode: resulting file is undersized and not playable. [amd k7 1850 Mhz, virtualdubmod 1.5.4.1, win me]


i can't even install XviD-Dec-1.0-Beta3.exe on my old amd k6-2+ 500 mhz win98se machine (same result with beta 2):

"XVID-DEC-1 führte eine ungültige Anweisung in
Modul XVID.AX bei 018f:10003325 aus."
[translation: invalid instruction in XVID.AX]

are there sse-optimizations in the installer ?? :D

greetings, Heini011

[kadajawi]

Originally posted by GolovachLena
I just made some encoding (2 h 22 m movie)... No avisynth filters just Crop and LanczosResize. The first pass gone pretty fast at 35-40 fps and took 1 h 30 m (i have P-4 and i think such amazing speed was due to sse2 optimization). But the second pass encoding speed lowered to approx 16 fps and it took more than 3 hours to finish. Turbo option was set on. Why such difference between passes?
They have done some optimisations... the second pass runs as slow as usual (3 fps for me), but the first pass is nearly twice as fast (5-6 fps). Great work :D

[gino25]

I have a problem when i decode a video.

Video 544*256
b-bop 3-1.50-1
gmc on
trellis
turbo mode


I have an athlon 2400+@2100mhz (200*10.5), with 1024 mb of ram pc 3200

When i decode a video the decoder uses full cpu (100%) but it isn' t in real time
+


I have tried some players, windows media player 9, bsplayer, zoomplayer, etc

[HBK]

Man, the optimizations that have been made are killer. I get 60fps when encoding black scenes (like the first few seconds of a movie), then I get constant 40fps all the way through. I encoded the Matrix Reloaded (138 minutes) last night and the first pass took a little over 90 minutes. The second pass seemed to be going at around 18-20fps.

The quality is amazing. It might just be me, but the difference between beta3 (the first Xvid 1.0 beta I've tried) and the last unstable codec (released back in June I think) is quite profound.

Well done, keep up the great work :D

[Koepi]

Gino:
look out for the "silent update" on my HP. (Especially the standalone decoder...]

Heini:
Hit "load defaults" after installing a new build.

Golovach:
Read the whole thread - those are known issues (ffdshow is buggy with packed bframes[xvid decoder decodes it fine]), the changelog clearly states "2pass overhauled, including fast first pass" - ...

Regards
Koepi

[mikeson]

Why don't people read threads from beginning and carefully. As Koepi and I clearly stated, fast first pass is due to switching off some ME not so important flags. Please stop asking about that.

[Leak]

Originally posted by Koepi
I thought you just mux audio during 2nd pass.

Damn. your "bugreport" is too weird for my simple brain. please redo things properly (read: setup avs, vdubmod, xvid manually) and see if you can confirm the false results.

I'm more and more confident it's your scripts.

Well, actually after encoding the 2nd episode "by hand" and taking a good look at the status window it turns out that the most probable suspect is "fast first pass" - up until recently, the output of the first pass really was the best quality output you could produce with the used settings which gave you a perfect indication whether the second pass would be undersized or not, so there probably would not even be a need to run the second pass as it would just produce the same (still undersized) result - which was okay with me, as I don't mind undersized files as long as I can use the same settings for all episodes and I'm getting good results with them.

If I assume correctly that fast first pass trades some of that quality for speed, could we please have "accurate first pass" back as an option? As it is now, the result of the first pass is hardly an indication whether the second pass will even reach the target size:

http://desdemona.ssw.uni-linz.ac.at/LastExile_02_Pass1.png
http://desdemona.ssw.uni-linz.ac.at/LastExile_02_Pass2.png

At least that's what I figure from the fact that neither the first nor the second pass even used a quantizer higher than 2 for I/P-frames and higher than 3 for B-frames.

I've encoded both passes in VirtualDubMod without muxing the audio, and the result is 175.786kB for the first pass and 162.394kB for the second pass. I'd bet that without "fast first pass" it'd been 162.394kB for both passes, and that's what I've assumed until now to mean that I could skip the second pass and save some time. Now, the first pass is bigger than neccessary (though I don't know whether it affects it's visual quality much) and to be honest, all I care about is quality, not the time it takes.

So could you or whoever implemented this please make "fast first pass" optional, unless the whole codebase was overhauled for it? I mean it's good for people who want fast encodes, but I'd rather have a first pass file that's an indication of the quality I'm going to get, so I don't even have to run the second pass if I don't like the quality the settings produced for the first pass.

np: Themselves - Another Part Of The Clown's Brain (Them)

[mikeX]

hi,
i just downloaded the beta 3, both the codec and the decoder from koepi's page, but when i tried to check out the decoders performance (with a beta 2 encoding) i came about some problems:
i use ffdshow's libavcodec, so i tried to enable the xvid decoder trough it's configuration window, but the option was grayed out (can't recall the version of ffdshow - winXP pro sp1a).
when i disabled xvid decoding in ffdshow i got the 3ivx D4 that comes with the latest k-lite codec pack instead, : (
so i uninstalled ffdshow and reinstalled it (version 2003.05.23).
now there is an option to use the xvid decoder but when i enable it i just get a black screen (both wmplayer & bsplayer)!

is there a way to get around this without having to install/uninstall a whole bunch of codecs and decoders????

(ps: is there any legal issue with k-lite codec pack??)

[Koepi]

Don't use codec packs - read the stickies & the FAQ.

Leak:
Fast first pass has this side effect, true. I'll see if we can make it an option - I had some doubts when we made it default, but now there's the proof that'll be useful to make it an option, people can be distracted.

Thanks for rechecking that manually.

Regards
Koepi

[mikeX]

@ koepi

sorry if i sound like an ass but could you have been less specific??:
read the stickies & the FAQ for what (meaning what to look for)???
do you imply that there are legal issues with k-lite???

anyway i uninstalled the codec pack and i can now use the xvid decoder when i disable xvid decoding in ffdshow...
but i'm missing an avi splitter and i get 'corrupted file - seeking will be slow' with bsplayer & 'format not supported' with wmplayer...: (

oh & a real big THANX for the quant matrices koepi!!!!(they weren't there on the older builds right??)

+ the movie looks kinda better on first glance with the xvid decoder! and what a surprise: the decoder lag seems to be gone (it's there if i play the movie through avisynth with avisource() but gone if i play the avi directly)!!

btw: since beta 2 (not 1) i got 2 xvid codecs in virtualdubmod (i know it's reported!)
now i get only one again but with 'YV12' fourcc. is that normal?
(virtuldubmod 1.5.10.1 builds 2389 and 2407)

[Leak]

Originally posted by Koepi
Fast first pass has this side effect, true. I'll see if we can make it an option - I had some doubts when we made it default, but now there's the proof that'll be useful to make it an option, people can be distracted.

Thanks for rechecking that manually.

No problem. Still, I think there's an even better use for getting the exact size of undersized files in the first pass than skipping the second pass on them:

Say you want to put 26 episodes of a series to a DVD-/+R (~4.5GB of space), so you're going for a filesize of ~170MB (actually that's what I'm doing... :)). So if you run a first pass on all 26 episodes with the options you settled on and find that a few files come out undersized in the first pass it's quite easy to calculate the amount of extra space you have left and adjust your target size for the second pass accordingly, which ought to give the files that weren't undersized a quality boost.

Seems like a good idea to me, at least. Of course, you can also do this with "fast first pass", but then it'll mean you have to encode all files that weren't undersized a third time, which will probably take a bit longer than what you saved by "fast first pass" in the first place.

np: Triosk Meets Jan Jelinek - Neckless (1+3+1)

[mikeX]

now i get only one again but with 'YV12' fourcc. is that normal?

Just found out that GSpot 2.21 finds an 'XVID' fourcc on the actual files instead of the 'XVID/YV12' that i got when encoding with the 'yv12' fourcc beta 2 codec, i don't think it's too reliable though...

[SeeMoreDigital]

I apologise in advance for not reading all of this thread so I don't yet know the ins and outs of this new version!

Anyway, I've just generated a couple of short 1pass 720x576 encode setting the aspect ratio to 16:9.

Now, when I played back the encodes in MPC and WinMedia players the aspect ratio did not output correctly. However, when I played the same encode using Nero's ShowTime player the aspect ratio was correctly displayed.... is it supposed to do this when it's still in an AVI container?

Cheers

EDIT: It would seem it is. I've just gererated another encode from the same source at 4:3 and the AR did not output at the coreect ratio. This is very, very clever!

[sysKin]

Originally posted by Leak
If I assume correctly that fast first pass trades some of that quality for speed, could we please have "accurate first pass" back as an option? As it is now, the result of the first pass is hardly an indication whether the second pass will even reach the target size:I was against that because I already can imagine people disabling fast1pass because they could think it gives them higher quality (and it's not true).
First pass should really just be an analysis of the video, not encoding.

However, there is a simple way to disable it - make your movie a quant zone (in first pass only) with quant 2. It will disable all speedups.

There is a different way - allow quant 1 if you think that your second pass might reach maximum size. It will allow second pass to be bigger than first pass, no matter what.

Radek

[mikeson]

@sysKin:

Great FAQ in your signature, it certainly stops a lot of useless questions. ;)

BTW thank you for your great work in developing XviD!

[Blue_MiSfit]

looks promising!!

currently encoding the second side of Das Boot at 608x320, shooting for about 620 megs using the following settings:

TURBO!!! :) (whats next, NOS?)
HVS - best matrix
VHQ 4
b-frames @ 3 / 1.5 / 1.0
qpel, gmc, chroma motion, trellis, and adaptive quant

first pass is freakin flying!!
nice work devs!

Another thing, I noticed beta3 chooses (in this firstpass anyway) a lot more p frames than beta2 did. Not sure exactly what this will mean, as I am just beginning to understand all this xvid talk (bframes, quants, etc..)

fascinating stuff all...
~misfit

[gino25]

Originally posted by Koepi
Gino:
look out for the "silent update" on my HP. (Especially the standalone decoder...]

Heini:
Hit "load defaults" after installing a new build.

Golovach:
Read the whole thread - those are known issues (ffdshow is buggy with packed bframes[xvid decoder decodes it fine]), the changelog clearly states "2pass overhauled, including fast first pass" - ...

Regards
Koepi

Now the deciding work well.

Thnks

[Leak]

Originally posted by sysKin
I was against that because I already can imagine people disabling fast1pass because they could think it gives them higher quality (and it's not true).

<nitpick>But it does - for the first pass video... or at least it produces a smaller file; I didn't really check whether the quality differs much.</nitpick>

First pass should really just be an analysis of the video, not encoding.


Well, I guess finding out the maximum file size possible falls under "analysis", right? :)

However, there is a simple way to disable it - make your movie a quant zone (in first pass only) with quant 2. It will disable all speedups.

Whoa - if it's that simple, I guess there's really no need for yet another option. :)

There is a different way - allow quant 1 if you think that your second pass might reach maximum size. It will allow second pass to be bigger than first pass, no matter what.

Yeah, well... I'm not really after maximizing the file size (I'm completely content with undersized files, as they leave you extra space for those files where the first pass is larger than the target size), but after getting an accurate quant-2-and-all-the-options-I've-set-encoded first pass, as it was up to (and including) beta 2... :)

np: Sole - Suicide Song (Bottle Of Humans)

[symonjfox]

Second Anamorphic test.

Source:
Shrek DVD.
Avisynth:
mpeg2source("shrek.d2v",ipp=false,IDCT=7,CPU=4)
Crop(8,8,-8,-8) #to crop black borders (now 704*560)
Xvid beta 3:
All @ default except:
16:9; 2 Bframes, Qpel, VHQ4, Chroma Motion, Trellis, NO turbo, NO packet frames.
Result bitrate (2 pass vbr): ~984 kbs
Audio:
Using OAGMachine, AAC-HE 6ch 143 kbs.
container:
MPEG4 using MP4Creator ... -interleave -optimize

Results: I've a very very good result, the quality is awesome. I noted that the final MP4 is very very heavy to run, on my 1800+ machine the playback is stutter. It uses 3ivx Direct show filter (100% CPU).
Instead playing it with FFdshow (video only) I get 40 ~ 60% CPU utilizzation (but AR is shown at 1:1).

[LigH]

Originally posted by Chainmax
What about making an avisynth filter out of the deblocker?

Sorry for answering so late... :o

MPEG2Dec3 already has deblocking filters (CPU and CPU2 parameters in the function "mpeg2source()"); and if you want to deblock further, use the function "BlindPP()" with almost the same parameters - I only forgot the name of the parameter which defines the quantizer supposed for the BlindPP postprocessing strength, please read that in the docs in the MPEG2Dec 1.10 package from Nic.

http://nic.dnsalias.com

[Assault]

Originally posted by sysKin
I was against that because I already can imagine people disabling fast1pass because they could think it gives them higher quality (and it's not true).
First pass should really just be an analysis of the video, not encoding.

Perhaps fast1stpass could be automatically disabled when you uncheck discard first pass. Because this options gets only unchecked when someone wants to keep the first pass file. With fast1stpass enabled keeping the first pass file doesn't make much sense. What do you think about that?

Assault

[Arcon]

i just wanted to watch an older movie i encoded with xvid14052003-1 with beta3 and the result differed pretty much:

beta3 (http://mitglied.lycos.de/hoarzt/doom/beta3.png)
1405 (http://mitglied.lycos.de/hoarzt/doom/older.png)

would it be possible to check the encoder-build and decode movies made by older builds correctly or is this too much work? i mean i can just install the older xvid-build whenever i want to watch such a movie and install the new xvid back after that, but it would be more convenient if xvid 1.0 could do this internally :)

[mikeX]

@ Arcon
u could also give ffdshow a try and avoid all that intalling/uninstalling...

made an encoding:
1st pass: half the speed of my beta 2 encodings
with adapt quant, q-pel, bvops @2-1.5-1 (sensitivity -5)
ME 6, vhq 4 (vhq 1 on the beta 2 + gmc), chroma (motion + optimizer) + turbo ;)
2nd pass: a slight speed increase compared to the beta 2 (2-4 fps) but i had vhq 4 instead of 1
the thing is though that i couldn't complete the 2nd pass cause virtualdubmod crashed (completely vanished, no crash report)!
it did that a lot with the beta 2 as well but i thought it had to do with some messing around i'd done to my DRAM timings in combination with some heavy avisynth filters (like denoising before the resize) - i used to get access violations as well...
i thought that was long gone though after i restored the default timings, but i guess it isn't... : (
athlon xp 1800+ 256MB DDR 333 on via KT3 Ultra
win xp sp1a...

btw: is it safe to use gmc with vhq??
&& how exactly does b-vop sensitivity affect b-frames (is the scale still -100 / 100)?

[mikeson]

@mikeX:
is it safe to use gmc with vhq??
&& how exactly does b-vop sensitivity affect b-frames (is the scale still -100 / 100)?
This has been discussed many many times. Please use Search function and read threads about 'Aloha' and 'Ciao' XviD releases.

[alucard83]

First I must thank the XviD guys for doing a great job with the codec!

Now, I just have one small nuisance that sometimes pops up but I'm not sure if it's vdmod or XviD itself. If for example I'm doing a two-pass encode and for some reason, I need to cancel the encode during the 2nd-pass, later on(like an hour or two later) I start over the 2nd-pass via the job control in vdmod, it goes extremely slowly, like 0-2 fps. I'm not sure if this a bug or not, but usually when it finishes the 1st pass and moves on, the 2nd pass encodes at much more respectable, realistic and faster rate.

I *was* using beta 2 at the time when this was happening, but I haven't checked out the b3 yet, so I'll give it a run to see.

[Mole]

Not sure if somebody has already suggested it.

Would it be possible to be able to save the current XviD settings including all zones information?

So, in additional to the "Load defaults.." button, you could also have a "Load settings" button as well where you can load your saved setting.

This would also be useful so people can share their XviD and zoning settings for a particular movie.

[jang0]

Originally posted by Mole
Not sure if somebody has already suggested it.

Would it be possible to be able to save the current XviD settings including all zones information?

So, in additional to the "Load defaults.." button, you could also have a "Load settings" button as well where you can load your saved setting.

This would also be useful so people can share their XviD and zoning settings for a particular movie.

As far as I know, Xvid settings are stored in the registry. (I know this for sure for devapi3 builds, haven't tested xvid1.0b yet) In the old builds they were stored in

HKEY_CURRENT_USER\Software\GNU\XviD

Perhaps they're still in the same place. So why don't you export this registry key with regedit right after you set up your favorite settings. So you would have something like favourite_setting1.reg, favourite_setting2.reg etc. and you just needed to double-click them to add the settings to the registry and therefor restore the corresponding Xvid settings.

[LigH]

GordianKnot 0.28.x creates such files (called *_firstpass.settings and *_secondpass.settings) when you set up the defaults for any movie in the "Options" tab. Those files are indeed REGEDIT4 files, readable with any text editor.

[Heini011]

@devs:

it would be a help, when "fast-fist-pass" is only active, when "discard-first-pass" option is checked.

greetings, Heini011.

[wannabe]

Arcon: i guess u are refering to the different iDCT issue, that Walken gives bad quality playback over Simple iDCT(that's what 1405 used). Honestly saying, u ll get ignored by now cuz i got ignored as well when i brought it up, cuz Koepi said sometime back ago that the final xvid decoder ll autodetect which iDCT to use, so xvid ll be backwards compatible and end of conversation.(still dont see the reason why is it a crime to ask the progression of the work that goes on with this feature...). The unavoidable question arises that if standalones ll do the same, that i guess they wont since they wont use koepi decoders, so after all we can safely say that it was a pretty foolish decision to rls some public builds with simple idct. I hope im wrong.


PS: FFdshow is not a solution, since it has that bug in its xvid idct that ll create the similar effect(just not that bad) for walken like u have with walken over simple. And it cant decode packed bitstream, and standalones wont use ffdshow as well.

[gizmotech]

Originally posted by sysKin

There is a different way - allow quant 1 if you think that your second pass might reach maximum size. It will allow second pass to be bigger than first pass, no matter what.

Radek

Now this is interesting. There is a way for the codec to create a stats file w/ quants lower then 2? if so, how is this achieved and does it require that the whole file be created and stored at q1 or can a intermediate q value be assigned (1.5 for example)

Gizmo.

[Koepi]

Originally posted by wannabe
Arcon: i guess u are refering to the different iDCT issue, that Walken gives bad quality playback over Simple iDCT(that's what 1405 used). Honestly saying, u ll get ignored by now cuz i got ignored as well when i brought it up, cuz Koepi said sometime back ago that the final xvid decoder ll autodetect which iDCT to use, so xvid ll be backwards compatible and end of conversation.(still dont see the reason why is it a crime to ask the progression of the work that goes on with this feature...). The unavoidable question arises that if standalones ll do the same, that i guess they wont since they wont use koepi decoders, so after all we can safely say that it was a pretty foolish decision to rls some public builds with simple idct. I hope im wrong.


PS: FFdshow is not a solution, since it has that bug in its xvid idct that ll create the similar effect(just not that bad) for walken like u have with walken over simple. And it cant decode packed bitstream, and standalones wont use ffdshow as well.

Heyhey, slow down.

you didn't get ignored. The topic isn't "wiped away". There's still no clear solution - so how could we update a status if there isn't one?


Xvid isn't "my invention". It's the whole team. You're insulting some very fine people which don't deserve your arrogance. If you have a problem with me, write a PM to me - or if you don't have the guts, to Doom9 - but leave the rest of the team out of this.

Time for rethinking what you wrote there. It's really beyond the borders/below the belt. (Makes me think - why should we even _think_ about what you write if you're just insulting.)

[Arcon]

Originally posted by Koepi
There's still no clear solution - so how could we update a status if there isn't one?
well, for a non-regular reader of the actual xvid development progress like me it's already a status that you are aware of this problem and try to find a solution thats better than manually swapping the codec on a per-movie basis :)

[wannabe]

If you have a problem with me, write a PM to me - or if you don't have the guts blabla

I already emailed you (a couple of times), you did never answer back.

you didn't get ignored

I had to ask re-ask you to react to my message in the Aloha thread.


By the way, about the last time in Aloha thread, you could clear me up the reason why u had to be so arrogant, when i asked about how the work was going on lately with that feature, since that topic, that you were refering to ("use the search function, we discussed it many times") was many months old, so i guessed that info is dated, and i thought you might have done something new with it in the new build thats why i brought it up again then. You did not answer just said that i violated some rules and should search for obsolate information.

I think i brought up an interesting topic, that how is gonna be xvid backwards compatible on PC and on Standalones it should be discussed in the beta threads, rather than making it into Koepis personal crusade, i did not offend any of you, especially not the other devs.

[CruNcher]

@wannabe i dont really understand you sorry but you have been aware that useing that build could make your encodes not playable anymore in the future i would be happy if im you that the XviD Devs think about how to solve that now and i have to advise you that only in Koepis build SimpleIdct was used a longer time in the CVS it was only in some days the problems that those encodes might produce on Standalones now especialy with Qpel cant be reverted back and no Standalone Manufacture will be interested to solve that problem.

[Kb_cruncher]

There is a different way - allow quant 1 if you think that your second pass might reach maximum size. It will allow second pass to be bigger than first pass, no matter what.

WOW.I just finished a first pass that came out 70mb below my target so i set q1 as minimum for all and set my file size for the second pass and it worked.Who would have thought a second pass bigger than the first:cool:

[Koepi]

kb_cruncher,

don't be too amazed, there's a (small) price to pay: q1 frames take up quite some CPU time to decode. This is no issue on "now used" CPUs, but if you stick with a pII or something like that, you'll notice some stuttering during playback :-/
I'm not too happy with that side effect, but it shouldn't matter anymore today :)

Regards
Koepi

[sysKin]

Originally posted by mikeX
how exactly does b-vop sensitivity affect b-frames (is the scale still -100 / 100)? Actually this scale has never been -100..100.

Currently, it's very sensitive - value 5 gives a huge boost of bframes. Lemme check for minimum... -35 I think. It will still allow some b-frames in rare cases, because the actual threshold is capped - values below -35 won't change sensitivity.

As usual there is no maximum, you need huge values if you want 5 b-frames in a row (useful for credits).

Radek

[mikeX]

thanx a lot for the info syskin : )

i'm working on some linux encodes right now with transcode.
i see there is a speed increase (1st pass at the moment) but
i have trouble activating certain new settings and i'm just getting
started with transcode... : (

should i keep posting or is this a 'windows' only thread??

[sysKin]

Originally posted by mikeX
i'm working on some linux encodes right now with transcode.
i see there is a speed increase (1st pass at the moment) but
i have trouble activating certain new settings and i'm just getting
started with transcode... : (

should i keep posting or is this a 'windows' only thread?? This particular thread is about Koepi's build so I think noone will complain if you just open a new thread. However, if you also expect a response (lol) you might try Linux forum instead of XviD forum...
I can't help you with transcode :( with one exception - make sure you have correct transcode module for 1.0 xvid, you can find them at http://ed.gomez.free.fr/

Good luck,
Radek

PS. trying to disable my signature here - let's see how it works

[ookzDVD]

@forum,

I did try the beta 3 last night, the result is just as good as
I expected. Two thumbs up for XviD!

[mikeson]

@sysKin:
PS. trying to disable my signature here - let's see how it works
Noooooooooooooo! :D

[riggits]

@wannabe:

there's a fairly clear disclaimer on the official xvid page explaining that backward compatibility isn't on the agenda, and that xvid is an alpha or beta status project designed to implement the mpeg4 specs. in other words, it's not perfect, and older movies just might not work. too bad 4 u. no need to be a dink about it, esp. since it's clearly stated on xvid's website.

[wannabe]

CruNcher + riggits: i never used 1405... im talking about other people who as you say did not realize the problem. They used that build for a long time for a lot of encodes, and still keep using it at the moment. And i, and a lots of other people got their encodes.

PS: the official xvid site does not put up any precompiled builds for the public, so therefor it wasnt their fault that some simple idct builds spread out.

[Koepi]

wannabe:
So, finally you're talking about pirated movies which got encoded with a build which was available for a very short time?

Yet another forum rules violation which you didn't get striked for yet (rule #6).

Be careful about the sound and the language in your posts, or you'll find yourself on a small posting vacation to cool down. (And once more: with ffdshow you can switch the idct to simple. Do that and you're done. On the other hand, upload a small sample which shows that effect somewhere and give us the location via PM - we could look into that what is b0rked and find a fix. We're discussing the stuff and SimpleIDCT isn't likely to blame.)

Koepi

PS: using SimpleIDCT _is_ mpeg4 compliant. It's just a matter of the distance between 2 intra-macroblocks (or i-frames). As long as there's a "refresh" every 132 frames for every macroblock (i think that was the number), you shouldn't see any colour mismatches.

PPS: riggits, well, you're right, but we always try to stay backward compatible (after all, mpeg4 is mpeg4). We have bitstream-numbers - thank god already back when we tested simpleidct - which help _indicate_ what went wrong back then. Unfortunately there were also builds out using walken idct with bitstream number 009, so after all we'll most likely end up making it a user-switchable idct in dshow decoder.

[fatxy]

lo xvid team

is there any chance to enable the bitrate slider in 2-pass mode too? in addition to filesize of course, so you could choose whats best for the current project.

cause its very circuitous to get proper filesizes with bitrate calcs for short vids like <60sec etc.

mfg fatxy

[mikeX]

yeah i thought maybe i could post to compare speeds and/or stuff like that, maybe i'll start a thread when i get things figured out ; )

ps: i was wrong about the increase in speed, it was actually a decrease (18-20 fps win vs 13 linux- 7-10 vs 6 fps for the 2nd pass)!! i should probably get the right module and configure it properly, btw thanks a lot for the link syskin :D
oh and does anyone have any thoughts about the crashes i mentioned earlier in this thread (could it be vdub having problems with the codec)?? i never really had them prior to the betas, even with nic's and koepi's 'unstable' builds (i also wasn't so heavy on the avs scripts -denoisers etc-)

[wannabe]

CruNcher + riggits: i never used 1405... im talking about other people who as you say did not realize the problem. They used that build for a long time for a lot of encodes, and still keep using it at the moment. And i, and a lots of other people got their encodes

Koepi: Where do you see piratism, cracks warez mentioned in my post ? I dont see any. I was refering to not copyrighted, free videos on the net. But you violatied Rule # 4 for being rude and not respecting your fellow man. Pls stop finding reasons to trash me.

[Teegedeck]

wannabe, you are not entitled to any special treatment here. Regard posting on forum.doom9.org as a privilege that just expired. I wanted to strike you but right now I see that I'm too late.

[Leak]

Originally posted by fatxy
is there any chance to enable the bitrate slider in 2-pass mode too? in addition to filesize of course, so you could choose whats best for the current project.

No need to take chances here - just select "Twopass - 2nd pass" and click on the button to the left of the input field below that should say "Target size (kbytes)" - it'll turn into "Target bitrate (kbps)"... :D

Some versions ago, Koepi made a button out of this, but it seems it's still not really obvious - how about turning it into a combo box to make it really ultra-obvious? :) (You see, buttons normally aren't meant to change their label when being clicked on - so I can see why people won't find it...)

np: Lawrence - If You Can't Understand (The Absence Of Blight)

[fatxy]

oha, thanks a lot :rolleyes:

never stumbled about this, prolly thought its a gui bug or sth like that ;)

but now i know, yahoo :D

PS: addin ALT text to display on moving mouse over would be nice tho

[mikeX]

hey wannabe is right you know, he didn't violate any rules (at least on this thread)
why all the hostility teegedeck?

[Leak]

Originally posted by mikeX
hey wannabe is right you know, he didn't violate any rules (at least on this thread)

Letting wannabe speak for himself:

i never used 1405... im talking about other people who as you say did not realize the problem. They used that build for a long time for a lot of encodes, and still keep using it at the moment. And i, and a lots of other people got their encodes.

You know, complaining about a problem with a specific build and then admitting to never having used it *AND* admitting to having that problem with other people's encodes *does* smell a lot like rule #6... *hint hint*

np: Lawrence - Thielhes (The Absence Of Blight)

[kadajawi]

yes, smells. But it is not a proof, for sure there are legal encodes using XviD which are freely distributed on the internet.

[mikeX]

letting wannabe speak for himself too:
i was refering to not copyrighted, free videos on the net

there is no explicit reference to anything illegal, his explanation seems adequate (unless there are such references in other posts he's made)

[Arcon]

Originally posted by Leak
You know, complaining about a problem with a specific build and then admitting to never having used it *AND* admitting to having that problem with other people's encodes *does* smell a lot like rule #6...
hm? i've seen many samples for various problems posted in this forum. if just watching clips/encodes made by others is considered 'warez' i think we are all guilty.

[The Link]

Why are there still people who think a forum is led democraticly? If one doesn´t agree with a moderator/developer it is not a problem of two persons but of just one (what others think about this disagreement is even more irrelevant).
What I want to say:
This thread is getting highly uninteresting! What about going back on topic!??

Regards,
The Link

[Koepi]

----- *don't read this if you look for technical info* ------
To end these "personal discussions" here:

We develop xvid for FREE in our SPARE TIME.

So we don't owe anyone anything. We're trying to be nice and support you here though.

But instead of attacking people and demanding things there could be a nicer sound in the posts in question. Especially when you reread the first sentence here, "it's free, we do it in our spare time".

The right way would have been to write "I still have a problem with encodes from old SimpleIDCT builds. This is a serious bug in my opinion, please reconsider doing something about it."

But this all just got personal, somebody wrote emails to dead accounts (my email addresses are easy to find on my site - the others are flooded with virii and spam and thus i don't use them anymore, so please don't use emails you find in very outdated documentation like XOE) and thinks he gets ignored.

With a little respect from and for each other this wouldn't (have) happen(ed). If you disrespect the work we do in our spare time for free (I hope after 3 times reading that _everyone_ should get the idea) and just attack us, you don't get the attention you want, but a flamewar. That's why Teegedeck (and I) see the need to use the brake.

So please, let's settle this, be nice to each other again and concentrate on XviD and the current bugs.

----- end of *don't read this if you look for technical info* ------

Good news: the SimpleIDCT-sample plays very well without problems on standalones based upon mediatek chipsets. We have a "hack" ready which makes decoding IDCT switchable but need to do further disucssions on this internally - it shouldn't be a hack but a graceful solution.

Regards
Koepi

[CruNcher]

@all I just tested the sample.avi on my MediaTek standalone and it has no color Problems :) would like to hear about peoples expierence playing that clip on Sigma and ESS based players :) but please your Player needs to support QPEL.

[Kb_cruncher]

I don't agree with attacks and complaints but i think a little tolerance would not go a miss.

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

[Teegedeck]

If we've learned a hard lesson from all the time in moderating, it is that it's not worth the time putting up with the playback-problems of people who are not themselves actively encoding but merely trying to watch some downloaded movie. If we hit someone by mistake it is unfortunate but one just cannot take all the trouble and stress that results from nitpicking. Especially if someone behaved very suspiciously but only denounces any guilt after being accused. We are not obliged to always be perfectly just in moderating. But we are obliged to be very strict about warez and moviez. So my moderating (and I guess Koepi's, too) is not always perfect but if we'd have to play by the rules of P2P users we'd soon be so unnerved that you'd have no moderators at all. And doom9 doesn't work without them.

And as soon as any user starts getting personally insulting, accusing a moderator I draw a line. Koepi does a job and a half for free and he certainly doesn't have to put up with insults. wannabe should have turned to Doom9, and only Doom9, if he had a problem with moderating over here.

[Koepi]

Originally posted by Kb_cruncher
I don't agree with attacks and complaints but i think a little tolerance would not go a miss.

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

If you have something with xvid+ac3 in it and don't know about ac3, it's a downloaded/pirated movie for sure.

This is the last off-topic for this thread, please.

Regards
Koepi

[mazzo]

I'm not sure this really is a XViD issue, so I just wonder if anybody has experienced the same:

I encoded a segmentedsource avi, 2 hrs 9 minutes long, for two discs. When XVid had finished, the file was not 1.4 Gb big, but 1.1. Unfortunately I deleted the original capture files, after playing some ten minutes from start, all looking fine. I thought the file only had muxed out or something.

But when I should watch the movie, I saw that after approx 1h 30, the picture froze and remained frozen to the end. Could this be caused by a bug in XviD or not?

[Koepi]

That doesn't sound like an xvid error, it sounds more like an issue with the segmented avisource. I did plenty of encodings with more than 1h30mins, so that time stamp isn't a limit we have troubles with.
Also, 1.1GB/1.4GB aren't magical numbers which could indicate a variable overflow or something similar.

Could it be that the first avi segment had about 1h30mins from the 2h9mins?

Regards
Koepi

[mazzo]

I'll have a new movie in the making just now, so I'll check it thoroughly.

I have never had any problems in encoding segmented avis earlier, I've done this for over a year now.

It might just be bad luck this time, perhaps my machine had a bad day or something.

[jang0]

Got a question concerning IDCT:

I've done a few encodes with the 140503 build (simple IDCT), at 640*480, h.263 matrix, 2pass, no B-Frames, no Qpel, no GMC, no trellis.

Using different versions of the xvid.ax decoder (newer ones using Walken) AND using ffdshow with different IDCT settings, I can't spot any artifacts such as horizontal lines or odd colors.

Of course I'm glad about that (perhaps my eyes are just too bad), but I wonder why those problems don't appear for me. Do those problems only apply for encodes using Qpel or any other ASP special stuff?

[bugsan]

I noticed that it misses one or more frames in my encodes. that occurs only with bframes. One or more frames are missing even in the stats file.
Just test this :
clip.Trim(0,10) => virtualdub shows 11 frames (it's ok)
Encode it with bf=2 or more.
look at video.pass, and *sometimes* the last frames are missing, depending on the max bframes.

[Arcon]

Originally posted by jang0
Using different versions of the xvid.ax decoder (newer ones using Walken) AND using ffdshow with different IDCT settings, I can't spot any artifacts such as horizontal lines or odd colors.
what happens if you tell ffdshow to use xvid.dll instead of xvid.ax or open the avi in vdubmod (which uses xvid.dll for decoding)?

the directshow-filter and the dll are not 100% identical (at least they were in the past where the ax had problems with smearing decoding some of my encodes while the dll hadn't).

[Chainmax]

From reading the first post, I gather that "fast first pass" isn't the same as "turbo mode". Where can I find it in the vfw config box and exactly what does it do?

[Isibaar]

Originally posted by Koepi


PS: using SimpleIDCT _is_ mpeg4 compliant. It's just a matter of the distance between 2 intra-macroblocks (or i-frames). As long as there's a "refresh" every 132 frames for every macroblock (i think that was the number), you shouldn't see any colour mismatches.


Unfortunately that's not true. I implemented the 132 inter MB refresh period as well as all the other additional requirements to IEEE 1180 that are specified in the MPEG-4 standard. But: it didn't help. To avoid visible mismatch between simple idct and walken idct (which are both perfectly compliant btw) you'd need a refresh interval of about 20 inter MBs. However this would mean a huge loss in compression performance.

So the situation is like this: It was a huge mistake to leave the idct implementation unspecified in the MPEG-4 standard. The requirements that were specified are absolutely insufficient. Autodetecting the idct that was used for encoding (if possible at all) is a rather weak and limited approach to cure idct mismatches. I've already posted some more info about the idct issue here on the forum: http://forum.doom9.org/showthread.php?s=&threadid=56190&perpage=20&pagenumber=6

@CruNcher:
I'm not so sure if I should be happy about your findings. If you have no color problems on your MediaTek standalone with a sample video that exhibits color artifacts when played back with walken idct, then that means that MediaTek implements another idct than walken. So it could be that the MediaTek standalone will then exhibit color problems when decoding 'regular' XviD streams that were encoded with walken idct.
Note: All above is just pure speculation. I really hope you'll never experience any odd colors with your standalone.

@jang0:
There don't have to be strange colors for each single encode when done with simple and then played back with walken idct (or vice-versa). It just happens sometimes under some bad circumstances.

Also, visible problems from idct mismatch can occur even when no ASP features (like qpel) were used. However qpel seems to amplify the problem, so the probability that something bad happens seems higher when qpel was activated.

[sysKin]

Hi everyone,

I made an ugly hack to xvid's directshow filter which allows switching iDCT while decoding.

You can download it (src & binary) from http://homepages.ihug.com.au/~syskin/dshow.rar .

Just click on a button in dshow's options to immediately switch to mmx-ed walken or mmx-ed simple. No CPU detection is performed so after you click, you won't be able to return to faster sse, sse2, 3dnow! etc version until you restart the player. Also, you need mmx support ;)

Have fun,
Radek

PS. /me really wonders why mpeg-4 guys chose dct.. there are so many integer dct approximations, from slow but reasonably close to fast and close-enough (like in h264)... ;_;

[archimage]

/rant
Wow i dont know how the xvid team puts up with this , since this is a `FREE` an `OPEN` project . I remember when people asked about xvid 1.0 , the retort was , "why" xvid shouldnt be bound by numbers because its constantly changing an improving , not to say that non-opensource code doesnt improve ,change , its just that anyone can download wincvs , checkout xvid , an compile it for their self . All i can say is i have the utmost respect for Koepi an Radek for taking on this challenge "xvid 1.0 Doom9 challenge ", an not going cr@zy .
/end rant

I downloaded beta3 source from xvid site , compiled with ICL 7.1 . Encoded 2010 frames at quant 3.5 , MSP 6 , VHQ 4 , Trellis , HVS Good , GMC , AQ , 1 BiDi 1.50 1.00 ,
/my compile - 16:42 min
/koepi build - 12:58 min

So regardless of what i said earlier , Thank You Koepi & Xvid team for this great build .

[poochie2]

I'm doing the first pass via xvid1beta3 and I saw the stats telling that @q2 after 60% of analisis I got an average bitrate of 725971 kbps and a total of 42929736kb of P Frames (but with a minimum of 92 and a max of 97500)... is this a bug only related to the stats viewer or will it screw up something?



:sly:

IMAGE LINK (ftp://we:we@151.26.151.208/weird.jpg)

[sysKin]

Originally posted by poochie2
I'm doing the first pass via xvid1beta3 and I saw the stats telling that @q2 after 60% of analisis I got an average bitrate of 725971 kbps and a total of 42929736kb of P Frames (but with a minimum of 92 and a max of 97500)... is this a bug only related to the stats viewer or will it screw up something?That's just stats bug, I mentioned it somewhere in my signature (about overflows when counting things).

Radek

[silver_cpu]

Fantastic!!

I've been testing out the "turbo" mode, and I must admit that it presents not only a very considerable speed advantage (from 20 to 35 fps first pass over beta2) , this advantage seems to scale as you increase the possible number of B/P frames. I will continue to test this, and post as soon as I determine the results. In any case, thank you very much for the speed-optimized decoder, it's made a huge difference in my viewing experience, and the encoder itself is a wonderful thing, improved by leaps over what it once was. To the Xvid development/release teams: THANK YOU

Edit: grammar

[Rookie]

Hello there!

I also had the flipped image problem. I checked "DirectVobSub Configure / Misc/ Flip Picture Vertically" but the problem still existed.

So i installed ffdshow and now the picture isnt flipped anymore but flickers like hell. :rolleyes:

I only encode movies by and by so i dont know much or better no technical details.

Didnt find anything useful in search function. :eek: :)

[sysKin]

Originally posted by silver_cpu
Fantastic!!What you say is very nice but I have to dissapoint you: 1. Turbo doesn't change the speed of first pass at all (first pass is fast but for a different reason) and 2. We didn't optimize decoder's speed, it's as slow as always (twice as slow as libavcodec).

Thanks for the kind words anyway ;)

Radek

[mikeson]

@Rookie:

So please do it again. These topic were already discussed. Furthermore almost whole this thread is about what you've asked for. :rolleyes:

Anyway...

I also had the flipped image problem. I checked "DirectVobSub Configure / Misc/ Flip Picture Vertically" but the problem still existed.

Use flip function in XviD DirectShow filter.

So i installed ffdshow and now the picture isnt flipped anymore but flickers like hell.
When using ffdshow on clip made with packed bitstream on and more than 1 b-frame in a row (that is default option), only internal DirectShow XviD decoder can decode this stream right. In ffdshow, there is wrong timing ATM...

[Tuning]

Thanks XviD developement team for new SSE2 optimizations. :D

[MajinMarc]

I'm actually making this post in response to all the crap that I just read from wannabe. Your name says it all bub. You wish you knew what you were talking about but rather you are just babling about things without throughly thinking about all the angles. Koepi wasn't trying to bash you but rather give you the more technical side of the problem that you seem to be having. You however made it a point to critisize the entire Xvid team without really knowing what you were talking about.
Ok next on to my comments about the Xvid team. I think your codec is coming along great, alot of quality Improvement. It's amazing how much effort you guys put in seeing as how this is a spare time project. I have a couple of concerns that I think are probably just something I'm doing wrong. I was testing a encode earlier this evening with the pretty basic settings. only thing I added was qpel, adaptive Quant, cartoon mode, GMC. I had a nromal first pass. 6-7fps like always even with the old builds with the same settings, with the exception of cartoon mode. I have used cartoon mode before and haven't had any problems. I was wondering if any of the other 3 modes can have a drastic effect on time....the second pass was moving at 1-2fps or is it just the interaction of one or more of these that slams the speed into the ground. unfortunately my slow ass computer cannot test all of these modes individually on a full length clip...it would take me days to full test these myself and I was wondering if anyone else had similar problems...this is NOT a slowdown due to fast mode cause I didn't even use it so it has to be something else. Thank you

[bond]

Originally posted by Isibaar
So the situation is like this: It was a huge mistake to leave the idct implementation unspecified in the MPEG-4 standard. The requirements that were specified are absolutely insufficient. Autodetecting the idct that was used for encoding (if possible at all) is a rather weak and limited approach to cure idct mismatches. I've already posted some more info about the idct issue here on the forum: http://forum.doom9.org/showthread.php?s=&threadid=56190&perpage=20&pagenumber=6hm as far as i get it most mpeg-4 codecs (xvid, divx5, nd) use walken idct, if i am right with that, thats the quasi standard and decoding should work fine with as good as all mpeg-4 implementations!?

[Mr_G_123]

will hinted me return in the follwing releses of xvid 1.0

[Teegedeck]

Nope.

[Mr_G_123]

REALLY not?:D not even something like hinted me, something original from the xvid team developers.

[Teegedeck]

Do a search on it. Hinted ME is a flawed concept, so it won't return.

[GolovachLena]

Originally posted by Tuning
Thanks XviD developement team for new SSE2 optimizations. :D

Which isn't working actually :( I was wrong at my previous post saying that SSE2 rocks... It rather sucks! MMX+Integer SSE shows more fps than SSE2 on my Pentium-IV. You may try with tests yourself.
Probably we should gather some money to help Koepi buy some P-4 in order to debug SSE2 optimization code... at last! ;)

[Mr_G_123]

Originally posted by Teegedeck
Do a search on it. Hinted ME is a flawed concept, so it won't return.
teanks anyway :D

[dimzon]

//OFFTOP
2GolovachLena
nice nickname :)

[iago]

Hello, ;)

I tried not to post any comments about "Selam" before I gave it a good try with a couple of full movie encodes. After watching the results with a careful eye, I must say that there has been a huge improvement over dev-api-3 and I'm really impressed. It's great work! Thanks a lot! :)

I used the turbo mode (great for my poor pc), h263, vhq1, chroma motion, b-frames 2/1.50/1.00, and an I-frame boost of 10 for the second pass, with a plain avs script without any filtering. 2ndPass/1stPass ratios were something like 2/3.

regards,
iago

(Only one issue I can mention here is that large flat surfaces such as walls still lack stability from time to time. However, I'm glad to see that the irritating black-blocking problem is almost totally gone!)

[Isibaar]

@MajinMarc:

Don't use GMC when you care about speed. It gives no real improvement but results in a significant slow-down in encoding speed. Also qpel is a speed killer as well and especially for cartoon-like content many people don't like it. However if you like it for your encodes then at least select the turbo switch which makes qpel somewhat faster. Apart from that it's normal that the first-pass is faster than the second-pass with Beta3, but your second-pass speed should increase considerably if you follow my proposals.

@bond:
Yes. Also I think that most standalones implement walken idct as well because this should make it easiest to become 'DivX certified'. So walken idct seems best for interoperability between today's existing MPEG-4 implementations.

[drebel]

@iago

You should also try adaptive quantization (old lumamasking).I think you 'll be pleasantly surprised there ;) I know I did.The gain is not that big but in cases which every bit counts...
I'm adressing to you as the "expert" in this old prob.It would be nice to know that Xvid made the use of lumafilter() obsolete, even though it never slowed down the encoding proccess much.

Certain posts mentioned "not that stable walls".Qpel or not?Does catoon mode help finally in this matter?

I ' ve been playing around with the "Usual suspects" movie R1 version : 2cds,ac3 5.1.I 've tried almost every setting available in small tests , even a whole encoding with the method which uses quant 3 for the first pass.I might say I liked a couple of things (IMHO):

- I grasped by the fact (mentioned in the forum by bond IIRC) that the human eye spots more details in vertical axis ,so I resized anamorphically (I tried to avoid resizing at all but I could fit the movie to my target with Andreas matrix).Zoom player does a fine job when Custom AR is selected (2.5:1).The only prob was that when I cropped from inside Avisynth ,there was a frame mismatch (overlapping ?) or something that created strange shadows from previous frames.So , I cropped from DVD2AVI3.

- The method with quant3 in first pass gave me a second pass larger than the first but I liked the quality or the traditional way better (less blocky for my eyes).

Nice first pass speed & quality boost(2nd pass) ,guys.

[kadajawi]

@MajinMarc: I believe the wannabe thing is done, no need to talk about it over and over again.

About your problem: I haven't experienced a speed up since Beta 2, except the fast first pass (twice as fast as the second pass). But as you say that the addition of cartoon mode was the only thing you changed, maybe try without. You don't have to run through the whole encode again, just a few minutes would be enough. 1-2 fps is indeed slow, try Isibaar's suggestions too :) Btw, what CPU do you have?

[mikeson]

@GolovachLena:
It rather sucks...
Probably we should gather some money to help Koepi buy some P-4 in order to debug SSE2 optimization code... at last!
Please learn how to behave on this forum or do not post at all. In your post you are insulting not only Koepi but whole XviD dev team. Furthermore your post has ZERO value as a bugreport.

Take your time, read Koepi's and Teegedeck's posts on previous pages about OpenSource and XviD and think first before you post or do not post.

[GolovachLena]

Take your time, read Koepi's and Teegedeck's posts on previous pages about OpenSource and XviD and think first before you post or do not post.

Forgive me for my bad language, i didn't want to insult anybody, it's merely misunderstanding. I'll read about OpenSource, but how this reading can help me to complain that SSE2 optimization obviously is NOT working? I have a P4 and i'm getting top performance only when i turn SSE2 off and turn on MMX and possibly integer SSE. What kind of bugreport can i provide except of empirical testing? Xvid doesn't crash or somewhat, it just works slower than it can.

[mikeson]

@GolovachLena:
I have a P4 and i'm getting top performance only when i turn SSE2 off and turn on MMX and possibly integer SSE
For this reason there is option in GUI to specify exactly which optimizations do you want to use.

If you are geting poor performance, disable CPU consuming features like Chroma motion, VHQ4, GMC a/o Qpel (although I wouldn't recommend disabling them), but this was already discussed here...

XviD is still evolving and in the first place there is stability and image quality, speed comes next.

Read here (http://forum.doom9.org/showthread.php?s=&threadid=24924) how to post bugreports.

[Mole]

Does the "Turbo Mode" has any impact on file size or quality?

[Koepi]

Mole:
yes, it has a small impact, quality may be a little lower, size a little bigger. But not much noticable.

Regards
Koepi

[dimzon]

Originally posted by Koepi
Mole:
yes, it has a small impact, quality may be a little lower, size a little bigger. But not much noticable.

What does it mean: not much noticable?

[Koepi]

dimzon:

just test it on a 1000 frames sample you like for yourself - once with turbo, once without. You need to judge for yourself.

Regards
Koepi

[N-Bomb]

What might be another bug with FFDShow and the new beta (don't see anyone else mentioning it)

I disabled packed bitstream and it seems that with this latest test encode, it starts the video with a few (looks like 2) frames from the end of the file, before moving on to the episode proper.

Actually, maybe not a bug with FFDShow, tho it goes away when using the XviD Dshow... in Virtualdub, those two frames from the end are there. This is very wierd. Anyone have a similar problem, or a solution?

Thanks!

[assa69]

hello everyone one

i just downloaed this build and i am using virtualdubmod version 1.5.10.1 but i started to have probelms like some of the clips i encoded using beta 2 apearing upside down and what is worst virdubmod stoped encoding now totally i mean when i hit the button to start encoding virdubmod crashs same thing is happing with virtualdub too why this happing

was there a bug in beta 2 and did i lost all the clips i encoded using beta 2.?

i am new to this all i started encdoing 2 weeks ago so i am sorry if this was obivious this thing to ask

thanks

[Stux]

Originally posted by Isibaar
Unfortunately that's not true. I implemented the 132 inter MB refresh period as well as all the other additional requirements to IEEE 1180 that are specified in the MPEG-4 standard. But: it didn't help. To avoid visible mismatch between simple idct and walken idct (which are both perfectly compliant btw) you'd need a refresh interval of about 20 inter MBs. However this would mean a huge loss in compression performance.

So the situation is like this: It was a huge mistake to leave the idct implementation unspecified in the MPEG-4 standard. The requirements that were specified are absolutely insufficient. Autodetecting the idct that was used for encoding (if possible at all) is a rather weak and limited approach to cure idct mismatches. I've already posted some more info about the idct issue here on the forum: http://forum.doom9.org/showthread.php?s=&threadid=56190&perpage=20&pagenumber=6


Yes, its a serious problem, and qpel just makes it worse

[assa69]

Stux


Do you have the same probelm .....???

[MajinMarc]

@all who responded to my last post.
Yeah I did notice that GMC decreases speed. but I did notice better quality with qpel. Fast first pass actually hasn't done anything for me. I have seen a 1fps increase in most of my AVs scripts. but even if I run a base encode with no filter, no cropping, no resizing I max out at 11fps...which I find strange seeing as how I get 25fps with divx...I don't like divx which is the reason I use Xvid. my current PC stats are as follows.
Dell inspiron 4100
P3 1.3 Ghz
256MB DDR
32MB Video Card.

This works fairly well I know it's a little weak but when I encode I do so with almost nothing running in the background. I have seen a system that is only 200mhz stronger than mine pull almost 12fps faster. If I remember correctly the Xvid codec is athlon optimized maybe this could be part of the reason. Is there any chance that the Xvid team will be making a Intel Optimized version...cause after referring with my friend a few seconds ago actually he has a dual p4 2.3HT and he only gets double the framerate and nowhere near the speed of the doom9 codec comparrisons 32fps.

Thanks for the input.

[Teegedeck]

Welcome, assa96.

First of all, please use proper punctuation, your post is hard to read.

Stux didn't comment on your problem, not even on an XviD-problem; he's talking about a flaw of MPEG4 standards.

My guess would be that you've accidentally entered non-existing values in the zones, or don't point to the correct .stats-file in 2nd pass. If this ain't the case: Does encoding with other codecs still work? Give us some details about your setup.

[Mr_G_123]

will nic or umaniac release some of their own version/modifactions to xvid 1.0 binary?
or (the mighty :D) koepi will do all the job (what a wonderfu job:D ).

[Koepi]

Nic will compile builds soon, too. He hasn't found the time recently due to his job, rejig,...

uManiac seems to have left for nearly a year now :-(

Regards
Koepi

[assa69]

Teegedeck

thanks for your concern and i am sorry for the misunderstanding

to makes things clear

i use single pass bite rate at max.

mothion search at 6

vhq at 4

and quantization type h263

now the porbelm is

some of the clips (not all) that I encoded using xvid build beta 2 are starting to apear up side down

about the crsah probelm i reinstalled xivd build beta 3 and virtualdub stoped crahsing now but the probelm of the clip apearing upside down is still exist

i didnt try to encode anythin using this build yet but i only encoded one of the clips that were apearing up side down again using build 3 hoping that it would correct the probelm but it didnt work the new result stil apears up side down

i also noticed (but thats not now but some time a goand has nothing to do with my probelm) that the clips you encode using xvid compression still can be played after you uninstall xvid from you computer but the player see the clips as divx file is this normal or what.?

[mikeson]

@assa69:

Have you read whole thread? I guess not because Koepi explains this in this very thread. So please read it from the beginning (and especially page 3) and next time use Search function more intensively.

[Assault]

@ assa96

In addition to mikeson's reply: you should stop posting all your questions twice. You already posted both your VDub/upside down problem and your observation that xvid files can be played back by the divx decoder in that thread (http://forum.doom9.org/showthread.php?s=&threadid=67563).

Assault

[dbzgundam]

I don't get it, how is everyone getting such high speeds with all those settings turned on?!!!

I'm using VHQ1, Motion 6, Chroma on/off = same speed, HVS good/H.263, Qpel, No GMC, Bvops, and two pass mode.

On both passes it runs at maybe 4 fps.

My filters are:

AVIsource(...)
LanczosResize(800, 600)
Awarpsharp(depth=20)
tweak(bright = -1, cont = 1)
textsub(...)
textsub(...)

Those filters shouldn't be too demanding...and why would they cut the speed down so much. I'm running a 1.3GHz Athlon (unclocked from 1.7GHz...I don't wanna bother explaining why)

[vinetu]

I don't get it, how is everyone getting such high speeds with all those settings turned on?!!!


dbzgundam

Your resolution is 800x600 - its near HDTV :)

[dbzgundam]

even when it's left at 640x480..not an increase.

[K-Dash]

Well, it kinda depends on your hardware.
Like I have XP2500+ Barton OCED @ 10x218FSB with Twinmos Winbound PC3200 2-2-2-11 and WD80GB with 25-26fps w/o filters or
XP2500+ Barton OCED @ 10x200FSB with Twinmos Winbound PC3200 2-2-2-11 and WD80GB with 18-20fps.

Tested on "Good times, bed times."
Unrestricted Profile
Single Pass
Target Bitrate 1000
Standard options
Chroma Motion, Chroma Optimizer
I/P/B Settings normal

[vio]

eh, just a cosmetic thing here, would it be possible to move the "Load Defaults..." button away from "OK"?

I just set up the codec and went to hit ok, missed.

Testing the codec on Jurassic Park, not doing so good. But then again neither did divx5, I'll play with it some more.

[MajinMarc]

@dbzgundam and others.
Well I just got done with another test and even when I use the default codec setup I'm surprised to say that the speed definitely crashes in the second pass even when turbo is off I have noticed that the speed drops dramatically in speed in comparrison to the last unstable build of Xvid. Usually I base my AVS script at 6-8fps in both passes on the dev-api-3 build. The same avs on the current build of xvid produces slower and sometimes uglier results. With that said I thinkt here are some minor errors I have found with my own encodes. Using it on Dragonball Red ribbon Saga Episodes I have managed to find an interesting "film Reel" image showing up in the upper left hand corner of the image when tried with Xvid 1 Beta 1 2 or 3. All testing is done with the exact same AVS and same settings for the codec. I haven;t been able to determine the problem as I have tried changing settings, using a basic crop and resize only script, changed Resolutions. Left off cropping and still the same result. If anyone knows of a good capture program I would like to take some Screenshots so I can post them as an example.

[MajinMarc]

Hello Fellow Xvid users. I know this may not be the best place to put this but I thought it'd be best to wish everyone on the development team(this basically includes everyone who posts on this board because everyone who posts has some sort of contribution to id errors or experiences that help make Xvid better) a very Happy New year. With this new year comes a promise of better encoding methods, codec improvements and lots more feedback. Good luck to everyone and once again have a happy new Year.

[cweb]

Happy New Year to everyone.

I'm testing the Selam build by Koepi (thanks!) and I'm happy to say that this build doesn't cause (or effect) a crash with TMPGENC after it encodes an MPEG1 using Avisynth (the previous build was doing this, I had posted earlier about it). So whatever it was it's been solved, and thanks again.

[cweb]

Originally posted by riggits
@wannabe:

there's a fairly clear disclaimer on the official xvid page explaining that backward compatibility isn't on the agenda, and that xvid is an alpha or beta status project designed to implement the mpeg4 specs. in other words, it's not perfect, and older movies just might not work. too bad 4 u. no need to be a dink about it, esp. since it's clearly stated on xvid's website.

In fact when I encode something using XviD and put it on a CD, I always put the corresponding codec for possible future use..

[cweb]

Originally posted by kadajawi
yes, smells. But it is not a proof, for sure there are legal encodes using XviD which are freely distributed on the internet.

For instance I have put my footage (I own it) from the local EU referendum celebrations from last year, encoded using XviD, freely available for download (but not redistribution obviously).

[cretin]

Yeah and what about commercials and free short films by indy filmmakers ? Some short films can have AC3 sound, today everybody can make AC3 athome, you cant strike down somebody because you think he is "suspicous", you are not God you know.

Heh Heh, so it turned out that you have no real proof against him but he had to be banned from the forum by some unfair moderator. And after all the last few pages are discussing the project that he brought up, and it turned out to be pretty serious. Nice job, next time ppl will think twice before they bring up a serious problem
in the fear of that they get suspended from forum just to quiet them.
Happy New Year.

[temporance]

Originally posted by cweb
Originally posted by kadajawi
yes, smells. But it is not a proof, for sure there are legal encodes using XviD which are freely distributed on the internet. For instance I have put my footage (I own it) from the local EU referendum celebrations from last year, encoded using XviD, freely available for download (but not redistribution obviously).For instance I have put my footage (I own it) from the local EU referendum celebrations from last year, encoded using XviD, freely available for download (but not redistribution obviously). "Legal encode using xvid" is an oxymoron. AFAIK, no-one has yet found a way of using xvid that doesn't either
(a) violate GPL, or
(b) infringe the MPEG-4 patents.
Most xvid users are doing (b) which in practice is probably OK for individuals that don't publish their encodings. If you publish something encoded using xvid it could be used as proof that you used an unlicensed encoder.
IANAL

[jang0]

:confused: :confused:

I thought Xvid is legal outside the USA and Japan !?

btw: What about DXN? Do they pay royalties for MPEG4?

[bond]

i doubt that you infringe any patents or licenses when you only encode using any mpeg-4 codec (if it were so every divx5 or 3ivx user would have to pay for using these 100% legal codecs, what definitely isnt the case)...
afaik not the users have to pay to the patent holders for a codec that uses these patents but the codec manufacturers have to (as xvid is only for educational purpose they dont have to pay for spreading the source code)

what you are not allowed to do as a user would be to spread these encodes afaik (independantly if you own the rights on the video source), but i am not sure if this also is the case if you dont charge anything for them...

[Stux]

Originally posted by bond
i doubt that you infringe any patents or licenses when you only encode using any mpeg-4 codec (if it were so every divx5 or 3ivx user would have to pay for using these 100% legal codecs, what definitely isnt the case)...
afaik not the users have to pay to the patent holders for a codec that uses these patents but the codec manufacturers have to (as xvid is only for educational purpose they dont have to pay for spreading the source code)

what you are not allowed to do as a user would be to spread these encodes afaik (independantly if you own the rights on the video source), but i am not sure if this also is the case if you dont charge anything for them...

There are MPEG "use" fees in some situations, most normal users probably wouldn't qualify.

It essentially comes down to is the use "for profit" and not "promotion"

IANALE, consult your assigned MPEG-LA representative ;)

[seewen]

I already told it with Beta 1, but I re-write it again:

You should let user define the MAX bitrate.

Beta 3 is unusable with KISS DP-450.
(In fact 99% of the movie is ok, but the player freeze when bitrate > ~4'000).

I really don't understand why devloppers (who made a great/huge job, that's not the point) doesn't listen to user swho ask for this feature since few month.

Bye, and thanks for all other features ;)

[Doom9]

@seewen: I can't locate it right now but I know that bitrate caps have been mentioned before and the answer was: not for XviD 1.0. It's not as simple as you think.. you also have to take care of VBV buffering requirements for the various MPEG-4 profiles. A simple bitrate cap wouldn't help your standalone much.

[Chainmax]

I get less than 1fps when encoding a DVD rip with the following AVS script:

mpeg2source("C:\MPEG-4\La Naranja Mecánica\ClckWrkOr.d2v")
Crop(0,48,720,380)
SeparateFields()
VagueDenoiser(threshold=2,method=1,nsteps=4,chroma=true)
Weave()
Telecide(order=1,guide=1,post=1,hints=true)
KernelDeint(order=1,sharp=true)
Decimate(cycle=5,quality=3)
Undot()
MipSmooth(preset="movieHQ")

And the following XviD settings: VHQ1, MSP 6, b-frames @ 2/1.50/1.00, Trellis, adaptive quant and turbo mode.

On an 850Mhz Athlon with 160Mb PC100 ram. With similar settings, devapi3 usually yielded me 3 to 6 fps. So, is this behaviour normal? Are there any further speed optimizations planned for the future or will I just have to upgrade my PC :(?

[Blue_MiSfit]

@Chainmax -

Yeah I think your hardware is to blame. That is a wicked avisynth script, and I am not surprised at all that you are only getting 1fps. I average 12-20 or so on secondpass with beta3 on my system (see below) which is probably several orders of magnitude faster than yours ;) Not to mention, I only use undot in my scripts in addition to crop and resize.

I think its time to upgrade. You would be amazed, its a lot cheaper than you think (nforce2 board, 2500+, 512mb ddr400 ram for less than $250 at newegg.com ;))

good luck.

[Blue_MiSfit]

also, about the stupid fool who didnt know how to deal with the audio track...

It is possible (however unlikely) that he got the file in a legitimate manor. However - suppose the following scenario.

What does the average AOLamer do after he downloads a rip off kazaa, and discovers he cant play the audio? Well he yells at his computer because "ITS AVI!!! UR SUPPOSED TO KNOW HOW TO PLAY AVI!!!! ALL MY OTHER AVIS WORK FINE!!!" then he starts googling around for DVD ripping, and surely enough he finds (the finest in the business to be sure) doom9. So he comes in here and starts asking questions.

Anyways... Sort of a rant against n00bs... but yeah I think he was a little kazaa-downloading bastard and banning him was a very good move ;)

~misfit

[cretin]

He did not say that he got it on kazaa, and its filename was dvdrip.illegalgroup, and unless he would say so, u cant ban him, because you have no proof. BTW the one who complained about the AC3 did not get banned just thread closed.

[sysKin]

Originally posted by seewen
I really don't understand why devloppers (who made a great/huge job, that's not the point) doesn't listen to user swho ask for this feature since few month.You do understand thsat your question can be rephased as "I asked for VBV ratecontrol but developers didn't drop out of school/work and didn't spend all the weeks they had to implement it"?

In other words: if you know how to do that, do that. I don't.

Radek

[cretin]

Well the KISS DP-450 is not DivX Certified at Home Theater level (up to 10000 kbps max bitrate) so dont get surprised if it doesnt work. But i would be really pleased if someone would let us know if the new beta plays on the KiSS DP-500 or some other Home Theater standalone because thats the real goal.

[MajinMarc]

Well since it seems this board has become a place to complain I'm gonna respond to all the people who complain about other users getting banned, as well as the people who said that Xvid developers aren't paying attention......F%ck you. Stop your god damn whining and ask some real questions or give comments about the codec in terms of how it can be improved....aka suggestions are always looked at but not always implemented. if you want a specific feature make it yourself. So if you can't do that stop complaining about it. Now if you find a bug or you think something is wrong make sure you describe your situation. Everything from your AVS to all the Xvid settings your using...yes they know there are still some bugs in it...yes they are trying to fix the major ones first....yse they know about alot of the problems already....aka look at syskin's posts and he has a giant ass list of complaints and problems that they are already aware of. Remember that these guys do this stuff in their free time and if you don't like the progress I'm gonna once again tell you to Make your own version of Xvid...then see how "easy" it is before you complain about something. Thank you and all you guys have a happy New year.

Sincerely,
A disgruntled poster who has seen like 4 pages of just random shit that has nothing to do with the codec other than complaining about something that is irrelevant

[Xndo]

I'm going to agree with marc on this, I've read about 5 pages of mindless dribble over "this is what should be in there" and blah blah blah, i think i read the same post by 5 people so far, and its just crap. Give them some time folks, they can only work as fast as they can. I also remember seeing posts over "turbo". Personaly its a nice idea, but losing quality to gain speed isn't a good idea, who cares if something takes longer to encode at least you know the quality is there, so just chill out and let the xvid team work on "real issues". I thank all of the Xvid Team for putting so much work into this. So give them a break and stop whining about every little thing.

[Gaia]

Originally posted by cretin
Well the KISS DP-450 is not DivX Certified at Home Theater level (up to 10000 kbps max bitrate) so dont get surprised if it doesnt work. But i would be really pleased if someone would let us know if the new beta plays on the KiSS DP-500 or some other Home Theater standalone because thats the real goal.

Just try it yourself.

Only thing i can say is i have DP-1000 and i don't have any problems with latest XviD 1.0 beta. In normal encodes bitrate never goes as high as 10000 kbs. Only problem is that bitrate might rise too fast. That usually happens only in 2 cd rips. Packed bitstream seems to work too.

Few days ago i tried to play few movies encoded with early XviD builds and i didn't have any problems.

[cweb]

Originally posted by temporance
"Legal encode using xvid" is an oxymoron. AFAIK, no-one has yet found a way of using xvid that doesn't either
(a) violate GPL, or
(b) infringe the MPEG-4 patents.
Most xvid users are doing (b) which in practice is probably OK for individuals that don't publish their encodings. If you publish something encoded using xvid it could be used as proof that you used an unlicensed encoder.
IANAL

In any case as far as I'm aware there's no local law which applies to the above (using encoders is not covered), plus it's not for commercial use (call it educational if it helps people get to use and experiment with XviD).

[cretin]

MajinMarc: Ok you can stop asskissing now, i doubt that the xvid devs would need that, but thank you for your efforts anyways.

[Arcon]

i just encoded a file with beta3 with these settings:

quant: mpeg
adaptive quantization
motion search: 6
vhq: 1
chroma motion
trellis
rest of the settings are default.

target size 1116616k

the output is 1108952k (the first time ever that xvid undesized by more than a few 100k). i did the 2nd pass a second time with a target size of 1124616 and the result was 1116892k, so there seems to be room to reach this size with these settings but somehow xvid undersizes by ~8mb. this is the avs i used:
LoadPlugin("mpeg2dec3.dll")
LoadPlugin("FluxSmooth.dll")
mpeg2source("my.d2v")
crop(10,2,706,476)
FluxSmooth(6,7)
LanczosResize(640,352)

don't know if you need any additional info (or even know what causes this and will have it fixed with the next release).

[Koepi]

Arcon,

can you retest the 2nd pass with setting iframe boost to 5 (or 10) percent and report back?

Thank you,

Regards
Koepi

[Chainmax]

Blue_MiSfit: I don't think my script is that heavy. KernelDeint is there in place of Telecide's default postprocessing, and Undot+Smoother seems to be a widely used combination on scripts around here. Only VagueDenoiser could be considered an extra load and even there the number of nsteps is reduced so as to keep CPU usage as low as possible.
Maybe the low speed I sense comes from the fact that I used to have 256MB of PC133 ram and now I have 160MB of PC100 ram (long story). In any case, I do want to upgrade my PC, but newegg.com doesn't accept international CCs and stuff is way too expensive here in uruguay (an Athlon XP 2500+ goes for ~140 bucks) :(.

[Blue_MiSfit]

it's not too bad... try an encode with just resize and undot... if its way faster then we'll know...

Anyways abot not being able to get parts yeah tahts a real bitch. a real bitch. I would say scour on resellerratings.com and try to find a reseller that will ship internationally...

best of luck

~misfit

[Arcon]

Originally posted by Koepi
can you retest the 2nd pass with setting iframe boost to 5 (or 10) percent and report back?

now i used an iframe boost of 7%, target size was 1116616k, result is 1108874k, so again ~8mb undersized.

[Koepi]

arcon:

do you have any zones defined with fixed quantizers (in the first pass)?

Regards,
Koepi

[Arcon]

Originally posted by Koepi
do you have any zones defined with fixed quantizers (in the first pass)?

i've got 2 zones, but both have a weight (1.0 and 0.4). the second one is grayscale. so no fixed quantizers.

[Koepi]

Weight zones still are buggy - don't use them, they destroy size predictability.

like i wrote in the _very first post_ of this thread: Known bugs (do not report them):
- Weight zones don't work properly - if you need zones, use quant zones instead.

Regards
Koepi

[cretin]

I made some tests with 2 and 3 consecutive B frames with the following settings:
Everything was the same except the B frame settings which were
2/1.50/0.75
3/1.50/0.75

The resulting avi-s were identical, both had the same amount of B frames, i even made a "compare by content" with windows commander and the two files were 100% identical. I would like to know if is this normal, or is there any way to force to codec to make more B frames ?(maybe the BVOP sensitivity in Zone controll ??) Its just allowing 3 bframes should have some advantage over 2 B frames by default or not ?

[mikeson]

@cretin:
is there any way to force to codec to make more B frames ?(maybe the BVOP sensitivity in Zone controll ??)
Yes, increase BVOP sensitivity to get more b-frames. Anyway setting Max consecutive BVOPs works for me. What does stats file say?


When you set BVOP sensitivity to 90, you will always get amount of b-frames specified in Max consecutive BVOPs

[sysKin]

Originally posted by cretin
maybe the BVOP sensitivity in Zone controll ??Exactly. I answered similar question not a long time ago.Its just allowing 3 bframes should have some advantage over 2 B frames by default or not ? [/B]When I tuned the b-frame decision, it turned out that the average PSNR of all frames is higher with one b-frame, then almost identical with the second (at its best thresholds I could find) and then again identical with the third - again at its best thresholds, which turned out to be so low, that 3rd b-frame is quite rare.

B-frames have some other advantages, mostly making the stream more robust to data corruption, DCT mismatch, and so on. In most cases you should use either 1 or 2, I can't really tell the difference. If you're going to write to XCD, or play at standalones (iDCT mismatch possible) you might want to use 3 with higher sensitivity (5..10). Some lossy radio channels would probably work even better at higher settings ;)

Default decision aims at maximum PSNR and as a result, inserts 3rd b-frame very rarely.

Radek

[symonjfox]

And what appends if I set 15 or more consecutive b frames?
In theory the I P B decision should never use 10 consecutive b frames, and the final stream will have the right amount of b frames that are needed for this GOP? Am I right?

PS: The very first time I used xvid (some time ago) I set max bframes at 10, I made a small encode, but it worked well and it was played back perfectly. The quality was good. But then I read lots of guides, forums, Doom9's Forum :D and I always set it to 2 or 3.

PS2: I'm making a small test ... gimme 30 minutes and I'll back

I set 15 consecutive B frames.

[Koepi]

you can set more bframes, but with defaults, you'll get max 3 bframes in a row anyways. so it should b safe to use higher values.

Unfortunately i discovered that some encodes _do_ look better when only using 1 bframe max. (i.e. matrix).

Regards
Koepi

[mikeson]

@Koepi:
Unfortunately i discovered that some encodes _do_ look better when only using 1 bframe max. (i.e. matrix).
Have you discovered any 'rule' that describes on what sources (dark/noisy as Matrix is) is better to use 1 bframe instead of 2?

[Koepi]

I think it depends on the noise in the source. But i didn't make extensive tests yet.

Regards
Koepi

[symonjfox]

Results:
AVS:LoadPlugin("C:\Programmi\Avisynth 2.5\plugins\mpeg2dec3.dll")
Mpeg2Source("VTS__01_P01.16~9_1.d2v",idct=7,ipp=false, CPU=5)
Crop(8,16,-8,-16)
Lanczosresize(544,544)
Lengh 6:40

Xvid: 2 passes, 700 kbs average (to test b frames with medium-low bitrate).
All defaults except 15 max B frames, No packet bitstream, AR 16:9, VHQ 1.

Results: 33 MB, Visual quality is good, but in my opinion not so much (maybe the 544*544 res?), there are no defects or problems while playing (tried Nero decoder and FFDshow).
I opened pass.stat using StatsReader. It surprised me: for example there was a very dark scene and in this scene there was 1 GOP composed by 1 I, 15 B, 1 P, 15 B, 1 P and 15 B! Bitrate in this scene was very low.
In the rest of the clip, the encode is quite normal: 1 or 2 max consecutive bframes. Sometimes I found 3 or 4.

Conclusion: I think that setting 15 or 20 Max B frames can be a good way to improve low bitrate encodes, or a good way to store more than 120 mins in 1 CD with decent quality. Maybe playing with the BVOP sensivity would help (for example -5 -10 for high quality encodes and 5 10 15 for low bitrate encodes).

[Arcon]

Originally posted by Koepi
Weight zones still are buggy - don't use them, they destroy size predictability.
sorry, i didn't remember that.

[MajinMarc]

I just did a test using Adaptive Quantization and I have to say that I am quite impressed. I used it on Rurouni Kenshin OVA ACT 1 and it decreased the size dramatically without losing quality. However I did notice that if I use it in conjunction with Warpsharp it produces funny results. Oftentimes a wierd gray block would apear in the middle of a completely back part. I'm not exactly sure why this is yet but I'm going to continue testing different settings to see if I can isolate the problem.
By the way jsut because I'm curious and have yet to try, in the old version of Xvid there was a little note about B-frames having a quality lowering effect. Is this still true for beta-3?

[mikeson]

@MajinMarc:
in the old version of Xvid there was a little note about B-frames having a quality lowering effect. Is this still true for beta-3?
Not exactly. B-frames are frames with higher (mostly) quantizer than I and P frames, so quality of B-frames is a little bit worse than I and P frames, but overall movie quality is better because more bits are spared for problematic scenes. Do a Search on B-frames, there are many threads explaining them in depth.

[sh0dan]

There IS problems with the Xvid Dshow decoder and colorspaces.

1) (very obvoius) The force-list is upside down. Forcing YV12 forces it to RGB24, selecting RGB24 actually forces YV12. YUY2 and RGB32 is also swapped.

2) YV12 also selects IYUV.

3) Flipped video. This is NOT a hardware issue.

If you have the time, you should have another look at it, and try making it a bit more reliable. Many problems emerge from using ffdshow in "Raw Mode", but it _is_ working on a bunch of other dshow filters. The video is flipped in both YUY2 and YV12, which suggests the XviD decoder is doing something funky that other filters aren't.

[happy_harry]

@sh0dan: Are you sure you're not using dvobsub?
dvobsub causes some problems on my winxp with xvid1.0b3.

[sh0dan]

@happy_harry: Yes - it is not loaded into the filter graph. And the problem persists, if I construct the graph manually in graphedit.

[Leak]

Originally posted by sh0dan
@happy_harry: Yes - it is not loaded into the filter graph. And the problem persists, if I construct the graph manually in graphedit.

Strange - I just tested it in Graphedit, and the only time I'll get an upside down picture is when DirectVobSub is loaded. If I disable it, XviD will be connected directly to the VMR9 renderer and all is peachy, be it RGB, YUY2 or YV12. Oh, and you're right, the list in the combobox is totally upside down as well. :)

Of course, just checking the "flip picture vertically" checkbox in DVobSub fixes this, but it's still strange, as it never happened with ffdshow using any output colorspace.

np: Static/Justine Electra - Inside Your Heaven (Flavour Has No Name)

[Nicholi]

And now for something completely different.

Ran across a very strange error during the 2nd pass of my happy anime encode.

XviD settings: (otherwise default besides these specified)
BVOPs: Off completely.
Chroma Optimizer: On
VHQ Mode: 0 - off
Max I-frame interval: 230

The encode itself is also using VFR if that matters at all (was planning to plug it into Matroska all nice and happy like), though I wouldn't think so. The first pass finishes quite nicely in under 30 min from the huffy avi with a size of 169,216,000 bytes. Seems to play normally and has no problems.
As I've read the 1st pass (in 2pass mode) of beta3 is no longer the same full quality as it used to be and a 2nd pass should be followed. So I did so entering 180,000 kbytes as my desired size and let it whir on. Vdub (1.5.10 build 18160) died at frame 1868. I tried a 2nd pass again only to fail. My good friend Gizmo suggested it may be the stats file so I ran another 1st pass and it died again at the same place on the 2nd pass.

Here is VDub's lovely crash message which has literally no meaning to me.

VirtualDub crash report -- build 18160 (release)
--------------------------------------

Disassembly:
01701460: 48 dec eax
01701461: 0cc7 or al, c7
01701463: 40 inc eax
01701464: 1000 adc [eax], al
01701466: 0000 add [eax], al
01701468: 00ba01000000 add [edx+01], bh
0170146e: 8955f0 mov [ebp-10], edx
01701471: 8d93e8000000 lea edx, [ebx+e8]
01701477: 8b4df8 mov ecx, [ebp-08]
0170147a: 52 push edx
0170147b: 51 push ecx
0170147c: e867c6ffff call 016fdae8
01701481: 83c408 add esp, 08
01701484: 8b55f8 mov edx, [ebp-08]
01701487: 8b4df4 mov ecx, [ebp-0c]
0170148a: 52 push edx
0170148b: 51 push ecx
0170148c: e857c6ffff call 016fdae8
01701491: 83c408 add esp, 08
01701494: 8b8b14450100 mov ecx, [ebx+14514]
0170149a: 8b9318450100 mov edx, [ebx+14518]
017014a0: 899314450100 mov [ebx+14514], edx
017014a6: 8b55d0 mov edx, [ebp-30]
017014a9: 898b18450100 mov [ebx+14518], ecx
017014af: 899320450100 mov [ebx+14520], edx
017014b5: 89b31c450100 mov [ebx+1451c], esi
017014bb: be01000000 mov esi, 00000001
017014c0: ff8324450100 inc dword ptr [ebx+14524]
017014c6: 8975f8 mov [ebp-08], esi
017014c9: 8b4d90 mov ecx, [ebp-70]
017014cc: 8bd1 mov edx, ecx
017014ce: 83e207 and edx, 07
017014d1: 743c jz 0170150f
017014d3: 2bca sub ecx, edx
017014d5: 83c108 add ecx, 08
017014d8: 83f920 cmp ecx, 20
017014db: 894d90 mov [ebp-70], ecx
017014de: 722f jc 0170150f
017014e0: 8b5588 mov edx, [ebp-78]
017014e3: 8b4d94 mov ecx, [ebp-6c]
017014e6: 895584 mov [ebp-7c], edx
017014e9: 8b7108 mov esi, [ecx+08] <-- FAULT
017014ec: 8975d8 mov [ebp-28], esi
017014ef: 8b45d8 mov eax, [ebp-28]
017014f2: 0fc8 bswap eax
017014f4: 8945d8 mov [ebp-28], eax
017014f7: 8b55d8 mov edx, [ebp-28]
017014fa: 8b4d94 mov ecx, [ebp-6c]
017014fd: 83c104 add ecx, 04
01701500: 895588 mov [ebp-78], edx
01701503: 8b7590 mov esi, [ebp-70]
01701506: 83c6e0 add esi, e0
01701509: 894d94 mov [ebp-6c], ecx
0170150c: 897590 mov [ebp-70], esi
0170150f: 8b936c450100 mov edx, [ebx+1456c]
01701515: 85d2 test edx, edx
01701517: 0f8434030000 jz 01701851
0170151d: 83bb2845010000 cmp dword ptr [ebx+14528], 00
01701524: 0f8400060000 jz 01701b2a
0170152a: 8b4df0 mov ecx, [ebp-10]
0170152d: 85c9 test ecx, ecx
0170152f: 0f85ea050000 jnz 01701b1f
01701535: 85ff test edi, edi
01701537: 0f85c9010000 jnz 01701706
0170153d: bf01000000 mov edi, 00000001
01701542: e95bfbffff jmp 017010a2
01701547: 8d4412e8 lea eax, [edx+edx-18]
0170154b: 8b7d84 mov edi, [ebp-7c]
0170154e: baffffffff mov edx, ffffffff
01701553: d3ea shr edx, cl
01701555: 8955e8 mov [ebp-18], edx
01701558: 85c0 test eax, eax
0170155a: 7e79 jle 017015d5
0170155c: 237de8 and edi, [ebp-18]
0170155f: 8b db 8b

Windows 5.1 (Windows XP build 2600) [Service Pack 1]

EAX = 01a00e50
EBX = 01a00d80
ECX = 00eebff8
EDX = 00000000
EBP = 0306f080
DS:ESI = 0023:00000001
ES:EDI = 0023:00000000
SS:ESP = 0023:0306f004
CS:EIP = 001b:017014e9
FS = 003b
GS = 0000
EFLAGS = 00010246
FPUCW = ffff027f
FPUTW = ffffaaaa

MM0 = cfcfcfcfcfcfcfcf
MM1 = cfcfcfcfcfcfcfcf
MM2 = cfcecbc8c8cbcdcd
MM3 = 00cf00ce00cb00c8
MM4 = cf81cf7bcf81cf7b
MM5 = cf81cf7bcf81cf7b
MM6 = cf81cf7bcf81cf7b
MM7 = cf81cf7bcf81cf7b

Crash reason: Access Violation

Crash context:
An out-of-bounds memory access (access violation) occurred in module 'xvid'...

...while decompressing video frame 1868 with "XviD MPEG-4 Codec" [biCompression=44495658] (VideoSource.cpp:1567)...

...while running thread "Processing" (thread.cpp:120).

Thread traces:

Thread 00000bcc (Main thread)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1786)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1768)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1786)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1768)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1786)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1768)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1786)
C:\p4root\dev_stable\VirtualDub\source\FilterSystem.cpp(569)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(618)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(648)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1768)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1786)
C:\p4root\dev_stable\VirtualDub\source\FilterSystem.cpp(429)
C:\p4root\dev_stable\VirtualDub\source\FilterSystem.cpp(569)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(618)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(648)
Thread 00000f28 (FastWriteStream)
Thread 00000308 (Processing)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1598)
C:\p4root\dev_stable\VirtualDub\source\Dub.cpp(1946)
C:\p4root\dev_stable\VirtualDub\source\VideoSequenceCompressor.cpp(389)
C:\p4root\dev_stable\VirtualDub\source\VideoSequenceCompressor.cpp(406)
C:\p4root\dev_stable\VirtualDub\source\Dub.cpp(2103)
C:\p4root\dev_stable\VirtualDub\source\Dub.cpp(2143)
C:\p4root\dev_stable\VirtualDub\source\Dub.cpp(1941)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1563)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1598)
C:\p4root\dev_stable\VirtualDub\source\Dub.cpp(1946)
C:\p4root\dev_stable\VirtualDub\source\VideoSequenceCompressor.cpp(389)
C:\p4root\dev_stable\VirtualDub\source\VideoSequenceCompressor.cpp(406)
C:\p4root\dev_stable\VirtualDub\source\Dub.cpp(2103)
C:\p4root\dev_stable\VirtualDub\source\Dub.cpp(2143)
C:\p4root\dev_stable\VirtualDub\source\Dub.cpp(1941)
C:\p4root\dev_stable\VirtualDub\source\VideoSource.cpp(1563)
Thread 00000e50 (Dub-I/O)

Thread call stack:017014e9: xvid!xvid_decore [016f0000+9f68+7581]
016f9ff3: xvid!xvid_decore [016f0000+9f68+8b]
016f1d03: xvid!00001d03
016f9f99: xvid!xvid_decore [016f0000+9f68+31]
016f231e: xvid!0000231e
016f8977: xvid!DriverProc [016f0000+873c+23b]
77f7e358: ntdll!RtlInvertRangeList [77f50000+2e26c+ec]
77f7e358: ntdll!RtlInvertRangeList [77f50000+2e26c+ec]
77e7b063: kernel32!GetModuleFileNameA [77e60000+1ada9+2ba]
77e7b085: kernel32!GetModuleFileNameA [77e60000+1ada9+2dc]
77e7aeb7: kernel32!GetModuleFileNameA [77e60000+1ada9+10e]
77f944a8: ntdll!RtlRemoteCall [77f50000+442ea+1be]
77f944a8: ntdll!RtlRemoteCall [77f50000+442ea+1be]
77f57f98: ntdll!RtlAllocateHeap [77f50000+7bae+3ea]
77f58a3a: ntdll!RtlAllocateHeap [77f50000+7bae+e8c]
77f944a8: ntdll!RtlRemoteCall [77f50000+442ea+1be]
77f58497: ntdll!RtlAllocateHeap [77f50000+7bae+8e9]
77f57f98: ntdll!RtlAllocateHeap [77f50000+7bae+3ea]
77f58a3a: ntdll!RtlAllocateHeap [77f50000+7bae+e8c]
77d44d8f: USER32!ClientThreadSetup [77d40000+4d57+38]
77f5b554: ntdll!NtAllocateVirtualMemory [77f50000+b548+c]
77f834de: ntdll!RtlSizeHeap [77f50000+33316+1c8]
77f596da: ntdll!RtlFreeHeap [77f50000+8a3e+c9c]
77f576f1: ntdll!LdrGetDllHandle [77f50000+718e+563]
77fb172e: ntdll!RtlConvertUlongToLargeInteger [77f50000+616c0+6e]
77f58497: ntdll!RtlAllocateHeap [77f50000+7bae+8e9]
77f57f98: ntdll!RtlAllocateHeap [77f50000+7bae+3ea]
77f58a3a: ntdll!RtlAllocateHeap [77f50000+7bae+e8c]
77f9790d: ntdll!RtlUnhandledExceptionFilter [77f50000+47865+a8]
771256e2: OLEAUT32!SafeArrayCopyData [77120000+53c7+31b]
77f5b584: ntdll!NtCallbackReturn [77f50000+b578+c]
77d44e9e: USER32!ClientThreadSetup [77d40000+4d57+147]
77f75dba: ntdll!KiUserExceptionDispatcher [77f50000+25dac+e]
77f5b644: ntdll!NtContinue [77f50000+b638+c]
77f75dc8: ntdll!KiUserExceptionDispatcher [77f50000+25dac+1c]
77e73887: kernel32!RaiseException [77e60000+13837+50]
77f944a8: ntdll!RtlRemoteCall [77f50000+442ea+1be]
77f58497: ntdll!RtlAllocateHeap [77f50000+7bae+8e9]
77e73887: kernel32!RaiseException [77e60000+13837+50]
77f5c244: ntdll!NtSetInformationFile [77f50000+c238+c]
77e7f0ce: kernel32!SetFilePointer [77e60000+1f02e+a0]
73bd181d: MSVFW32!ICSendMessage [73bd0000+17f4+29]
73bd181d: MSVFW32!ICSendMessage [73bd0000+17f4+29]
73bd47c6: MSVFW32!ICDecompress [73bd0000+478b+3b]
004a0712: VideoSourceAVI::streamGetFrame()
00492eac: AVIOutputFile::writeIndexedChunk()
00463870: Dubber::WriteVideoFrame()
0045b68f: AVIPipe::getReadBuffer()
0046411e: Dubber::ThreadRun()
77e73887: kernel32!RaiseException [77e60000+13837+50]
77f5b884: ntdll!NtDuplicateObject [77f50000+b878+c]
77e7f01b: kernel32!DuplicateHandle [77e60000+1efb6+65]
004aed3e: VDThread::StaticThreadStart()
004c6cac: _threadstartex@4()
77e7d33b: kernel32!RegisterWaitForInputIdle [77e60000+1d2f8+43]

-- End of report

Lotta spam I understand if you all hate me now. I'm guessing its some strange problem on my machine, though I'm not sure only recently formatted and haven't encoded a thing yet so I'm just going to go back to beta2 and see what happens. Best of luck on beta4 :) looking forward to it.

[Soulhunter]

Originally posted by symonjfox
Maybe playing with the BVOP sensivity would help (for example -5 -10 for high quality encodes and 5 10 15 for low bitrate encodes). Would this be better than using the 2/3 but with lower quantizers... ??? :confused:

[seewen]

@Radek & Doom9
Sorry, I thought it was easy to do it. (it was in dev-api-3, so I thought... )

But why did you remove the DXN profiles ?
At least for the few encodes I made with Beta 1 & 2, it worked well.
---

@Cretin (Ca c'est un pseudo qui te convient à merveille)
DP-500 = DP-450 + NC
Both have the same chipset/problems.

Companies have to pay if they want the little "DXN logo" on their products... And I bet that's why DP-450, 508, 1000, 1500, 1504, etc.. doesn't have the little logo.

But till today I thought that everybody would understand that a "DXN certified" player remain certified even if you take the NetworkCard off, or if you add a HardDrive or you change the Box...

[symonjfox]

Originally posted by Soulhunter
Would this be better than using the 2/3 but with lower quantizers... ??? :confused:
I don't know ... I have many tests to do to understand if this is good or bad.

The only thing I surely know, is that in 2 pass encodes, B frames help a lot (expecially in 1 CD rips), and IMO using up to 10 or more consecutive B frames shouldn't be bad, because in the few tests I made, this only appends in very very still and dark scenes (so there's no visual difference with the original). The I P B decision algorithm is very good, if you set 10 consecutive B frames, it surely use 2 or 3 consecutive B in normal encodes, so there's no matter.

My next tests will show if I'm right or not.

I just launched some ideas that I have never heard before. AFAIK nobody used 10, 15, 20 consecutive B frames, just because Dev3 algo wasn't smart enough and also developers sayd to set it to 3 or 4 at max. Now as far as I can see, there sholud be no problem, maybe some standalone compatibility problem?

[sysKin]

Originally posted by Nicholi
Here is VDub's lovely crash message which has literally no meaning to me.The stack trace is a very weird combination of xvid's decoder (!) and nvidia's video driver (!!). Very very strange...
Does anyone else have had any crash with beta3?

Originally posted by seewen
@Radek & Doom9
Sorry, I thought it was easy to do it. (it was in dev-api-3, so I thought... )No it wasn't there either... XviD's decoder never respected maximum bitrate setting, even if GUI pretended otherwise.
But why did you remove the DXN profiles ?
At least for the few encodes I made with Beta 1 & 2, it worked well.It's one thing to 'borrow' profiles from DXN - they probably wouldn't mind - but another thing to borrow profiles and *not respect them*. I don't think DXN would forgive us doing so.
Or users, btw.

Radek

[bugsan]

(edit: i am using a cvs version compiled yesterday)
this psnr test shows that bframes are bad with high motion scenes, and good with low motion scenes.
with a low motion scene, psnr (overall) is increased by 0.78
with a medium motion scene, psnr (overall) is increased by 0.28
with a hi motion scene, psnr (overall) is decreased by 0.16

i think ibp decision algorythm is bad.


Low Motion: 500kbps
Med Motion: 800kbps
Hi Motion: 1600kbps

|---------------|---------------|---------------|
| Low Motion | Med Motion | Hi Motion |
|-------------------|------------ --|---------------|---------------|
| Options | PSNR | PSNR | PSNR | PSNR | PSNR | PSNR |
| | |overall| |overall| |overall|
|-------------------|-------|-------|-------|-------|-------|-------|
| minimum |44.1442|43.8022|44.7109|43.9511|43.2975|43.0578|
| bf2 sens-20 |44.7117|44.4438|44.8077|44.1885|43.3478|42.9984|
| bf2 |44.8131|44.5867|44.8473|44.2396|43.3023|42.8922|
| bf2 sens+20 |44.8171|44.5887|44.8759|44.2354|43.2732|42.8460|
|-------------------|-------|-------|-------|-------|-------|-------|

[DevilsChild]

How does your data show that b-frames are bad with high-motion scenes? Didn't you use different bitrates for the different scenes? Maybe they increase quality at low bitrates and slightly decrease quality at high bitrates?

[bugsan]

How does your data show that b-frames are bad with high-motion scenes? Didn't you use different bitrates for the different scenes?

bitrates are different because compressibility for each scene is different. High motion scenes will get always more bits than low motion scenes ;)


Maybe they increase quality at low bitrates and slightly decrease quality at high bitrates?

sorry to say that, but in a movie there are high bitrate scenes (~high motion scenes) and we could increase quality of these scenes by removing bframes from them.

[symonjfox]

I agree with you (B frames in high motion).

But this is only "mathematically" speaking.
Yes, high motion scenes need higher bitrate to get the same quality as a slow scene, BUT our eyes have a different perception of quality. If you have a blocky slow scene you surely see it's bad; if you have an high motion blocky scene, maybe you won't notice it since it's too fast (if you watch it frame by frame ... off course you see it).

[mikeson]

Originally posted by bugsan
i think ibp decision algorythm is bad.
Why should it be bad? You hardly notice worse b-frame in high-motion, but when in low-motion it would be more noticable IMHO.

[bugsan]

Why should it be bad
I think bframes should be totaly droped above 5% of key-blocks/frame (kblk).
kblocks are more quantized in bframes because bframes have a higher quant. and those blocks give a lower psnr...

maybe i am wrong...

[Nicholi]

Returning from before, beta2 finished the encode just fine 1st pass. And I tried a 2nd pass just to see what happened and no crash.

Perhaps I'll try clearing all my nvidia drivers and reinstalling them again and try beta3 some other time.

[Tommy Carrot]

I'm totally satisfied with the current b-frame decision algorithm, i don't think it should be changed. The older xvid versions had too restrictive algorithm, and the quality gain was much less noticable with them than right now with b-frames. Bugsan, you know PSNR is not everything, you shouldn't base your opinion on it.

[sh0dan]

Originally posted by sysKin
The stack trace is a very weird combination of xvid's decoder (!) and nvidia's video driver (!!). Very very strange...
Does anyone else have had any crash with beta3?


I don't see any references to the nVidia drivers - where are you seeing this?

A strange thing is however that it happends in the DEcompressor, which shouldn't be used for the operation you describe (unless I'm reading it wrongs).

MSVFW32!ICDecompress is the decompressor called from Vdub to fetch frames, but if you are encoding from a HuffYUV file it doesen't really make much sense that the decompressor is invoked. Weird!

[EthanoliX]

Talking about b-frames I have a question:

When doing a 2-pass encode, is the ipb decision algorythm used to affect bitrate distribution? Or is it only a matter of setting the quantizers to get the desired rate during a specific scene?

[sysKin]

Originally posted by bugsan
I think bframes should be totaly droped above 5% of key-blocks/frame (kblk).
kblocks are more quantized in bframes because bframes have a higher quant. and those blocks give a lower psnr...B-frames don't have kblocks.
I never said my p/b decision is the best possible, but it is the best so far, mostly because there is no competitors :D. You're free to join the 'race' for best decision code ;). The rule is that if someone's code is better, it gets used in cvs :)

Lack of competition isn't good.

Radek

[mikeson]

@Nicholi:

Please check if VirtualDub.subset.AddRange(x,x) in VirtualDub[Mod].jobs does not exceed amount of frames you're encoding (it may happen when you insert encoding into queue (jobs) and then later change trim in AviSynth script).

[mikeX]

i'd say about 7 out of 10 of my encodes with vdubmod & avisynth don't make it through the second pass since xvid 1 beta 1 :(

the latest crash went like this:

i made a basic avisynth script with a d2v source & fed it to virualdubmod through job control (2 passes):
avisynth 2.53 build nov 11 2003
virtualdubmod 1.5.10.1 build 2047
xvid 1 beta 3 (koepi's)

i got a non fatal (for vdubmod) error at about 80% of the second pass.
i couldn't start the pass again cause i got an avisynth read error as soon i tried to.
so i closed and reopened vdubmod and started the second pass again this time not through job control.
very close to the end of the movie (less than 1 min till the end of the pass, didn't look at anything else, like frame number etc, at the time) i got the following error:

Avisynth read error: access violation at 0x12101010 attempting to read from 0x12101010

doing as mikeson advised nicholi i found that vdubmod sellects a range of 170264 while gordian knot gives 170263 as the last frame when i open my d2v project.

i aslo found this at the job file, regarding the failed second pass i made through job control:
// $error "Avisynth read error:
Avisynth: caught an access violation at 0x015c36e7,
attempting to write to 0x77767b84"

i guess the second crash could be explained by the fact that the first pass worked on 170264 frames whereas that last pass was dealing with 170263 frames
looking at the stats file from the first pass i found that these were the last 3 frames

b 3 0 480 0 146 138
b 3 0 480 0 139 129
b 3 0 480 0 139 127

the stream should end with a p or I frame right?

but what about the first crash (the one through job control)?

why didn't it crash at the end as well???

all of my older crashes don't seem to occur at the end of the file either but i don't have any more info about them (just a couple of 'crashinfo.txt' files from vdubmod)

should i post those crashinfo files or is it really not an xvid bug?

[mikeson]

I've got a little bugreport here. It seems (at least that is what I've discovered) that XviD 1.0 Beta3 doesn't encode last frame.

Hardware:
P4 2.6GHz
1GB RAM
GeForce4 4400Ti

Software:
AviSynth 2.5.3
Koepi's XviD 1.0 Beta3
VirtualDubMod 1.5.10.1 (build 2389)
WinXP SP1

In XviD I've tried default settings and also my personal settings:
- MSP6
- Chroma motion
- VHQ4
- Trellis quantization
- MPEG quantization type
- Adaptive quantization
- GMC
- Qpel
- BVOPs(2,1.50,1.00)
- Packed bitstream
- Chroma optimizer

AviSynth script:
LoadPlugin("D:\Program Files\XviD\AviSynth_filters\yv12\MPEG2Dec3dg.dll")
mpeg2source("i:\Bug's Life.d2v",cpu=0,idct=7)
trim(0,1000)
crop(0,72,720,432)
LanczosResize(720,304)
Limiter(16,235,16,240)

...and encoded this short clip via XviD 1.0 Beta3, DivX 5.1.1 and CorePNG.

Number of frames reported by VirtualDubMod:
- AviSynth script itself - 1001 frames
- DivX - 1001 frames
- CorePNG - 1001 frames
- XviD - 1000.

In Java XviD Stats Viewer number of frames was 1000.
In Koepi's StatsReader 2.1 number of frames was 1003 (maybe it counts first three 'non-video' lines).

[EDIT]
When I do not use Packed bitstream, number of frames in stats file is:
- by Java XviD Stats Viewer - 999 frames
- by Koepi's StatsReader - 1002 frames
[EDIT]

[crusty]

Hi all, happy new year and just some remarks.

Sorry if any of this has been answered before and just hit me if you no like < Crusty straps on crash helmet> :D
It's been a while since my last encode and my last readup on this forum.

Syskin:
B-frames have some other advantages, mostly making the stream more robust to data corruption
Exactly why does it make it more robust? Because the information in a B-frame is less important?

Koepi:
I think it depends on the noise in the source. But i didn't make extensive tests yet.
Well that would make sense...after all B-frames carry over less accurate information than I/P-frames, so more noise in source would be more detrimental to the result if there are more B-frames....theoretically.....I think....perhaps not. :D

A question about making the IDCT decision automatic:

What kind of differences would an automatic algorithm have to sense to be able to switch automatically?
We've seen the weird discoloring effects when using differing IDCT implementations in the clip and the decoder, but how would these be translated to values in the actual frame.
I mean, how would you be able to see from the values in a macroblock that it's the 'wrong' IDCT without actually looking at the clip and seeing purple skies etc. ?
Also, would the problem lie in Keyframes, or would it also be in all other frames?

Like the developers said, it would be nice to have this done automatically, but they're not even sure if it's theoretically possible,let alone practical.

I'm no programmer and my math sucks bigtime but my first guess would be to look for the mathematical differences between the two IDCT implementations, and then to look for instances where you get different end values for the same start value.
Then, since we're talking about the decoding end here, you would have to make the decoder aware of those values that are 'known' to be 'possibly' created differently by two IDCT's.
If that would not be enough, the decoder would then have to look for more complex differences, like patterns of values.
So far it doesn't sound impossible, but it does sound very CPU intensive, and would take a lot of programming and testing.

It sounds like the manual method is so far the easiest way of implementing it, but it requires user intervention.
Since it's virtually impossible to have two versions of the decoder on a windows system at the same time, you'd be left with only a few options:
-Supply every project with it's own player, with the right codec built-in.
-Somehow create information about the correct IDCT-choice inside the videofile itself which could be detected by all newer codecs. This would be like setting a kind of 'encoder version info' inside the film. If this is impossible to do in the header of the file, it would have to be done in the content.
BTW: This sounds more intrusive than it would be. Version info could for instance be encoded in several ways. I'm talking about 'fingerprinting' the version info into a macroblock.
Please bear in mind that encrypting information (like plain text) into graphical information (like a bmp or a jpg) is very possible.
Some examples:
Take the first frame of the movie, then double it. Alter one macroblock, let's say the first one from the top left, in a predefined mathematical way to give it the version info and let all decoders from that moment on look for that 'fingerprint'. If it's not there, it's made by an older codec, and the decoder could adjust accordingly.
The altered macroblock would look like nothing more than a 'glitch' in the first frame, if noticable at all.
On second thought, you could let the decoder adjust the values in the macroblock to reflect the original values (before it was fingerprinted) and you wouldn't notice any difference at all!!

You could even make a tool that would adjust avi's made by older encoders that lack this feature. Since all new decoders would look for this feature, it would not be impossible for older encodes to be correctly displayed with newer decoders.
Sure there would be practical problems, like having to alter stuff that you already burned to a CD, but then again nothing in life is perfect.

You would btw not break any mpeg-4 compatability, since for other decoders it would be nothing more than a glitch that might make one macroblock, in one frame, look bad. Only 'fingerprint'-aware decoders would know that it is information and not noise.

It might sound complex, but on the whole I think it would be much, MUCH easier to implement than trying to have the decoder make a 'best guess' about which IDCT was used.
You could use this for the IDCT problem, but you could also use this to have the decoder automatically detect other known problems based on the version info, like for instance Q-pel smearing and modulated QM. It would make the decoder bigger, for every workaround takes up space, but not necessarily slower, since version detection would be a breeze.

Any thoughts on this?

[Wuntvor]

If im not mistaken , the reason why bframes make a file more robust is that no other frames reference a b-frame. A broken bframe will only be showed for an instant, but a broken i/p fram will then influence all the following frames that depends on it.

regards
/wuntvor

[mikeson]

I've found temporary fix to bug I've submited few posts ago (last frame not encoded in XviD). The point is in increasing frames of video by one in script (exactly copying last frame after real last frame, so last frame will be there twice).

I warn you, this fix is very ugly written:
whole = mpeg2source("i:\AntZ.d2v",cpu=0,idct=7)
part1 = trim(whole,0,111849)
part2 = trim(whole,111849,111849)
AlignedSplice(part1,part2)

Hope this works.

[bugsan]

@mikeson
this bug is caused by xvid itself. last frames are missing in the stats file AND in the encoded video.
the number of missed frames depends on max bframes value.

[RadicalEd]

Originally posted by mikeson
I warn you, this fix is very ugly written:
whole = mpeg2source("i:\AntZ.d2v",cpu=0,idct=7)
part1 = trim(whole,0,111849)
part2 = trim(whole,111849,111849)
AlignedSplice(part1,part2)

Hope this works.

You could just do DuplicateFrame(111849) :\

[mikeX]

hmmm, i made the first pass again now without job control

there is no error message but the pass is definately not complete since the xvid status window only shows 170244 frames prossesed
looking at the stats file (which is identical to the previous one) more carefully i notice this at the end:
...
p 2 115 140 225 7659 803
b 3 0 480 0 823 360
b 3 0 480 0 444 360
p 2 105 192 183 1388 880
b 3 0 480 0 164 155
b 3 0 480 0 164 149
b 3 0 480 0 200 167
b 3 0 480 0 190 158
b 3 0 480 0 156 146
b 3 0 480 0 141 136
b 3 0 480 0 146 138
b 3 0 480 0 139 129
b 3 0 480 0 139 127 (9 b-frames)

well i guess i shouldn't have set max b-frames to 20 :(
i based that on what symonjfox reported about his tests and thought i'd give it a try
the codec had no problem using 20 b-frames at the beginning of the movie though:
i 2 480 0 0 1372 1372
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
b 3 0 480 0 8 8
p 2 0 0 480 67 67

gonna try it again with max b-frames 2

rest of the settings:
ME 6 | Chroma Motion | VHQ 4 | max I frames 250 | H.263 matrix | Adaptive Quant | Q-Pel | Quant ratio 1.5 | Quant offset 0.75 | Closed GOV | Chroma Optimizer
rest @ default

[sysKin]

Originally posted by crusty
[Exactly why does it make it more robust? Because the information in a B-frame is less important?Exactly like Wuntvor said - a broken b-frame is just one broken frame. It might even be skipped completely an you won't see a difference. A broken p-frame makes everything broken until next keyframe.

Then, since we're talking about the decoding end here, you would have to make the decoder aware of those values that are 'known' to be 'possibly' created differently by two IDCT's.If decoder knew how the picture should look like, it wouldn't even require any bitstream (think about the compression ratio lol). Since it doesn't know that, it can't detect if the picture is wrong.
-Somehow create information about the correct IDCT-choice inside the videofile itself which could be detected by all newer codecs.Of course. We already know that all simple-idct encodes have XviD009 identification, but unfortunately there are also some walken-idct encodes which also have XviD009. It was a huge mistake not to change version number, or add any more info, to the changed builds.
If this is impossible to do in the header of the file, it would have to be done in the content.LOL definitely possible, all mpeg-4 encoders I know of add this signature to the file :)
You could even make a tool that would adjust avi's made by older encoders that lack this feature. Since all new decoders would look for this feature, it would not be impossible for older encodes to be correctly displayed with newer decoders.
Just like fixing aspect ratio, removing b-frame hacks etc etc it requires an mpeg-4 parser which we don't have.
Once someone would write such parser, I'd be happy to add more features to it - including this.

Originally posted by bugsan
this bug is caused by xvid itself. last frames are missing in the stats file AND in the encoded video.
the number of missed frames depends on max bframes value.It's not a bug - xvid is perfectly able to flush all b-frames from the queue once encoding is finished. xvid_encraw shows (and documents) how to do it - you set input picture to NULL and call encoder as long as it gives any bitstream output.

The only thing is that it can't be done in VfW. If you think it can be done, please add it.

Radek

[temporance]

Originally posted by sysKin
It's not a bug - xvid is perfectly able to flush all b-frames from the queue once encoding is finished. xvid_encraw shows (and documents) how to do it - you set input picture to NULL and call encoder as long as it gives any bitstream output.

The only thing is that it can't be done in VfW. If you think it can be done, please add it.It can be done in VfW because DivX5 does it. I believe a slight VfW hack was necessary to achieve this so it only works with some encoding tools like recent versions of VirtualDub. HTH.

[Koepi]

Use max bframes=1 and packed bitstream and see if a frame is missing.

(My guess is: don't play around with advanced settings if you don't know or like what they do ;) )

Regards
Koepi

[sysKin]

Originally posted by temporance
It can be done in VfW because DivX5 does it.Are you sure? Since divx5 produces delay 0x7f frame (it was their idea in the first place) and this frame gets ignored by vdub, you have exactly one frame ignored and missing. I see no way how the avi is supposed to have the same number of frames.

Does anyone know the trick used?

Radek

[mikeson]

I've done the same tests as I've submited few posts ago but with older VirtualDub 1.5.4 and number of frames is correct (in both .stats file and AVI).

I'll download some older versions of VirtualDub and VirtualDubMod than is the current one is and try to track down this weird behaviour.

[temporance]

Originally posted by sysKin
Are you sure? Since divx5 produces delay 0x7f frame (it was their idea in the first place) and this frame gets ignored by vdub, you have exactly one frame ignored and missing. I see no way how the avi is supposed to have the same number of frames.

Does anyone know the trick used?
AIUI: The first B-frame results in a 0x7f delay frame which is discarded by VDub. However this puts VDub into a special mode where it requests the last video frame to be encoded twice. So as long as xvid produces the delay frame, VDub will take care of the rest. Not sure if it works for >1 consequetive B though.

Try encoding sequences of 3 frames with DivX5 + B frames.

[sysKin]

Originally posted by temporance
AIUI: The first B-frame results in a 0x7f delay frame which is discarded by VDub. However this puts VDub into a special mode where it requests the last video frame to be encoded twice. So as long as xvid produces the delay frame, VDub will take care of the rest. Not sure if it works for >1 consequetive B though.OOkie, good hack. The only change xvid needs is that VDub should count the number of 0x7f frames and call the encoder as many times in the end. Done.

Of course we have to find out if VD is performing this trick for XviD at all (at the beginning it didn't even skip xvid's 0x7f frames)

Radek

[edit] I don't really like the idea of XviD being called "buggy" just because virtualdub is hacked to workaround DivX's issues but not XviD's.

[mikeX]

my latest test with max b-frames 2 & no packed bitstream verifies mikeson's observations, xvid's status window displays a total of 170262 frames prossesed (d2v -> 170263). the end of the stats file is like this:

...
b 3 0 480 0 22 22
b 3 0 480 0 21 21
p 2 0 48 432 183 154
b 3 0 480 0 54 54
b 3 0 480 0 55 55
p 2 0 320 160 647 430


i'm gonna try what koepi suggested next

btw virtualdumod still has an extra frame (blank) at the end

[mikeson]

Originally posted by sysKin
I don't really like the idea of XviD being called "buggy" just because virtualdub is hacked to workaround DivX's issues but not XviD's.
Me neither.

BTW I've tried VirtualDub 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9 and 1.5.10 and last version where this behaviour did not occured was 1.5.4.

[draGOAn]

Well, I´m really sad, that the new XviD codecs [after the 20030624] don´t work with AutoGK! :(
But I tested in another machine (for playback), and it´s very cool!
:cool:
I hope, len0x made compatible with codec selam, in his next release! ;)
Or he wait a rock-solid XviD v1.0 from Koepi? :helpful:

[GolovachLena]

Originally posted by mikeson
BTW I've tried VirtualDub 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9 and 1.5.10 and last version where this behaviour did not occured was 1.5.4.

That's not amazing. As far as i know, VirtualDub code was completely reworked since 1.5.5 and since that it has various problems with handling B-frame videos and many other bugs as well. Personally i reverted to most stable version 1.5.4.

[mikeX]

koepi's suggestion worked: i got 170264 frames (this means i also got the last blank frame vdubmod added) and the video.pass file looks ok:
...
p 2 0 47 433 194 165
b 3 0 480 0 54 54
p 2 0 321 159 656 437
b 3 0 480 0 61 61
p 2 0 371 109 762 483

i guess waiting for a more stable virtualdub is all we can do?

:: edit ::

new test, this time max b-frames @ 2, packed bitstream enabled, 'discard first pass' unchecked:

status window indicates 170263 prossesed frames

hmmm, must be the 'discard first pass' option...

at the end of the dub (frame 170263 - 99%) vdubmod went 0.0 fps for some time before the operation completed

video.pass:
...
p 2 0 48 432 189 160
b 3 0 480 0 54 54
b 3 0 480 0 55 55
p 2 0 320 160 653 436
b 3 0 480 0 58 58

xvid couldn't cope with vdubmod's extra frame this time

[mfluder]

Guys, I already posted the same conclusion about this problem but no one bothered to look into it. Please read my post (the last one) in this (http://forum.doom9.org/showthread.php?threadid=61346) thread and you'll see that this isn't a normal behaviour. Basically, like mikeson said, it's a bug in VirtualDub(Mod) as avs2avi and older VDub(Mod) versions don't have this last-frame-missing thing (thank God I'm using avs2avi for encoding).

mfluder

[powerslave]

Yes, len0x said that once xvid 1.0 ends its beta run and is officially
released, he will go about changing gknot to be compatable with it.

[mikeson]

I can confirm, that number of frames in AVI generated by AVS2AVI is correct (as in AVI generated by VirtualDub 1.5.4 is), but crashing issue (on end of long encoding) still remains in both of them.


I have to add that I'm not saying it is XviD issue, there is a lot of steps in encoding process...



I've reinstalled whole system (WinXP) from scratch and it seems that crashing on end of long encoding is gone. I have to say that (at least in my case) it was NOT issue caused by XviD, because DivX encoding crashed also. More testing in progress...

[Nicholi]

@mikeson

See thats the thing, not only am i not queue'ing any jobs (or using vdubmod), i am not using avisynth. I'm encoding directly from a huff'man AVI loaded in Vdub, which was previously encoded with avisynth of course. Its quite peculiar...and evul.

[m0rtal]

maybe I'm blind, but I can't find "fast first pass" option... wtf? :confused:

[zulu]

Originally posted by m0rtal
maybe I'm blind, but I can't find "fast first pass" option... wtf? :confused:
thats because it's not an "option" ;)

[m0rtal]

Originally posted by zulu
thats because it's not an "option" ;)
so what is it? ;)

[zulu]

it's not configurable in the vfw gui.
see syskin's post (http://forum.doom9.org/showthread.php?s=&threadid=67495&perpage=20&highlight=fast%20first%20pass&pagenumber=4#post418483) for more info and a trick to disable fast first pass anyway.

[bond]

as fast first pass doesnt hurt quality it doesnt make sense to add an option to disable or enable it...

[Assault]

Originally posted by Bond
as fast first pass doesnt hurt quality it doesnt make sense to add an option to disable or enable it...

IMHO there is one situation where it could make sense. Namely when you uncheck the "discard first pass" option. As Leak already posted it doesn't make sense to keep the first pass file for archiving when fast first pass is enabled. ;)

Assault

[mikeson]

Originally posted by Assault
IMHO there is one situation where it could make sense. Namely when you uncheck the "discard first pass" option. As Leak already posted it doesn't make sense to keep the first pass file for archiving when fast first pass is enabled. ;)
Assault
So, you are free to set quant 2 in zones and do only one pass without FAST1PASS flags turned on as sysKin already mentioned. ;)

[Assault]

@ mikeson

I know that this is possible. But thanks anyway. :p

@ all

The intention of my post wasn't to convince any xvid developper to make fast first pass an option(I know what's their attitude towards this). ;)
I only wanted to clarify bond's statement.

Assault

[Snilly]

Hey guys,

Just wanted to confirm something. Would you expect the playback on Xvids with Qpel and GMC turned on to eat up more CPU? I'm getting a stuttering when I play back stuff where I have enabled them both (but they look great! :)

Snilly

[mikeson]

@Snilly:

Yes, CPU load while decoding will be more intensive with Qpel and GMC.

[DevilsChild]

Originally posted by Snilly
Just wanted to confirm something. Would you expect the playback on Xvids with Qpel and GMC turned on to eat up more CPU? I'm getting a stuttering when I play back stuff where I have enabled them both (but they look great! :)


I've noticed that movies made with Qpel and GMC don't play very well in ffdshow (the framerate drops considerably). The XviD decoder doesn't seem to have any problems with those features. Guess ffdshow needs more work so it can handle XviD's GMC...

[Heini011]

Hi,

i have trouble with virtualdubmod 1.5.4.1 too.

while converting a big job (134.000 frames) vdm crashes randomly. i use avisynth 2.53 as frameserver under WinME.

when i used the program last time, it crashed after 11 hours at 99%. sometimes it crashed just after few hours... its really frustrating :-(

before xvid 1.0 beta came out, i had used virtualdubmod 1.5.4.1 long time together with divx without any problem.


i play at the moment with the SetMemoryMax() setting in avisynth.

plugins used:

LoadPlugin("C:\Programme\AviSynth 2.5\plugins\MPEG2Dec3.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\undot.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\Deen.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\Vaguedenoiser")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\UnFilter")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\FluxSmooth.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\VSFilter.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\LoadPlugInEx2.dll")
LoadPlugin("C:\Programme\AviSynth 2.5\plugins\DustV5.dll")

greetings, Heini011.

[Koepi]

Devilschild:

You may try playing around with different ffdshow builds, some builds may be faster in decoding that.

Hein011:
That's very weird. Can you give your system specs? XviD stresses memory and hardware a little more than other codecs sometimes (at least I could observe that on friend's computers).
Did you overlock your machine?

Regards
Koepi

[Soulhunter]

@Heini011

Don't know If its true, but I read it helps to downscale the RAM latency to prevent failures like this... ;)

Bye

[Aktan]

Hi, while i was searching the web to find out what a S Frame was, I can across this paper:

http://research.microsoft.com/asia/dload_files/group/imedia/2002p/sprite_pcm_01.pdf

Since I don't know how MPEG4 works, I don't know if this would be of help since it claims to do GMC faster and in better quality.

I just thoguht the dev would like to check it out :)

[Heini011]

Hi,

@Koepi:
i use an amd athlon xp at 1850 mhz, nforce2 chipset, 256 mb ram, ati radeon 9100 graphics

my system is ever been 3dmark-stable. i have already lowered the cpu-clock and increased the vcore a little. but the problem remains.

i have tested virtualdub 1.5.10 now. the same result.

but i use now a long avisynth-script with many filters. so i can not say, that the problem must came from xvid. maybe i should spend my pc more ram...

greetings, Heini011.

[mikeX]

::edit::

i must be blind or something

[Alvy]

@ Heini
(as I reported before) 'display decompressed output' leads to those crashes. (I have not used beta 3 yet but it resisted in beta 1 and 2).
So perhaps this is the reason for your crashes, too?

[nanga parbat]

Greetings!

I don't know if that's the same like Heini011's problem, but I've been trying to encode a PAL movie and it seems that Selam crashes my Computer.
I guess it's safe to assume it is due to that build, since reverting back to previous build seems to be working, at least I have done a first pass with Ciao and it worked (only that there was a 'possible livelock' at last frame, but that is another issue, I guess).

I cannot give you any crash report, since I don't even see a bluescreen or so, just reboot, no appearance in any log...

some specs:
AthlonXP 1600+, Win2k SP3, GeForce4Ti 4200, Asus A7v266

used DvD2AVIdg, AviSynth 2.53, VDubMod 1.5.10.0 build 2407

script:
loadplugin("...\MPEG2Dec3dg.dll")
loadplugin("...\UnDot.dll")
mpeg2source("...colc.d2v",cpu=0,idct=7).trim(0,154299)
crop(14,84,-10,-84)
undot()
bicubicresize(624,336,1/3,1/3)

xvid:
profile: unrestricted, H.263, Q-pel, GMC, BVOP's 2/1.50/1.00, Closed GOV
advanced options: Motion Search 6, VHQ 4, Chroma Motion, Max-I frames 250, Trellis quant
all else off

2nd pass would be:
I-frame boost 10, I-frames closer than 3 get 20 reduction,
Max. Overflow 25/25, Curve Compression 15 10 15


So far the crashes appear randomly, i had a valid first pass once, but never got the second one to finish. On other first passes it crashes, too.
First i've thought that cropping might be not so good, so tried mod16 cropping - doesn't matter...
Tried without undot - doesn't matter...
Tried Avisynth 2.50, VDubMod 1.5.4.1 - doesn't matter...
Even tried lanczosresize, whole movie - same outcome...

As i said, Ciao does the first pass, haven't done 2nd yet since there was no time.

I will look into going a bit lower with my xvid settings or trying out VDub, to see if that makes any difference.
Please note that i do not specifically want to blame xvid for this, i just assume. It might even be my Comp, I just don't want to reinstall from scratch right now, since else it is working fine.

guidance, nanga!

P.s: i know about 'load defaults' ;)
[edit] 'diplay decompressed output' not turned on!

[nanga parbat]

hm, just had a crash with ciao... on 2nd pass.
there seems to be some other thing to it.
hope i don't need to go back to pre-1.0 :/

nanga

[Koepi]

You need better cooling for your system - sounds to me like xvid stresses your hardware too much.

Regards
Koepi

[mikeX]

You need better cooling for your system - sounds to me like xvid stresses your hardware too much.
yeap, that could be it. i had similar reboots a while ago when my VIA chipset fan stoped working ...

[chilledinsanity]

You need better cooling for your system - sounds to me like xvid stresses your hardware too much.

If he can get earlier builds working then that's not the case. It's not out of sight, but overheating isn't exactly the leading cause of computer problems, especially in the winter. Any 3D game will tax the CPU as much as xvid, so maybe try other CPU-intensive programs to determine whether that's the problem. If it's not, I'd recommend a virus scanner (free one at www.grisoft.com). I had all sorts of weird crap happening with my system before I found out I was infected.

[Aktan]

2 Questions:

1. When I turn on GMC for 1-pass, I noticed in dgbview that there was no S-frames used while encoding. Then in 2-pass there were S-frames used. Also if I change the zone that start from frame 0 and force it to quant 2, the 1-pass then does use S-frames (plus the major drop in speed). This leads me to believe that 1-pass without forcing it, will not use GMC even when it is checked. Is it suppose to happen this way?

2. In Xvid extra status box, I notice that S-frames are counted as P-frames. Are S-frames like P-frames?

[mikeson]

@Aktan
When I turn on GMC for 1-pass, I noticed in dgbview that there was no S-frames
FAST1PASS mode switches off some flags and GMC is one of them IMHO. sysKin already explained this somewhere.
Also if I change the zone that start from frame 0 and force it to quant 2, the 1-pass then does use S-frames (plus the major drop in speed)
Setting quant to 2 in zones results in switching FAST1PASS mode off.
Is it suppose to happen this way?
Yes.

[Henry The Ripper]

Originally posted by gino25
I have problems to download this beta3.

I use mozilla and explorer and no download manager, but i have always a message of error

If you have a firewall, turn it off for the time the save window opens.

[nanga parbat]

If he can get earlier builds working then that's not the case.

well koepi 24062003 has failed, too.
might be a 'lil hot in down there...

sorry to have been so fast in blaming the codec!

bigup! nanga

[chemmajik]

I've noticed on all beta builds that the codec automatically chooses above normal priority, which can make a system totally unusable until it is stopped capturing. It would be convenient to allow the user to choose which priority when using first pass low-res modes, or add that to the low-res profiles included.

[Teegedeck]

What application do you use for encoding? When I last looked, selecting a priority was something you couldn't do in a codec but in the application that uses the codec.

[chemmajik]

Task Monitor while capturing within XP, control alt delete click on whatever app you are using to then lower the priority. I'm using VirtualVCR for low res stuff, but it seems VirtualDub doesnt have this problem. I know that VirtualVCR uses preview while VirtualDub uses overlay. But I never had this problem before the beta's with that program, but I maybe wrong because I did do a fresh install 1 or 2 builds before the beta's. What about the new dshow filter think it could effect preview? DiVX5 is working fine with it thou, which is why it seems something may have changed. I'm using single pass 3K, that has always worked in the past builds. I can go back & recompress if I need too.

[homersapien]

Originally posted by nanga parbat
hm, just had a crash with ciao... on 2nd pass.
there seems to be some other thing to it.
hope i don't need to go back to pre-1.0 :/

nanga

All three of the 1.0 betas do this on ALL of my comps. Sometimes both passes will run perfect, sometimes the first pass will run and the second pass will crash near the end, sometimes both passes will run for ~1 second each but no error is given. Does it on default settings and non-default settings.

Its NOT a heat problem...I've used several different versions of Xvid up to this point, and the 1.0 beta is the only one thats given me problems. I've tried the last few versions of both Vdub and Vdubmod. Strangely enough, 1.0 (all three betas) appear to crash less with Vdub(non-mod.)

Sooo...I'm back to XviD-24062003-1 again.

[Koepi]

If a program vanishes into nothing - without error report - this is sure a memory problem. Either your memory is broken or you use too aggressive memory timing settings. Seen this myself on some overclocked computers, and it always helped to _not_ overclock the system.

Regards
Koepi

[Teegedeck]

Originally posted by chemmajik
I know that VirtualVCR uses preview while VirtualDub uses overlay.
[...]What about the new dshow filter think it could effect preview?
I know nothing about that program you use and how XviD's .ax could come into play through it, so I can't help you. Sorry.

[_rEuTeL_]

will there be a fourth beta or will the next release be a final version?
and when could we expect a release?

grtz

[mikeson]

@_rEuTeL_:
will there be a fourth beta or will the next release be a final version?
Maybe...why do you need it anyway? If you can't wait, download gamr's build or compile build from CVS yourself.
and when could we expect a release?
When it is done. :rolleyes:


Sorry, but this kind of questions is exactly what not to ask for.

[vinetu]

Since I overclock my comp. UP and DOWN permanently,
I can recommend an ULTRA sensitive to Memory-Chipset-CPU
speed problems application - "7-Zip" in "Compression level:Ultra" mode.

Xvid beta 3 work here -no crashes with 4 jobs in VDubMode
(2x1pass & 2x2pass ~ 20 hours render)...

[Q-W-Y]

mikeson


Ale ale kolego, nebud tak napruzen ;)

:devil:

[sysKin]

Originally posted by Koepi
If a program vanishes into nothing - without error report - this is sure a memory problem.Actually it did the same for me when sprintf() had too small string buffer. These crashes are untracable, I'm sure it's a bug in windoze but what can you do.

I run some memory-proofing tests recently and there is one thing wrong/strange. Seems easy but I couldn't understand it yet. Maybe if I do, everything will be fixed?
Originally posted by _rEuTeL_
will there be a fourth beta or will the next release be a final version?I sure hope that next release will be RC1.

Radek

[chemmajik]

Well let me ask this is there any code that does change priority's within the beta builds?

Also is XVid still compilable under Visual C 6 Pro?

[Aktan]

@mikeson

Thx for the reply, and sorry for not looking for the answer more :)

[Koepi]

chemmajik:
no. it's the encoding application which sets priorities, a codec _can't_ do that.

syskin:
if he used a build of mine i can't think of any condition where a sprintf would cause that, the buffers(in the stats DebugOutput) are sufficient. It would have happened to more people if that would be the problem - i'm very confident.

Regards
Koepi

[sysKin]

Originally posted by Koepi
syskin:
if he used a build of mine i can't think of any condition where a sprintf would cause that, the buffers(in the stats DebugOutput) are sufficient. It would have happened to more people if that would be the problem - i'm very confident.Yes it's definitely not sprintf() here - I just meant that lame bug will also make application disapear into void ;)

Radek

PS Koepi where are you:confused:

[homersapien]

Originally posted by Koepi
If a program vanishes into nothing - without error report - this is sure a memory problem. Either your memory is broken or you use too aggressive memory timing settings. Seen this myself on some overclocked computers, and it always helped to _not_ overclock the system.

Regards
Koepi

In my case, it has nothing to do with the computers, it is a problem with the 1.0 builds. Or maybe the combination of 1.0 and vdub/mod, because it only happens when I try to run jobs using the Job Control. All non-Beta 1 Xvids I've tried have been fine.

[Prettz]

What ever happened to the "Payback Proportionally" and "Payback with Bias" options?


edit: a second question: syskin's sig says that weight zones with different weights don't work in beta3. Did they used to work in beta2? Because I've done 1 encode using different weights with beta2 (haven't tried beta3 yet due to no internet access) and it seems to have done what I wanted it to.

[Soulhunter]

Originally posted by homersapien
Or maybe the combination of 1.0 and vdub/mod, because it only happens when I try to run jobs using the Job Control...
Same for me !!!

But I thought its VDubMod's fault... :confused:

Bye

[Koepi]

A, you use jobcontrol. Don't do that with certain vdub(mod) versions, it's broken there, this is true. It works correctly for me, but I still use vdubmod 1.5.4.1(build 2066) and an older avisynth version.

Thanks for adding the missing information to track down your problem :)

Regards
Koepi

[vip]

Got excatly the same problem as homersapien described before. All 1.0 beta branch crashes vdubmod when using job control. But it happens only on my home PC (Athlon XP2200+/256Mb/KT266A, not overclocked), on my new office PC (Celeron 2.4GHz/256Mb/i845PE, not overclocked also) it works like a charm (thanks to developers and Koepi for excelent work)... All systems has WinXP Pro and DirectX 9b installed, versions of xvid codec (beta3 build by Koepi) and vdubmod (1.5.10.1 build 2366) are the same on both machines. Had a total clean up on my home pc and reinstalled codecs - didnt help...

[Koepi]

Vip:

please try that vdubmod version I use on your athlon - I have an athlonXP here, too. Can you report back if it works correctly then?

Regards
Koepi

[mikeX]

is it me or are all the crashes reported here happening on Athlons??
i think 1.5.4.1 2066 crashed with beta 3 on me once too

most recent crash (vdubmod 1.5.10.1(2407)):

An out-of-bounds memory access (access violation) occurred in module 'xvid'...
...while compressing frame 34765 from 032b0000 to 03bf0020 (VideoSequenceCompressor.cpp:406)...
...while running thread "Processing" (thread.cpp:120).

trying the same pass right now with 1.5.4.1 ...

[Danzel]

@chemmajik
Yes, Xvid still compiles with VC6, i did it myself just the other day ;)

I followed the guide at http://www.discdude.net/xvid/compile.html
but, the one problem i had was that nasm wouldnt work, just use the latest nasm for win32 off the nasm page and you wont have this problem
(I used the one that the guide links to down in the faq section, which wouldnt work for me at all)

Danzel.

[mikeX]

trying the same pass right now with 1.5.4.1 ...

OK :D

[chemmajik]

Thanks Koepi(had a feeling it was the application, prob need to email VirtualVCR author then) & Danzel(cool VC6 compiler help) responses... I'll be glad when the gui gets finally finalized so we can get first pass hiquality back to working as easy & good as prior stable builds with default settings. The beta's are so much different then prior builds, but I understand why it was implemented thru the various profiles, even thou there maybe needs of adding a couple like 480x480 or 640x480 & 480x240-479 modes profiles.

[seany]

Hi there,

I've just a simple question: where to turn on deblocking/deringing? I can't find it... (using WinXP). Well I found out that with the "old" media player you can turn it on in the options of the file you're playing - but isn't there another way to get to these options????

Thanks a lot!

seany

[Asrial]

Koepi, can you create an option to output the frame information (the section that shows during encoding) to a text file so that it can be reviewed later?

I want to check what quants my encode is doing but I keep forgetting to check before I close vdub.

[communist]

Originally posted by seany
Hi there,

I've just a simple question: where to turn on deblocking/deringing? I can't find it... (using WinXP). Well I found out that with the "old" media player you can turn it on in the options of the file you're playing - but isn't there another way to get to these options????

Thanks a lot!

seany
WMP 7 or higher doesnt allow or have the feature to control codec.
My advise use a real media player like Media Player Classic :)

[m0rtal]

recently I've tested b-frames on 1cd encode
settings was
max consecutive bvops: 20
bvop sensivity (for movie): 3
bvop sensivity (for credits): 5
result was amazing :)
codec often inserts all 20 b-frames in a row, and it doesn't affect quality! I should consider to increase "max consecutive bvops" to 30 ;)

[symonjfox]

Originally posted by m0rtal
recently I've tested b-frames on 1cd encode
settings was
max consecutive bvops: 20
bvop sensivity (for movie): 3
bvop sensivity (for credits): 5
result was amazing :)
codec often inserts all 20 b-frames in a row, and it doesn't affect quality! I should consider to increase "max consecutive bvops" to 30 ;) Me too. It's a good thing.

The bad things I think are 2:
1- Maybe the processing power needed for decode 20 b frames is greater that decode mixed b and p frames, I think.
To the other side, these frames are smaller (lower bitrate) and should take less power to decode ... I don't know. Maybe someone more technical than me could answer.
2- Maybe there should be any problems with standalones, they sometimes have trouble with more than 1 b frame, with 20 they get crazy :D

If someone cold try on standalone, I'd be glad. Until I'll have more feedback about 20 bframes, I won't use more than 5.

[Micro]

Originally posted by mikeX
is it me or are all the crashes reported here happening on Athlons??
i think 1.5.4.1 2066 crashed with beta 3 on me once too

most recent crash (vdubmod 1.5.10.1(2407)):

An out-of-bounds memory access (access violation) occurred in module 'xvid'...
...while compressing frame 34765 from 032b0000 to 03bf0020 (VideoSequenceCompressor.cpp:406)...
...while running thread "Processing" (thread.cpp:120).

trying the same pass right now with 1.5.4.1 ...

I had two crashes with XviD 1.0 beta3 and Vdubmod 1.5.10.1 job control. Cashes happened always during second pass. Running second pass again without VD job control - no crashes.
Running WinXP on P4 2.4 @3.06GHz.
All other applications were stable so far (more than 6 months)

[m0rtal]

Originally posted by symonjfox
The bad things I think are 2:
1- Maybe the processing power needed for decode 20 b frames is greater that decode mixed b and p frames, I think.
To the other side, these frames are smaller (lower bitrate) and should take less power to decode ... I don't know. Maybe someone more technical than me could answer.
I think in our new millenium it's not so important anymore :)

2- Maybe there should be any problems with standalones, they sometimes have trouble with more than 1 b frame, with 20 they get crazy
is don't bother me much - I'm using matroska container, which is currently not supported by standalones, so I don't care :)

[Manao]

@micro : I would say VDubMod 1.5.10 is guilty. It is highly unstable. I now use VDubMod 1.5.4 for compressing, and 1.5.10 for muxing into ogm / mkv.

[symonjfox]

Originally posted by m0rtal I think in our new millenium it's not so important anymore :) Instead I think it's important, because much people still have an old computer, and some standalones have not enough power to decode some kind of streams.is don't bother me much - I'm using matroska container, which is currently not supported by standalones, so I don't care :) First or later I really think that everyone of us will have a standalone. IMO it's important create streams playable NOW, in the FUTURE, and EVERYWHERE!

Maybe not all have my targets of life, and use Xvid for the reasons I use it. But I cooperate to grow all togheter.

[Heini011]

hi,

my problem with virtualdubmod 1.5.4.1 crash was NOT xvid's fault! i had used to many filter instances in my avisynth script.

i have done 2 large 2-pass conversions in batch mode now without any problem.

greetings, heini011.

[mikeX]

nice to see a P4 crash come in to play :devil:

i had crashes without job control iirc (i'm not really sure)
anyway things so far indicate it's not xvid related :)

btw how does everybody run such overclocked systems??? i try raising my FSB a few Hz and i can't even get into windows, does my cooler suck that bad?... :(

[Blue_MiSfit]

btw how does everybody run such overclocked systems??? i try raising my FSB a few Hz and i can't even get into windows, does my cooler suck that bad?...

a little OT, but a brief explanation

your ram probably sucks. If (for example) you are running a palomino core athlon XP (anything before the 2500+), it rides a 266mhz DDR bus. In this situation, your ram is likely DDR266(pc2100), which runs at a clock frequency of 133mhz (266ddr). Most DDR266 doesnt tolerate overclocking very well, especially at low latencies. I run DDR400 memory, and my Barton core athlon xp, which operates at at 333mhz ddr bus by default can run at 200mhz perfectly.

It all depends on how good your CPU, cooler, motherboard, and RAM are.
If you have an athlonXP, try boosting your clock multiplier a bit, as this doesnt affect your fsb speeds at all, but rather the resultant clock frequency of your cpu.

sorry about being OT, but any scent of overclocking leaves me aroused lol...

peace
~misfit

[alexnoe]

Blue_MiSfit:
The Kingston DDR266 CL2 memory I used some time ago tolerated 152 MHz (b0rks at 153), and the Infineon DDR333 memory I know have tolerates 188 MHz (did not test more). So you are even more right with 'it depends on the memory you have'

[kadajawi]

My Infineon PC2700 doesn't take very much... as soon as I raise the FSB I get problems with memtest86 in one test after a few hours... how many errors and how long it takes depends on the OC (well, other than that its stable... up to 400 MHz (didn't test more). I can raise the RAM voltage for a bit of stability.
Anyway, my 1700+ CPU runs at 2600+. Could do 2700+, but I would need to raise voltage quite a bit. Well, it really depends on your cooling, your CPU (every CPU is different) and your other hardware, mainly board and RAM.
But I agree this is the wrong place to discuss about overclocking :D

[kadajawi]

I noticed that while playback using Windows Media Player or Zoom Player XviD a video gets much brighter. The same video in huffyuv looks much darker, even if the video is encoded using quant 1 etc. So I tried loading it into VirtualDubMod, and voila, it looks as dark and detailed as it should. I've tried XviD and ffdshow, no difference. Any idea?

Doing side by side comparison of the XviD video (using default settings and "check everything you can" ;) setting) and huffyuv using VDM I also noticed that the video got a greenish tint, a bit muddy, a bit darker. But really not very much...

[Koepi]

Search for your overlay colour controls and you'll see that the drivers set the brightness to a higher value.

Koepi

[kadajawi]

That solved it. Though I never changed that. But I noticed that default with the latest NVidia is 114%. Strange.

[vip]

Koepi,
i've tried vdubmod 1.5.4.1 as you suggested before and it crashes too, regular vdub crashes as well... After flushing avisynth plugin folder as Wilbert suggested in this thread (http://forum.doom9.org/showthread.php?threadid=69008) and leaving there only mpeg2dec3, undot and convolution3d vdubmod dont crash anymore... This is a bit weird 'cos i have used them all the time so they couldnt be the real reason of vdubmod crashes...

[Flipin]

kadajawi,
The nvidia overlay "problem" is far stranger than 114%. With both of my nvidia cards (GF3, GF4), the image is actually darker than the original when everything is set to 100%. It's a sort of a level cut-off so everything dark is even darker, if not black. Also the colours are a bit pinkish/bluish. As far as I can tell, the defaults are trying to emulate the TV colour spectrum when using the default 6500/9300 colour temperatures on your CRT.
That's fine as long you use the defaults, but I'm using custom colour settings that makes even 9300k look greenish warm. So in my case, nvidia's settings will do more harm than good.
Some ways of fixing this: use Zoomplayer and use the "Use color control interface" and reset the colours.. It'll give you the original colours. Another way of fixing it is by using VMR9. I've heard some ppl. complaining that it's crappy quality but that's only because it doesn't support I420, YV12,YUY2,UYVY or RGB output properly (bad conversion?). They all give various degrees of green or pink for some reason. It only works perfectly is when using YVYU output (slow) in ffdshow. This of course probably depends on your GFX and it's texture rendering capabilities but even now I'm using this on my GF4 and Radeon7000 on another comp. without problems.
The resize quality is slightly better with VMR9 than on nvidia overlay, that being the only difference between using zoomplayer's colour adjustments and VMR9. (+ some bugs with multiple monitors when using nvidia overlay, as zoomplayer crashes)

Hope this helps,
Flipin

[begu]

Originally posted by m0rtal
recently I've tested b-frames on 1cd encode
settings was
max consecutive bvops: 20
bvop sensivity (for movie): 3
bvop sensivity (for credits): 5
result was amazing :)
codec often inserts all 20 b-frames in a row, and it doesn't affect quality! I should consider to increase "max consecutive bvops" to 30 ;)

Well what values can be used in bvop sensitivity. I tried 20 and it did cause more bframes. I tried even 60 and maybe got few more. Is there any trick to do the b-frame positioning in the stream in the same way than ffvfw? It places frames like this (when using 3 bframes):
i p bbb p bbb p bbb p bbb ...
But I have found that xvid chooses not always use 3 consecutive, like this:
i p bb p bbb p bbb p bb p bb p b p bbb ...

I have not tested if I use 100 for sensitivity, maybe then it will place always 3 b-frames in row.

Are the sensitivities in different zones somehow dependant from each other, like m0rtal used 3 and 5 ?

[m0rtal]

Originally posted by begu
Well what values can be used in bvop sensitivity. I tried 20 and it did cause more bframes. I tried even 60 and maybe got few more. Is there any trick to do the b-frame positioning in the stream in the same way than ffvfw? It places frames like this (when using 3 bframes):
i p bbb p bbb p bbb p bbb ...
But I have found that xvid chooses not always use 3 consecutive, like this:
i p bb p bbb p bbb p bb p bb p b p bbb ...

I have not tested if I use 100 for sensitivity, maybe then it will place always 3 b-frames in row.

Are the sensitivities in different zones somehow dependant from each other, like m0rtal used 3 and 5 ?
well, it's almost useless to have 3 consecutive b-frames and sensivity @ 20 or 60 - you can't get more than 3 frames in a row, so why bother? if you want to have more b-frames, you should try increasing "max consecutive" value.
and about b-frames in zones... why not? credits are less important to me, that's why I increase sensitivity... and got more b-frames comparing to main movie.

[begu]

Well, actually I meant that if I set max consecutive b-frames to 3, in the result I get something between 1-3 consecutive b-frames.
Like previous post:
i p bb p bbb p b p b p bb p bbb p bbb .. so on.
I get smooth results using ffvfw and 3 b-frames, and I get:
i p bbb p bbb p bbb p bbb .. so on.
See, there isn't always 3 consecutive b-frames using xvid.

But maybe it is not harmful always having 3 b-frames in a row. The encoder seems to make good decisions, if using a b frame or not.
The behaviour between the codes just made me to think is there possible the xvid to produce always 3 (or more) b-frames in a row. I just then compare the result and see, if there is any difference. Just trust Your own eyes :)

[m0rtal]

begu
I think that codec makes it's own decisions regarding b-frames, thus inserting from 1 to n b-frames standing upon it's own algorythm.
but I think that it is possible to enforce codec to always insert as much b-frames as user want... good proposal for developers!

[Koepi]

If you want to have "constant bframes" in a row you just need to set the bframe sensitivity to i.e. 100 or more - the codec will then be forced to nearly always use the IPBBBPBBB scheme.

(This isn't good for quality and/or compressability though.)

Regards
Koepi

[begu]

Thanks Koepi, that was just the idea, I was looking.
Now, there is one question more.

If I want better quality out of b-frames, I must lower their quantizers. I did a test, where I did set the quantizer ratio to 1.00 and the offset to 0.

In the result I got always the same quantizer for the b-frame than for the p-frame. The result did have better quality compared to default 1.50 / 1.00. And the frame size in kb was still lower in b- than p-frame. And ofcourse the above will happen.

But the question is, how does the b-frame image quality compare to the p-frame if their quantizers are the same? Like quantizer 3 for both. The b-frame uses little less kb, but will it contain as much quality as p-frame?

I ask this because in default setting the b-frame contains less image quality than p-frame (due to the quantizer difference). And I need as much image quality as possible. So using the same image quality for b- and p-frames would be the optimal thing. So should the quantizer of the b-frame be the same or maybe one notch higher than the quantizer of p-frame to obtain the same quality? Or maybe the b-frame should be quantizer of one notch lower than p-frame. That would be overkill I think, right? (also maybe it is not possible, it would need smaller than 1.00 for ratio, maybe it works, hmm) [sorry for bad english]

I have noticed, that if I use the default 1.50 / 1.00 together with 2 or 3 consecutive b-frames, the quality slightly pumps up and down in the cycle of p- and b-frames. I need to get smooth quality, and it seems that using same quantizer will improve it.

So in the end, I may have answered to my own question. But maybe someone more professional could give an aspect too. :)

[Selur]

just wondering did anyone try a quantizer ratio of 0.75 for bframes ?

Cu Selur

[m0rtal]

Originally posted by Selur
just wondering did anyone try a quantizer ratio of 0.75 for bframes?

quantizer ratio or offset?
I've tried offset 0.75, works just fine!

[Selur]

quantizer ratio or offset?
like I wrote, I ment ratio :)

[m0rtal]

Originally posted by Selur
like I wrote, I ment ratio :)
then my answer will be "NO" :(

[Soulhunter]

I think I do a small PSNR test for tomorrow...

Fixed qunat2 with no BVOP's -VS- Fixed qunat2 with quant2 BVOP's

PS: Has somebody allready tested how cartoon-mode works with real movies ???

Bye

[Koepi]

Yes. A year ago (or even longer) sysKin invented a small glitch he called TOO_SMALL_LIMIT.

Overall reaction was:
- Booo! Where are my details?
- Boo! You suck!

and so on.

It's cartoon mode. What do you expect?!?! It won't help quality on "real life footage".

Koepi

[The Link]

- Booo! Where are my details?
- Boo! You suck!

Should one be frightened of an avatar with such a strong personality as yours? ;)

(Sorry for being off topic!)

[mikeX]

talking about avatars and being completely OT i would like to say Teegedeck stole my idea for an avatar :devil:
oh well :rolleyes:
i guess i'll look for a picture of Harpo :D

[b00zed]

Originally posted by Blue_MiSfit
a palomino core athlon XP (anything before the 2500+)

Actually the palominos topped out at 2100+, and all palomino speed grades were eventually replaced by thoroughbreds anyway.

I hope this line of discussion hasn't become so OT that it gets removed...

[Koepi]

Further o/c or hardware discussion can take place in our PC Hard & Software Forum (http://forum.doom9.org/forumdisplay.php?s=&forumid=16) - thanks for not further polluting this thread.

Regards
Koepi

[begu]

Well what about my post considering the quality of the b-frames, when using the same quantizer for p- and b-frame? Anyone else tried this?

I did not yet try lower quantizer for b-frame, but when using the same, the quality is nice. Also it takes little less space than using only p-frames, when trying to get best possible quality. I will do tests more soon.

[Koepi]

bframes at the same quant as i and p frames shouldn't give an improvement in either quality or filesize.

But of course you have to judge for yourself.

Regards
Koepi

[begu]

Ok, I might be wrong.
All I know, that i-frame takes many times more bits than p- or b-frame at same quantizer.

And I was in such asumption, that the b-frame takes less bits than p-frame, when using same quantizer. Ok, I will try look more carefully.
When using virtual dub, there can be seen the video stream info, where the framesize can be seen.

Now, I might just imagine, but I can see from the graph, when there is b-frame. This is because there are for example two to three lower bars between a little higher ones (p-frames).

And when using same quantizer, there are still slightly lower consecutive bars between slightly higher bars (p-frames). But of course I should use statsreader to find out. Sorry or possible mis-information.

[Soulhunter]

Originally posted by Koepi
It's cartoon mode. What do you expect?!?! It won't help quality on "real life footage".
I hoped it could help with moving noise in uniform arears (aka. moving wall texture...) as a stabilizing factor !!!


Ive done some test encodes with qunat2 BVOP's !!!

So far, it looks like this...

"avg. I-VOP size" : 2 = "avg. P-VOP size" : 2 = "avg. B-VOP size"


Bye

[Stux]

Originally posted by begu
Ok, I might be wrong.
All I know, that i-frame takes many times more bits than p- or b-frame at same quantizer.

And I was in such asumption, that the b-frame takes less bits than p-frame, when using same quantizer. Ok, I will try look more carefully.
When using virtual dub, there can be seen the video stream info, where the framesize can be seen.

Now, I might just imagine, but I can see from the graph, when there is b-frame. This is because there are for example two to three lower bars between a little higher ones (p-frames).

And when using same quantizer, there are still slightly lower consecutive bars between slightly higher bars (p-frames). But of course I should use statsreader to find out. Sorry or possible mis-information.

The thing to be careful of is if you are using packed-bframes then the bframe will actually be in the previous p-frame, and where the bframe should be will be a very small frame.