Using previous 1st pass stats in reencoding.

[kenpachi]

I encoded my clip with GrainFactory3(5,4,3,70,76,90,1.30,1,0.70,0,0,0,0,0,24,56,128,160). Unfortunately, the bitrate seemed to be too low causing blocking. I need to lower the grain down and reencode it with x264 2passes. Can I use previous stats from 1st pass? The only thing I'm going to change is parameters in GrainFactory3. Can I do so with no quality loss?

[LoRd_MuldeR]

I think you can re-use the "old" stats file, as long as the frame numbers are still identical, i.e. there must not be more or fewer frames in the video than in the first pass and there must not be any "shift" in the frame numbers. Also: The more the video has changed between the two passes, e.g. because of different filter (settings), the bigger the quality loss will be - compared to re-doing both passes.

[kenpachi]

In the end I decided not to risk at all and did a proper encoding. Not to mention I'm gonna reencode it again ;] , this time with changing AQ from 1.0 to 1.2 and smoothing the levels. I've always encoded with AQ=1.2 but changed the param that one time because I had an encoded sample showing it should have been ok. My bad it was a sample from the second part of the movie when the first one is from a slightly different source (DVD). The previous encoding resulted in visible blue blocking in dark areas. My bad.

Nowadays, x264 gives stats and stats.mbtree. Who knows what is what and what it predicts. If motion bitrate compensate only then that'd be all right but I guess it's more like deciding what frames need more or less bitrate which is highly affected by grain. I don't know.

[LoRd_MuldeR]

Nowadays, x264 gives stats and stats.mbtree. Who knows what is what and what it predicts.

It's an additional stats file required for x264's MB-Tree feature.

More info:
http://git.videolan.org/?p=x264.git;a=commit;h=bb66c482242a0747823661b212114c1a2f015fe3

See also:
http://x264dev.multimedia.cx/archives/98


I guess it's more like deciding what frames need more or less bitrate which is highly affected by grain.

That's pretty much the idea of 2-Pass encoding (or "qcomp" in general) without MB-Tree.

MB-Tree does the same thing for individual Macroblocks instead of whole Frames, taking into account how much each Block will influence future frames...