[Ffmpeg-devel-old] Re: [Ffmpeg-devel] Snow motion blocks
Tue Apr 19 04:49:58 CEST 2005
On Mon, 2005-04-18 at 14:39 -0400, Rich Felker wrote:
> On Mon, Apr 18, 2005 at 09:20:46PM +0300, Tuukka Toivonen wrote:
> > > Details at: http://skal.planet-d.net/coding/interpolation.html
> > Ah. Finally I understand, I hope, your paper main idea. So you
> > generalize half-pixel linear interpolation into "infinite resolution"
> > linear interpolation, compute analytically the optimum MV in this
> > infinite resolution, and then round it to the nearest
> > half- or integer pixel location.
> > Interesting idea. I actually found your page when I was looking
> > for material for my paper, but back then I didn't quite understand it.
> > Might work nicely if newer standards such as H.264 would use
> > linear interpolation for fractional pixel interpolation, but as they don't,
> > the methods are less useful :(
> 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
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.
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).
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).
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).
BTW, any comments about trying bi-cubic instead of bi-linear?
More information about the ffmpeg-devel