[Ffmpeg-devel] [PATCH] increase max numbers of B frames
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.
[ ... ]
> 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...
Size: 2771 bytes
Desc: not available
More information about the ffmpeg-devel