[FFmpeg-trac] #9447(avfilter:closed): avfilter/vf_v360 interprets commands as relative rotation offsets
FFmpeg
trac at avcodec.org
Wed Oct 20 15:14:05 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):
Landed in the mpv build now allowing for more complex testing of rotating
multiple axes asynchronously.
The need to re-state the rotations for axes intended to be unmodified
becomes quite troublesome, for example combining a:
yaw from -45 to 45 from 2-6s alongside a
pitch from -45 to 45 from 4-8s
Requires the pitch commands to be split up so that there are three
separate command intervals for this movement, one for pure yaw, one for
pitch and continuing the yaw movement, one for pitch alone but re-stating
the now unmodified yaw.
In doing that I'm occasionally seeing quick flashes of some of rotations
reset to 0 as intervals switch - I suspect it's either timestamp precision
or the alignment of the timestamp in the command script and the
presentation timestamp of the frame for which the interval expression is
being evaludated.
I suppose the core questions are:
- Is it necessary to switch off reset_rot every command evaluation?
- Is it necessary to zero pitch,yaw,roll every evaluation while in
reset_rot mode?
I'd tentatively suggest something like this might be a better way of
handing the flag and rot resets:
{{{
static int process_command(AVFilterContext *ctx, const char *cmd, const
char *args, char *res, int res_len, int flags)
{
V360Context *s = ctx->priv;
int ret;
if (s->reset_rot) {
reset_rot(s);
} else {
s->yaw = s->pitch = s->roll = 0.f;
}
ret = ff_filter_process_command(ctx, cmd, args, res, res_len, flags);
if (ret < 0)
return ret;
return config_output(ctx->outputs[0]);
}
}}}
As it removes the side effects of resetting the untouched rotations and
allows consistent setting of reset_rot mode once, perhaps I'm missing
something, particularly in calling reset_rot before
ff_filter_process_command?
--
Ticket URL: <https://trac.ffmpeg.org/ticket/9447#comment:22>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list