what are P frames and B frames?

[eddypilot]

I would also like to know what motion estimation is. How will changing these things effect the quality and size of my video capture?

[mpack]

I assume you know that there are three frame types you'll normally hear about - I frames (or key frames), P frames and B frames. I frames are stand alone single images, very like a JPEG. I frames are higher quality but consume the most bits in the output stream.

A P (Predicted) frame is encoded as the differences between it and the last keyframe. P frames consume fewer bits than I frames, but more than B frames.

A B (Between) frame is encoded as the differences between the last I or P frame and the next I or P frame. B frames consume fewer bits than either I or P frames, but too many B frames will degrade quality.

Every image (I, P or B) is broken up (tiled) into "macroblocks" of 16x16 pixels. Each macroblock can be of the "intra" type (meaning stand-alone like an I frame - all of whose macroblocks are intra), or the "non-intra" type, meaning that it uses forward or backward difference or an average of both.

Part of the coding of forward or backward macroblock differences is a "pointer" to the past or future tile (which need not necessarily be aligned with the macroblock grid) which is most like the tile being coded now. The process of searching for the best match is called "motion compensation", since its purpose its purpose is to improve the effectiveness of difference coding by compensating for motion (of objects or the camera) within the field of view.

High quality motion compensation is inherently slow because the only really accurate way to do it involves comparing "this" macroblock against every possible position for an equal size tile on past and future frames. There are tricks you can use to speed things up, but these generally result in less precision in the matching (less precise match equals more bits need to encode this macroblock equals fewer bits left for other macroblocks equals reduced quality throughout).

Hope that answers your question!

[KoalaBear]

I imagine by the way your question is phrased that you're capturing MPEG in real time, and you're looking for some guidance with respect to the settings. That's actually a much different question than the one that you asked, but I'll try to explain both in order to illustrate the difference.

P and B frames are essentially blueprints that tell an MPEG decoder how to shift blocks of memory around in order to construct a new frame from an old one. Motion estimation is the method by which those blueprints are constructed.

Basically, every macroblock in a reference frame is searched for within a certain radius in a target frame, with three possible outcomes: (1) an identical match, which is coded with a motion vector; (2) a near match, which is coded with a motion vector plus a pixel differential; and (3) no match, which is coded as a full macroblock.

Ideally we want as many frames as possible to be coded using as many motion vectors as possible because they're cheap compared to coding a macroblock. But the greater the search radius (aka 'motion estimation precision') the harder the processor has to work to find them, the greater the probability it will need to drop frames to catch up.

Bitrate is the property that determines the quality of an MPEG file, not the GOP structure. The GOP is really just a shorthand form of expressing how to distribute the bits across a particular unit of time. When people change the GOP they do so for the purpose of optimizing the MPEG for a particular purpose (editing for example), but never to gain a compression advantage. It simply can't be done, at least not on a real-time basis. Rearranging weight doesn't change its mass, right?

But the greater the estimation you can handle, the more macroblocks will be coded as motion vectors, the higher the overall playback quality. If at any point within the current GOP (given the three ways motion estimation can be represented) you exceed the maximum bitrate, compression artifacts will occur. This is because you simply cannot stuff 10 lbs into a 8-lb sack. Either you increase the bitrate (which could well destroy [S]VCD compliance) or you capture in a format other than MPEG (YUV9, YUY2 etc.) so you can dampen the motion before encoding it. But you can't have both at once.

Does this make sense? Because I can scale the description up or down to accomodate your experience, but I need to know how far from bullseye the dart actually landed.

[bvcproductions]

So, what's the best frame type to capture or export the video?

I, P, or B?

[Greg12]

You can capture to I frame only. I hear alot of ppl with real time MPEG encoders do this.

You can capture to I and P frames only.

You can capture to I, P and B frames.

These are ur three choices.

Acording to TMPG

I (intra frame)

P (forward predictor frame)

B (bi-directional predictor)

<font size=-1>[ This Message was edited by: Greg12 on 2001-11-20 20:57:28 ]</font>

[kinneera]

You can't have P-frames without I-frames, and you can't have B-frames without P-frames. So the short answer is, the best type for capture is I-frames.

[KoalaBear]

Maybe that description wasn't as clear as I'd hoped.

Leave the default GOP structure as it is, folks, unless you have a good reason to change it. Such reasons include (but are not limited to) --

