> On Friday, October 17, 2014 2:30 PM, Nicholas Robbins <nickrobb...@yahoo.com> > wrote:
> <snip actual request> > > Ok, it seems like this should be easier. If we had a filter that did the same > thing as vf_perspective but with inverse options this would be easy. So > instead > telling it what points you want to send to the corners, you tell it where you > want the corners sent. > > I ran the math and the formulas to map between the two different ways of > specifying the projective transformation are a bit messy. For instance, if > you > want to send the corners to x0:y0:x1:y1:x2:y2:x3:y3 the first option for the > vf_perspective should be > <snip messy formula> > > not something you can put on the command line or even want to work out by > hand. > However, it would be totally doable to calculate in filter initialization. > > So is it possible to make a filter that is basically just a wrapper around > another filter? This hypothetical filter (call it vf_keystone) would just > call > vf_perspective with crazy options. Clearly I could just copy the > vf_perspective > filter and then insert these changes, but than any future changes to > vf_perspective wouldn't filter down to vf_keystone. > > Is this possible? > > -Nick Upon further thought and a closer read of the vf_perspective code, I think an easier option would be to insert an option of "sense" or "mode" or something. Then condition the code at lines 144-160 (these lines calculate the matrix used for the transformation) and then put in another block conditioned on the "mode" that finds the inverse matrix rather than the matrix currently found. Is this a reasonable approach? If so, I think I'll put this in in a little while. -Nick _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
