Re: [FFmpeg-devel] [PATCH] configure: enable windres on win32/win64 if available

[Matthias Troffaes]

On Fri, Jul 9, 2021 at 9:27 PM James Almer  wrote:

> Wouldn't it make more sense to add support for rc.exe instead?


Yes, that's an excellent point, and I agree that would be better.
Additionally, I've just found the patch breaks the build on some libraries
(at least postproc), my apologies for missing that on submission.

Kind regards,
Matthias
___
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".

Re: [FFmpeg-devel] [PATCH] fix some filter dependencies

[Matthias Troffaes]

On Sun, May 9, 2021 at 9:19 AM Anton Khirnov  wrote:
> Quoting Matthias Troffaes (2021-05-03 10:14:04)
> > ... ping. Is there anything else needed?
>
> Queued, will push shortly.

Great, thanks!

> But in the future please send git-formatted patches, they require less
> work to apply.

Yes, I'll definitely keep this in mind. For the record, I reposted it
as a git-formatted patch here:

http://ffmpeg.org/pipermail/ffmpeg-devel/2021-May/279927.html

Kind regards,
Matthias
___
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".

Re: [FFmpeg-devel] [PATCH 2/2] configure: dnn needs avformat

[Matthias Troffaes]

On Thu, May 6, 2021 at 3:54 AM Guo, Yejun  wrote:
> thanks for the catch, the native backend uses AVIOContext to load model
> from file. Will push this patch soon.

You're welcome. Thanks for accepting!

Kind regards,
Matthias
___
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".

Re: [FFmpeg-devel] [PATCH 1/2] configure: fix some filter dependencies

[Matthias Troffaes]

On Tue, May 4, 2021 at 1:27 PM Matthias C. M. Troffaes
 wrote:
> Fixes builds with
>
> --disable-avcodec --disable-avformat --enable-avfilter
>
> which currently results in a broken avfilter library due to a few
> filters that require avcodec or avformat getting mistakenly
> compiled.

Note that this part of the patch series was originally posted back in February:

http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/275819.html

but it did not show up on patchwork (due to an issue with gmail,
maybe, I'm now using git send-email instead of attachment and that
seems to work better with patchwork). I'd appreciate if both patches
could be applied, if acceptable.

Kind regards,
Matthias
___
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".

Re: [FFmpeg-devel] [PATCH] fix some filter dependencies

[Matthias Troffaes]

... ping. Is there anything else needed?

Kind regards,
Matthias

On Sun, Feb 7, 2021 at 4:30 PM Nicolas George  wrote:

> Matthias Troffaes (12021-02-07):
> > Currently, ffmpeg builds with --disable-avcodec --disable-avformat
> > --enable-avfilter result in a broken avfilter library due to a few
> > filters that require avcodec or avformat are mistakenly compiled in.
> > For example, see:
> >
> >
> https://ci.appveyor.com/project/mcmtroffaes/ffmpeg-msvc-build/builds/37633531/job/x19boq3c5qi4u132#L414
> >
> > The attached patch fixes this.
>
> Should be ok, thanks.
>
> Regards,
>
> --
>   Nicolas George
> ___
> 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".
___
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".

[FFmpeg-devel] [PATCH] fix some filter dependencies

[Matthias Troffaes]

Currently, ffmpeg builds with --disable-avcodec --disable-avformat
--enable-avfilter result in a broken avfilter library due to a few
filters that require avcodec or avformat are mistakenly compiled in.
For example, see:

https://ci.appveyor.com/project/mcmtroffaes/ffmpeg-msvc-build/builds/37633531/job/x19boq3c5qi4u132#L414

The attached patch fixes this.


0014-avfilter-dependency-fix.patch
Description: Binary data
___
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".

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: Don't use restrict directly to fix build on MSVC

[Matthias Troffaes]

I can confirm this patch fixes the compile problem on MSVC. See:

https://ci.appveyor.com/project/mcmtroffaes/ffmpeg-msvc-build/build/job/get5kbjlyw6w1vi5
https://github.com/mcmtroffaes/ffmpeg-msvc-build/commit/d1cc29f4c56937ec75b297bc6feaf0fd8989a549

Kind regards,
Matthias

On Sun, Nov 10, 2019 at 1:47 AM Andreas Rheinhardt
 wrote:
>
> 004ebd4b added a function with a parameter that was declared as restrict
> and not av_restrict. This is not supported by MSVC as several FATE-boxes
> that now fail to build show. So use av_restrict.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
> Here is one of many logs of a failing build with MSVC:
> http://fate.ffmpeg.org/log.cgi?slot=x86_64-msvc15-windows-native=compile=20191110013536
>
> I don't have an MSVC setup and can therefore only attest that this patch
> doesn't affect either GCC or Clang (as expected).
>
>  libavcodec/dvdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
> index cfa0fb9905..578d7f505f 100644
> --- a/libavcodec/dvdec.c
> +++ b/libavcodec/dvdec.c
> @@ -269,7 +269,7 @@ static inline void bit_copy(PutBitContext *pb, 
> GetBitContext *gb)
>  put_bits(pb, bits_left, get_bits(gb, bits_left));
>  }
>
> -static av_always_inline void put_block_8x4(int16_t *block, uint8_t *restrict 
> p, int stride)
> +static av_always_inline void put_block_8x4(int16_t *block, uint8_t 
> *av_restrict p, int stride)
>  {
>  int i, j;
>  const uint8_t *cm = ff_crop_tab + MAX_NEG_CROP;
> --
> 2.20.1
>
> ___
> 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".
___
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".

Re: [FFmpeg-devel] [PATCH] libavfilter/af_astats: fix msvc compile error

[Matthias Troffaes]

On Mon, Apr 29, 2019 at 7:32 PM Paul B Mahol  wrote:
> On 4/29/19, Matthias Troffaes  wrote:
> > MSVC requires an explicit cast from void * to void when applying the
> > ternary conditional operator to switch between methods that return
> > void. The attached patch fixes the problem.
> >
> > For information, log of failed build:
> >
> > https://ci.appveyor.com/project/mcmtroffaes/ffmpeg-msvc-build/builds/2414/job/bbeyhavgy4kmqu7k
> >
> > Kind regards,
> > Matthias
> >
>
> Applied.

Thanks very much, Paul!

Kind regards,
Matthias
___
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".

[FFmpeg-devel] [PATCH] libavfilter/af_astats: fix msvc compile error

[Matthias Troffaes]

MSVC requires an explicit cast from void * to void when applying the
ternary conditional operator to switch between methods that return
void. The attached patch fixes the problem.

For information, log of failed build:

https://ci.appveyor.com/project/mcmtroffaes/ffmpeg-msvc-build/builds/2414/job/bbeyhavgy4kmqu7k

Kind regards,
Matthias
diff --git a/libavfilter/af_astats.c b/libavfilter/af_astats.c
index 1ec56d72cc..bb9a23a017 100644
--- a/libavfilter/af_astats.c
+++ b/libavfilter/af_astats.c
@@ -496,7 +496,7 @@ static void set_metadata(AudioStatsContext *s, AVDictionary **metadata)
 
 #define UPDATE_STATS(planar, type, sample, normalizer_suffix, int_sample) \
 if ((s->measure_overall | s->measure_perchannel) & ~MEASURE_MINMAXPEAK) {  \
-UPDATE_STATS_##planar(type, update_stat(s, p, sample, sample normalizer_suffix, int_sample), s->is_float ? update_float_stat(s, p, sample) : s->is_double ? update_double_stat(s, p, sample) : NULL, );\
+UPDATE_STATS_##planar(type, update_stat(s, p, sample, sample normalizer_suffix, int_sample), s->is_float ? update_float_stat(s, p, sample) : s->is_double ? update_double_stat(s, p, sample) : (void)NULL, ); \
 } else {   \
 UPDATE_STATS_##planar(type, update_minmax(s, p, sample), , p->nmin = p->min normalizer_suffix; p->nmax = p->max normalizer_suffix;); \
 }
___
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".

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Matthias Troffaes]

Dear Paul,

On Thu, Nov 1, 2018 at 5:26 PM Paul B Mahol  wrote:
> > I found a way of doing this differently, as I now found that tmix
> > doesn't actually step frames, unlike skipblend. For history's sake,
> > the way to get skipblend behaviour is to do something like
> > "tmix=frames=100,framestep=150" for instance assuming you want to
> > blend 100 frames, skip 50, and so on. It is *much* slower compared to
> > skipblend by quite a large factor, as tmix does a lot of redundant
> > computations, but it works.
>
> I think that adding option to skip some frames can be added.

Thanks, that would be quite useful for performance. I'll then have a
look at contributing a patch to implement such option.

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Matthias Troffaes]

Dear Paul,

On Thu, Nov 1, 2018 at 11:21 AM Matthias Troffaes
 wrote:
> Would you consider accepting a patch that added an integer "cutoff"
> option to tmix, for the purpose of setting all weights for frames
> beyond "cutoff" to 0? The reason for requesting this is that in some
> workflows, one is blending together a lot of frames at once, and
> specifying a vector of, say, 100 ones followed by a zero, when
> blending together, say, 200 frames, whilst possible, is rather
> tedious; for instance "tmix=frames=200:cutoff=100" (weights are 1 by
> default so this should then work as expected).

I found a way of doing this differently, as I now found that tmix
doesn't actually step frames, unlike skipblend. For history's sake,
the way to get skipblend behaviour is to do something like
"tmix=frames=100,framestep=150" for instance assuming you want to
blend 100 frames, skip 50, and so on. It is *much* slower compared to
skipblend by quite a large factor, as tmix does a lot of redundant
computations, but it works.

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Matthias Troffaes]

Dear Paul,

On Thu, Nov 1, 2018 at 10:34 AM Paul B Mahol  wrote:
> Duplicates funcionality of tmix filter.

Many thanks for your reply, and for pointing out the existence of the
tmix filter. Please forgive my ignorance about it. I see tmix was only
added in April this year, whilst I've been carrying skipblend (and
tried getting it upstreamed a few times) since June 2017. No matter,
it's great to see this sort of functionality finally included!

Would you consider accepting a patch that added an integer "cutoff"
option to tmix, for the purpose of setting all weights for frames
beyond "cutoff" to 0? The reason for requesting this is that in some
workflows, one is blending together a lot of frames at once, and
specifying a vector of, say, 100 ones followed by a zero, when
blending together, say, 200 frames, whilst possible, is rather
tedious; for instance "tmix=frames=200:cutoff=100" (weights are 1 by
default so this should then work as expected).

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Matthias Troffaes]

Dear FFmpeg developers,

... is there a possibility for this patch to get applied? Obviously
I'm happy to work further on the code where need be to get this
upstreamed.

Kind regards,
Matthias
On Wed, Oct 24, 2018 at 11:14 AM Matthias Troffaes
 wrote:
>
> Attached a patch which adds a "skipblend" filter, which I've been
> using for a while. My hope is that an ffmpeg developer here can merge
> it. The filter is similar to the framestep filter, but additionally
> blends frames together at each step, for a motion blur effect. The
> number of frames that are blended (i.e. the exposure time, in frames)
> can be set, allowing control over the strength of the motion blur. The
> filter has timeline support, and supports both 8-bit and 16-bit pixel
> formats. Tests and documentation included.
>
> The main use so far that I (and others) have for this filter is to
> blend down high framerate footage, generated through computer
> rendering, to produce a high quality motion blur effect.
>
> Note that a similar effect is already possible by repeatedly chaining
> the tblend and framestep=step=2 filters; see for example:
>
> https://video.stackexchange.com/questions/16552/4x-resample-videoframes-using-ffmpeg
>
> But this is limited to steps that are powers of two, and this does not
> allow an intermediate exposure time. It's also slower.
>
> In the documentation, I've also added links between framestep, tblend,
> and the new skipblend filter, to help users to find the right filter
> they are looking for.
>
> Kind regards,
> Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Matthias Troffaes]

Attached a patch which adds a "skipblend" filter, which I've been
using for a while. My hope is that an ffmpeg developer here can merge
it. The filter is similar to the framestep filter, but additionally
blends frames together at each step, for a motion blur effect. The
number of frames that are blended (i.e. the exposure time, in frames)
can be set, allowing control over the strength of the motion blur. The
filter has timeline support, and supports both 8-bit and 16-bit pixel
formats. Tests and documentation included.

The main use so far that I (and others) have for this filter is to
blend down high framerate footage, generated through computer
rendering, to produce a high quality motion blur effect.

Note that a similar effect is already possible by repeatedly chaining
the tblend and framestep=step=2 filters; see for example:

https://video.stackexchange.com/questions/16552/4x-resample-videoframes-using-ffmpeg

But this is limited to steps that are powers of two, and this does not
allow an intermediate exposure time. It's also slower.

In the documentation, I've also added links between framestep, tblend,
and the new skipblend filter, to help users to find the right filter
they are looking for.

Kind regards,
Matthias
From 9f2f5b68d664ee879eed363c309cca887443251d Mon Sep 17 00:00:00 2001
From: "Matthias C. M. Troffaes" 
Date: Wed, 5 Apr 2017 11:56:04 +0100
Subject: [PATCH] avfilter: add skipblend filter

---
 Changelog  |   1 +
 doc/filters.texi   |  30 +++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/version.h  |   2 +-
 libavfilter/vf_skipblend.c | 272 +
 tests/fate/filter-video.mak|  12 ++
 tests/ref/fate/filter-skipblend-anim-1 |  17 ++
 tests/ref/fate/filter-skipblend-anim-2 |  17 ++
 tests/ref/fate/filter-skipblend-gray-1 |  14 ++
 tests/ref/fate/filter-skipblend-gray-2 |  13 ++
 11 files changed, 379 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/vf_skipblend.c
 create mode 100644 tests/ref/fate/filter-skipblend-anim-1
 create mode 100644 tests/ref/fate/filter-skipblend-anim-2
 create mode 100644 tests/ref/fate/filter-skipblend-gray-1
 create mode 100644 tests/ref/fate/filter-skipblend-gray-2

diff --git a/Changelog b/Changelog
index 0343ce9cd1..3545b3aa75 100644
--- a/Changelog
+++ b/Changelog
@@ -94,6 +94,7 @@ version 4.0:
 - segafilm muxer
 - vfrdet filter
 - SRCNN filter
+- skipblend video filter
 
 
 version 3.4:
diff --git a/doc/filters.texi b/doc/filters.texi
index 740eec670c..59fa9bffd2 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -5775,6 +5775,7 @@ The threshold below which a pixel value is considered black; it defaults to
 
 @end table
 
+@anchor{tblend}
 @section blend, tblend
 
 Blend two video frames into each other.
@@ -5786,6 +5787,8 @@ stream, the first input is the "top" layer and second input is
 The @code{tblend} (time blend) filter takes two consecutive frames
 from one single stream, and outputs the result obtained by blending
 the new frame on top of the old frame.
+See @ref{skipblend} for blending more than two frames at once
+from the same stream.
 
 A description of the accepted options follows.
 
@@ -9992,9 +9995,11 @@ This flag is enabled by default.
 @end table
 @end table
 
+@anchor{framestep}
 @section framestep
 
 Select one frame every N-th frame.
+See @ref{skipblend} for blending skipped frames.
 
 This filter accepts the following option:
 @table @option
@@ -15508,6 +15513,31 @@ ffmpeg -i input1.mkv -i input2.mkv -filter_complex "[0:v][1:v] signature=nb_inpu
 
 @end itemize
 
+@anchor{skipblend}
+@section skipblend
+
+Skip frames whilst blending skipped frames, for a motion blur
+effect. The number of frames that are blended (i.e. the exposure time,
+in frames) can be controlled, allowing control over the strength of the
+motion blur.
+See @ref{framestep} for skipping frames without blending.
+See @ref{tblend} for blending consecutive frames without skipping.
+
+This filter accepts the following options:
+@table @option
+@item step
+Skip @code{step} frames each step.
+Allowed values are positive integers between @code{1} and @code{65535}.
+Default value is @code{1}.
+@item blend
+Blend the first @code{blend} frames on every step,
+to produce a motion blur effect.
+Allowed values are positive integers between @code{1} and @code{step},
+where @code{1} corresponds to no motion blur, and @code{step}
+corresponds to maximal motion blur.
+Default value is @code{step}.
+@end table
+
 @anchor{smartblur}
 @section smartblur
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 7beec310f8..1eaa47d9b6 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -356,6 +356,7 @@ OBJS-$(CONFIG_SHUFFLEPLANES_FILTER)  += vf_shuffleplanes.o
 OBJS-$(CONFIG_SIDEDATA_FILTER)   += f_sidedata.o
 OBJS-$(CONFIG_SIGNALSTATS_FILTER)+= 

Re: [FFmpeg-devel] [PATCH v2 2/3] avformat/mxfenc: write reel_name if metadata key is present

[Matthias Troffaes]

Dear Mark,

On Thu, Nov 30, 2017 at 4:53 AM, Mark Reid  wrote:
> clang give me a warning telling to do this instead
> packages[3] = {{0}};
> I assume thats correct as I see thats used throughout the codebase.

Ah yes, that's perfect - good catch.

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/3] avformat/mxfenc: write reel_name if metadata key is present

[Matthias Troffaes]

Dear Mark,

On Wed, Nov 29, 2017 at 4:11 AM, Mark Reid  wrote:
> @@ -1445,12 +1463,13 @@ static int 
> mxf_write_header_metadata_sets(AVFormatContext *s)
>  AVDictionaryEntry *entry = NULL;
>  AVStream *st = NULL;
>  int i;
> -
> -MXFPackage packages[2] = {};
> +MXFPackage packages[3] = {};

Here, may I suggest

MXFPackage packages[3] = {0};

for C99 compliance? For instance, msvc does not support an empty
struct initializer. See for instance
https://stackoverflow.com/questions/17589533/is-an-empty-initializer-list-valid-c-code

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Matthias Troffaes]

... any chance for this patch to get applied? Quick link to original thread:

https://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/211866.html

Rebased version of patch against latest master attached.

Kind regards,
Matthias
diff --git a/Changelog b/Changelog
index 187ae79..4fa0870 100644
--- a/Changelog
+++ b/Changelog
@@ -29,6 +29,7 @@ version :
 - limiter video filter
 - libvmaf video filter
 - Dolby E decoder and SMPTE 337M demuxer
+- skipblend video filter
 
 version 3.3:
 - CrystalHD decoder moved to new decode API
diff --git a/doc/filters.texi b/doc/filters.texi
index 119d1be..45b01ac 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4826,6 +4826,7 @@ The threshold below which a pixel value is considered black; it defaults to
 
 @end table
 
+@anchor{tblend}
 @section blend, tblend
 
 Blend two video frames into each other.
@@ -4837,6 +4838,8 @@ stream, the first input is the "top" layer and second input is
 The @code{tblend} (time blend) filter takes two consecutive frames
 from one single stream, and outputs the result obtained by blending
 the new frame on top of the old frame.
+See @ref{skipblend} for blending more than two frames at once
+from the same stream.
 
 A description of the accepted options follows.
 
@@ -8580,9 +8583,11 @@ This flag is enabled by default.
 @end table
 @end table
 
+@anchor{framestep}
 @section framestep
 
 Select one frame every N-th frame.
+See @ref{skipblend} for blending skipped frames.
 
 This filter accepts the following option:
 @table @option
@@ -13429,6 +13434,31 @@ ffmpeg -i input1.mkv -i input2.mkv -filter_complex "[0:v][1:v] signature=nb_inpu
 
 @end itemize
 
+@anchor{skipblend}
+@section skipblend
+
+Skip frames whilst blending skipped frames, for a motion blur
+effect. The number of frames that are blended (i.e. the exposure time,
+in frames) can be controlled, allowing control over the strength of the
+motion blur.
+See @ref{framestep} for skipping frames without blending.
+See @ref{tblend} for blending consecutive frames without skipping.
+
+This filter accepts the following options:
+@table @option
+@item step
+Skip @code{step} frames each step.
+Allowed values are positive integers between @code{1} and @code{65535}.
+Default value is @code{1}.
+@item blend
+Blend the first @code{blend} frames on every step,
+to produce a motion blur effect.
+Allowed values are positive integers between @code{1} and @code{step},
+where @code{1} corresponds to no motion blur, and @code{step}
+corresponds to maximal motion blur.
+Default value is @code{step}.
+@end table
+
 @anchor{smartblur}
 @section smartblur
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index ee16361..06930bb 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -295,6 +295,7 @@ OBJS-$(CONFIG_SHUFFLEPLANES_FILTER)  += vf_shuffleplanes.o
 OBJS-$(CONFIG_SIDEDATA_FILTER)   += f_sidedata.o
 OBJS-$(CONFIG_SIGNALSTATS_FILTER)+= vf_signalstats.o
 OBJS-$(CONFIG_SIGNATURE_FILTER)  += vf_signature.o
+OBJS-$(CONFIG_SKIPBLEND_FILTER)  += vf_skipblend.o
 OBJS-$(CONFIG_SMARTBLUR_FILTER)  += vf_smartblur.o
 OBJS-$(CONFIG_SOBEL_FILTER)  += vf_convolution.o
 OBJS-$(CONFIG_SPLIT_FILTER)  += split.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index b1c2d11..977604f 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -306,6 +306,7 @@ static void register_all(void)
 REGISTER_FILTER(SIDEDATA,   sidedata,   vf);
 REGISTER_FILTER(SIGNALSTATS,signalstats,vf);
 REGISTER_FILTER(SIGNATURE,  signature,  vf);
+REGISTER_FILTER(SKIPBLEND,  skipblend,  vf);
 REGISTER_FILTER(SMARTBLUR,  smartblur,  vf);
 REGISTER_FILTER(SOBEL,  sobel,  vf);
 REGISTER_FILTER(SPLIT,  split,  vf);
diff --git a/libavfilter/version.h b/libavfilter/version.h
index a252aec..01dd1db 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -30,7 +30,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVFILTER_VERSION_MAJOR   6
-#define LIBAVFILTER_VERSION_MINOR  95
+#define LIBAVFILTER_VERSION_MINOR  96
 #define LIBAVFILTER_VERSION_MICRO 100
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
diff --git a/libavfilter/vf_skipblend.c b/libavfilter/vf_skipblend.c
new file mode 100644
index 000..2915b43
--- /dev/null
+++ b/libavfilter/vf_skipblend.c
@@ -0,0 +1,272 @@
+/*
+ * Copyright (c) 2012 Stefano Sabatini
+ * Copyright (c) 2017 Matthias C. M. Troffaes
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even 

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Matthias Troffaes]

Dear Moritz,

On Mon, Jun 5, 2017 at 3:21 PM, Moritz Barsnick  wrote:
> I can't comment on the rest (and still really like the concept), but
> just this:
>
>> +Allowed values are positive integers between @code{1} and @code{65535}.
>
> This maximum value is no longer correct.

It's correct as far as I can tell. From the code:

{ "step", "set frame step",  OFFSET(frame_step), AV_OPT_TYPE_INT64,
{.i64=1}, 1, UINT16_MAX, FLAGS},

So you can see that UINT16_MAX (=65535) is the maximum value for the
step size, as documented. (Note that the type is AV_OPT_TYPE_INT64
because UINT16_MAX doesn't necessarily fit into an int, as you
correctly pointed out earlier.)

>> +Allowed values are positive integers between @code{1} and @code{step},
>> +where @code{1} corresponds to no motion blur, and @code{step}
>> +corresponds to maximal motion blur.
>
> Just wondering: Isn't this also useful for a slideshow-like
> transition/fade, not just for motion blur? (I'm saying: If so, the user
> needs to know.)

Good point, one could use it that way too, yes. I don't think it's
essential to the patch, but I'd be happy to submit a follow-on patch
to mention this use as well.

> I think I need to build and test it, to see if it fits
> my needs. ;)

Ok, thanks!

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect

[Matthias Troffaes]

Dear Paul,

On Wed, May 31, 2017 at 7:59 PM, Paul B Mahol  wrote:
> This code does not belong in this filter.
>
> Make new filter instead.

May I kindly ask why you think so? I considered this as well but then
decided against it, as this new filter would behave like framestep as
a common special case, and would also share a reasonable amount of
code with framestep. I don't feel very strongly either way though.

I can split this into a new filter if that's deemed better by the
majority here. How should it be called? It generalises both
tblend=average (step=2, blend=2) and framestep (any step, blend=1) -
so maybe "frameblend"? Should blend default to step (so it behaves
like tblend by default but supporting more than 2 frames), or to 1 (so
it behaves like framestep by default, as in the current patch)?

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect

[Matthias Troffaes]

Dear Moritz,

On Wed, May 31, 2017 at 2:17 PM, Moritz Barsnick  wrote:
> On Wed, May 31, 2017 at 13:31:14 +0100, Matthias C. M. Troffaes wrote:
>> @@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest 
>> within each release,
>>  releases are sorted from youngest to oldest.
>>
>>  version :
>> +- framestep filter: add blend parameter for motion blur effect
>>  - deflicker video filter
>
> Did you read the text up there? You need to add your change to the
> bottom of the ":" list.

Oh dear, that's embarrassing. I must have misread the instruction.
Thanks for pointing out - I'll fix this.

>> +int frame_blend;///< how many frames to blend on each step
> [...]
>>  static const AVOption framestep_options[] = {
>>  { "step", "set frame step",  OFFSET(frame_step), AV_OPT_TYPE_INT, 
>> {.i64=1}, 1, INT_MAX, FLAGS},
>> +{ "blend", "number of frames to blend per step",  OFFSET(frame_blend), 
>> AV_OPT_TYPE_INT, {.i64=1}, 1, 65535, FLAGS},
>
> Your maximum is too high to be assigned to an int, unless you properly
> checked that any overflow still results in correct behaviour. The upper
> limit probably needs to be "INT_MAX" (which would be 32767, but you can
> use the constant).

On various platforms (such as a standard 64-bit Fedora install),
INT_MAX is 2147483647 (for example see
https://www.tutorialspoint.com/c_standard_library/limits_h.htm) and
that value *will* potentially overflow the code as the internal buffer
requires all values across the blend added up to fit into a uint32_t.
To avoid overflows, the maximum value for blend therefore needs to
satisfy the following inequality:

blend_max * pix_value_max <= 2^32 - 1

and since the filter supports up to 16 bit formats, this gives the constraint:

blend_max <= (2^32 - 1) / (2^16 - 1)

which is satisfied by 65535. Technically 65537 would work as well.

Shall I change AV_OPT_TYPE_INT into AV_OPT_TYPE_INT64 for both
parameters, use INT64_MAX for the maximum value of "step", and
UINT16_MAX for the maximum value of "blend"? That should eliminate a
possible overflow on those platforms where INT_MAX is only 32767.

>>  AVFilterContext *ctx = outlink->src;
>> -FrameStepContext *framestep = ctx->priv;
>> -AVFilterLink *inlink = ctx->inputs[0];
>> +const FrameStepContext *s = ctx->priv;
>> +const AVFilterLink *inlink = ctx->inputs[0];
>>
>>  outlink->frame_rate =
>> -av_div_q(inlink->frame_rate, (AVRational){framestep->frame_step, 
>> 1});
>> +av_div_q(inlink->frame_rate, (AVRational){s->frame_step, 1});
>>
>>  av_log(ctx, AV_LOG_VERBOSE, "step:%d frame_rate:%d/%d(%f) -> 
>> frame_rate:%d/%d(%f)\n",
>> -   framestep->frame_step,
>> +   s->frame_step,
>> inlink->frame_rate.num, inlink->frame_rate.den, 
>> av_q2d(inlink->frame_rate),
>> outlink->frame_rate.num, outlink->frame_rate.den, 
>> av_q2d(outlink->frame_rate));
>> +
>>  return 0;
>>  }
>
> Isn't this just a rename and const-ification? This probably doesn't
> belong into this patch (perhaps a separate one, if at all.) And it adds
> an empty line, which certainly doesn't belong into a functional patch.

Sure, I'll split it off into a separate patch. The use of "framestep"
for the context is very confusing with frame_step already being used
for the actual frame step value. Other filters use "s" for the context
and this simply brings the code in line with naming conventions
elsewhere. It seemed like a good thing to include, but I agree it's
not functional, just code cleanup.

Thank you for the prompt feedback!

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect

[Matthias Troffaes]

Note that this is a resubmission of
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209794.html - in
particular the mips test failure reported in
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/209820.html has
been fixed.

Kind regards,
Matthias

On Wed, May 31, 2017 at 1:31 PM, Matthias C. M. Troffaes
 wrote:
> This patch adds a "blend" parameter to the framestep filter, to blend
> frames together at each step, for a motion blur effect. The number of
> frames that are blended (i.e. the exposure time, in frames) can be
> controlled, allowing control over the strength of the motion blur. The
> filter has timeline support, and supports both 8-bit and 16-bit pixel
> formats.
>
> This can be used for instance to blend down high framerate footage to
> produce a high quality motion blur effect.
>
> Note that a similar effect is already possible by repeatedly chaining
> the tblend and framestep=step=2 filters; see for example:
>
> https://video.stackexchange.com/questions/16552/4x-resample-videoframes-using-ffmpeg
>
> But this is limited to steps that are powers of two, and this does not
> allow an intermediate exposure time. It's also slower.
>
> Tests and documentation included.
> ---
>  Changelog  |   1 +
>  doc/filters.texi   |   7 +
>  libavfilter/vf_framestep.c | 241 
> ++---
>  tests/fate/filter-video.mak|  12 ++
>  tests/ref/fate/filter-framestep-anim-1 |  17 +++
>  tests/ref/fate/filter-framestep-anim-2 |  17 +++
>  tests/ref/fate/filter-framestep-gray-1 |  14 ++
>  tests/ref/fate/filter-framestep-gray-2 |  13 ++
>  8 files changed, 302 insertions(+), 20 deletions(-)
>  create mode 100644 tests/ref/fate/filter-framestep-anim-1
>  create mode 100644 tests/ref/fate/filter-framestep-anim-2
>  create mode 100644 tests/ref/fate/filter-framestep-gray-1
>  create mode 100644 tests/ref/fate/filter-framestep-gray-2
>
> diff --git a/Changelog b/Changelog
> index 1949ec7..cef06eb 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest 
> within each release,
>  releases are sorted from youngest to oldest.
>
>  version :
> +- framestep filter: add blend parameter for motion blur effect
>  - deflicker video filter
>  - doubleweave video filter
>  - lumakey video filter
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 107fe61..0160954 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -8453,6 +8453,13 @@ This filter accepts the following option:
>  @item step
>  Select frame after every @code{step} frames.
>  Allowed values are positive integers higher than 0. Default value is 
> @code{1}.
> +@item blend
> +Blend @code{blend} consequentive frames on every step,
> +to produce a motion blur effect.
> +Allowed values are positive integers between @code{1} and @code{step},
> +where @code{1} corresponds to no motion blur, and @code{step}
> +corresponds to maximal motion blur.
> +Default value is @code{1}.
>  @end table
>
>  @anchor{frei0r}
> diff --git a/libavfilter/vf_framestep.c b/libavfilter/vf_framestep.c
> index 8102e7c..33a380f 100644
> --- a/libavfilter/vf_framestep.c
> +++ b/libavfilter/vf_framestep.c
> @@ -1,5 +1,6 @@
>  /*
>   * Copyright (c) 2012 Stefano Sabatini
> + * Copyright (c) 2017 Matthias C. M. Troffaes
>   *
>   * This file is part of FFmpeg.
>   *
> @@ -24,13 +25,24 @@
>   */
>
>  #include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
>  #include "avfilter.h"
>  #include "internal.h"
>  #include "video.h"
>
>  typedef struct NullContext {
>  const AVClass *class;
> -int frame_step;
> +int frame_step; ///< step size in frames
> +int frame_blend;///< how many frames to blend on each step
> +int nb_planes;  ///< number of planes in the pixel format
> +int planewidth[4];  ///< width of each plane (after subsampling)
> +int planeheight[4]; ///< height of each plane (after subsampling)
> +uint32_t *data[4];  ///< buffer for blending input frames
> +
> +void (*blend_set)(AVFilterContext *ctx, AVFrame *in, int plane);
> +void (*blend_add)(AVFilterContext *ctx, AVFrame *in, int plane);
> +void (*blend_div)(AVFilterContext *ctx, AVFrame *in, int plane);
> +int (*filter_frame)(AVFilterLink *inlink, AVFrame *in);
>  } FrameStepContext;
>
>  #define OFFSET(x) offsetof(FrameStepContext, x)
> @@ -38,43 +50,229 @@ typedef struct NullContext {
>
>  static const AVOption framestep_options[] = {
>  { "step", "set frame step",  OFFSET(frame_step), AV_OPT_TYPE_INT, 
> {.i64=1}, 1, INT_MAX, FLAGS},
> +{ "blend", "number of frames to blend per step",  OFFSET(frame_blend), 
> AV_OPT_TYPE_INT, {.i64=1}, 1, 65535, FLAGS},
>  { NULL },
>  };
>
>  AVFILTER_DEFINE_CLASS(framestep);
>
> +#define DEFINE_BLEND(NAME, TYPE, DECL, EXPR) 
>   \
> +static void blend_##NAME##_##TYPE(AVFilterContext *ctx, 

Re: [FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect

[Matthias Troffaes]

On Thu, Apr 6, 2017 at 5:00 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Thu, Apr 06, 2017 at 02:09:46PM +0100, Matthias Troffaes wrote:
>> Many thanks for your feedback, Michael and Nicolas.
>>
>> On Wed, Apr 5, 2017 at 7:02 PM, Michael Niedermayer
>> <mich...@niedermayer.cc> wrote:
>> > fails on qemu mips
>>
>> Thank you for flagging this failure. I'm currently trying to reproduce
>> the problem. May I ask what toolchain you typically use to compile to
>> mips? (I'm trying debian malta on qemu-system-mips, but it seems that
>> the configure script can't correctly set up config.h in that
>> environment.)
>
> its a really old cross compiler from the no longer existing emdebian
>
> i also have a native loongson system but that is less convenient to
> test with

Ok. In the mean time I fixed the configure problem - just had to
specify "--cpu 24kc" explicitly. Now compiling slowly but steadily.

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_framestep: add blend parameter for motion blur effect

[Matthias Troffaes]

Many thanks for your feedback, Michael and Nicolas.

On Wed, Apr 5, 2017 at 7:02 PM, Michael Niedermayer
 wrote:
> fails on qemu mips

Thank you for flagging this failure. I'm currently trying to reproduce
the problem. May I ask what toolchain you typically use to compile to
mips? (I'm trying debian malta on qemu-system-mips, but it seems that
the configure script can't correctly set up config.h in that
environment.)

On Thu, Apr 6, 2017 at 8:42 AM, Nicolas George  wrote:
> There is already blending code in vf_framerate and vf_overlay,

... indeed, and also in vf_blend.

> I think
> we should not add new similar code without sharing it as much as
> possible.

Thanks for pointing out the existence of similar code. I agree.

There is however one problem: all blend codes mentioned work on 2
frames only. Whilst it is possible to express an n-frame blend in
terms of n-1 consecutive 2-frame blends with appropriate weights, the
issues with doing so are that it is much slower for large n (n-1
additions + 1 divide per pixel for n-frame blend, versus n-1 additions
+ n-1 multiplications + n-1 divides per pixel for n-1 consecutive
2-frame blends), and that the precision might be compromised as the
current 2-frame blend code round everything to the integer at each
step. Here's some python code to demonstrate the latter problem:

rnd = round

def blend_exact(xs):
return rnd(sum(xs) / float(len(xs)))

def blend_recurse(xs):
head = xs[0]
if len(xs) == 1:
return head
else:
tail = xs[1:]
return rnd((head + len(tail) * blend_recurse(tail)) / float(len(xs)))

def test(xs):
print(blend_exact(xs))
print(blend_recurse(xs))

test([1,1,3])
test([1,1,1,3])
...
test([1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,3])
...

The exact version gives 1 for all of these test cases, whilst the
recursive version gives 2 - I'd say that's quite bad: you can add as
many 1's to the front as you want, the result for the recursive
version will always return 2, even if the exact result is arbitrarily
close to 1.

One way of fixing this is by increasing the precision of the 2-frame
blend. However, the current blending codes for 2 frames, as they are
designed now in ffmpeg, do not have increased precision in the target
frame. They are therefore unsuitable for consecutively blending a
large number of frames: they are both slower and less inaccurate for
that purpose when compared to the exact version as in the patch.

This all said, I could absolutely see good use in refactoring the code
to provide a common basis for the various frame blending codes that
are already out there. Given that there is no suitable n-frame blend
code currently elsewhere (unless someone can point me to it, but I
didn't find anything), do you think it is fair of me to argue that
such refactoring is beyond the scope of this specific patch?

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel