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

shae · 30th July 2008, 21:37

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 · 30th July 2008, 22:15

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 · 30th July 2008, 22:21

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 · 31st July 2008, 00:49

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 · 31st July 2008, 04:03

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 · 31st July 2008, 12:46

eh... avi/vfw...

shae · 1st August 2008, 23:23

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 · 2nd August 2008, 09:16

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 · 2nd August 2008, 18:04

Quote:

Originally Posted by 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.

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 · 2nd August 2008, 19:11

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

30th July 2008, 21:37	#1 \| Link
shae Registered User Join Date: Jun 2006 Posts: 397	What might cause I-VOPs to be 2 frames before scene changes? 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?

31st July 2008, 12:46	#6 \| Link
Sharktooth Mr. Sandman Join Date: Sep 2003 Location: Haddonfield, IL Posts: 11,768	eh... avi/vfw... __________________ MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! Last edited by Sharktooth; 1st August 2008 at 13:40.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

30th July 2008, 22:15	#2 \| Link
Ranguvar Registered User Join Date: Feb 2007 Location: ::1 Posts: 1,236	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?

30th July 2008, 22:21	#3 \| Link
shae Registered User Join Date: Jun 2006 Posts: 397	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?)

31st July 2008, 00:49	#4 \| Link
plugh A hollow voice says Join Date: Sep 2006 Posts: 269	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...

31st July 2008, 04:03	#5 \| Link
squid_80 Registered User Join Date: Dec 2004 Location: Melbourne, AU Posts: 1,963	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.

1st August 2008, 23:23	#7 \| Link
shae Registered User Join Date: Jun 2006 Posts: 397	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.

2nd August 2008, 09:16	#8 \| Link
squid_80 Registered User Join Date: Dec 2004 Location: Melbourne, AU Posts: 1,963	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.

2nd August 2008, 19:11	#10 \| Link
shae Registered User Join Date: Jun 2006 Posts: 397	It seems to be handled in imgFilters/TimgFilterShowMV.cpp.