2nd pass gets out of synch with 1st pass

[plugh]

I am seeing a problem wherein part way through my second pass I start seeing a pattern, both in the Vdub video frame size display while encoding, AND in the drfanalyzer graphic after encoding. The pattern is that at scene changes the P frame immediately preceding the I frame that starts the new scene has grown *significantly* compared to the same sequence of frames in the 'full quality' first pass encode.

The problem begins after the one and only N-VOP appears in the first pass AVI file.

Now bear with me, I think my evidence is compelling.

The encodes -
As I said first pass is full quality, and I keep the output avi.
Second pass is sized basically the same as the first pass; from examination of framesize patterns, there isn't any under/over correction going on. That is, no periodic 'higher quant/lower size' or 'lower quant/higher size' frames occur comparing 1st and 2nd pass output files. Thus there shouldn't be any frame size differences (except I-frame boost).

The two png's show drfanalyzer snapshots of the same sequence of frames from the 1st and 2nd pass output files. It's a little difficult to see, but the orange lines immediately preceding the black I-frame lines are significantly larger, even though they are at the same quant. Note that the fourth I-frame, not at a scene boundary, doesn't exhibit this pattern. (Side note: I have requested an enhancement to mpeg4modifier to include frame size so this can be more easily observed).

The only rationale I could come up with for this behaviour was if somehow the first frame of the new scene was being encoded as the final frame of the preceding scene. I investigated and think I found where things seem to go wrong.

What follows is a side by side comparison of the first pass output file and frame lists of both 1st and 2nd pass avis (generated by Mpeg4modifier). I have taken the liberty of adding frame numbers to the .pass file and reordering the mpeg4modifier frame lists into time order to match the .pass file.

1st pass avi file 1st pass out/2nd pass input 2nd pass avi file
51848: I-VOP (0:36:02.212) 051848. i 2 2720 0 0 77089 10591 51848: I-VOP (0:36:02.212)
...
52070: B-VOP (0:36:11.428) 052069. b 3 0 2720 0 11 11 52070: B-VOP (0:36:11.428)
52069: P-VOP (0:36:11.470) 052070. p 2 0 0 2720 360 360 52069: P-VOP (0:36:11.470)
52072: B-VOP (0:36:11.512) 052071. b 3 0 2720 0 16 16 52072: B-VOP (0:36:11.512)
52071: P-VOP (0:36:11.553) 052072. p 2 0 0 2720 383 383 52071: P-VOP (0:36:11.553)
52074: B-VOP (0:36:11.595) 052073. b 3 0 2720 0 11 11 52074: B-VOP (0:36:11.595)
52073: P-VOP (0:36:11.637) 052074. p 2 0 0 2720 360 360 52073: P-VOP (0:36:11.637)
52076: B-VOP (0:36:11.678) 052075. b 3 0 2720 0 11 11 52076: B-VOP (0:36:11.678)
52075: P-VOP (0:36:11.720) 052076. p 2 0 0 2720 360 360 52075: P-VOP (0:36:11.720)
52078: B-VOP (0:36:11.762) 052077. b 3 0 2720 0 12 12 52078: B-VOP (0:36:11.762)
52077: P-VOP (0:36:11.803) 052078. p 2 0 2 2718 362 362 52077: P-VOP (0:36:11.803)
52080: B-VOP (0:36:11.845) 052079. b 3 0 2720 0 12 12 52080: B-VOP (0:36:11.845)
52079: P-VOP (0:36:11.887) 052080. p 2 0 2 2718 362 362 52079: P-VOP (0:36:11.887)
52082: B-VOP (0:36:11.929) 052081. b 3 0 2720 0 11 11 52082: B-VOP (0:36:11.929)
52081: P-VOP (0:36:11.970) 052082. p 2 0 0 2720 360 360 52081: P-VOP (0:36:11.970)
52084: B-VOP (0:36:12.012) 052083. b 3 0 2720 0 16 16 52084: B-VOP (0:36:12.012)
52083: P-VOP (0:36:12.054) 052084. p 2 0 0 2720 383 383 52083: P-VOP (0:36:12.054)
52086: B-VOP (0:36:12.095) 052085. b 3 0 2720 0 11 11 52086: B-VOP (0:36:12.095)
52085: P-VOP (0:36:12.137) 052086. p 2 0 0 2720 360 360 52085: P-VOP (0:36:12.137)
52087: N-VOP (0:36:12.179) 052087. p 2 0 0 2720 7 7 52087: N-VOP (0:36:12.179)
52088: I-VOP (0:36:12.221) 052088. p 2 0 0 2720 7 7 52088: P-VOP (0:36:12.221)
52090: B-VOP (0:36:12.262) 052089. i 2 2720 0 0 7538 7533 52089: I-VOP (0:36:12.262)
52089: P-VOP (0:36:12.304) 052090. b 3 0 2720 0 29 29 52091: B-VOP (0:36:12.304)
52092: B-VOP (0:36:12.346) 052091. p 2 0 80 2640 450 450 52090: P-VOP (0:36:12.346)
52091: P-VOP (0:36:12.387) 052092. b 3 0 2720 0 89 89 52091: P-VOP (0:36:12.387)

As you can see, everything is going along fine, with all three in lockstep, until the n-vop appears.

In the 1st pass avi, the next frame is an I-frame.
In the .pass data file, next frame is another p-Frame.
And the 2nd pass avi, as directed by the 1st pass data file, encodes a P-frame there (where I-frame used to be)

Is this a known bug? I'm using koepi v1.1.0 final.

[squid_80]

First off well done for noticing. There are a hell of a lot of encodes around that have this same effect (first frame after scenechange is a blocky-as-hell p frame).

Is this a known bug? I'm using koepi v1.1.0 final.

There was a bug exactly like this that was fixed:
Changes since 1.1.0:
xvidcore library
Fixed bug when frame-drop (N-VOP) feature is used in combination with packed B-frames
Fix for premature EOF in xvid_decraw example
Fixed potential crash on Intel EMT64 architecture
Several fixes for IA64 platform (patch by Thomas Koeckerbauer)
Fix for visual_object_verid vs. video_object_layer_verid problem
Ensure intervening bytes are preserved in BitstreamInit()

The actual bug is that the n-vop is written to the stats file twice.
So the question is, were you using packed bitstream or is there another bug?

[plugh]

No, no packed b-frames - checkbox is off.
And frame drop ratio is zero.

From the pattern, and hypothesizing that those three 'P's before the 'I' were supposed to be just two 'P's, and scanning through encoder.c for 1.1.0, I'm wondering if:

pattern WAS B-P-B-I, which triggerred logic to convert 'B before I' to P, and this P turned into N-vop

From my glance at code, it sorta looked like that path might output the same thing twice.

Have editted the .pass file to remove one of those two 'runt' Ps (actually moved to end to keep count the same), and am re-running 2nd pass.

Moitah has (already!) updated mpeg4modifier as per my request, so I should be able to do better comparisons tomorrow.

[squid_80]

I'd try an updated build (1.1.2) anyway, my memory is shocking (I was actually the one who sent the patch) so I looked up the devel mailing list and found this from bond: http://list.xvid.org/pipermail/xvid-devel/2006-February/005314.html

A quick fix option is to get one of the builds that celtic_druid made that have n-vops completely disabled.

[plugh]

I saw that entry in the 1.1.2 notes, but since I'm not using packed b-frames, didn't think it applied. Will try 1.1.2, too.

[plugh]

Completed the new 2nd pass with edited / corrected .pass file.

drfanalyzer graphic attached shows the difference - compare it to previously posted 1st and 2nd pass graphics.

