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

[Javier Cabezas]

As I told you several times, here's an example of stuff that happens with
Fraps. When you are recording something with a very low refresh rate (i.e.
desktop) at 30 fps, for every 30 seconds of video you can have only 1-2 I
frames and the rest are repeated frames. When using avcodec now to decode
it, so it can be converted/processed it into a more common format like
H.264, I get 2 frames at the output each 30 seconds, instead of 900.
Processing VFR is a nightmare. Sure, I can hack around it and after
spending the morning on it I could get to something usable to feed an
encoder with. Or I could just use the Fraps decoder directly and don't use
avcodec at all. Remember, Fraps is a CFR codec. If I tell Fraps to record a
30 fps video and when decoding I get an average of 1 fps and VFR, the
output is useless.
 I'd love to give you a sample but they are freaking huge, it'd take me
days to upload one. Best it's to create them yourself.

And I also forgot to answer your earlier, sorry. The new code is complex
because the old code uses reget_buffer. This optimization did the frame
copy behind the scenes. It cannot be used with multithreading, so a new
copy function had to be added before removing it. And to add multithreading
contexts have to be updated as new frames are decoded, hence the
update_thread_context function. Both are the bulk of the patch, and both
are needed to get the needed functionality. I don't see how they are more
complex than the decoder itself, the copy function IS part of the decoder
itself. And the update function is needed for MT.


2012/2/5 Reimar Döffinger <Reimar.Doeffinger at gmx.de>

> On 5 Feb 2012, at 20:47, Javier Cabezas <jcabgz at gmail.com> wrote:
> > Then I'll leave this to you guys. I'll use the patch privately and update
> > if things in ffmpeg change in the future, because I can't use it the way
> it
> > is now.
>
> If you report what exactly you are trying to do that is broken now there's
> at least a chance someone will figure out the best way to fix it and do it.
> As long as the only argument we know about is that you really want it to
> behave differently but have no test-case to reproduce a real issue while
> ffmpeg itself works just fine you'll probably have to maintain that patch
> indefinitely.