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

FFmpeg trac at avcodec.org
Mon Oct 4 18:31:52 EEST 2021

#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

 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

More information about the FFmpeg-trac mailing list