[MEncoder-users] Adding harddup as an afterthought?

[Reimar Döffinger]

Hello,
On Sat, Sep 29, 2007 at 06:36:48PM +0000, Ilya Zakharevich wrote:
> [A complimentary Cc of this posting was NOT [per weedlist] sent to
> Rich Felker 
> <mencoder-users at mplayerhq.hu>], who wrote in article <20070929071846.GM246 at brightrain.aerifal.cx>:
> 
>    > > 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?
> 
>    0-frames are not frames.  They are 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.
> 
> Let me restate my question: if decoder gets
> 
>   P 0 0 0 0 0 0 0 0 0 B P
> 
> how should it predict the movements of the B frame?  By 0.5 of
> movement of (the second) P, or by 0.9 of it?

There is no "0" for the decoder, the decoder gets P B P.
All the "0"-frames do is tell the _player_ that it should display the P
frames for 10 times the normal time. This is just a hack for containers
that do not support arbitrary timestamps but only fixed fps.
Again, the decoder is in no way involved in handling the 0-frames. In a
framework like ffmpeg actually nobody besides the demuxer will even be
able to see them.

Greetings,
Reimar Döffinger