(a) Editing/transcoding. All I-frames, at an obscene bitrate. It feels and edits just like an AVI, but its an MPEG. You can slice it. You can dice it. You can compile new scene transitions. You can do whatever you want with the proviso that when you're finished, it has to be transcoded down to VCD bitrates in order to be used for that purpose. That takes as long as coding from AVI itself, so why not just capture AVI?

(b) IVTC. You're changing the framerate from 29.97fps to 23.97fps, so the default GOP structure has one fewer P-frame. This isn't a requirement of MPEG, just common sense: you want an I-frame roughly twice a second, so you have to account for six fewer frames per GOP (i.e., 1/4/2, L=15).

(c) Ultra-difficult frame types. Animation is a bitch. MPEG is designed for continuous-tone images, not line art. This is the only time GOP experimentation is useful, and even then only if you understand the relationship between GOP structure and bitrate allocation. Don't try this at home.

Any other time, you don't need to worry about GOPs or their structure. The default is as good as you can get.

[eddypilot]

KoalaBear... that is prefect. I was looking for better understanding of what those settings do.
Now to apply it to doing vidoe capture.
Please correct me if i misunderstood.
If I turn up the Motion Estimation Quality, and the computer can't handle the setting then it will drop frames.

From what you said I infer that frame dropping even is small amounts is bad and I should avoid that. I assume that I can resample the video and get better motion estimation after it is captured(when all frames can be processed).

My next question is about Constant bit rate vs. Varible bit rate. Can you explain that please?
Thank you for your help.

[KoalaBear]

Well, Eddypilot, it's like this:

You should never drop a frame at all, ever, no. In reality we all do, but if the drop ratio exceeds 1% the file is essentially toast for anything other than burning as-is.

That's why most of us capture AVI. We can measure that. We can declare a segment usable or not, fix it if possible and recapture it if necessary. If we captured in MPEG to start with, it would be difficult or impossible to replace a damaged segment seamlessly, so we don't even try.

VBR is very, very useful at DVD bitrates (~9 Mb/S). At [S]VCD bitrates it's just a convenient way to shrink the overall size of a particular recording.

Alot of people think that VBR "saves" bits it doesn't spend on low-motion segments to lavish on high-motion segments later. In reality, you can't exceed 2.6 Mb/S for a compliant SVCD, so any extra bandwidth you accumulate is thrown away. Low-motion segments are reduced to their practical minimum, but high-motion segments remain starved.

Thankfully, there's more than one way to skin a cat.

<font size=-1>[ This Message was edited by: KoalaBear on 2001-11-20 22:11:26 ]</font>

[hazmat42]

Hey, I think that your discussion may lead to a solution of my problem. It seems that I cannot fast forward or rewind my 2 MPEG-1 files, and I believe it has something to do with the GOP structure of the file. I have made a few VCD's before, but I'm still new at this, and I've learned alot from your posts. I need to know how to modify the GOP structure if that's possible (so I don't have to reencode).
Here is my original post:


https://www.videohelp.com/phpBB/viewtopic.php?topic=66640&forum=3

I would really appreciate any advice that any of you could give me.

[mpack]

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD><font size=-1>Quote:</font><HR size=1 color=black></TD></TR><TR><TD><FONT SIZE=-1><BLOCKQUOTE>
On 2001-11-20 20:57:40, kinneera wrote:
You can't have P-frames without I-frames, and you can't have B-frames without P-frames.
</BLOCKQUOTE></FONT></TD></TR><TR><TD><HR size=1 color=black></TD></TR></TABLE>

Uhh... actually you *can* have B frames without P frames. A B frame can quite happily reference two I frames.

[ksandbergfl]

What an excellent thread. I'm glad I stumbled across it.

Does anyone know if there's a way to change the motion estimation setting on a Dazzle USB (a real-time MPEG1 encoder)? I've been capturing at 3MB/s, then using TMPG to "transcode" down to VCD format... the output is pretty good (to me), but I'm hoping, perhaps futilely, that I can get the Dazzle to encode VCD format MPEG directly with better quality (than the default Dazzle VCD template).

I'm quite comfortable hacking the Windows registry, I'm hoping it's as simple as that.... I just need to know which setting to tweak.

Thanks!

Keith
Melbourne, FL