GNOME Bugzilla – Bug 764667
videoaffinetransformationmeta: doesn't define the coordinate space
Last modified: 2016-05-15 07:54:54 UTC
i.e. currently it's not defined whether it operates on vertex values between [0, 1] or [-1, 1] or put another way, where the origin is which is an important consideration when writing/integrating transformation matrices. e.g the flip matrix is different between the two above mentioned coordinate spaces. [0, 1]: 1, 0, 0, 0, 0, -1, 0, 0, 0, 0, 1, 0, 0, 1, 0, 1, Origin is in a corner. [-1, 1]: 1, 0, 0, 0, 0, -1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, Origin is in the centre. In the wild, both conventions are used in different places. In OpenGL, vertex coordinates use [-1, 1], texture coordinates are [0, 1]. DirectX seems to be the same except the z-axis is [0, 1] and uses a different handedness (another thing to define) in their coordinate system. The current assumption by android MediaCodec is that the matrix is used for texture coordinates, i.e. [0, 1] however changing between them is relatively easy (another two matrix transformations).
I think the only thing we can do here for backwards compat is to define it to the coordinate space we're currently assuming. A version 2 of that meta could then get a flag to switch. But as you say, conversions are rather simple anyway.
> A version 2 of that meta could then get a flag to switch. Just to be sure, we can extend existing meta structs without breaking API/ABI, they're never allocated on the stack after all.
Yes, but existing users of the meta would not know about that field... and as that field changes expected behaviour, they would behave wrong if the field is set to a different value than what is currently assumed.
Created attachment 327877 [details] [review] video/affinetransformationmeta: define the coordinate space used.
commit 1e3f5e0ecf6795034c87e09447d0bca935cb098e Author: Matthew Waters <matthew@centricular.com> Date: Sat May 14 15:43:24 2016 +0300 video/affinetransformationmeta: define the coordinate space used Based on the expected output from the already existing usage by androidmedia and the opengl plugins. https://bugzilla.gnome.org/show_bug.cgi?id=764667