On 6 April 2018 at 17:59, Vittorio Giovara <vittorio.giov...@gmail.com> wrote:
> Yes the order of operations is a problem in a generic matrix, but for a > display matrix the order is more or less consolidated in a defacto > standard: > check for flip first, then rotation. We have the same pattern in h264 and > hevc decoder for the rotation side data. > > You are right that the description of the API does not convey the order > and that it should be better documented, although I don't have a specific > standard to quote (besides what is already mentioned in display.h). > > > > The "special cases" are also the most common operations that every > player > > > implements so I think it makes sense to have them readily available, > with > > > as few calls as possible. > > > > With what i suggest, not sure i explained it well enough > > there would be a single call to provide a struct or array of 4 scalars > > a 90 degree to the right rotation would for example have a > > {90, 1, 1, 0} and could be checked for by memcmp() or a more specialized > > function that returns a scalar "difference" > > so testing for these common operations should be very simple and compact. > > Testing for another angle of rotation or other transform would be > similarly > > simple. > > > Well the only downside of that is that we are replacing a well-known set of > instructions coded in a 3x3 matrix with a ffmpeg-only 4x1 array of > integers. > You would need special code and documentation to parse either the matrix or > the array, so it kinda defies my attempt at simplifying the API: I feel > like > having a negative scale factor to represent a flip is as complex as having > euclidean math to compute the rotation angle when the allowed orientations > are just 4. > > On the other hand, I'm not strongly advocating for one way of another, if > you could maybe point me to the right direction and share some code on how > you mean the matrix parsing should be carried out I'll try to prepare a > second version of this patch. > > Vittorio > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > I agree, I'd rather have a standard 3x3 matrix exposed than making something new up. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel