What might cause I-VOPs to be 2 frames before scene changes?

[shae]

I just encountered an odd Xvid encoding. Keyframes are present 2 frames before scene changes. It's not decoder delay. What might cause such a strange behavior?

[Ranguvar]

The minimum keyframe interval could force Xvid to place a keyframe early, and there might be a restriction on how far keyframes must be from each other, so it didn't place one right at the scene change... unless this is consistent with each scene change?

[shae]

It's a fragment cut from a larger video, so I don't know what happens in all of it, but in the part I have it's like that before every scene change.

How can you enforce minimum distance between keyframes?

And how can a fully lit P-VOP after a completely black frame not be I-VOP? (Could all MBs be I but the frame as a whole not considered I?)

[plugh]

IIRC, there was a bug in earlier version(s) of xvid involving n-vops that could put pass1 and pass2 out of sync. (The .pass file controls pass2 frame types.) Perhaps you are seeing a manifestation of this...

[squid_80]

It could be the n-vop bug but that normally led to I frames appearing after their proper position, not before. Possibly the source used directshowsource() and it presented different frames on each pass. Maybe it was encoded in non-packed mode, they decided for some stupid reason it wasn't good enough and fed the encoded file back in for a third pass - using the original stats file.

[Sharktooth]

eh... avi/vfw...

[shae]

Is there a way to see the macroblock types of a frame(something like ffdshow's visualization of MVs)? I'm curious about the properties of these non-I-VOPs on a scene change.

[squid_80]

Not that I know of. Maybe a request could be made to the ffdshow folks - if they can show the quantizer I'd imagine they should be able to show the block type using a similar method.

[LoRd_MuldeR]

Not that I know of. Maybe a request could be made to the ffdshow folks - if they can show the quantizer I'd imagine they should be able to show the block type using a similar method.

I think all the "ffdshow guys" do is enabling the visualization options of the libavcodec decoder (like "-lavdopts vismv=7" in MPlayer)
So adding new visualizations would require support by libavcodec, I guess...

[shae]

It seems to be handled in imgFilters/TimgFilterShowMV.cpp.