[MPlayer-DOCS] CVS: main/DOCS/man/en mplayer.1,1.909,1.910

[Loren Merritt]

On Fri, 4 Mar 2005, Guillaume Poirier wrote:
> On Fri,  4 Mar 2005 14:11:03 +0100 (CET), Loren Merritt CVS wrote:
>
>> sync to x264 r150: new option 'b_pyramid'
>>
>> +.B (no)b_pyramid
>> +Allows B-frames to be used as references for predicting other frames.
>
> That's very interesting... Out of my curiosity, I'm wondering how come
> that hasn't been possible before, in MPEG-[124]...
> Is that:
> a) because the inloop filter allow a better control of display quality
> b) because the single DCT algorithm permitted by the norm avoids
> drifts a lot more that MPEG
> c) all of the above
> d) none of the above

(a) doesn't apply as long as you keep the B-refs at the same quantizer as 
the P-frames (Which I don't do in x264, but one could.)
(b) doesn't apply becuse in MPEG-[124] the B-refs would be used only to 
predict the adjacent B-frames, not kept for further P-frames since MPEG-4 
doesn't have multiple references.
Also note that H.264 isn't just a lot better at avoiding drift. The 
standard defines a bit-exact output for any coded stream, and a compliant 
decoder must have no drift at all.

It would have been possible before. For that matter, I can't think of any 
H.264 feature that couldn't be back-ported to MPEG-4 ASP. But if you 
did that to all of the features, you'd end up with H.264 again. It's just 
a question of how much complexity is needed in the codec, and how much 
time it took to tune the standard.
e.g. There was some discussion a while ago about tacking CABAC onto XviD, 
but eventually Radek joined x264 instead.

--Loren Merritt