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

[Javier Cabezas]

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.

When frame multithreading reget_buffer cannot be used, so in order to have
the previous frame available when a repeat frame comes, a 2 frame buffer is
used: the current one and the previous one. This implementation of MT is
almost the same as the one used in the mimic decoder.
 frapsMTv2.patch is attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: frapsMTv2.patch
Type: application/octet-stream
Size: 15653 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120201/87af71d4/attachment.obj>