[Ffmpeg-devel-old] Re: [Ffmpeg-devel] Snow motion blocks
Tue Apr 19 06:26:57 CEST 2005
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??
More information about the ffmpeg-devel