[FFmpeg-cvslog] r18421 - trunk/libavcodec/pngdec.c

Reimar Döffinger Reimar.Doeffinger
Fri Apr 10 22:21:02 CEST 2009


On Fri, Apr 10, 2009 at 03:57:46PM -0400, Ronald S. Bultje wrote:
> Now that we're on the subject of this anyway, can someone explain me
> in layman terminology how this works? It seems like these P-frames are
> a mask (i.e. nearly-black) of a "difference" between the last frame
> and the current actual frame, and I suppose near-black is easier to
> encode (lower bitrate, because less "signal").

It is not a mask, it is the difference (delta), in this case byte-wise,
between two files. If only small parts of the video change most of the
difference has the same value (0) and thus is trivial to compress.
The same applies for fade-ins/fade-outs of a still frame, the delta is
mostly the same for all pixels (though non-zero), which is basically just
as simple to compress.
The precise values usually do not matter much for compressibility, how
"random" they are matters - which btw. is one way to test whether data
is random, it is very unlikely that you can compress random data at
all, no matter the algorithm.
Which is why part of a compression often is some way to transform the
input data so it "looks" less random to your compression
algorithm.

> So here's what I don't understand: pd is a uint8 and pd_last is a
> uint8, so every pixel in the mask is always positive. Doesn't that
> make no sense at all? Shouldn't a mask be (for reatively stable noise
> / rando input) zero on average, i.e. some negative, some positive?

If you always walk east shouldn't you then get lost in the infinity
instead of coming (more or less) back to home from the other side?
A uint8_t variable just like the earth is of limited size. So if you
always add one you will somewhen end up at the start.
Or in short 255 + 1 == 0.
Which also means that 255 == -1.



More information about the ffmpeg-cvslog mailing list