"I Frame" only captures - good or bad?

[energy80s]

I always heard that he best quality MPEG capture was "I Frame" only. Now in another post, some people are saying that the standard I,B,P - GOP is far better! So which is it to be for high bitrate MPEG1 captures?

God, I'm very confused ... either that or this bottle of Chardonnay is kicking in!!

[Sulik]

IBP will always be better (in theory at least) than I-frame only at the same bitrate.

However, at high bitrates (10+Mbps for 720x480), you probably will not see any difference between I-frame only and IBBP.

The only advantage of I-frames is that they do not depend on previous or future frames, so that you can do frame-accurate video editing without re-encoding. The other advantage is that it doesn't require a lot of processing power to encode.

If you're capturing at very high bitrate and intend to edit your file later, you might want to go for for 720x480 I-frame only @ 12Mbps.

You can also do a quality test yourself: encode 720x480 @ 4Mbps I-frame only and IBBP in MMC, then compare the quality of both files -> I guarantee that you'll see the difference between I and IBP.

Do the same test at 12Mbps, and you probably will not see any difference (although IBP will always be higher quality).

Remember that P and B frames can also be coded as an I-frame -> the decision is made per macroblock (16x16 block).
Here is the more technical explanation:
Macroblocks in I-frames can only be intra-coded (like JPEG).
Macroblocks in P-frames can be intra-coded or forward non-intra coded (only the difference is encoded)
Macroblocks in B-frames can be encoded as intra, forward non-intra, backward non-intra or bidirectional (forward+backward).

It all comes down to more choices available to the encoder in order to achieve the same result using fewer bits. If you use fewer bits, then you can encode more information, meaning higher quality (less quantization).

[kinneera]

Do the same test at 12Mbps, and you probably will not see any difference (although IBP will always be higher quality).

At very high bitrates, I-frame only is higher quality - it is very similar to MJPEG. At low bitrates (typically 4Mbps or lower), it isn't as good because the bits have to be spread over more lower-compression I-frames.

[Sulik]

Kinneera: This is a myth. I-frame only can NEVER be higher quality as IBBP (unless there is a bug in the encoder), for the reasons I mentioned.

It can get very close (or the same) at extremely high bitrates, but never better. There is less information to encode in P/B frames, thus the encoder can use a lower quantization, hence higher overall video quality.

[kinneera]

I don't get the feeling you have an entirely complete understanding of this topic.

P and B frames are much more heavily compressed than I frames, and they use a lossy form of compression. Given a sufficient bitrate, neither of these frames types is necessary to maintain a transparent quantization level. Beyond that point, requiring the encoder to use them is a detriment to the quality not a benefit. Preserving as much data as possible in every frame becomes the goal given a high enough allowable bitrate.

The tradeoff at low bitrates is that by using motion prediction to compress intermediary frames even more allows periodic keyframes to be as high quality as possible. Under these circumstances, I-frame only or a high frequency of I-frames becomes undesirable.

The authors of the MPEG specification themselves had something of a fight over the need for B-frames at all, you should check out the MPEG FAQ sometime.

[Sulik]

Both I, P and B frames are using lossy compression. How lossy depends on the bitrate restrictions.
The reason why P and B frames are more compressed is because there is simply less information to code, due to prediction (the encoder only has to encode the difference between the reference and current frame).

P vs B is a different issue, some people may argue that the advantage of B vs P frames is minimal and may not be worth the added complexity and delay (backward prediction introduce a delay in the decoder).

[kinneera]

Both I, P and B frames are using lossy compression. How lossy depends on the bitrate restrictions.
The reason why P and B frames are more compressed is because there is simply less information to code, due to prediction (the encoder only has to encode the difference between the reference and current frame).

Right, but it would be preferable not to have to use prediction - it is merely another one of the tricks to achieve more compression, not more quality.

I-frame compression is very similar to JPEG compression, which is why at high bitrates it behaves very similar to MJPEG. I don't think I've ever heard anyone say MJPEG would be better if motion-predicted frames were interpolated.

[Sulik]

