I'd like to suggest to revert this patch for the v360 filter:
http://ffmpeg.org/pipermail/ffmpeg-cvslog/2020-October/124887.html
Why should it be reverted?
-- Because after this patch, the yaw, pitch and roll angles have a
different meaning. If they are set in the command line, they are
interpreted as absolute angles. However if they are sent via sendcmd,
they are interpreted as relative angles.
-- As far as I know, no other filter has such behaviour where an option
gets a different meaning if it's set via sendcmd.
-- It's impossible to test a rotation in the command line, and later set
the same rotation via sendcmd. The result would be totally different.
-- It breaks previously correct behavior. See for example chapters 2.111
and 2.115 in my book:
http://www.astro-electronic.de/FFmpeg_Book.pdf
-- It's undocumented.
-- I don't see any workaround to simulate an absolute rotation with
relative rotations. I've tried it but it doesn't work. It might work for
one rotation axis, but if two or three axes are involved simultaneously,
it gets extremely complicated.
Why was this patch made?
-- Because there was a problem with gimbal lock in some rare cases. I
never saw this problem.
What's the correct way to solve this problem?
-- Most important is to revert this patch. That means there will be
gimbal lock in some rare cases. The user has to take care of it, and
avoid these rare cases.
-- New options could be added for relative rotations: rel_yaw,
rel_pitch, rel_roll. Then the user could decide if he prefers absolute
or relative rotations. However from my point of view, I don't need
relative rotations.
See also ticket 9447.
Michael
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
