[PATCH] Fraps: restore old behavior regarding P frames

[STaRGaZeR]

Recently there have been several commits by Reimar changing the Fraps decoder behavior regarding P frames. 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 video. 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. 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 big.

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.

[Elon Musk]

Is decoding broken or what?

[STaRGaZeR]

Yes. P frames, or repeated frames, are not delivered anymore. That's because they're now considered skip, but they are not. It's all in the bug report.

[Carl Eugen Hoyos]

Please send patches to ffmpeg-devel where they can be discussed.

[Carl Eugen Hoyos]

​http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/140807

Please reopen this ticket if you can explain the use-case where the new behaviour is a regression (and not an improvement).