[MEncoder-users] Adding harddup as an afterthought?

[Rich Felker]

On Fri, Sep 28, 2007 at 11:08:27PM +0000, Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was NOT [per weedlist] sent to
> Loren Merritt 
> <mencoder-users at mplayerhq.hu>], who wrote in article <Pine.LNX.4.64.0709280042190.1467 at akuvian.org>:
> > >>   b) if the preceding frame is B, duplicate it?
> > >>
> > >> (Of course, it could overload the maximal count of B-frames supported
> > >> by the player; but I do not think the probability of this mattering is
> > >> high...)
> > 
> > I don't know of any players that have any limit on the number of B-frames
> > (except maybe Quicktime, which is broken in too many ways to count)
> > 
> > > This would probably work decently, albeit wasting some space.
> > 
> > B-frames' mvs are predicted from the following P-frame's mvs.
> > And the prediction formula depends on the relative frame numbers, so 
> > inserting a new B-frame would break any existing adjacent B-frames even 
> > if you got the new frame to work.
> 
> Now I'm completely lost: how the player is suppose to number B-frames
> in the presence of 0-frames?

These “0-frames” are not frames. They’re simply times at which there
is no frame to present, for the purpose of fitting a
fixed-time-increment container format. The decoder should never see
them.

> [And anyway, one could move the 0-frame up to the next P-frame; its
> exact location is not very crucial, right?]

Indeed, this should be tolerable in many cases.

Rich