[MPlayer-users] non-mod16 resolutions
D Richard Felker III
dalias at aerifal.cx
Wed Sep 15 10:37:36 CEST 2004
On Wed, Sep 15, 2004 at 08:42:25AM +0100, Martin Collins wrote:
> On Tue, 14 Sep 2004 12:28:41 -0700 (PDT)
> Loren Merritt <lorenm at u.washington.edu> wrote:
> > changed.
> That's better :-)
> Interesting that the bitrate increases linearly with the resolution
> rather than as the square as one would (naiively) expect.
yes, very interesting since i hypothesized this in the draft encoding
guide, i.e. that bits_per_pixel should not be used, but instead
bits_squared_per_pixel, for the purpose of scaling image size versus
quality. it's nice to see it backed up by data.
anyway the naive expectation comes from disregarding the nature of the
dct or frequency-domain transforms in general. from a space-domain
perspective, when you scale down a portion of the pixels are lost, and
the size of the raw uncompressed image goes down accordingly. but from
a frequency-domain perspective, when you scale down you're shifting
the data up to higher-frequency coefficients. if there were already
data in the high-frequency coefficients, it would be lost, but in
practice many high-freq coefficients are (near-)zero for high
ideally, in the extreme case where all the high-freq coefficients are
zero, scaling down should not decrease the bitrate at all! but mpeg
based codecs suck and have a lot of needless overhead per block, so
even then it makes a little difference.
high-freq coefficients 0: bitrate constant
high-freq coefficients large: bitrate scales with pixels
high-freq coefficients small: hard to predict rigorously but in
practice bitrate scales with sqrt(pixels) as seen in this data
disclaimer: i tried to keep the above simple and intuitive, at the
expense of rigor. please don't flame for this. :) things are actually
a little more complicated.
More information about the MPlayer-users