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

[Rich Felker]

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).

> 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...

> 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??

> BTW, any comments about trying bi-cubic instead of bi-linear?

Do you know what it means??

Rich