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

[Reimar Döffinger]

On Wed, Feb 01, 2012 at 08:00:00PM +0100, Michael Niedermayer wrote:
> On Wed, Feb 01, 2012 at 06:41:07PM +0100, Javier Cabezas wrote:
> > Indeed. But this codec doesn't work like that, it explicitly produces CFR
> > AVI files. The output should be CFR, as both the reference decoder and
> > ffmpeg did before. You can see in the commit I linked how in the v2 fate
> > test now almost all frames are removed because they are copies. ffmpeg
> > might be able to handle this, but other apps won't. And they really
> > shouldn't with Fraps.
> > 
> > Isn't kostya the original author? Maybe we can ask him. IMHO the bottom
> > line is that if ffmpeg wants to be compliant with the reference decoder it
> > should repeat them. That's the reason why the original author used
> > reget_buffer, I think.
> 
> The original author is Roine Gustafsson, blame show mike, kostya and
> reimar as significant contributors, so added who iam not sure if they
> read ffmpeg-dev to CC

I discussed it off-list before but it went nowhere.
I don't have any specific example where this would be _needed_, it
adds significant, complex code (IMHO more complex than the decoder
itself) and it is worse performance.
Even if there were problems, finding another way would be highly preferred.
At least when easily possibly, it is better for a decoder to signal when
frames are identical instead of duplicating them internally
which in itself is additional processing and might have even more
significant follow-on processing, e.g. when doing high-quality
scaling, denoise or similar.

> If we can find a consensus that would be great. If not then whoever
> volunteers to maintain the file (in the has a git clone of ffmpeg and
> volunteers to review patches & fix regressions in it) shall decide
> If we have no such person, ill try to find a coin and toss it ;)
> so it will be better if someone does volunteer ...

Due to the above the submitter will not be helped by me volunteering.
Though the code is really trivial and not really an effort to maintain,
The issues really only come in with the huffman coding.
Which I am fairly certain differs between v2/3 and v4/5, more
specifically the handling of symbols with 0 count (see issue 75).
Removing the flag FF_HUFFMAN_FLAG_ZERO_COUNT as stated there changes
things but does not really fix it, which is not surprising since the
huffman tree then ends up with nodes (i.e. not symbols) as leaves.
"Fixing" that however makes it only look worse, so no idea what would
be the correct behaviour and reverse-engineering that seems like a lot of
pain.