[Ffmpeg-devel-old] Re: [Ffmpeg-devel] Snow motion blocks

[Robert Edele]

On Tue, 2005-04-19 at 00:26 -0400, Rich Felker wrote:
> On Mon, Apr 18, 2005 at 10:49:58PM -0400, Robert Edele wrote:
> > > I haven't been following this discussion, but I'd be very interested
> > > in replacing snow's motion comp with linear interpolation if empirical
> > > results turn out to be good. The higher order interpolation we're
> > > using now is much slower, and since it's effectively a sharpening
> > > filter, it probably adds artifacts that make it more difficult for the
> > > wavelet transform to encode the residue efficiently (i.e. more
> > > high-frequency coefficients).
> > > 
> > > My naive guess would be that higher-order motion comp has effects
> > > similar to mpeg_quant for mpeg4 encoding, i.e. improved psnr at very
> > > low quantizers, but worse quality (esp. worse artifacts) at higher
> > > quantizers. Unless removing it makes low-quant snow a LOT better at
> > > compression, I think the speed issue is enough to put me strongly in
> > > favor of using linear interp. But I'd like to hear more points on all
> > > sides.
> > > 
> > > Rich
> > I have lots of varied results, but they were from before my mc_block
> > patch was applied. In particular, animation benefited from linear, but
> > animation also triggered the mc_block bug the most (sharp black lines,
> > and especially heavily white material like an episode of Caillou that I
> > was using for testing, overflowed mc_block a lot). Linear did not
> > trigger the mc_block bug, so it was unfairly favored before.
> 
> But on a theoretical basis it should be favored. Anything other than
> linear essentially amounts to just doing stupid loop filters after
> motion comp (sharpening filter).
This filter IS motion comp. What you want is for the pixels to match as
closely as possible to what the actual pixel is, to save bits.
> 
> > What I do know is the choice of interpolation is quite important, easily
> > causing an over 10% change in file size (and an added effect from psnr).
> 
> Are you sure it doesn't just change the psnr at a given quantizer? If
> you're going to make comparisons you MUST hold all but two variables
> fixed and let one vary depending on the other. For instance compare
> psnr at a fixed bitrate, or file size at a fixed psnr...
psnr went up as file size went down, and vice versa. I wouldn't have a
clue how to separate the two, but as they both go the same way, it
doesn't really matter.
> 
> > Since the change can run both ways, perhaps having two mc methods and
> > making it an option (speed and good animation/MPEG transcode
> > performance, or slower but better live performance).
> 
> IMO this is stupid.
> 
> > I might very well also just brute-force a solution. There are only about
> > 10,000 or so possible values for 6 coefficients (assuming symmetry).
> 
> Do you even understand what you're doing??
Not exactly, but brute force doesn't require that.
> 
> > BTW, any comments about trying bi-cubic instead of bi-linear?
> 
> Do you know what it means??
Yes. You use a cubic (ax^3 + bx^2 + cx + d) interpolation to figure out
a pixel value, using 4 coefficients as inputs, instead of two inputs and
linear (ax + b) interpolation. It generally gets you closer to the
'real' value, which hopefully would mean a better motion comp match.

Robert