[FFmpeg-devel] [PATCH] display: Add AVDisplayOrientation API

Michael Niedermayer michael at niedermayer.cc
Fri Apr 6 02:08:18 EEST 2018


On Thu, Apr 05, 2018 at 01:51:10PM +0200, Vittorio Giovara wrote:
> ---
> > On Wed, Apr 04, 2018 at 05:30:24PM +0200, Vittorio Giovara wrote:
> > >  libavutil/display.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >  libavutil/display.h | 53 ++++++++++++++++++++++++++++++
> > >  2 files changed, 145 insertions(+)
> 
> >     It might be more usefull to fully factorize the matrix than these special cases
> > 
> >     for example the matrix can be described by these 4 scalars
> >     1. rotation
> >     2. horizontal scale
> >     3. vertical scale
> >     4. shear
> 
> With the proposed API the matrix is already factorized: a mask is returned
> containing a set of  operation. Special cases such as custom rotation is
> already factorized, as in you need to call an additional function on the
> same matrix to know more about the rotation angle. On the other hand the
> most common cases are already ready to be used right away.

no, the proposed API is not equivalent if thats what you mean.

What i suggest gives a single unique factorization represented by 4 scalar values

The API proposed prior does not gurantee a unique result. Instead a single
matrix can be represented by a almost infinite number of operations
In practice this means you cannot test the factorization by a simple
equality check as a single matrix can be factored in many different ways.

Also the prior API has a issue with order of operations. These operations
are not commutative, the order of flip and rotate makes a big difference.
And at this point i do not see what it can even be used for.
The rotation angle is different for example depending on what other operations
are done before and after the rotation for a matrix.


[...]
> 
> >     (there are more parameters like translation and z specific changes but IIUC
> >       these have no meaning ?)
> 
> Correct given that video right now is a 2d surface we can ignore anything
> related to the depth axis.
> 
> >     Note fliping in above would be a negative scale value
> >     shear could be specified as the angle between the x/y basis vectors
> > 
> >     The reason i suggest this is that these 4 values are easier to understand
> >     for a human and should allow reconstructing an equivalent transform matrix.
> >     While at the same time not limiting things to a subset of special cases
> > 
> 
> 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.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180406/6d3e4851/attachment.sig>


More information about the ffmpeg-devel mailing list