[Ffmpeg-devel] [PATCH] increase max numbers of B frames
Tue Feb 21 21:23:28 CET 2006
On Tue, 21 Feb 2006, Matthias Wieser wrote:
> Am Montag, 20. Februar 2006 21:58 schrieb Loren Merritt:
>> IBBBBBBBBBBBBBBBBBBBBB: also legal. You don't strictly need any
>> P-frames at all.
> Nobody uses this pattern, so what makes b-frames worse than p-frames? I
> thought that b-frames only have advantages, but no disadvantages?!
Nobody uses it because it's hard to do right and/or fast. Most codecs
perform motion estimation as: find a motion vector for each reference
frame, then try one vs the other vs bidirectional.
Theoretically, you can gain some compression by using a "pseudo-bidir"
mode, where both references are different frames in the past. In some
of the cases where conventional multiref helps in h264, you can do better
yet by averaging 2 or more references.
It would be slow. I think that to use it effectively you'd have to
jointly optimize the reference frame decision and both motion vectors.
(We have a "jointly optimize both motion vectors" option in x264 and lavc,
and it's already slow.)
Is it used frequently enough? If we put B-frames everywhere, then it costs
some fraction of a bit to say that we're _not_ using pseudo-bidir mode in
each macroblock that uses conventional prediction. Whether the savings add
up to more than that distributed cost? Probably, but it's something to
More information about the ffmpeg-devel