Following are two side-by-side comparisons of mpeg4modifier frame lists surrounding one of the i-frames shown in graphics. (Note that I did NOT reorder frames into time sequence this time)
1st pass avi borked 2nd pass avi
53937: P-VOP (0:37:29.371) ( 33599) 53938: P-VOP (0:37:29.413) ( 35519)
53938: B-VOP (0:37:29.329) ( 9742) 53939: B-VOP (0:37:29.371) ( 10702)
53939: P-VOP (0:37:29.454) ( 37047) 53940: P-VOP (0:37:29.496) ( 38141)
53940: B-VOP (0:37:29.413) ( 9965) 53941: B-VOP (0:37:29.454) ( 12356)
53941: P-VOP (0:37:29.538) ( 31417) 53942: P-VOP (0:37:29.579) ( 31467)
53942: B-VOP (0:37:29.496) ( 12833) 53943: B-VOP (0:37:29.538) ( 9200)
53943: P-VOP (0:37:29.621) ( 33013) 53944: P-VOP (0:37:29.663) ( 46840)
53944: B-VOP (0:37:29.579) ( 11377) 53945: B-VOP (0:37:29.621) ( 10529)
53945: P-VOP (0:37:29.705) ( 36748) 53946: P-VOP (0:37:29.746) ( 38191)
53946: B-VOP (0:37:29.663) ( 15655) 53947: B-VOP (0:37:29.705) ( 12159)
53947: P-VOP (0:37:29.788) ( 32911) 53948: P-VOP (0:37:29.830) ( 32713)
53948: B-VOP (0:37:29.746) ( 12675) 53949: B-VOP (0:37:29.788) ( 9524)
53949: P-VOP (0:37:29.871) ( 33396) 53950: P-VOP (0:37:29.913) ( 34741)
53950: B-VOP (0:37:29.830) ( 10669) 53951: B-VOP (0:37:29.871) ( 10771)
53951: P-VOP (0:37:29.955) ( 36197) 53952: P-VOP (0:37:29.996) ( 77999)
53952: B-VOP (0:37:29.913) ( 11366) 53953: B-VOP (0:37:29.955) ( 14593)
53953: I-VOP (0:37:29.996) ( 76279) 53954: I-VOP (0:37:30.038) ( 73208)
53954: P-VOP (0:37:30.080) ( 31804) 53955: P-VOP (0:37:30.122) ( 36244)
53955: B-VOP (0:37:30.038) ( 11412) 53956: B-VOP (0:37:30.080) ( 9310)
53956: P-VOP (0:37:30.163) ( 34690) 53957: P-VOP (0:37:30.205) ( 35989)
53957: B-VOP (0:37:30.122) ( 8711) 53958: B-VOP (0:37:30.163) ( 7979)
53958: P-VOP (0:37:30.247) ( 33872) 53959: P-VOP (0:37:30.288) ( 34021)
53959: B-VOP (0:37:30.205) ( 10667) 53960: B-VOP (0:37:30.247) ( 9165)
53960: P-VOP (0:37:30.330) ( 33154) 53961: P-VOP (0:37:30.372) ( 32408)
53961: B-VOP (0:37:30.288) ( 8368) 53962: B-VOP (0:37:30.330) ( 7626)
53962: P-VOP (0:37:30.413) ( 35777) 53963: P-VOP (0:37:30.455) ( 31619)
53963: B-VOP (0:37:30.372) ( 8020) 53964: B-VOP (0:37:30.413) ( 9301)Note in particular the P-frame preceding the I-frame in the 'borked' file vs the 1st pass file. Also note the generally poor correlation between frame sizes. Compare this to the quite good correlation below
1st pass avi fixed 2nd pass avi
53880: I-VOP (0:37:26.952) ( 56691) 53880: I-VOP (0:37:26.952) ( 113310)
... (original q=2 i-frame) (boosted q=1 i-frame)
53937: P-VOP (0:37:29.371) ( 33599) 53937: P-VOP (0:37:29.371) ( 33593)
53938: B-VOP (0:37:29.329) ( 9742) 53938: B-VOP (0:37:29.329) ( 9703)
53939: P-VOP (0:37:29.454) ( 37047) 53939: P-VOP (0:37:29.454) ( 37123)
53940: B-VOP (0:37:29.413) ( 9965) 53940: B-VOP (0:37:29.413) ( 10079)
53941: P-VOP (0:37:29.538) ( 31417) 53941: P-VOP (0:37:29.538) ( 31492)
53942: B-VOP (0:37:29.496) ( 12833) 53942: B-VOP (0:37:29.496) ( 12914)
53943: P-VOP (0:37:29.621) ( 33013) 53943: P-VOP (0:37:29.621) ( 32963)
53944: B-VOP (0:37:29.579) ( 11377) 53944: B-VOP (0:37:29.579) ( 11221)
53945: P-VOP (0:37:29.705) ( 36748) 53945: P-VOP (0:37:29.705) ( 36788)
53946: B-VOP (0:37:29.663) ( 15655) 53946: B-VOP (0:37:29.663) ( 15847)
53947: P-VOP (0:37:29.788) ( 32911) 53947: P-VOP (0:37:29.788) ( 32846)
53948: B-VOP (0:37:29.746) ( 12675) 53948: B-VOP (0:37:29.746) ( 12662)
53949: P-VOP (0:37:29.871) ( 33396) 53949: P-VOP (0:37:29.871) ( 33312)
53950: B-VOP (0:37:29.830) ( 10669) 53950: B-VOP (0:37:29.830) ( 10581)
53951: P-VOP (0:37:29.955) ( 36197) 53951: P-VOP (0:37:29.955) ( 36215)
53952: B-VOP (0:37:29.913) ( 11366) 53952: B-VOP (0:37:29.913) ( 11265)
53953: I-VOP (0:37:29.996) ( 76279) 53953: I-VOP (0:37:29.996) ( 76279)
53954: P-VOP (0:37:30.080) ( 31804) 53954: P-VOP (0:37:30.080) ( 31804)
53955: B-VOP (0:37:30.038) ( 11412) 53955: B-VOP (0:37:30.038) ( 11412)
53956: P-VOP (0:37:30.163) ( 34690) 53956: P-VOP (0:37:30.163) ( 34690)
53957: B-VOP (0:37:30.122) ( 8711) 53957: B-VOP (0:37:30.122) ( 8711)
53958: P-VOP (0:37:30.247) ( 33872) 53958: P-VOP (0:37:30.247) ( 33872)
53959: B-VOP (0:37:30.205) ( 10667) 53959: B-VOP (0:37:30.205) ( 10667)
53960: P-VOP (0:37:30.330) ( 33154) 53960: P-VOP (0:37:30.330) ( 33154)
53961: B-VOP (0:37:30.288) ( 8368) 53961: B-VOP (0:37:30.288) ( 8368)
53962: P-VOP (0:37:30.413) ( 35777) 53962: P-VOP (0:37:30.413) ( 35777)
53963: B-VOP (0:37:30.372) ( 8020) 53963: B-VOP (0:37:30.372) ( 8020)The small difference in frame sizes in the first several frames is due to the effect of the preceding boosted I-frame on them. The I-frame at 53953 was not boosted so the following frames match exactly.

I conclude that the second 'runt' P-frame entry in the .pass file should not be there. Definite bug...

It may be a few days before I do the 1.1.2 tests, as I want to complete the encode series I'm working on first.

PS - One interesting side effect of removing the bogus entry - encode time dropped from over 11 hours for the 'borked' encode to under 10 hours for the 'fixed' one.

[plugh]

Just finished re-encoding this with 1.1.2 code base.
The entry in the 1st pass output file is not duplicated.

It appears 1.1.2 fix also applies to NON-packed b-frame case.

Cudos and Thanks to squid_80!