[FFmpeg-devel] [PATCH] Fraps: restore old behavior regarding P frames
jcabgz at gmail.com
Thu Feb 9 20:48:14 CET 2012
Too vague? For god's sake, I can't believe that. I think it's crystal clear
already after 20+ PMs/emails: I need/want avcodec to give me those repeated
frames, like the reference decoder does and like avcodec did before your
changes. Is it clear now or not? I hope yes, because I won't comment on
this anymore. I think I've already lost enough time trying to convince you
to fix something you broke, with all good intentions I'm sure, but you
I hope other people summiting patches and coding for the good of the
community are treated better than me, because this wasn't pleasant at all.
I don't really feel like contributing again. Maybe the fork is a better
place to do things like this after all, their Fraps decoder isn't even
Do what you feel best. No hard feelings.
2012/2/6 Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> On Mon, Feb 06, 2012 at 07:17:28PM +0100, Javier Cabezas wrote:
> > As I told you several times, here's an example of stuff that happens with
> > Fraps.
> And as before it is too vague for anyone to be able to really
> investigate and check alternative fixes.
> > 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.
> Which program are you using to do this conversion?
> Can it not be configured how to encode as e.g. FFmpeg can (why not)?
> And why is it a problem that you get only two frames / 30s in the
> output H.264? Which concrete problem does that cause it that you
> not only consider it an annoyance but even say that with the new
> behaviour the FRAPS decoder is useless to you?
> > 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.
> Well, I sure do think that the additional threading code is harder
> to understand code than all the rest of the decoder together
> (except the huffman code, but that is mostly because it was and
> probably still is needlessly obfuscated).
> But maybe that's just me.
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel