Opened 8 years ago

Closed 8 years ago

#963 closed defect (needs_more_info)

[PATCH] Fraps: restore old behavior regarding P frames

Reported by: STaRGaZeR Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: fraps
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


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 ( 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.

Attachments (1)

frapsMTv2.patch (15.3 KB) - added by STaRGaZeR 8 years ago.

Download all attachments as: .zip

Change History (5)

Changed 8 years ago by STaRGaZeR

comment:1 Changed 8 years ago by richardpl

Is decoding broken or what?

comment:2 Changed 8 years ago by 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.

comment:3 Changed 8 years ago by cehoyos

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

comment:4 Changed 8 years ago by cehoyos

  • Resolution set to needs_more_info
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.