[FFmpeg-devel] [RFC] Affine video transformation filter

[Michael Bradshaw]

On Thu, Jul 5, 2012 at 9:46 AM, Nicolas George
<nicolas.george at normalesup.org> wrote:
> Le septidi 17 messidor, an CCXX, Michael Bradshaw a écrit :
>> However, I'm not sure how to best handle the overlapping functionality
>> of affine transformations and existing filters. We already have
>> transpose, scale, v/hflip (and maybe others?) video filters, which
>
> IMHO, redundancy is not a problem provided the reason for it are good and
> well understood by everyone. In this particular case, I think it is
> perfectly fine: everyone should be able to realize that a hflip filter is
> simpler to use and faster than a generic affine filter, but can only be used
> for horizontal flipping.

Good to hear, I feel the same. A single affine filter could also give
better (quality and/or speed wise) results than chaining multiple
filters together because it resamples the image once instead of
repeatedly, so it certainly (theoretically) has some merit, at least.

>> Should overlapping functionality be removed (i.e. disable scaling)
>> from the affine transformation filter?
>
> How would you do that, anyway?

By not exposing those options :) Some things could actually be removed
from the matrix (like translation), but other things are too similar
to do that (like rotation and scaling + skewing, as they're
essentially the same operation). I probably wouldn't have messed with
the matrix though; I would've just hidden/removed options.

>> haven't thought of a way to specify the background fill color that I
>> like, though.
>
> That is a problem for all filters that may leave part of the video blank:
> pad (has a color option), tile (arbitrary black), etc. A global solution
> would be welcome.

What kind of a global solution, do you mean? One for
specifying/parsing the color option or one for applying the color? If
you're talking about the specifying/parsing aspect, I've actually
wondered what it might be like to have proper AVOptions for filters,
but I haven't thought of a decent way to parse them (simplest case is
"name=value", separated by colons or something)...

> As a side note, I wonder how much a good anti-aliasing algorithm is
> important for an affine transform. I have the notion that adding a ×2 or so
> factor to the affine transform and then downscaling with a good and highly
> optimized downscaler would give almost as good and fasts results with much
> less code.

I wonder how that would compare to just doing bilinear sampling...

Thanks,

Michael