Question regarding I-Frames

[MoonWalker]

In the first pass the I-Frames are written down in the stats file. In the second pass does XviD inserts more I-Frames, besides the ones it had at the first pass??

Thanks,
MoonWalker

[iago]

@MoonWalker

AFAIK, no. I-frame decision/insertion is done only in the first pass, and the second pass just uses these data from the first pass and doesn't insert any more I-frames. (?)

regards,
iago

[Koepi]

Moonwalker,

XviD 2pass code is "reusing" the keyframes (or better: the keyframe positions) from the first pass and there shouldn't be a way that other keyframes are inserted. If there are different ones it is a *caugh* feature which we need to know more about...

Where did this happen?

With which build?

Regards,
Koepi

[Acaila]

Just a side question:

Why doesn't xvid store the compressed keyframes in the 1st pass stats file and copy these into the destination file during the second pass. This would save the time for re-encoding I-frames.

I assume it's not possible, otherwise it would have been done already. But why isn't it possible?

[sysKin]

Originally posted by Acaila
Why doesn't xvid store the compressed keyframes in the 1st pass stats file and copy these into the destination file during the second pass. This would save the time for re-encoding I-frames.

I assume it's not possible, otherwise it would have been done already. But why isn't it possible?

I guess we don't do that, because we can't expect that 2nd pass will use quant 2 for those frames. As a result, we would have to design a special format of those frames - not quantized at all (that would be something like quant 0.33 if I'm not mistaken).
Encoding I-frames is very fast. I bet that reading the I-frame from a file would be slower itself - now continue with quantization, writing to bitstream etc - not worth it ;)

Radek

PS as for the 2nd pass, my motion estimation code has been uploaded to cvs. It contains hinted motion search for 2nd pass, which is way faster then normal (full) search, while gives the same (even a bit higher) quality. What do you think?

[Koepi]

sysKin,

I nearly wrote back on the devel list, but since you post here as well:

You're using MVhints as starting point for a refined search now on second pass? That's great news.
But I'm a bit unsure if I should build a "devel version" of XviD... and maintaining 2 binaries is a little complicated. Maybe I can do a devel snapshot every now and then and... hm, stable shouldn't be modified as often, so I would update devel version more often...

Did you read about the proposal for adaptive quantization a few threads below this? I think with MV hints this could be exploited, can you try that please? ;)

Best regards and thanks for your work!

Koepi

[rui]

Originally posted by Koepi
. Maybe I can do a devel snapshot every now and then and... hm, stable shouldn't be modified as often, so I would update devel version more often...


rui chearing devel, devel, devel, devel, devel... :D

[sysKin]

Originally posted by Koepi
You're using MVhints as starting point for a refined search now on second pass? That's great news.
Yes, I simply start a diamond in the position found in the first pass, OR in the best 16x16 vector being one of four 8x8 vectors (if first pass decided to choose inter4v mode). I also use full diamond for inter4v search because limited 16x16 search give too little information about possible 8x8 blocks.
Did you read about the proposal for adaptive quantization a few threads below this? I think with MV hints this could be exploited, can you try that please? ;) You mean TOOSMALL_LIMIT depending on the lenght of motion vectors? That's easy to do :) and I can try today. However, if you mean 'real' adaptive quantization based on first-pass MVs, then I'm not sure I can do this - most of encoder.c is a mistery for me ;)

Radek

[Defiler]

Does this mean that MV hinting is soon going to be something worth enabling, rather than a feature to be avoided at all costs? In the past, people have spoken of it as if it were some kind of war criminal. :)

[Koepi]

sysKin:

I managed to compile a version of dev-api-3 and going to test it on my movie(full 2pass, CG-Animation-matrix, no lumi masking) first before releasing an "unstable/dev-api-3-build" additionally to the usual "stable" binary.

I wanted to give it a shot with bframes (max=3, ratio=150) and MVhints, but that immediatly crashed the codec - maybe we should note that (or we should extend MVhints if possible).

Looking at the debug output everything looks fine btw.!

Thanks for your great work,

regards,
Koepi

EDIT:
Defiler,

MVhints in the stable tree degrade quality a little bit as there MVhints aren't what the name suggests - the motion search doesn't take place in second pass at all.
With the dev-3-api and sysKin's motion algorithms this changes, those binaries can improve quality (at least they won't degrade it) as the gained values are used to extend the search and still are faster. unforntunately they don't work with BFrames yet. But I'll post results later when I have them.

[iago]

Good news are arriving very fast and continuously these days ;) I guess I'll postpone all my archiving-purpose encodes and only focus on testing for a while! ;)

best regards,
iago

[sysKin]

Originally posted by Koepi
I managed to compile a version of dev-api-3 and going to test it on my movie(full 2pass, CG-Animation-matrix, no lumi masking) Yes test it please, I got some reports saying that it's not stable but it works fine for me....
As for custiom quant matrix, I don't know if the recent fix is in cvs.
Don't use as much as 3 b-frames with cvs code - it's just too much, and this code doesn't have P/B decision in it. However, I just posted my most recent code on xvid-devel and if you use this one, you can (should? for testing at least) do the following:
max_bframes = 4
use divx5 compatiblity mode (it's more logical, it should always be on)
use b-frame quantizer ratio of about 150%. In fact, I propose (damn forgot it in the mail) to remove the ratio, and use quantizer +1 or +2 for b-frames.I wanted to give it a shot with bframes (max=3, ratio=150) and MVhints, but that immediatly crashed the codec - maybe we should note that (or we should extend MVhints if possible).Yes, hinted ME (of any kind) doesn't work with max_bframes >=0 :(

Radek

[-h]

Yes, hinted ME (of any kind) doesn't work with max_bframes >=0 :(

I never knew you were in Adelaide! I'm so sorry for you ;)

I'd like to get hinted ME working in B-frames again, however I don't know nearly as much about B-frame motion compensation as Pete. Might be a good chance to learn though.

-h

[sysKin]

Originally posted by -h
I never knew you were in Adelaide! I'm so sorry for you ;)Ugly, isn't it? :sly:
I'd like to get hinted ME working in B-frames again, however I don't know nearly as much about B-frame motion compensation as Pete. Might be a good chance to learn though.
I don't expect B-frames hinted ME. There are four modes so we in fact have four simple searches. Changing it to four 'even simplier' searches won't help...
At the other hand B-frame encoding is very slow (not if there is one B frame but much more) so maybe everything is worth trying ;)

What I meant was hinted ME for P frames in B-frame encoding.

Radek

[MoonWalker]

About the I-Frames :

I have done 3 encoding with int cc,statsreader and nitrogen's

stats file
Number Of Intra-Frames (Key-Frames) : 2655
Number Of Inter-Frames (P-Frames) : 193500
Total Number Of Frames : 196155

Internal
Number Of Intra-Frames (Key-Frames) : 2629
Number Of Inter-Frames (P-Frames) : 193526
Total Number Of Frames : 196155

StatsReader
Number Of Intra-Frames (Key-Frames) : 2632
Number Of Inter-Frames (P-Frames) : 193523
Total Number Of Frames : 196155

Nitrogen's
Number Of Intra-Frames (Key-Frames) : 2628
Number Of Inter-Frames (P-Frames) : 193527
Total Number Of Frames : 196155

So the codec adds/removes some I-Frames in the second pass..

MoonWalker

[Koepi]

sysKin,

if the I/P/B decision isn't taken from the first pass, how could a 2pass properly work then? It should overquantize some frames and give others too much bitrate etc... Time to introduce new flags like #define NNSTATS_BFRAME (1<<30) at NNSTATS.drf?
Would be nice to add that as quant "Bidir" additionally to "Intra" and "inter", would be far more useful for VfW/Debugview output...

Just some suggestions while still doing my first pass ;)

Regards,
Koepi

[Marc FD]

Originally posted by sysKin
In fact, I propose (damn forgot it in the mail) to remove the ratio, and use quantizer +1 or +2 for b-frames.


I remember there will be a Bframe_ratio_a and a Bframe_ratio_b in the Dev-Api-3. Just wait for pete finishing it.

this way, we use an affine function for Bframes quants :

BframeQuant = Bframe_ratio_a*Quant + Bframe_ratio_b

it's the best way because
Quant 10*200% = 20 = ugly and
Quant 10+1 = Quant 11 = almost no gain

[Koepi]

Uh, bad results:

I #defined BFRAMES as well as BFRAMES_DEC and it still makes the media player crash when decoding with xvid.
So I used ffdshow - and found an old issue I had some weeks back with gruels code: misplaced MBs every now and then and "jerky" motion.

Ok, gave up hope on BFrames again and test MVhints now - let's hope it doesn't degrade quality (but maybe increase it - that'd be so cool).

I'll keep you posted.

Well, at least I won't release that binary as it is really dangerous to play with it and I don't think we need "unneccessary" bug reports that we can do ourselfes first ;)

Just wanted to share my progress again...

Regards,
Koepi

[sysKin]

Originally posted by Koepi
I #defined BFRAMES as well as BFRAMES_DEC and it still makes the media player crash when decoding with xvid.
So I used ffdshow - and found an old issue I had some weeks back with gruels code: misplaced MBs every now and then and "jerky" motion.
I knew it :(
Just make a simple test (with a short clip): encode it with b-frames and check how it's decoded with xvid itself. Virtualdub is best for this check - it plays fine here.
Ffdshow can't play such files - this is true.
However, if Vdub will show all the artifacts - and most likely crash after a few seconds - then I really really have a problem because how can I debug when I don't have a bug at hand? :(
Don't bother sending me buggy video - I already have one, made by GomGom.Well, at least I won't release that binary as it is really dangerous to play with it and I don't think we need "unneccessary" bug reports that we can do ourselfes first ;)Yes, even if it worked for you, it would probably be still too soon to release it ;)Just wanted to share my progress again...Thanks, I need the reports.

Radek

[sysKin]

Originally posted by Koepi
if the I/P/B decision isn't taken from the first pass, how could a 2pass properly work then? It should overquantize some frames and give others too much bitrate etc... Time to introduce new flags like #define NNSTATS_BFRAME (1<<30) at NNSTATS.drf?
Would be nice to add that as quant "Bidir" additionally to "Intra" and "inter", would be far more useful for VfW/Debugview output...Yes, P/B decision should definitely be copied from the first pass. But I have no idea how stats work, so I won't fix it ;)
Copying the decision from first pass will also result in speed gain.

[scorchED]

Originally posted by MoonWalker
About the I-Frames :
...
So the codec adds/removes some I-Frames in the second pass..

MoonWalker

Maybe it's because of consecutive I-Frames:rolleyes:

[MoonWalker]

Originally posted by scorchED
Maybe it's because of consecutive I-Frames:rolleyes:

Hmm..I did a change to xda to report cc I-Frames in the stats file..I run it with the stats generated with these tests I made and I didn't find any cc I-Frame..So they are inserted in the 2nd-pass..Is it possible for this to be happenig due to the "Below I-Frame distance" and the "I-Frame reduction" mechanism??

MoonWalker

[Koepi]

Nope, that mechanism reduces the bitrate for the first iframes of a consecutive iframe series (or cc iframes in general).

This doesn't remove any keyframe, weird ideas you have! (c)mastaa yoda

Regards,
Koepi

[MoonWalker]

Originally posted by Koepi
Nope, that mechanism reduces the bitrate for the first iframes of a consecutive iframe series (or cc iframes in general).

This doesn't remove any keyframe, weird ideas you have! (c)mastaa yoda

Regards,
Koepi

:)..I just say it that, because I have started to see cc I-frames from the day that mechanish got introduced..But it's propably irellevant

MoonWalker

[MoonWalker]

Has the I-Frame decision mechanism changed from 23072002??

I say this cause I get this...

Using XviD-23072002-1 by Koepi(this is just before the I-Frame reduction mechanism had been added)
1st-pass
Number Of Intra-Frames (Key-Frames) : 226
Number Of Inter-Frames (P-Frames) : 6430
Total Number Of Frames : 6656
Average 1-Pass Size : 11965 bytes
2nd-pass
Number Of Intra-Frames (Key-Frames) : 225
Number Of Inter-Frames (P-Frames) : 6431
Total Number Of Frames : 6656


Using XviD-23092002-1 by Koepi
1st-pass
Number Of Intra-Frames (Key-Frames) : 180
Number Of Inter-Frames (P-Frames) : 6476
Total Number Of Frames : 6656
Average 1-Pass Size : 11443 bytes
2nd-pass
Number Of Intra-Frames (Key-Frames) : 173
Number Of Inter-Frames (P-Frames) : 6483
Total Number Of Frames : 6656


MoonWalker

[duartix]

Has the I-Frame decision mechanism changed from 23072002?? I believe the way it decides to put an I-Frame has to do with a certain treshold of Key MB. Maybe something else has made this treshold become higher thus the less I-Frames number on the newer version.
Well I'm not really deep into these matters, it was just an idea.

[Koepi]

We need to find out where this derives from as it is a _real_ problem:

I'm currently reencoding Monster's Inc. and see some scenes where the overflow rises really huge with _1_ frame and then the following frames get quantized too high. I think these are our lost keyframes.

I looked through VfW and couldn't find any error, so it must be in the core. Sending of a mail to xvid-devel now.

Regards,
Koepi

[Koepi]

@Moonwalker,

do you still have the stats-file for that example or can you reproduce these results and keep the stats file then?

I'll build a special version of the stats-reader which throws out the number of keyframes in the stats-file - just to see if they already get stored wrong, which helps locating the problem.

Thanks,

best regards,
Koepi

[-h]

This is a strange one. The only way I can picture this happening is a misassignment in vfw, because when you call FrameCodeI() in xvidcore, you can't get a P-frame!

I have all of today free, I'll try to find what's causing this.

-h

[MoonWalker]

Originally posted by Koepi
@Moonwalker,

do you still have the stats-file for that example or can you reproduce these results and keep the stats file then?

I'll build a special version of the stats-reader which throws out the number of keyframes in the stats-file - just to see if they already get stored wrong, which helps locating the problem.

Thanks,

best regards,
Koepi

:( ..I have deleted it..But I can reproduce another one at about 5 hours counting from now..I let you know when the encoding is finished..

MoonWalker

[MoonWalker]

DONE!!

1st-Pass

Number Of Intra-Frames (Key-Frames) : 2655
Number Of Inter-Frames (P-Frames) : 193500
Total Number Of Frames : 196155

2nd-Pass

Number Of Intra-Frames (Key-Frames) : 2630
Number Of Inter-Frames (P-Frames) : 193525
Total Number Of Frames : 196155


OT : I got better avg.quantizers with XviD-04102002-1 (2.396) than with XviD-23092002-1 (2.507)...

MoonWalker

[Koepi]

Oops, sorry, went to bed too early, find attached a build of the statsreader that gives i/p/total frames statistics after opening the statsfile.

Regards,
Koepi

[MoonWalker]

Hi Koepi,

I just tested your stats reader.It's the same just like my previous post(so xda reports correctly :) )..

I have noticed something.The codec removes I-frame.It does not add..I will now make a special ver of my prog to see if the I-Frames are at the same position(well most of them) or not..

MoonWalker

[Koepi]

Uhm, I don't quite understand (xda?):

The stats file has the iframes from the first pass? Or do they already miss in the stats file?

Regards,
Koepi

[MoonWalker]

Uhm, I don't quite understand (xda?):

xda = XviD Analyzer ;)

The stats file has the iframes from the first pass? Or do they already miss in the stats file?

That's what I will check out..But as I can see some I-frames are not in the second pass, just in the first

MoonWalker

[Koepi]

Can you please open your first pass stats file with the statsreader version I posted above?
It'll show a messagebox where it spits out:
iframes, pframes, total frames - and can you post them here then, too?

Thanks,

regards,
Koepi

[MoonWalker]

Koepi,

I have made an .xls with the I-Frame for 1st and 2nd pass.Do you want to send it to you?

It seems tha the codec gratualy "looses" some I-Frames.It's ok til frame 19500, but from there it "looses" some.

EDIT Wow. Simultanious post :). The numbers are excaclty as I posted above. iframes: 2655 pframes: 193500 total frames: 196155

MoonWalker

[-h]

It seems tha the codec gratualy "looses" some I-Frames.It's ok til frame 19500, but from there it "looses" some.

I can create a build which will post debug information if the stats file and encoded result are of different frame types. Would you be willing to sit through another encode? :)

-h

[Marc FD]

@Moonwalker

can you do another check ? please check for the iframe number of the resulting avi with Vdub file->file info

to be 100% sure of your results.

Thx.

[Koepi]

I'll encode "Amelie" in some minutes, I'll add such a comparison to my build, too.
Dunno if that helps though ;)

Regards,
Koepi

[MoonWalker]

Originally posted by -h
I can create a build which will post debug information if the stats file and encoded result are of different frame types. Would you be willing to sit through another encode? :)

-h

No broblem.Every pass takes about 2.5 hours so it's ok :)

@MarcFD
From Vdub I-Frames 2630 (just as xda ;) )

MoonWalker

[frankio]

I've recently encoded a well-known anime and I'm a bit disappointed with the way XviD puts
consecutive I-Frames (up to 150 in a very detailed scene but with no flashes or similar).

Specifically I ripped first chapter (4104 frames) and I got 123 (from frame 310 to 432)
consecutive I-Frames out of 209 total.
excerpt from DebugView:
20 lines alternating "intra quant:2 H.263 kblocks:576 mblocks:0" and
"inter quant:2 H.263 kblocks:0 mblocks:576"
123 lines "intra quant:2 H.263 kblocks:576 mblocks:0"

NOTE: I am referring to I-Frames placed in the 1st pass, in the 2nd pass (Int. Scaling)
I can see the overflow go as high as -1521265 where the "burst" ends and then forthcoming P-Frames
get quant > 10 (depending on the final filesize). This is clearly an unexpected behavior!

My settings:
XviD-29122002-1 and XviD-03012003-1 Koepi's builds
Motion Search 6
Quant h263
Max I-Frame 300
Min I-Frame 1
Use Chroma Motion
B-Frames 3/150/100, NO Qpel
DX50 B-VOP compat
I-Frame Boost 20%, Below I-Frame dist 10%, I-Frame bitrate reduct 20%
cc 0:0 altCC disabled
and the latest YV12 arsenal (MPEG2Dec3, Conv3D, VirtualDubMod, AviSynth)

Setting Min I-Frame Interval greater than 1 didn't change anything.
Disabling B-Frames helped a bit but I still got 29 consecutive I-Frames out of 95 total.
If I disable B-Frames AND set Min I-Frame to e.g. 6 instead of those 29 consecutive I-Frames
I got 5 uniformly spaced (displaced by 6) I-Frames (the problem is still there!?)

In both cases the "burst" of I-Frame appears where the bitrate curve (reported by StatsReader)
has a high slope: seems like the codec can't allocate enough bits and puts keyframes
(don't know if this makes sense though).

Reading other posts in the forum I was convinced that XviD makes his best putting keyframe and
was better to disable Min I-Frame Interval (set to 1), so here's my question:
How can I avoid those bad keyframes in-a-row with Min I-Frame set to 1?


I know I'm using devel builds and I'd better solve my problems my own but it seems to me that
this is not a problem related to dev-tree because I've noticed it also in older builds
(XviD-30062002-1.exe, XviD-29082002-3.exe, etc.), but I didn't have tried yet XviD 0.90 stable
(I couldn't find a binary nor I have MS DDK which I suppose is required to build a win32 vfw codec).


BTW all my respect goes to the XviD community, specially hard-core developers and serial tester,
for this great opportunity to snoop in a such great project (hopefully I will contribute a day...) :)

TIA

[FunMan]

Hi to all,

I don't know if mine is the same or similar problem you discussed about. Anyway I've a problem with forced iframe with last version of "unsatable" XviD.

Is normal that if I set "Minimum i-frame interval" to 1 and "maximum i-frame interval" to 250, as always I do (with previous version of Xvid I've no problem), for a small piece of very static movie of about 2000 frame I obtain *only* 1 iframe and 414 pframe + 1585 bframe?

I don't know if the problem is enabling bframe (as I said the movie is very static), 5/100/100 DX50 B-VOP compatibility enabled, anyway it's impossible to rewind of forward on this movie for the absence of iframes.

Any idea?
Thanks in advance,

FunMan

P.S. I attached a 1st pass log of the movie. I'm using Koepi XviD-03012003-1.

[Selur]

@FunMan: seems like it's a know bug ;)
Just read about it here:
http://forum.doom9.org/showthread.php?s=&threadid=40896&perpage=20&pagenumber=12

Cu Selur

[FunMan]

Thanks, it's a known bug, ok.... but this will be fixed? The problem is only that bframe aren't considered as "frame between iframe"? I don't know, in the example I said there are about 400 pframe and only 1 iframe. Ora bframe are considered as iframe? I'm confused.

bye
FunMan

[frankio]

Maybe I'm not made myself clear (sorry for the previous long post!) so I've attached 2 captures from StatsReader (Bframes on, Bframes off).
My problem is too many keyframes!

[frankio]

and with BFrames Off