MJPEG would be much better if they used prediction. The only advantage of MJPEG and I-frame only is less requirement on cpu speed (they didn't have that much horsepower available when they created MJPEG).

P and B frames are not any more compressed than I-frames. The reason why they require less bits to encode is that there is less information to compress.

If you take a static sequence, where all frames are identical, the number of bits you need for I-frame only will be the same for all frames. For a IPPPP sequence, only the first I-frame will be encoded, all P-frames would have virtually zero information to encode.
This means that the encoder can use many more bits for the I-frame, meaning higher overall quality.

[tom28]

If I Frame only is like MJPEG and encoding MJPEG into MPEG is bad since MPEG is sensitive to noise that was made on the MPEG.

Does it mean for MPEG1/2, I Frame only is not as good as IPB?

lol, of course it was a little too technical for me....so I just want to ask a simple question.

Or did I ask the wrong question?

[Sulik]

IPB is always better than I-frame only. How much better depends on the bitrate (as bitrate gets higher and quality gets better, the differences are less and less visible to the human eye).

Another simpler way of looking at it is that I-frame only requires 50% more bitrate than IBBP in most cases.
For example:
- IBBP @ 4Mbps is equivalent to I-frame only @ 6Mbps
- IBBP @ 8Mbps is equivalent to I-frame only @ 12Mbps
- IBBP @ 12Mbps is equivalent to I-frame only @ 18Mbps

[kinneera]

IPB is always better than I-frame only

Absolutely NOT! P and B frames have associated degrees of image degradation, which will not occur if only I-frames are used.

The concept of a static image is both irrelevant and misleading - if you have a single image you want to display you will encode it as an MPEG still.

For all realistic applications with video, where motion is involved, I-frame only will describe every frame completely using only compression techniques very similar to JPEG - and it will avoid motion artifacts introduced by P and especially B frames. This of course means that a sufficient bitrate is necessary to avoid dilution of bits over that many I-frames, which is the low-bitrate tradeoff that resulted in P and B frames.
But like I said before, the image spoilage introduced by P and B frames becomes a detriment not a benefit beyond a certain point, so blanket statements such as IBP is always better than I-frame only is simply untrue.

[marsmayhem]

Are we still talking about I-frames-only for *capturing*?

I was also led to believe that capturing using I-frames only was a good thing because the CPU required less work to calculate IPB frames during the capture step. Later, when encoding to final target file (VCD or SVCD etc), the encoder would use the I-frames and determine the GOP from those frames.

Also, how comparable are MPEG2 I-frame only captures at 8Mbps or more to MJPEG captures? If you're capturing at that high a rate, would it be better to just go with MJPEG, or is there still quite a difference in capture file sizes?

[Sulik]

kineera: I don't know where you got that information, but it is simply not true. I suggest you read more about the MPEG encoding process (doom9.org can be a pretty good source).

Remember that the only difference between an I-frame and a P or B frame is added restriction on the macroblock coding type (A P-frame is just like an I-frame if it is entirely intra coded, in the case of a scene change for example).

You can verify this by encoding an IBBP sequence vs an I-frame sequence with a constant quantization. The IBBP sequence will use less bits, and the image quality (PSNR) will be identical.

The quality in MPEG is only related to the quantization level used, and the quantization level is only restricted by the target bitrate. Thus using fewer bits at the same quantization means being able to use a lower quantization (higher quality) for the same bitrate than the equivalent I-frame only.

[kinneera]

Given an equal quantization, the use of P and B frames is only beneficial from a compression perspective, not a fidelity perspective.

A P-frame is just like an I-frame if it is entirely intra coded, in the case of a scene change for example)

Do you realize the logical contradiction you're posing here? If we were to suppose a worst case scenario, in which every frame is entirely different, you are in effect saying that every frame would be coded as an I-frame - funny that.

MPEG is lossy compression. P and B frames are intentionally designed to be smaller - else why would they exist - thus more lossy compression is applied to such frames. This reduces the fidelity of the video, and introduces artifacts. It is simply common sense that anything that encodes the same video using fewer bits is going to be lower fidelity. Maintaining a better perceived quality at substantially reduced bitrates is the entire goal of MPEG, thus the voluntary use of P and B frames to artificially raise the perceived quality.

If you exceed the upper limits on a particular mode of compression - roughly speaking the point at which you have enough bits that it is no longer justified - then forcing its use will have a negative impact. If you have enough space for a bitmap, why use a JPEG? We accept the tradeoff for the benefit of compression, not quality.

