[FFmpeg-devel] [PATCH] Fraps: restore old behavior regarding P frames
Michael Niedermayer
michaelni at gmx.at
Wed Feb 1 05:34:56 CET 2012
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120201/3188ae3c/attachment.asc>
More information about the ffmpeg-devel
mailing list