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

Erik Slagter erik
Wed Feb 22 11:14:57 CET 2006

On Tue, 2006-02-21 at 13:07 -0800, Loren Merritt wrote:
> > For this test I took a short clip, with forced B frames, otherwise the
> > encoder would not select more than 1 B frame at a time...
> Do not compare just bitrate. Remember that one of the reasons B-frames 
> improve compression is that they allow asymmetric allocation of quality, 
> whereby the B-frames are quantized more and the P-frames less. But if you 
> encode with constant QP, then it quantizes B-frames more and doesn't 

[ ... ]

Thanks. I will do some more, hopefully, more representative tests, using
bitrate target. I realise qp is not 100% authoritative on quality, but
at least it's something more or less objective.

> 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.

[ ... ]

Clear now.

> 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.)

Yeah, that I remembered. So in h264 there is no theoretical limit on gop
size, only practical ones, like scene cuts?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2771 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20060222/0e903a8b/attachment.bin>

More information about the ffmpeg-devel mailing list