[Ffmpeg-devel] [PATCH] increase max numbers of B frames

[Michael Niedermayer]

Hi

On Tue, Feb 21, 2006 at 01:07:08PM -0800, Loren Merritt wrote:
[...]
> There is no optimal GOP size in h264. Bigger GOP = better compression, up 
> until 1 GOP = 1 movie scene, at which point increasing the allowed GOP 
> size won't affect the encode at all. Because the codec will choose to put 
> an I-frame at the scenecut no matter how big the GOP is allowed to be.
> The only tradeoff is compression vs seeking and error resilience. There 
> are other ways to deal with error resilience that are much better than 
> extra I-frames, so I consider only compression vs seeking. The default is 
> GOP=250 because 10 seconds is a reasonable seeking granularity, and it's 
> not worth the interface complexity to make it depend on framerate. Keep in 
> mind that this is only a worst-case; if scenes are shorter than 10 
> seconds, you'll still be able to seek to each scenecut.
> 
> This is not the same as in mpeg*, where there is an additional factor 
> arguing for smaller GOPs: DCT drift. The mpeg4 standard recommends no more 
> than about 100 P-frames (actually they give a specific number, I don't 
> know where they got it from), and mpeg2 recommends 12-18 frames, or 4-6 
> P-frames. As long as you use the same implementation of DCT in both the 
> encode and decoder, the length doesn't matter. But if they differ (and 
> many mpeg2 codecs are pretty sloppy about this), then you get accumulated 
> error. (For some reason, the most common symptom I've seen of this is 
> horizontal green and purple stripes.)

mpeg* IIRC doesnt have a limit on the number of P frames but instead a
(silly) limit on the number of P-frame coded non intra MBs in a row at 
any spot, the max is 132 and that is in the specs at least since h.261
so anyone caring about how they came up with that limit must look at h.261
or older stuff

[...]

-- 
Michael