View Full Version : What causes compression "pumping"?
ChiDragon
11th May 2013, 00:07
Not sure if that is the right term or something else entirely.
There is an HD channel here that just shows pretty still photo slideshows set to music all day and night. If viewed closely enough you can see the image degrade and then pop back into "perfection", over and over in a cycle.
Normally I would blame noise for the predicted frames being visibly different from the keyframes, but this should be an all-digital setup on their end.
poisondeathray
11th May 2013, 00:15
Usually from a large change in bitrate (either up or down) from B->I or P->I frame transition ; ie poor encoding and bitrate distribution . Also know as "keyframe popping"
LoRd_MuldeR
11th May 2013, 13:26
I-Frames usually get a certain "quality boost" (i.e. lower quantizer, i.e. less loss) compared to other frame types. That's because the I-Frame is the beginning of a new GOP and all other frames in that GOP use the I-Frame as a reference, directly or indirectly. And that means that all frames in the GOP will benefit from starting with a higher quality I-Frame.
A problem that can arise is the so-called "I-Frame Popping". That happens when after a series of P- and B-Frames there suddenly is a new GOP starting with an I-Frame. As that I-Frame has "higher quality" than the previous P- or B-Frame, due to the "I-Frame Boost", there can be a visible jump in the quality.
Good encoders will prevent this effect, simply by adaptively positioning the I-Frames. Rather than starting with a new GOP after fixed intervals (i.e. a constant number of frames), which quite often will result in I-Frames being placed in the middle of a scene, they place I-Frames adaptively (i.e. only at a scene change). Naturally this removes the problem, as the "I-Frame Popping" will not be visible when it happens directly at a scene cut. Nonetheless, it still can happen that the encoder is forced to put an I-Frame in the middle of the scene, because the user has configured a "maximum I-Frame distance" and that value is reached before the next scene cut. Again, good encoders will invoke a special "non-scenecut keyframe" handling in this specific case, in order to suppress the "I-Frame Popping".
Obviously, your "HD channel" uses a not-so-good encoder. Or they have screwed up the configuration. Or both :rolleyes:
(BTW: In H.264 there is another distinction between I-Frames and IDR-Frames. Ideally, a scene should start with an IDR-Frame. In the middle of the scene, if at all, only an I-Frame should be placed.)
ChiDragon
11th May 2013, 19:19
But in this case there should be no delta between the I, P, and B frames in the still image, so why would the predicted frames show degradation?
poisondeathray
11th May 2013, 20:06
But in this case there should be no delta between the I, P, and B frames in the still image, so why would the predicted frames show degradation?
Even with a static, photo slideshow - in all cases, it simply "inadequate compression" , usually from insufficient bitrate.
Now this can mean a number of things - this can mean too low bitrate for that encoder under these circumstances, could mean poor encoding settings thus poor compression eg. from no b-frames etc...many , many things. The cyclical nature of your observation strongly suggests "keyframe popping"
You've confirmed that your specific case is "higher quality" keyframes , but also common is the opposite case - lower quality I frames that "pop" into view" and the other frame types are actually better over time. Although the allocation of bitrate to I frames is proportionately higher than the others, it isn't enough (not enough total bitrate at all)
e.g
http://www.mediafire.com/?6qhf61c1xfk9e6x
You can open up with ffdshow's osd, or ffvideosource, ffinfo() to see the keyframe types
wonkey_monkey
11th May 2013, 20:07
I always assumed this happened (with still image sequences) because the I-frames are lower quality. Subsequently, the smaller B- and P- frames refine the poor I-frame to a closer approximation of the uncompressed original, until the next I-frame comes around.
Edit: what he said ^.
LoRd_MuldeR
11th May 2013, 20:40
But in this case there should be no delta between the I, P, and B frames in the still image, so why would the predicted frames show degradation?
Well, even if we assume there is absolutely no noise or anything in their input/preprocessing, i.e. all input frames are 100% identical, I still think the following can happen: The first frame is encoded as an I-Frame. But as the compression is not lossless, even the I-Frame will have some quality loss. Now, the input for second frame (in coding order), which will be encoded as P-Frame, still is the original image without any quality loss. At the same time, the reference is not the original image, but the I-Frame as the decoder would have decoded it, i.e. containing some loss. So there will be a (probably small) delta, right? If so, these deltas could add up over time, until we do a "reset" at the next I-Frame.
ChiDragon
11th May 2013, 21:40
I think I see what you mean.
I tuned into the channel today to try to capture a sample to demonstrate, only to find that the stills are now perfect. The crossfades are horrific, but once it pops back to just a still I couldn't find any evidence of difference between the frames looking at the screen from inches away.
poisondeathray: Interesting, but some of the clear "pops" are P-frames according to FFInfo. I've had my doubts about its accuracy though...
poisondeathray
11th May 2013, 21:54
poisondeathray: Interesting, but some of the clear "pops" are P-frames according to FFInfo. I've had my doubts about its accuracy though...
FFInfo is probably accurate.
In that example all the "big pops" are I frames. The "little pops" occur when the quality actually increases with subsequent P-frames . If you use an encoder or with settings that feature higher I frame: P frame bitrate allocation, you can imagine where the "keyframe pops" will increase the quality, and the quality will gradually deteriorate before the next I frame "pop"
ChiDragon
12th May 2013, 02:13
Ah yes, I was too busy looking for the pop phenomenon to see that the P-frame pops were sudden quality jumps and not drops.
If you use an encoder or with settings that feature higher I frame: P frame bitrate allocation, you can imagine where the "keyframe pops" will increase the quality, and the quality will gradually deteriorate before the next I frame "pop"
That's where you're losing me again. As per the post #7 idea?
poisondeathray
12th May 2013, 15:50
Ah yes, I was too busy looking for the pop phenomenon to see that the P-frame pops were sudden quality jumps and not drops.
That's where you're losing me again. As per the post #7 idea?
It's just explaining how you might get quality an increase in "quality" with keyframes, instead of decrease. Usually I frames have higher bitrate allocation either way, but it's the relative ratio that is important
Relatively too much distribution to I frames over other frame types - this would mean P (and B if they are used) would get less for a given bitrate. I frames look better, but at the expense of the other frame types which deteriorate in quality over time in that GOP until the next I frame .
Relatively too little distribution to I frames over other frame types - this would mean I frames are lower quality and quality increases over the GOP until the next I frame
ChiDragon
13th May 2013, 08:29
Relatively too much distribution to I frames over other frame types - this would mean P (and B if they are used) would get less for a given bitrate.
So you have a high-quality I-frame still image, and the predicted frame has little bitrate. But it shouldn't need any (significant) bitrate to produce a duplicate of the I-frame. Instead it produces a degraded version of the I-frame and uses up bits. Why?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.