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

Loren Merritt lorenm
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?!
>
> Regards,
>  Matthias

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.
The problems:
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 
consider.

--Loren Merritt





More information about the ffmpeg-devel mailing list