[FFmpeg-trac] #9447(avfilter:closed): avfilter/vf_v360 interprets commands as relative rotation offsets

[FFmpeg]

#9447: avfilter/vf_v360 interprets commands as relative rotation offsets
------------------------------------+------------------------------------
             Reporter:  Saul Baker  |                    Owner:  (none)
                 Type:  defect      |                   Status:  closed
             Priority:  normal      |                Component:  avfilter
              Version:  git-master  |               Resolution:  invalid
             Keywords:  v360        |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |
------------------------------------+------------------------------------
Comment (by Saul Baker):

 Replying to [comment:5 Elon Musk]:
 > Please refrain from reopening or commenting on this issue if you have
 not anything new and relevant to add.
 >
 > Also perhaps you want to solve your issues the wrong way from start.

 I genuinely feel that the previous behaviour was more applicable to use
 cases of the filter, certainly in that repo example and Michael's book
 code it's the most direct and standardised expression of how to manipulate
 the filter - incremental stateful adjustment simply seems like the wrong
 model.

 Replying to [comment:7 Michael Koch]:
 > I would always choose absolute angles. In my opinion, relative angles
 are useless.

 Yeah, I'm struggling to think of a situation where the relative would be
 useful, other than when you're seeing real-time output and want to nudge
 it manually but that doesn't really fit the ways the commands are used, at
 least through ffmpeg and sendcmd perhaps libav world is different?

 Implementation wise: a mode or secondary property to target for relative
 rotation could use the flow in '''process_command''' as it stands at the
 moment whereas absolute rotation via mode or the default properties could
 reset the '''rot_quaternion''' prior to '''ff_filter_process_command'''?

 I appreciate that this is designed to make some use cases more pleasant
 and prevent the users getting into recoverable but confusing situations -
 but I think it's undeniable that there's a tension between this behaviour
 - how commands and users expect to update filter parameters, and what
 makes the most sense in defining scripted reprojection.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/9447#comment:8>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker