Using dynamic inputs to support the additional plugins seemed
preferable over seperate filters. For backwards compatibility, all
frame properties are copied from the first input, adjusting only
the necessary ones for multiple inputs.
Signed-off-by: Stefan Breunig
---
doc/filters.texi
The filter test exercises the timeline editing and uses a filter
which depends on the time parameter.
Signed-off-by: Stefan Breunig
---
tests/fate/filter-video.mak | 9 +
tests/ref/fate/filter-frei0r-filter | 10 ++
tests/ref/fate/filter-frei0r-source | 10 ++
3
av_frame_copy doesn't copy the input's PTS property, which resulted
in the frei0r filter always receiving the same (non-sensical) time.
For example, this results in a static distortion, when it should be
changing over time:
ffmpeg -filter_complex "testsrc2=s=342x142:d=5,frei0r=distort0r" out.mp4
The frei0r API expects the time in seconds, but was given it in
milliseconds. The bug might exist since 41f1d3a (~14 years ago),
but plugins depending on the time are unwatchable without this
patch. For example:
ffmpeg -filter_complex "testsrc2=d=5,frei0r=distort0r" out.mp4
Signed-off-by: Stefan
+if (in[i]->linesize[0] != out->linesize[0]) {
+AVFrame *aligned = ff_default_get_video_buffer2(outlink, outlink->w,
outlink->h, 1);
+ret = av_frame_copy(aligned, in[i]);
+copies |= 1 << i;
+in[i] = aligned;
+goto end;
+}
Hi Michael,
This affects users, so it needs to be documented.
Good hint. I assume you meant in the Changelog, even if it is otherwise
relatively high level compared to this change?
Do you know someone who may be interrested in maintaining
vf_frei0r in ffmpeg ?
Unfortunately not. The upstream
--- Begin Message ---
The frei0r API expects the time in seconds, but was given it in
milliseconds. The bug might exist since 41f1d3a (~14 years ago),
but plugins depending on the time are unwatchable without this
patch. For example:
ffmpeg -filter_complex "testsrc2=d=5,frei0r=distort0r" out.mp4
