[FFmpeg-devel] [PATCH] Fraps: restore old behavior regarding P frames

[Javier Cabezas]

Indeed. But this codec doesn't work like that, it explicitly produces CFR
AVI files. The output should be CFR, as both the reference decoder and
ffmpeg did before. You can see in the commit I linked how in the v2 fate
test now almost all frames are removed because they are copies. ffmpeg
might be able to handle this, but other apps won't. And they really
shouldn't with Fraps.

Isn't kostya the original author? Maybe we can ask him. IMHO the bottom
line is that if ffmpeg wants to be compliant with the reference decoder it
should repeat them. That's the reason why the original author used
reget_buffer, I think.

2012/2/1 Michael Niedermayer <michaelni at gmx.at>

> On Wed, Feb 01, 2012 at 03:16:47AM +0100, Javier Cabezas wrote:
> > Recently there have been several commits by Reimar changing the Fraps
> > decoder behavior regarding P frames, this one being the first one (
> >
> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6a9b565e0a238b475e036c2e0a77b991cb0a3efb
> ).
> > These frames are not skip frames, but repeat frames, as seen here (
> > http://wiki.multimedia.cx/index.php?title=Fraps) and confirmed by
> looking
> > at the reference decoder's output. Since Fraps is both a screen capture
> > codec and a CFR codec, when it records something with a refresh rate
> slower
> > than the target fps specified in its settings it adds these repeat frames
> > to achieve the target framerate.
> >
> > By removing reget_buffer and outputting nothing when a P frame is
> reached,
> > the decoder is now VFR and not compliant because of the reasons explained
> > above. There can be files with 1 I frame at the beginning and the rest
> > being P frames, in this situation ffmpeg now outputs only 1 frame for the
> > entire duration of the sample. I've been talking to Reimar, but he thinks
> > that since visually a repeated frame and a skip frame are the same, the
> > current behavior is correct and saves processing power. The problem is
> that
> > it renders the output unusable depending on the number of these repeated
> > frames and it's completely different from the reference decoder's output.
> > I've written a patch that fixes the regression by outputting these
> repeated
> > frames when it should as before, but needs review as the changes required
> > to do this and MT at the same time are quite large.
>
> It would be alot easier to duplicate the frames in the application
> like ffmpeg. Which actually, it should do already when needed.
>
> Also do we have a maintainer for fraps? Or someone who volunteers to
> maintain it (maintainer == someone with a git tree who reviews patches
> and applies them to his tree and fixes regressions)
> ?
>
> If we have a maintainer (or volunteer) he should review this and
> decide.
>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> it is not once nor twice but times without number that the same ideas make
> their appearance in the world. -- Aristotle
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>