Above the level of artifact transparency (~8 to 10 Mbps), there is absolutely no reason to sacrifice data fidelity by using P and B frames when there is no correlating visual impact for most people. At that point, preserving as much data as possible is almost certainly the priority - typically so a post-capture encoder will have more to work with. Thus, there are many situations in which P and B frames are desirable, primarily at low bitrates for the exact reason you stated, but not always. It is factually incorrect to state that MPEG with P and B frames is always better than I-frame only.

[Sulik]

I guess there is no point in continuing to argue. I strongly suggest that you read more about MPEG encoding, so you'll get a better idea of what you're talking about.

If every frame is entirely different (ie. noise), P and B frames WILL (or at least should with a good encoder) be entirely intra coded, making them pretty much equivalent to I-frames (with a bit of an extra penalty of about 4-bits per macroblock), since there is no advantage of using differential (non-intra) coding over intra coding (I-frame style).

You can increase compression without losing quality. For example, if you zip a text file it will be smaller, but the process is lossless. The same process is achieved in P and B frames by reducing the amount of information to compress (differentially coded), not by 'increasing' the compression.

The only lossy process in MPEG is the quantization of the DCT coefficients, which has pretty much nothing to do with the frame type (except that intra blocks typically use a different quantization matrix than quantizes more the high frequencies).

[kinneera]

I'm have a perfectly fine grasp of the methodologies behind MPEG encoding, and I am essentially in agreement with you about the technical details. What I disagree with is the inferences and implications to be drawn when addressing certain scenarios. I am reasonably happy with where the discussion is at, in any case.

Basically if the allowable bitrate is high enough (or stated differently, a high level of compression is not desired), there is no advantage to the use of P and B frames. This scenario is most probable when doing video capture, where the goal is to preserve as much video information as possible for the encoder when producing the final output.

For all other purposes, it is probably preferable to use P and B frames to achieve the compression per equivalent perceived quality advantage.

The one addendum I would make, however, is that the zipfile argument is also slightly off-target. The non-intra encoding decisions to be made when creating P and B frames are not nearly as cut and dry. The motion search algorithms that are implemented for this purpose are really the flesh and blood of any encoder, and quality clearly varies wildly from encoder to encoder, and even within the same encoder depending on the parameters you set. This clearly implies that P and B frames introduce a type of potential quality loss that is not present in I-frame encoding. Huffyuv and MJPEG clearly do not use motion-predicted frames for precisely this reason - fidelity is the highest priority.

[Thorn]

Rather than debate the academics... I know for a fact that I-frame only capture has advantages over IBP sometimes. My original capture system was an ATI AIW 128 on a C450. It didn't have enough power to encode IBP in realtime so it dropped frames or encoded very badly. With I-frame only at a high bitrate, the quality was only bad :) I then encoded into the final format.

Now of course, I can capture in Huffyuv (some prefer MJPEG to save room) and that's superior to any mpeg capture if you have the space (it's lossless) so the only question is what yeilds the best quality for the final format. For vcds the bitrate is fixed so compression is necessary (and going to filmrate helps if the conversion can be done well). I always assumed the frame sequence was fixed so I just let TMPGenc decide what to do.

[Nelson37]

I think the point here is that P and B frames might be more EFFICIENT, and even if nearly lossless (which in the case of a noisy cable capture, I don't think they can be), there is still a process being done, w/possible complications due to CPU usage ; dropped frames, etc. While IF YOU HAVE THE BITRATE TO SPARE I-frame only is at least as good with no CPU penalty. I personally see more artifacts in P and B frames, assuming I'm seeing this correctly I -B -P -B views as #1 good #2 worse #3 slightly better #4 worst of all. I- frame only captures are of uniformly good quality, with fewer "squiggly" artifacts, fewer dropped frames.

The encoding process is another story, where filesize is much more important.

[energy80s]

Right, I've had a bit of time to play around with I Frame vs IBP Frame captures. I've found that my PC will drop a lot of frames on IBP caps at even quite low bitrates, but that I Frame only captures are perfect at 15mbps bitrates! So I guess I'll stick to I Frame captures for the moment.

One thing though is that the video seems to jerk ever so slightly on movement even at 100% motion prediction settings, whereas AVI caps are perfectly smooth. Is this just part of the MPEG capture process or can the picture be smoothed out better?