On Thu, 5 Jul 2007, flavio wrote: > If you will... I've been reading about P, B, I frames for almost two years > (even this: http://bmrc.berkeley.edu/frame/research/mpeg/mpeg2faq.html) and > this paragraph seems the most comprehensible piece I ever seen. I mean, it > finally made me understand it. Could you go on and explain the P-frames or > point to any good link on this issue? Would help a lot!
P-frames are similar to B-frames, but they only depend on previous I-frames, not on future I-frames. So they're easier to decode - you don't need to look ahead in the stream. As I understand it, the usual case, which may be the only one allowed in MPEG2, is that B-frames depend on the I-frames on either side, and P-frames depend on the one immediately previous I-frame. But more recent standards like MPEG4 allow P- and B-frames to have more elaborate dependencies (like on several I-frames, or even on other P- and B-frames). If you use a codec like MJPEG, every frame is coded independently, so in effect, they're all I-frames. That makes seeking much easier, but it's expensive in bits. Some discussion is in this Wikipedia article: http://en.wikipedia.org/wiki/Video_compression_picture_types [your later correction has been applied to this quote:] > would be: would it make sense to increase the number of I-frames during > conversion as to increase "quality" - for the video would have more of > "complete frames" and less B-frames? I think it depends on the source material. As long as each frame is a lot like the previous one, you win by having more B-frames. For instance, if it's a video of a talking head, with the same background in all the frames, then long GOPs (GOP = Group Of Pictures, basically one of those I-frame to I-frame intervals) are good. The B-frames let you just encode the moving mouth and leave the background as "the same as the last I-frame," and it's helpful to do that. But if there are going to be big changes from one frame to another, like in a typical music video where there are a lot of cuts, you win by having an I-frame near each cut so that you can correctly express "change the entire image all at once". Cuts are hard to encode in B-frames because the B-frame is trying to describe "how is this frame different from the last?" and the answer is "completely!" Imagine what happens if you have two cuts with no I-frame in between: I B B B <cut> B B B B B B <cut> B B I Assuming B-frames are described in terms of I-frames and not each other (which I think is the deal with MPEG2), then those B-frames in the middle have to be described in terms of their differences from the two I-frames at either end. But since those I-frames are from different edits, they probably bear no relation to the B-frames in the middle, so those B-frames will each have to be described by basically giving the entire literal frame (as if they were I-frames), and that's going to be expensive. You really want there to be at least one I-frame in the middle section there, so that the other frames can be described in small space by their differences from it instead of in large space as independent frames. So: you really don't want to have an edit so short that it doesn't contain at least one I-frame. Too many I-frames and you're wasting bits by storing again unchanging background data that you could have picked up from other frames. Too many B-frames and you run the risk of not having a good reference frame nearby, so that you waste bits by storing unchanging data repeatedly as if it were changing data. The optimal tradeoff depends on how often different parts of your image change. This is where two-pass encoding comes in. If you do two-pass encoding, the encoder is supposed to spend the first pass analysing the video to figure out where are the most advantageous places to put the I-frames, as well as figuring out the tradeoffs of "this part of the video needs more bits, so I'll steal some from this other part that is easier to encode, in order to maintain the average bit rate". Generally there isn't going to be a simple solution like "longer intervals equals better quality" because if there were, that would already be the encoder's default setting. Note that the decoder has to keep old frames, and look ahead for new frames, that it will need to decode current frames; with a larger GOP, that becomes a larger number of frames and so the decoder needs a bigger buffer. That could be an issue for DVD players with hardware limits on buffer size, and for software decoders too. -- Matthew Skala [EMAIL PROTECTED] Embrace and defend. http://ansuz.sooke.bc.ca/ _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
