Re: [FFmpeg-devel] [PATCH] avfilter/libvmaf: remove deprecated options
Hi, On Thu, Oct 5, 2023 at 1:19 PM Kyle Swanson wrote: > Removal of deprecated libvmaf filter options. These options have been > deprecated since 3d29724c008d8f27fecf85757152789b074e8ef9 (Jan 23, > 2022). Patch attached. I'll push this tomorrow. Thanks, Kyle ___ 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/libvmaf: remove deprecated options
Hi, On Mon, Oct 9, 2023 at 10:17 AM Kyle Swanson wrote: > On Thu, Oct 5, 2023 at 1:19 PM Kyle Swanson wrote: > > Removal of deprecated libvmaf filter options. These options have been > > deprecated since 3d29724c008d8f27fecf85757152789b074e8ef9 (Jan 23, > > 2022). Patch attached. > > I'll push this tomorrow. Pushed. Thanks, Kyle ___ 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] avfilter/libvmaf: update pix_fmts
Hi, This patch adds 12/16-bit support to the libvmaf filter. Unless there are questions/reviews, I'll push tomorrow. Patch attached. Thanks, Kyle 0001-avfilter-libvmaf-update-pix_fmts.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] avfilter/libvmaf: update pix_fmts
Hi, On Tue, Oct 10, 2023 at 1:02 PM Kyle Swanson wrote: > This patch adds 12/16-bit support to the libvmaf filter. Unless there > are questions/reviews, I'll push tomorrow. Patch attached. Merged. Thanks, Kyle ___ 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] VMAF is now propagated to the AVFrame coming from the graph
Hi, On Fri, Oct 13, 2023 at 11:01 PM wrote: > > From: ichlubna > > Related to my ticket here: https://trac.ffmpeg.org/ticket/10586 > VMAF score was not propagated to AVFormat like SSIM or PSNR in the result of > the filter graph. I have fixed this to make the usage consistent and possible > to get VMAF score per-frame in libavfilter. > The only dirty thing here is the added for loop to compute the score twice. > This is done to get the score in real time. Otherwise the score is delayed by > one frame. Computing the score twice should not affect the final averaged > result as each frame is added twice so the average does not change. Thank you for the patch. Give me a few days, and I will review this. Thanks, Kyle ___ 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] avfilter/libvmaf: fix broken cuda build
Hi, I broke the libvmaf_cuda build after 6028728bb829c04cc68c66c846c75a70bf4c0613. Fix is attached. I will merge this patch soon. Thanks, Kyle 0001-avfilter-libvmaf-fix-broken-cuda-build.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] avfilter/libvmaf: fix broken cuda build
On Tue, Oct 24, 2023 at 1:56 PM Kyle Swanson wrote: > I broke the libvmaf_cuda build after > 6028728bb829c04cc68c66c846c75a70bf4c0613. Fix is attached. I will > merge this patch soon. Pushed. ___ 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: merge loudnorm filter functionality into f_ebur128.c
Hi, On Wed, Nov 15, 2023 at 12:39 PM Paul B Mahol wrote: > > Attached. Only had a few minutes to look at this. Seems like more than just merging two filters, I see a bunch of new filter options for example. Can you explain? Thanks, Kyle ___ 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: merge loudnorm filter functionality into f_ebur128.c
Hi, On Sun, Nov 19, 2023 at 3:48 AM Paul B Mahol wrote: > > On Fri, Nov 17, 2023 at 7:38 AM Kyle Swanson wrote: > > > Hi, > > > > On Wed, Nov 15, 2023 at 12:39 PM Paul B Mahol wrote: > > > > > > Attached. > > > > Only had a few minutes to look at this. Seems like more than just > > merging two filters, I see a bunch of new filter options for example. > > Can you explain? > > > > The linear mode and scanning, both input to filter and filter output itself > should give similar results. > The dynamic mode now actually can be configured how aggressively it will > expand / compress audio. > Because current state of filter have numerous issues: > > - using unmaintained old libebur128 module, when same functionality is > already available in existing filter. > - code duplication and functionality duplication due the above > - buggy limiter - causing clipped samples randomly > - buggy first and final frame filtering > - over-complicated flow path for dynamic code in filter > - excessive compressing of audio dynamic range, causing extreme smaller > LRU from output audio > - and probably more that I forgot > > Some options from this patch can be probably removed, like attack/release > options, and just use defaults as currently in patch. > > > > Thanks, > > Kyle OK. Give me some time to review this. Unfortunately, I can't be quick since it is a Holiday week here and the diff is pretty hard to read. I'm hoping this still gives exact/equivalent loudnorm output, since this is a pretty widely used filter. My first reaction is combining the filters like this might make things more complicated, but I will keep an open mind while reviewing. Thanks, Kyle ___ 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] doc/filters: restore libvmaf option pool entry
Hi, On Mon, Nov 27, 2023 at 1:29 AM Gyan Doshi wrote: > > Will push soon. This filter can take any number of models now, each defining their own pooling methods. Looking at the docs now, I can see that it's not clear how to do this, I'll need to send a patch on that. The global `pool` option has been deprecated and removed already. Thanks, Kyle ___ 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] doc/filters: restore libvmaf option pool entry
Hi, On Mon, Nov 27, 2023 at 10:15 AM Gyan Doshi wrote: > Do you mean in the lib? Because in ffmpeg git master, in the wrapper, > the option remains available and undeprecated. > > Regards, > Gyan Oops, you're right. Ignore everything I just said, sorry for the noise. Thanks, Kyle ___ 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: merge loudnorm filter functionality into f_ebur128.c
Hi, On Thu, Nov 30, 2023 at 6:11 AM Paul B Mahol wrote: > > I tested this a lot, and its great move forward. > > Make more useful testing and review next time, I'm sure you are quite > capable person. Paul, I agree with Anton. Refactoring the code (i.e. changing filter behavior) and combining it with f_ebur128.c all at once makes the diff very hard to review. I suggest an incremental approach, let's address the issues you've identified with the loudnorm filter one by one, and then a second stage where we see about combining with f_ebur128.c. Thanks, Kyle ___ 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: merge loudnorm filter functionality into f_ebur128.c
Hi, On Thu, Nov 30, 2023 at 1:36 PM Paul B Mahol wrote: > > Loudnorm filter is big pile of hacks, I wanted to move forward and I > improved it. > > I received nothing in return just some politics talks. > > I will apply this soon unless technical comments arise. > > Why would I spend on this more my precious time? For no real gain as I will > again > receive nothing in return except some useless comment and no single > technical aspect. Please don't merge this as-is. I'm sure there are good changes/fixes here that we should merge, but you need to help your reviewers understand what is going on. One big commit that combines both refactoring across files with introduction of new filter behavior is very hard to review. That's why I'm suggesting we do this in two steps, I think Anton's suggestion is the same. Thanks, Kyle ___ 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: merge loudnorm filter functionality into f_ebur128.c
Hi, On Thu, Nov 30, 2023 at 2:43 PM Paul B Mahol wrote: > But how you could refactor code if one filter shares nothing with another > filter code? > > Its not possible. You all seem to not understand problem at all. I get that this patch swaps the libebur128 loudness computation with the f_ebur128 code. But it also changes the behavior of the AGC and limiter, right? It looks like a whole new algorithm. That's what I mean by new filter behavior. Thanks, Kyle ___ 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: merge loudnorm filter functionality into f_ebur128.c
Hi, On Fri, Dec 1, 2023 at 2:37 AM Paul B Mahol wrote: > Keeping old code will not make patch any prettier. It's not really about pretty, it's about splitting up the patch so we can do things one at a time. I think the change to use f_ebur128.c loudness computation might have some advantages, but I can't test them in isolation. The changes to the loudnorm algorithm I have more questions about, but I can't test those in isolation either. Thanks, Kyle ___ 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] avfilter/libvmaf: small cleanup for style, whitespace, unused
Hi, Small cleanup patch for vf_libvmaf.c. Will apply soon. Thanks, Kyle 0001-avfilter-libvmaf-small-cleanup-for-style-whitespace-.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] avfilter/libvmaf: small cleanup for style, whitespace, unused
On Fri, Dec 1, 2023 at 1:57 PM Kyle Swanson wrote: > Small cleanup patch for vf_libvmaf.c. Will apply soon. Pushed, thanks. ___ 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/vf_libvmaf: fix string comparison bug
Hi,
On Mon, Dec 4, 2023 at 7:59 AM Nil Fons Miret via ffmpeg-devel
wrote:
>
> The libvmaf filter was doing substring checks in place of string
> equality comparisons. This led to a bug when the user specified the
> pooling method "harmonic_mean", since "mean" was checked first and the
> substring comparison returned true. This patch changes all substring
> comparisons for string equality comparisons. This is both correct and
> more efficient than the existing method.
>
> Signed-off-by: nilfm
> ---
> libavfilter/vf_libvmaf.c | 30 +++---
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c
> index 12810b7267..46ff8154ef 100644
> --- a/libavfilter/vf_libvmaf.c
> +++ b/libavfilter/vf_libvmaf.c
> @@ -251,7 +251,7 @@ static int parse_features(AVFilterContext *ctx)
> const AVDictionaryEntry *e = NULL;
>
> while (e = av_dict_iterate(dict[i], e)) {
> -if (av_stristr(e->key, "name")) {
> +if (!strcmp(e->key, "name")) {
> feature_name = e->value;
> continue;
> }
> @@ -312,29 +312,29 @@ static int parse_models(AVFilterContext *ctx)
> char *path = NULL;
>
> while (e = av_dict_iterate(dict[i], e)) {
> -if (av_stristr(e->key, "disable_clip")) {
> -model_cfg.flags |= av_stristr(e->value, "true") ?
> +if (!strcmp(e->key, "disable_clip")) {
> +model_cfg.flags |= !strcmp(e->value, "true") ?
> VMAF_MODEL_FLAG_DISABLE_CLIP : 0;
> continue;
> }
>
> -if (av_stristr(e->key, "enable_transform")) {
> -model_cfg.flags |= av_stristr(e->value, "true") ?
> +if (!strcmp(e->key, "enable_transform")) {
> +model_cfg.flags |= !strcmp(e->value, "true") ?
> VMAF_MODEL_FLAG_ENABLE_TRANSFORM : 0;
> continue;
> }
>
> -if (av_stristr(e->key, "name")) {
> +if (!strcmp(e->key, "name")) {
> model_cfg.name = e->value;
> continue;
> }
>
> -if (av_stristr(e->key, "version")) {
> +if (!strcmp(e->key, "version")) {
> version = e->value;
> continue;
> }
>
> -if (av_stristr(e->key, "path")) {
> +if (!strcmp(e->key, "path")) {
> path = e->value;
> continue;
> }
> @@ -529,13 +529,13 @@ static int activate(AVFilterContext *ctx)
> static enum VmafOutputFormat log_fmt_map(const char *log_fmt)
> {
> if (log_fmt) {
> -if (av_stristr(log_fmt, "xml"))
> +if (!strcmp(log_fmt, "xml"))
> return VMAF_OUTPUT_FORMAT_XML;
> -if (av_stristr(log_fmt, "json"))
> +if (!strcmp(log_fmt, "json"))
> return VMAF_OUTPUT_FORMAT_JSON;
> -if (av_stristr(log_fmt, "csv"))
> +if (!strcmp(log_fmt, "csv"))
> return VMAF_OUTPUT_FORMAT_CSV;
> -if (av_stristr(log_fmt, "sub"))
> +if (!strcmp(log_fmt, "sub"))
> return VMAF_OUTPUT_FORMAT_SUB;
> }
>
> @@ -545,11 +545,11 @@ static enum VmafOutputFormat log_fmt_map(const
> char *log_fmt)
> static enum VmafPoolingMethod pool_method_map(const char *pool_method)
> {
> if (pool_method) {
> -if (av_stristr(pool_method, "min"))
> +if (!strcmp(pool_method, "min"))
> return VMAF_POOL_METHOD_MIN;
> -if (av_stristr(pool_method, "mean"))
> +if (!strcmp(pool_method, "mean"))
> return VMAF_POOL_METHOD_MEAN;
> -if (av_stristr(pool_method, "harmonic_mean"))
> +if (!strcmp(pool_method, "harmonic_mean"))
> return VMAF_POOL_METHOD_HARMONIC_MEAN;
> }
>
> --
> 2.37.1 (Apple Git-137.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".
Will push this tomorrow.
Thanks,
Kyle
___
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/vf_libvmaf: fix string comparison bug
On Wed, Dec 6, 2023 at 9:54 AM Kyle Swanson wrote: > Will push this tomorrow. Pushed, thanks. ___ 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] lavfi: add qrencodesrc source
Hi, On Sat, Dec 9, 2023 at 10:14 AM Stefano Sabatini wrote: > > On date Thursday 2023-11-30 01:49:14 +0100, Stefano Sabatini wrote: > > --- > > configure | 4 + > > libavfilter/Makefile| 1 + > > libavfilter/allfilters.c| 1 + > > libavfilter/vsrc_qrencode.c | 435 > > 4 files changed, 441 insertions(+) > > create mode 100644 libavfilter/vsrc_qrencode.c > > Rev2 with padding and doc. libavfilter/vsrc_qrencode.c:42:10: fatal error: 'textutils.h' file not found #include "textutils.h" ^ 1 error generated. Thanks, Kyle ___ 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 v2] avcodec: libdav1d AV1 decoder wrapper.
Hi, On Sun, Sep 30, 2018 at 5:08 PM James Almer wrote: > From: Ronald S. Bultje > > Originally written by Ronald S. Bultje, with fixes, optimizations and > improvements by James Almer. > > Signed-off-by: James Almer > --- > Updated with some refactoring and to use a few new public facing fields > recently introduced. > > The API is unstable and in constant development, and it's not going to be > frozen until a release is made, so I'm not sure if it's a good idea to push > this before ffmpeg 4.1 is tagged. > > configure | 4 + > libavcodec/Makefile| 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/libdav1d.c | 273 + > 4 files changed, 279 insertions(+) > create mode 100644 libavcodec/libdav1d.c > Not a review, but I was able to successfully build and decode. Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libvmaf: update docs
From: Kyle Swanson
For context: https://github.com/Netflix/vmaf/issues/237
Signed-off-by: Kyle Swanson
---
I'll push this sometime in the next 24hrs unless someone has an issue.
doc/filters.texi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index a2ef327688..5ab8ffbccb 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11243,7 +11243,9 @@ Set the file path to be used to store logs.
Set the format of the log file (xml or json).
@item enable_transform
-Enables transform for computing vmaf.
+This option can enable/disable the @code{score_transform} applied to the final
predicted VMAF score,
+if you have specified score_transform option in the input parameter file
passed to @code{run_vmaf_training.py}
+Default value: @code{false}
@item phone_model
Invokes the phone model which will generate VMAF scores higher than in the
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvmaf: update docs
Hi,
On 10/22/18, Kyle Swanson wrote:
> From: Kyle Swanson
>
> For context: https://github.com/Netflix/vmaf/issues/237
>
> Signed-off-by: Kyle Swanson
> ---
>
> I'll push this sometime in the next 24hrs unless someone has an issue.
Almost forgot about this. Pushed an updated version. Thanks.
>
> doc/filters.texi | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index a2ef327688..5ab8ffbccb 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -11243,7 +11243,9 @@ Set the file path to be used to store logs.
> Set the format of the log file (xml or json).
>
> @item enable_transform
> -Enables transform for computing vmaf.
> +This option can enable/disable the @code{score_transform} applied to the
> final predicted VMAF score,
> +if you have specified score_transform option in the input parameter file
> passed to @code{run_vmaf_training.py}
> +Default value: @code{false}
>
> @item phone_model
> Invokes the phone model which will generate VMAF scores higher than in the
> --
> 2.18.0
>
>
Kyle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Add alternative delogo algorithm for my donation
Hi,
On 12/11/18, uwe.fre...@gmx.de wrote:
> Hello,
>
> I would like that the delogo filter is improved by an alternative way of
> removing the logo. It's the "UGLARM" mode known from Virtual Dub's
> DeLogo filter and ffdshow.
> I used it many years (under Windows), but now moving to Linux miss it
> using ffmpeg as encoding tool.
>
> Since an ffmpeg developer can probably add the code in a fragment of the
> time and more consistently than it would take me to add it, I'd like to
> hire someone to do so.
>
> The code is just ~50 lines, and already available in c for ffdshow. I'd
> donate 50 EUR (PayPal) for someone adding it - hopefully into the normal
> production code for everyone to use. :)
> So if someone knows the delogo code / filter code and volunteers, let me
> know. :) I would be really glad if this could be done.
>
>
> ++ How does it work:
>
> The algorith is called "UGLARM mode" and takes all pixels of the 1-pixel
> border of the box covering the logo into account to interpolate the
> inner pixels. Each pixel is taken into account according to an
> exponential value of the distance. The result is a more blurred and I
> find much more pleasing effect than the current xy-algorithm in
> ffmpgeg's delogo filter, which tends to show vertical and horizontal
> lines / crosses. Although the calculation takes more time than the
> xy-interpolation, this is absolutely not relevant compared to the video
> encoding time.
>
> The code was impemented by myself ~15 years ago for the VirtualDub
> filter "LogoAway" by Chris Wojdon. It was taken over in the ffdshow
> Codec package for Windows.
>
> "UGLARM" stands for "Uwe's Great LogoAway Remove Mode". :-) It was my
> not-so-serious answer to Chris about how we could name it. But the name
> was taken over in his filter and later ffdshow, where it's available
> until now.
>
> ++ How does it look:
>
> See these examples:
> http://www.fixya.com/support/r3995122-remove_logo_from_avi_mpg4_file_using
> https://forum.videohelp.com/threads/260207-Remove-Spoilers-Logos-etc
> (search for "UGLARM" for the image).
>
> ++ Code to add:
>
> I alreday took a look at the ffmpeg code and ffdshow code.
> In ffdshow, you can find the functions in TimgFilterLogoaway.cpp:
> https://sourceforge.net/p/ffdshow-tryout/code/HEAD/tree/trunk/src/imgFilters/TimgFilterLogoaway.cpp
>
> In ffmpeg, it has to be added in libavfilter/vf_delogo.c, function
> apply_delogo.
You should also try vf_removelogo. It is supposedly better than the
more simple vf_delogo.
>
> Here's the relevant code to add (+ some config variable to set the mode
> I guess):
>
> // Precalculate weights once.
> void TimgFilterLogoaway::Tplane::calcUweWeightTable(int w, int h, int power)
> {
> double e = 1.0 + (0.3 * power);
> int x;
> for (x = 0; x < w; x++)
> for (int y = 0; y < h; y++)
> if (x + y != 0) {
> double d = pow(sqrt(double(x * x + y * y)), e);
> uwetable[x + y * w] = 1.0 / d;
> } else {
> uwetable[x + y * w] = 1.0;
> }
>
> for (x = 1; x < w - 1; x++)
> for (int y = 1; y < h - 1; y++) {
> double weightsum = 0;
> for (int bx = 0; bx < w; bx++) {
> weightsum += uwetable[abs(bx - x) + y * w];
> weightsum += uwetable[abs(bx - x) + abs(h - 1 - y) * w];
> }
> for (int by = 1; by < h - 1; by++) {
> weightsum += uwetable[x + abs(by - y) * w];
> weightsum += uwetable[abs(w - 1 - x) + abs(by - y) * w];
> }
> uweweightsum[y * w + x] = weightsum;
> }
> }
>
> // apply filter
> void TimgFilterLogoaway::Tplane::uwe(const TlogoawaySettings *cfg)
> {
> if (!uwetable) {
> uwetable = (double*)aligned_malloc(w * h * sizeof(double));
> uweweightsum = (double*)aligned_malloc(w * h * sizeof(double));
> calcUweWeightTable(w, h, cfg->blur);
> }
>
> for (int x = 1; x < w - 1; x++)
> for (int y = 1; y < h - 1; y++) {
> double r = 0;
> const unsigned char *lineN = bordn, *lineS = bords;
> for (int bx = 0; bx < w; bx++) {
> r += lineN[bx] * uwetable[abs(bx - x) + y * w];
> r += lineS[bx] * uwetable[abs(bx - x) + abs(h - 1 - y)
> * w];
> }
> const unsigned char *lineW = bordw, *lineE = borde;
> for (int by = 1; by < h - 1; by++) {
> r += lineW[by] * uwetable[x + abs(by - y) * w];
> r += lineE[by] * uwetable[abs(w - 1 - x) + abs(by - y)
> * w];
> }
> logotempdata[y * logotempstride + x] = uint8_t(r /
> uweweightsum[y * w + x]);
> }
>
> }
>
>
> Regards,
> Uwe
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Thanks,
Kyle
__
Re: [FFmpeg-devel] [PATCH v1 1/4] avfilter/af_loudnorm: Add file option for the measured stats
Hi, On Thu, Apr 9, 2020 at 10:57 AM Nicolas George wrote: > There is JSON-specific code in af_loudnorm.c, there should not be, I > think we should start here. > > My opinion is we should rework ffprobe's writers and move them to lavu. > That would be the first step. Is there already a helper API for filters (or codecs) that output a statistics file? If not, that's probably a pretty big undertaking. In the codec case, there are probably stats files which we have no control over, since they are written directly by some linked library. As an aside, I've often thought about improving the 2-pass version of this filter and not reuse the AGC on pass 2. A stats file would be a requirement for this. Thanks, Kyle ___ 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/af_loudnorm: Don't mix dB and linear values when calculating linear offset with inputs <3s
Hi, On Tue, Apr 28, 2020 at 12:58 AM Paul B Mahol wrote: > > On 4/26/20, Sebastian Dröge wrote: > > From: Sebastian Dröge > > > > s->target_i and global are in dB but s->target_tp and true_peak are > > linear. Instead of mixing these in the calculations, convert the former > > first to have all following calculations in the same unit. > > --- > > libavfilter/af_loudnorm.c | 5 ++--- > > 1 file changed, 2 insertions(+), 3 deletions(-) > > > > LGTM, but better ask and CC maintainer directly. Tested and pushed. Thank you. Thanks, Kyle ___ 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] configure: remove libvmaf from EXTERNAL_LIBRARY_VERSION3_LIST
since libvmaf v1.5.1, libvmaf has been relicensed as BSD+Patent Signed-off-by: Kyle Swanson --- configure | 1 - 1 file changed, 1 deletion(-) diff --git a/configure b/configure index 7495f35faa..e0b76ac1ea 100755 --- a/configure +++ b/configure @@ -1741,7 +1741,6 @@ EXTERNAL_LIBRARY_VERSION3_LIST=" liblensfun libopencore_amrnb libopencore_amrwb -libvmaf libvo_amrwbenc mbedtls rkmpp -- 2.26.2 ___ 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] configure: remove libvmaf from EXTERNAL_LIBRARY_VERSION3_LIST
Hi, On Mon, Jun 29, 2020 at 10:05 AM Kyle Swanson wrote: > > since libvmaf v1.5.1, libvmaf has been relicensed as BSD+Patent > > Signed-off-by: Kyle Swanson > --- > configure | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/configure b/configure > index 7495f35faa..e0b76ac1ea 100755 > --- a/configure > +++ b/configure > @@ -1741,7 +1741,6 @@ EXTERNAL_LIBRARY_VERSION3_LIST=" > liblensfun > libopencore_amrnb > libopencore_amrwb > -libvmaf > libvo_amrwbenc > mbedtls > rkmpp > -- > 2.26.2 > Missed the filter docs. Updated patch attached. Thanks, Kyle 0001-configure-remove-libvmaf-from-EXTERNAL_LIBRARY_VERSI.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] configure: remove libvmaf from EXTERNAL_LIBRARY_VERSION3_LIST
On Mon, Jun 29, 2020 at 12:14 PM Derek Buitenhuis wrote: > You'll need to update the pkg-config check too if you want to > to this, since it's at >= 1.3.9 right now. > > - Derek Thanks. Updated patch attached. 0001-configure-remove-libvmaf-from-EXTERNAL_LIBRARY_VERSI.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 v1 2/2] configure: Fix for the configure failed for vmaf
Hi, On Wed, Nov 13, 2019 at 10:36 PM Limin Wang wrote: > Please ignore the patch, I haven't used the old version. As vmaf library use > libvmaf.pc, it better to keep it filename same, so let waiting vmaf to fix > it. Merged your PR over on the VMAF repo. This FFmpeg patch should be ignored. Thanks, Kyle ___ 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] avfilter/vf_libvmaf: update filter for libvmaf v2.0.0
Hi, Patch attached. This is an update to the libvmaf avfilter to use the new libvmaf v2.* API which was released about 6 months ago. High level: the filter should be simpler to use now for basic users, but also more flexible for power users. libvmaf can be configured with one or many vmaf models, all of which can be parameterized/overloaded by the caller. Likewise, one or many extra feature extractors can be enabled with custom parameters. This logic mirrors what is available in the vmaf command-line tool. The option parsing is honestly not the most ergonomic, I don't think, but it is the best I could come up with. Each option (model/feature) takes the form of a string containing a list of `|` delimited dicts. There's a non-trival amount of code in here to do that option parsing. There will be another libvmaf minor version release soon, so please don't push this patch before that time so pkg-config can be updated and mismatches avoided. Thanks, Kyle 0001-avfilter-vf_libvmaf-update-filter-for-libvmaf-v2.0.0.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] avfilter/vf_libvmaf: update filter for libvmaf v2.0.0
Hi, Updated patch attached. Thank you to Christopher Degawa for testing and providing feedback. Kyle 0001-avfilter-vf_libvmaf-update-filter-for-libvmaf-v2.0.0.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] doc/developer: require transparency about sponshorships.
Hi,
On Fri, Jan 11, 2019 at 10:21 AM Nicolas George wrote:
>
> Rationale:
>
> * This requirement should offset a little the incentive to neglect
> design, code quality and politeness during the review process when
> done for money.
>
> * The review process itself and future maintenance burden cost efforts
> to the whole project; knowing that sponsorship has been given, to an
> individual or to the whole project, helps evaluating if the benefits
> match the costs.
>
> * Inclusion in FFmpeg implies implicit endorsement by the project;
> we owe to our users to disclose when this endorsement is not genuine;
> this is to relate to mandatory flagging of advertisement in mass media.
>
> * Systematic disclosure and transparency make a stronger position
> against accusations of bias or conflict of interest for difficult
> policy decisions.
>
> * Documenting bounties may give an incentive to new contributors
> who may not be aware of these opportunities.
>
> Signed-off-by: Nicolas George
> ---
> doc/developer.texi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 5c342c9106..1d77250083 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -420,6 +420,13 @@ your name after it.
> If at some point you no longer want to maintain some code, then please help
> in
> finding a new maintainer and also don't forget to update the
> @file{MAINTAINERS} file.
>
> +@subheading Disclose sponsors and other remunerations
> +If the patch is the result of sponsored work, expects a bounty or benefited
> +from any kind of specific remuneration or payment, include the identity of
> +the sponsors, the identity of the recipients (if it is not exactly the
> +author of the patch) and the amount (or an approximation if it is not
> +possible to define it exactly) in the commit message.
> +
> We think our rules are not too hard. If you have comments, contact us.
>
> @chapter Code of conduct
> @@ -664,6 +671,9 @@ are notoriously left unchecked, which is a serious
> problem.
> @item
> Test your code with valgrind and or Address Sanitizer to ensure it's free
> of leaks, out of array accesses, etc.
> +
> +@item
> +Did you disclose any sponsorship in the commit message?
> @end enumerate
>
> @chapter Patch review process
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Lots of people get paid to work on OSS. It's not a conspiracy, that's
just the way it is. If someone gets paid to write a patch that does
something useful, great. They got paid, and FFmpeg is better. If
someone gets paid to write a patch that's no good, we just don't merge
it. I don't see any reason FFmpeg should be concerned who is getting
paid and how much.
Thanks,
Kyle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.
Hi, On Fri, Jan 11, 2019 at 11:05 AM Nicolas George wrote: > > Kyle Swanson (12019-01-11): > > Lots of people get paid to work on OSS. It's not a conspiracy, that's > > just the way it is. If someone gets paid to write a patch that does > > something useful, great. They got paid, and FFmpeg is better. If > > someone gets paid to write a patch that's no good, we just don't merge > > it. I don't see any reason FFmpeg should be concerned who is getting > > paid and how much. > > I agree with that. Only you are suggesting a "conspiracy". Sorry, bad word choice. > > I am not suggesting we ban people from getting paid, I am not leading a > "witch hunt", I only advocate for transparency and honesty. > > Are you against transparency and honesty? > > On the other hand, I have observed in the past patches that were of poor > quality and suspected they were the result of sponsorships. I would like > to know. Would you not? If someone sends a bad patch, we have no obligation to merge it. > > Regards, > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
Hi, On Wed, Feb 6, 2019 at 1:20 PM Reto Kromer wrote: > > Werner Robitza wrote: > > >I propose that FFmpeg maintains its own ffmpeg formula under > >its GitHub organization > > I second the idea. +1 > > (Homebrew works now on any modern x86_64 architecture running > Linux, macOS and Windows with Linux.) > > >I am happy to maintain this formula – and maybe there are other > >community members who want to support this effort. The > >maintenance effort would basically be: bumping the formula > >everytime there's an official release, and testing its build. > > I would be happy to help. Me too. > > Best regards, Reto Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg
Hi, On Wed, Feb 6, 2019 at 1:43 PM Helmut K. C. Tessarek wrote: > Anyhow, I don't think that adding a formula to the ffmpeg src tree is > the right approach. I don't think that's the suggestion. Separate Github repo belonging to the FFmpeg Github organization. Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/opusenc: use correct format specifiers
Squelches the following compiler warnings:
libavcodec/opusenc.c:1051:16: warning: format specifies type 'long' but
the argument has type 'long long' [-Wformat]
avctx->bit_rate/1000, clipped_rate/1000);
^~~~
libavcodec/opusenc.c:1051:38: warning: format specifies type 'long' but
the argument has type 'long long' [-Wformat]
avctx->bit_rate/1000, clipped_rate/1000);
^
Signed-off-by: Kyle Swanson
---
libavcodec/opusenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/opusenc.c b/libavcodec/opusenc.c
index 56368db..292d060 100644
--- a/libavcodec/opusenc.c
+++ b/libavcodec/opusenc.c
@@ -1047,7 +1047,7 @@ static av_cold int opus_encode_init(AVCodecContext *avctx)
avctx->bit_rate = coupled*(96000) + (s->channels - coupled*2)*(48000);
} else if (avctx->bit_rate < 6000 || avctx->bit_rate > 255000 *
s->channels) {
int64_t clipped_rate = av_clip(avctx->bit_rate, 6000, 255000 *
s->channels);
-av_log(avctx, AV_LOG_ERROR, "Unsupported bitrate %li kbps, clipping to
%li kbps\n",
+av_log(avctx, AV_LOG_ERROR, "Unsupported bitrate %lli kbps, clipping
to %lli kbps\n",
avctx->bit_rate/1000, clipped_rate/1000);
avctx->bit_rate = clipped_rate;
}
--
2.10.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/opusenc: use correct format specifiers
Hi,
On Sun, Mar 26, 2017 at 1:20 PM, Nicolas George wrote:
>
> Thanks for the patch.
>
> Le sextidi 6 germinal, an CCXXV, Kyle Swanson a écrit :
> > Squelches the following compiler warnings:
> >
> > libavcodec/opusenc.c:1051:16: warning: format specifies type 'long' but
> > the argument has type 'long long' [-Wformat]
> >avctx->bit_rate/1000, clipped_rate/1000);
> >^~~~
> > libavcodec/opusenc.c:1051:38: warning: format specifies type 'long' but
> > the argument has type 'long long' [-Wformat]
> >avctx->bit_rate/1000, clipped_rate/1000);
> > ^
> >
> > Signed-off-by: Kyle Swanson
> > ---
> > libavcodec/opusenc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/opusenc.c b/libavcodec/opusenc.c
> > index 56368db..292d060 100644
> > --- a/libavcodec/opusenc.c
> > +++ b/libavcodec/opusenc.c
> > @@ -1047,7 +1047,7 @@ static av_cold int opus_encode_init(AVCodecContext
> > *avctx)
> > avctx->bit_rate = coupled*(96000) + (s->channels -
> > coupled*2)*(48000);
> > } else if (avctx->bit_rate < 6000 || avctx->bit_rate > 255000 *
> > s->channels) {
> > int64_t clipped_rate = av_clip(avctx->bit_rate, 6000, 255000 *
> > s->channels);
>
> > -av_log(avctx, AV_LOG_ERROR, "Unsupported bitrate %li kbps,
> > clipping to %li kbps\n",
> > +av_log(avctx, AV_LOG_ERROR, "Unsupported bitrate %lli kbps,
> > clipping to %lli kbps\n",
>
> The old specifier was wrong, but %ll is wrong too: avctx->bit_rate is
> int64_t, not long nor long long.
Thanks, new patch is attached. %" PRIu64 " should be correct.
>
>
> > avctx->bit_rate/1000, clipped_rate/1000);
> > avctx->bit_rate = clipped_rate;
> > }
>
> Regards,
>
> --
> Nicolas George
0001-libavcodec-opusenc-use-correct-format-specifiers.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/opusenc: use correct format specifiers
On Sun, Mar 26, 2017 at 1:53 PM, Kyle Swanson wrote:
> Hi,
>
> On Sun, Mar 26, 2017 at 1:20 PM, Nicolas George wrote:
>>
>> Thanks for the patch.
>>
>> Le sextidi 6 germinal, an CCXXV, Kyle Swanson a écrit :
>> > Squelches the following compiler warnings:
>> >
>> > libavcodec/opusenc.c:1051:16: warning: format specifies type 'long' but
>> > the argument has type 'long long' [-Wformat]
>> >avctx->bit_rate/1000, clipped_rate/1000);
>> >^~~~
>> > libavcodec/opusenc.c:1051:38: warning: format specifies type 'long' but
>> > the argument has type 'long long' [-Wformat]
>> >avctx->bit_rate/1000, clipped_rate/1000);
>> > ^
>> >
>> > Signed-off-by: Kyle Swanson
>> > ---
>> > libavcodec/opusenc.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/libavcodec/opusenc.c b/libavcodec/opusenc.c
>> > index 56368db..292d060 100644
>> > --- a/libavcodec/opusenc.c
>> > +++ b/libavcodec/opusenc.c
>> > @@ -1047,7 +1047,7 @@ static av_cold int opus_encode_init(AVCodecContext
>> > *avctx)
>> > avctx->bit_rate = coupled*(96000) + (s->channels -
>> > coupled*2)*(48000);
>> > } else if (avctx->bit_rate < 6000 || avctx->bit_rate > 255000 *
>> > s->channels) {
>> > int64_t clipped_rate = av_clip(avctx->bit_rate, 6000, 255000 *
>> > s->channels);
>>
>> > -av_log(avctx, AV_LOG_ERROR, "Unsupported bitrate %li kbps,
>> > clipping to %li kbps\n",
>> > +av_log(avctx, AV_LOG_ERROR, "Unsupported bitrate %lli kbps,
>> > clipping to %lli kbps\n",
>>
>> The old specifier was wrong, but %ll is wrong too: avctx->bit_rate is
>> int64_t, not long nor long long.
>
>
> Thanks, new patch is attached. %" PRIu64 " should be correct.
Ignore previous patch, we should actually be using %" PRId64 ". Can't
believe that took three tries ⊙﹏⊙.
>
>>
>>
>> > avctx->bit_rate/1000, clipped_rate/1000);
>> > avctx->bit_rate = clipped_rate;
>> > }
>>
>> Regards,
>>
>> --
>> Nicolas George
0001-libavcodec-opusenc-use-correct-format-specifiers.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/af_loudnorm: do not upsample during second-pass linear normalization
Signed-off-by: Kyle Swanson
---
libavfilter/af_loudnorm.c | 58 +++
1 file changed, 34 insertions(+), 24 deletions(-)
diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c
index 9d91c76..e3e815e 100644
--- a/libavfilter/af_loudnorm.c
+++ b/libavfilter/af_loudnorm.c
@@ -682,6 +682,7 @@ static int request_frame(AVFilterLink *outlink)
static int query_formats(AVFilterContext *ctx)
{
+LoudNormContext *s = ctx->priv;
AVFilterFormats *formats;
AVFilterChannelLayouts *layouts;
AVFilterLink *inlink = ctx->inputs[0];
@@ -707,15 +708,17 @@ static int query_formats(AVFilterContext *ctx)
if (ret < 0)
return ret;
-formats = ff_make_format_list(input_srate);
-if (!formats)
-return AVERROR(ENOMEM);
-ret = ff_formats_ref(formats, &inlink->out_samplerates);
-if (ret < 0)
-return ret;
-ret = ff_formats_ref(formats, &outlink->in_samplerates);
-if (ret < 0)
-return ret;
+if (s->frame_type != LINEAR_MODE) {
+formats = ff_make_format_list(input_srate);
+if (!formats)
+return AVERROR(ENOMEM);
+ret = ff_formats_ref(formats, &inlink->out_samplerates);
+if (ret < 0)
+return ret;
+ret = ff_formats_ref(formats, &outlink->in_samplerates);
+if (ret < 0)
+return ret;
+}
return 0;
}
@@ -754,21 +757,6 @@ static int config_input(AVFilterLink *inlink)
init_gaussian_filter(s);
-s->frame_type = FIRST_FRAME;
-
-if (s->linear) {
-double offset, offset_tp;
-offset= s->target_i - s->measured_i;
-offset_tp = s->measured_tp + offset;
-
-if (s->measured_tp != 99 && s->measured_thresh != -70 &&
s->measured_lra != 0 && s->measured_i != 0) {
-if ((offset_tp <= s->target_tp) && (s->measured_lra <=
s->target_lra)) {
-s->frame_type = LINEAR_MODE;
-s->offset = offset;
-}
-}
-}
-
if (s->frame_type != LINEAR_MODE) {
inlink->min_samples =
inlink->max_samples =
@@ -790,6 +778,27 @@ static int config_input(AVFilterLink *inlink)
return 0;
}
+static av_cold int init(AVFilterContext *ctx)
+{
+LoudNormContext *s = ctx->priv;
+s->frame_type = FIRST_FRAME;
+
+if (s->linear) {
+double offset, offset_tp;
+offset= s->target_i - s->measured_i;
+offset_tp = s->measured_tp + offset;
+
+if (s->measured_tp != 99 && s->measured_thresh != -70 &&
s->measured_lra != 0 && s->measured_i != 0) {
+if ((offset_tp <= s->target_tp) && (s->measured_lra <=
s->target_lra)) {
+s->frame_type = LINEAR_MODE;
+s->offset = offset;
+}
+}
+}
+
+return 0;
+}
+
static av_cold void uninit(AVFilterContext *ctx)
{
LoudNormContext *s = ctx->priv;
@@ -914,6 +923,7 @@ AVFilter ff_af_loudnorm = {
.priv_size = sizeof(LoudNormContext),
.priv_class= &loudnorm_class,
.query_formats = query_formats,
+.init = init,
.uninit= uninit,
.inputs= avfilter_af_loudnorm_inputs,
.outputs = avfilter_af_loudnorm_outputs,
--
2.10.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_loudnorm: do not upsample during second-pass linear normalization
Hi,
On Sun, Apr 2, 2017 at 6:32 PM, Kyle Swanson wrote:
> Signed-off-by: Kyle Swanson
> ---
> libavfilter/af_loudnorm.c | 58 +++---
> -
> 1 file changed, 34 insertions(+), 24 deletions(-)
>
> diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c
> index 9d91c76..e3e815e 100644
> --- a/libavfilter/af_loudnorm.c
> +++ b/libavfilter/af_loudnorm.c
> @@ -682,6 +682,7 @@ static int request_frame(AVFilterLink *outlink)
>
> static int query_formats(AVFilterContext *ctx)
> {
> +LoudNormContext *s = ctx->priv;
> AVFilterFormats *formats;
> AVFilterChannelLayouts *layouts;
> AVFilterLink *inlink = ctx->inputs[0];
> @@ -707,15 +708,17 @@ static int query_formats(AVFilterContext *ctx)
> if (ret < 0)
> return ret;
>
> -formats = ff_make_format_list(input_srate);
> -if (!formats)
> -return AVERROR(ENOMEM);
> -ret = ff_formats_ref(formats, &inlink->out_samplerates);
> -if (ret < 0)
> -return ret;
> -ret = ff_formats_ref(formats, &outlink->in_samplerates);
> -if (ret < 0)
> -return ret;
> +if (s->frame_type != LINEAR_MODE) {
> +formats = ff_make_format_list(input_srate);
> +if (!formats)
> +return AVERROR(ENOMEM);
> +ret = ff_formats_ref(formats, &inlink->out_samplerates);
> +if (ret < 0)
> +return ret;
> +ret = ff_formats_ref(formats, &outlink->in_samplerates);
> +if (ret < 0)
> +return ret;
> +}
>
> return 0;
> }
> @@ -754,21 +757,6 @@ static int config_input(AVFilterLink *inlink)
>
> init_gaussian_filter(s);
>
> -s->frame_type = FIRST_FRAME;
> -
> -if (s->linear) {
> -double offset, offset_tp;
> -offset= s->target_i - s->measured_i;
> -offset_tp = s->measured_tp + offset;
> -
> -if (s->measured_tp != 99 && s->measured_thresh != -70 &&
> s->measured_lra != 0 && s->measured_i != 0) {
> -if ((offset_tp <= s->target_tp) && (s->measured_lra <=
> s->target_lra)) {
> -s->frame_type = LINEAR_MODE;
> -s->offset = offset;
> -}
> -}
> -}
> -
> if (s->frame_type != LINEAR_MODE) {
> inlink->min_samples =
> inlink->max_samples =
> @@ -790,6 +778,27 @@ static int config_input(AVFilterLink *inlink)
> return 0;
> }
>
> +static av_cold int init(AVFilterContext *ctx)
> +{
> +LoudNormContext *s = ctx->priv;
> +s->frame_type = FIRST_FRAME;
> +
> +if (s->linear) {
> +double offset, offset_tp;
> +offset= s->target_i - s->measured_i;
> +offset_tp = s->measured_tp + offset;
> +
> +if (s->measured_tp != 99 && s->measured_thresh != -70 &&
> s->measured_lra != 0 && s->measured_i != 0) {
> +if ((offset_tp <= s->target_tp) && (s->measured_lra <=
> s->target_lra)) {
> +s->frame_type = LINEAR_MODE;
> +s->offset = offset;
> +}
> +}
> +}
> +
> +return 0;
> +}
> +
> static av_cold void uninit(AVFilterContext *ctx)
> {
> LoudNormContext *s = ctx->priv;
> @@ -914,6 +923,7 @@ AVFilter ff_af_loudnorm = {
> .priv_size = sizeof(LoudNormContext),
> .priv_class= &loudnorm_class,
> .query_formats = query_formats,
> +.init = init,
> .uninit= uninit,
> .inputs= avfilter_af_loudnorm_inputs,
> .outputs = avfilter_af_loudnorm_outputs,
> --
> 2.10.1
>
>
If no one has anything for this, I'll push it in the next day or so.
Kyle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_loudnorm: do not upsample during second-pass linear normalization
On Tue, Apr 4, 2017 at 7:14 AM, Kyle Swanson wrote:
> Hi,
>
>
> On Sun, Apr 2, 2017 at 6:32 PM, Kyle Swanson wrote:
>
>> Signed-off-by: Kyle Swanson
>> ---
>> libavfilter/af_loudnorm.c | 58 +++---
>> -
>> 1 file changed, 34 insertions(+), 24 deletions(-)
>>
>> diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c
>> index 9d91c76..e3e815e 100644
>> --- a/libavfilter/af_loudnorm.c
>> +++ b/libavfilter/af_loudnorm.c
>> @@ -682,6 +682,7 @@ static int request_frame(AVFilterLink *outlink)
>>
>> static int query_formats(AVFilterContext *ctx)
>> {
>> +LoudNormContext *s = ctx->priv;
>> AVFilterFormats *formats;
>> AVFilterChannelLayouts *layouts;
>> AVFilterLink *inlink = ctx->inputs[0];
>> @@ -707,15 +708,17 @@ static int query_formats(AVFilterContext *ctx)
>> if (ret < 0)
>> return ret;
>>
>> -formats = ff_make_format_list(input_srate);
>> -if (!formats)
>> -return AVERROR(ENOMEM);
>> -ret = ff_formats_ref(formats, &inlink->out_samplerates);
>> -if (ret < 0)
>> -return ret;
>> -ret = ff_formats_ref(formats, &outlink->in_samplerates);
>> -if (ret < 0)
>> -return ret;
>> +if (s->frame_type != LINEAR_MODE) {
>> +formats = ff_make_format_list(input_srate);
>> +if (!formats)
>> +return AVERROR(ENOMEM);
>> +ret = ff_formats_ref(formats, &inlink->out_samplerates);
>> +if (ret < 0)
>> +return ret;
>> +ret = ff_formats_ref(formats, &outlink->in_samplerates);
>> +if (ret < 0)
>> +return ret;
>> +}
>>
>> return 0;
>> }
>> @@ -754,21 +757,6 @@ static int config_input(AVFilterLink *inlink)
>>
>> init_gaussian_filter(s);
>>
>> -s->frame_type = FIRST_FRAME;
>> -
>> -if (s->linear) {
>> -double offset, offset_tp;
>> -offset= s->target_i - s->measured_i;
>> -offset_tp = s->measured_tp + offset;
>> -
>> -if (s->measured_tp != 99 && s->measured_thresh != -70 &&
>> s->measured_lra != 0 && s->measured_i != 0) {
>> -if ((offset_tp <= s->target_tp) && (s->measured_lra <=
>> s->target_lra)) {
>> -s->frame_type = LINEAR_MODE;
>> -s->offset = offset;
>> -}
>> -}
>> -}
>> -
>> if (s->frame_type != LINEAR_MODE) {
>> inlink->min_samples =
>> inlink->max_samples =
>> @@ -790,6 +778,27 @@ static int config_input(AVFilterLink *inlink)
>> return 0;
>> }
>>
>> +static av_cold int init(AVFilterContext *ctx)
>> +{
>> +LoudNormContext *s = ctx->priv;
>> +s->frame_type = FIRST_FRAME;
>> +
>> +if (s->linear) {
>> +double offset, offset_tp;
>> +offset= s->target_i - s->measured_i;
>> +offset_tp = s->measured_tp + offset;
>> +
>> +if (s->measured_tp != 99 && s->measured_thresh != -70 &&
>> s->measured_lra != 0 && s->measured_i != 0) {
>> +if ((offset_tp <= s->target_tp) && (s->measured_lra <=
>> s->target_lra)) {
>> +s->frame_type = LINEAR_MODE;
>> +s->offset = offset;
>> +}
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> static av_cold void uninit(AVFilterContext *ctx)
>> {
>> LoudNormContext *s = ctx->priv;
>> @@ -914,6 +923,7 @@ AVFilter ff_af_loudnorm = {
>> .priv_size = sizeof(LoudNormContext),
>> .priv_class= &loudnorm_class,
>> .query_formats = query_formats,
>> +.init = init,
>> .uninit= uninit,
>> .inputs= avfilter_af_loudnorm_inputs,
>> .outputs = avfilter_af_loudnorm_outputs,
>> --
>> 2.10.1
>>
>>
> If no one has anything for this, I'll push it in the next day or so.
>
> Kyle
>
Pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: make ff_framequeue_skip_samples() more useful.
Hi, On Sun, Jan 29, 2017 at 11:54 AM, Nicolas George wrote: > > Le decadi 10 pluviôse, an CCXXV, Muhammad Faiz a écrit : > > LGTM > > Thanks, pushed. > > Regards, > > -- > Nicolas George > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Forwarding here so it doesn't get lost in trac. It appears that this patch caused a bug: https://trac.ffmpeg.org/ticket/6349#comment:3 Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
Hi, On Mon, May 1, 2017 at 3:18 AM, Paul B Mahol wrote: > On 4/30/17, Nicolas George wrote: >> Le primidi 11 floreal, an CCXXV, Muhammad Faiz a ecrit : >>> Are you working on these? Because currently I'm not. >> >> There is nothing to work on yet: the message you answer to is raising a >> question about the global design of the internal API. That question >> needs an answer before any work can be done, and I can not decide alone. >> > > How nice, introducing bug that causes crash and then claiming there is > not such bug. > > Which filters you consider deemed worthy to not crash? > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Maybe 383057f8e744efeaaa3648a59bc577b25b055835 should be reverted until API stuff is sorted. This should also be backported to 3.3 because these issues are present in that release. Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libmp3lame: properly handle unaligned frame data
Hi, On Tue, May 2, 2017 at 12:18 PM, wm4 wrote: > On Tue, 2 May 2017 16:16:35 +0200 > Nicolas George wrote: > >> Le duodi 12 floréal, an CCXXV, Paul B Mahol a écrit : >> > This is all one big mess. >> >> It is, but I will not take responsibility when it is not mine. >> >> Libavfilter was in need of a serious overhaul. I do not see you denying >> it, and you suffered from the limitations it was causing as much as >> anybody else. I have undertaken that overhaul, and the help I received >> from other developers in that project has been scarce, to say the least. > > That doesn't free you from the responsibility to keep things in a > reasonably working state. > >> I do not complain, I can manage on my own; it will take longer, but I am >> in no rush. But I will not let the complaints of the inspectors of >> finished work trouble me. > > I can understand that attitude, but if a fix takes "longer" and > meanwhile certain filters or encoders crash left and right in git > master and even in the latest FFmpeg release, there's a need to act > quickly, even if it means reverting certain patches. I believe this is still broken on git master and is present on release 3.3. If a proper fix is going to take time, the patches that caused this should probably just be reverted for the time being, IMHO. > I don't want to blame anyone (and I ask you not to blame others either, > like you did above), but please fix/avoid crashing bugs? > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.3.1
Hi, On Sun, May 14, 2017 at 5:15 AM, Michael Niedermayer wrote: > On Sun, May 14, 2017 at 11:05:42AM +0200, Hendrik Leppkes wrote: >> On Sun, May 14, 2017 at 3:18 AM, Michael Niedermayer >> wrote: >> > Hi all >> > >> > ill make 3.3.1 soon (likely within 24h) and releases from other >> > maintained branches after that (if nothing unexpected happens) >> > >> > If you want to backport something, do it now >> > >> >> Was the lavfi alignment issue resolved for 3.3.1? > > i dont remember / think not > > >> If not, we should just apply the patch to re-align the output from >> framequeue to restore behavior of previous versions. > > if theres a regression and you have a fix, feel free to apply it > > thx It appears that the avfilter alignment bug was finally sorted and backported to 3.3 (thanks Muhammad). I'd argue that 3.3.2 is warranted sooner than later even though 3.3.1 was cut so recently. > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many things microsoft did are stupid, but not doing something just because > microsoft did it is even more stupid. If everything ms did were stupid they > would be bankrupt already. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] order T-shirts
Hi, Yeah, got mine too! Arrived safely in the USA. Thanks Thilo! Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] order T-shirts
Hi, On Sun, Sep 4, 2016 at 2:34 PM, Thomas Volkert wrote: > Hi, > > Some guys at the VDD asked for FFmpeg T-shirts. > I'd like to do a new T-shirt order. The shirts could be given to > multimedia devs who stop at one of our next booths. > > My idea is to order 25 shirts: > > 1*S > 5*M > 10*L > 7*XL > 2*XXL > > Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt. > So, we are talking about a maximum price of 562,50 Euro (excluding > delivery costs). > > If you like or don't like this idea, feel free to leave a comment here. > > Best regards, > Thomas. > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Can I order one too? I wear a size medium. How should I pay you? Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library
Hi, >On Sun, Oct 16, 2016 at 2:32 PM, Marton Balint wrote: I haven't been checking ffmpeg-devel too much lately and just saw these patches today. I'm glad to see that an ffmpeg libebur128 port is being taken seriously now, I had some trouble getting traction on a few similar patches earlier this year. A new version of libebur128 was released a few days ago, so we can probably improve this port even more. The loudnorm filter continues to be a popular ffmpeg feature. I still get messages about af_loudnorm from users all the time, so it'd be nice to remove the external library dependancy and open this up to everyone. > Also contains the following changes to the library: > - add ff_ prefix to functions > - remove cplusplus defines. > - add FF_ prefix to contants and some structs > - remove true peak calculation feature, since it uses its own resampler, and > af_audnorm does not need it. I'd argue that we should include the true peak calculation because after this port we'll want to replace the code in f_ebur128 as well. Libebur128 v1.2 drops the speex resampler and includes its own small resampler (fast and passes all the EBUR128 tests.) Also there's a patch I sent in June which uses libavresample APIs. > - remove version info and some fprintf(stderr) functions > - convert to use av_malloc > - always use histogram mode for LRA calculation, otherwise LRA data is slowly > consuming memory making af_loudnorm unfit for 24/7 operation. It also uses a > BSD style linked list implementation which is probably not available on all > platforms. So let's just remove the classic mode which not uses histogram. Probably a good idea! Seems awkward to include the BSD `queue.h` file, but probably not the end of the world. > - add ff_thread_once for calculating static histogram tables > - convert some functions to void which cannot fail > - remove intrinsics and some unused headers > - add support for planar audio Any other thoughts? I'll take a closer look at the patches tonight. Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library
On Mon, Nov 7, 2016 at 6:00 PM, Marton Balint wrote: > > On Fri, 4 Nov 2016, Marton Balint wrote: > >> >> On Thu, 3 Nov 2016, Hendrik Leppkes wrote: >> >>> On Mon, Oct 17, 2016 at 5:20 PM, Moritz Barsnick >>> wrote: On Mon, Oct 17, 2016 at 17:09:15 +0200, wm4 wrote: > > Does this copy parts of libebur128 to FFmpeg? > Why? There was a long discussion regarding this patch: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192668.html (in summary: "please don't require yet another small external library, rather port it to ffmpeg and maintain it") leading to this one: >>> >>> The generic idea was not to just copy/paste an external library into >>> internal code, but extend the ebur128 code we already have - at least >>> that way we get code written by one of our maintainers, code he knows >>> and can properly maintain. >> >> >> I copied the external library because we needed an API. The way the >> internals work, I used the library code because it was simply easier, than >> factoring out f_ebur128 stuff, also there are some features which >> f_ebur128.c does not have (variable sample rate support), and there was the >> licensing issue GPL v.s. LGPL. >> >>> If you just copy the implementation of a library, you might as well >>> just use that library - thats what it exists for. Why do we want to >>> increase the maintenance burden of our project when other people (ie. >>> the authors of libebur128) are already doing it as well? >> >> >> In general I agree with people who think that for small code, it is better >> to integrate it into our codebase, because >> - it can benefit from features we already have (e.g. resampling) >> - makes it easier for developers to work on features based on this >> - code gets more review than code in a small 3rd party library >> - code and/or improvements have stronger requirements performance-wise >> - code is better audited (Coverity, etc) >> >> Yes, some additional maintenance burden is the price we pay for this, >> which is IMHO in this case is acceptable. >> > > Is it fine to apply, or we should put this to a vote? Give me another day to review the patch. Meant look at this last weekend. > > Thanks, > > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library
On Tue, Nov 8, 2016 at 9:39 AM, Kyle Swanson wrote: > On Mon, Nov 7, 2016 at 6:00 PM, Marton Balint wrote: >> >> On Fri, 4 Nov 2016, Marton Balint wrote: >> >>> >>> On Thu, 3 Nov 2016, Hendrik Leppkes wrote: >>> >>>> On Mon, Oct 17, 2016 at 5:20 PM, Moritz Barsnick >>>> wrote: >>>>> >>>>> On Mon, Oct 17, 2016 at 17:09:15 +0200, wm4 wrote: >>>>>> >>>>>> Does this copy parts of libebur128 to FFmpeg? >>>>>> Why? >>>>> >>>>> >>>>> There was a long discussion regarding this patch: >>>>> >>>>> http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192668.html >>>>> >>>>> (in summary: "please don't require yet another small external library, >>>>> rather port it to ffmpeg and maintain it") leading to this one: >>>>> >>>> >>>> The generic idea was not to just copy/paste an external library into >>>> internal code, but extend the ebur128 code we already have - at least >>>> that way we get code written by one of our maintainers, code he knows >>>> and can properly maintain. >>> >>> >>> I copied the external library because we needed an API. The way the >>> internals work, I used the library code because it was simply easier, than >>> factoring out f_ebur128 stuff, also there are some features which >>> f_ebur128.c does not have (variable sample rate support), and there was the >>> licensing issue GPL v.s. LGPL. >>> >>>> If you just copy the implementation of a library, you might as well >>>> just use that library - thats what it exists for. Why do we want to >>>> increase the maintenance burden of our project when other people (ie. >>>> the authors of libebur128) are already doing it as well? >>> >>> >>> In general I agree with people who think that for small code, it is better >>> to integrate it into our codebase, because >>> - it can benefit from features we already have (e.g. resampling) >>> - makes it easier for developers to work on features based on this >>> - code gets more review than code in a small 3rd party library >>> - code and/or improvements have stronger requirements performance-wise >>> - code is better audited (Coverity, etc) >>> >>> Yes, some additional maintenance burden is the price we pay for this, >>> which is IMHO in this case is acceptable. >>> >> >> Is it fine to apply, or we should put this to a vote? > > Give me another day to review the patch. Meant look at this last weekend. These patches look good to me. If we're going to do this, we really need to keep the true peak mode in the libebur128 port. This is a huge part of the R128 spec, and it's important that it stays in. Of course redundant code is bad, so we'll need to update f_ebur128 as well (which has a true peak requirement.) I already have a patch for f_ebur128. Marton, it might be easier for you to update the patch to include true peak mode but I could do it as well. It'd be interesting to benchmark the libebur128 FIR resampler vs. swresample. Also, this port is only like ~670 lines of C plus a header. It makes sense to port it to FFmpeg instead of linking it. Also, on my systems (osx, linux) af_loudnorm is ~5x faster then it was when libebur128 was dynamically linked. Thanks, Kyle > >> >> Thanks, >> >> Marton >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library
On Thu, Nov 10, 2016 at 4:16 PM, Marton Balint wrote: > > On Thu, 10 Nov 2016, Kyle Swanson wrote: > >> On Tue, Nov 8, 2016 at 9:39 AM, Kyle Swanson wrote: >> >> These patches look good to me. If we're going to do this, we really >> need to keep the true peak mode in the libebur128 port. This is a huge >> part of the R128 spec, and it's important that it stays in. Of course >> redundant code is bad, so we'll need to update f_ebur128 as well >> (which has a true peak requirement.) I already have a patch for >> f_ebur128. Marton, it might be easier for you to update the patch to >> include true peak mode but I could do it as well. It'd be interesting >> to benchmark the libebur128 FIR resampler vs. swresample. > > > I'd rather push the patch as it is, then if you are interested, you can > start working on true peak. OK? Cool, patch is attached. Resampling here is done via libswresample. > > Since true peak calculation is so entirely different from loudness > calculation, you might also create a separate API/Context for it. Just > beacuse both loudness measurement and true peak is referenced in EBU R128 > recommendation, we don't necessarily have to use the same API for them. For > example, for true peak measurement, you might want to specify the > oversampling factor, but not the channel layout... > > Regards, > > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel 0001-avfilter-ebur128-add-true-peak-mode.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavfi/loudnorm: add an internal libebur128 library
On Fri, Nov 11, 2016 at 6:12 PM, Marton Balint wrote: > > On Thu, 10 Nov 2016, Kyle Swanson wrote: > >> On Thu, Nov 10, 2016 at 4:16 PM, Marton Balint wrote: >>> >>> >>> On Thu, 10 Nov 2016, Kyle Swanson wrote: >>> >>>> On Tue, Nov 8, 2016 at 9:39 AM, Kyle Swanson wrote: >>>> >>>> These patches look good to me. If we're going to do this, we really >>>> need to keep the true peak mode in the libebur128 port. This is a huge >>>> part of the R128 spec, and it's important that it stays in. Of course >>>> redundant code is bad, so we'll need to update f_ebur128 as well >>>> (which has a true peak requirement.) I already have a patch for >>>> f_ebur128. Marton, it might be easier for you to update the patch to >>>> include true peak mode but I could do it as well. It'd be interesting >>>> to benchmark the libebur128 FIR resampler vs. swresample. >>> >>> >>> >>> I'd rather push the patch as it is, then if you are interested, you can >>> start working on true peak. OK? >> >> Hi, > Ok, I applied it. Awesome. Thanks for your work on this! > >> Cool, patch is attached. Resampling here is done via libswresample. >> > > Yeah, I think I mentioned earlier that the library has a problem with true > peak measurement, notably it cannot measure true peak without any loudness > measurement, which is a shame performance-wise, since the user might neeed > true peak only. I guess you're technically right about this, but if someone _only_ wanted true peak stats, they wouldn't/shouldn't be using the ebur128 API/filter. `-af aresample=192k,astats` already does the trick. The EBU R128 spec says this: `A minimum feature set is required for all EBU Mode loudness meters: an EBU Mode compliant meter shall be able to measure and display the three main measures ‘Programme Loudness’, ‘Loudness Range’ and ‘Maximum True Peak Level’.` Basically, we need to include true peak in our EBU R128 implementation, and it's clean and convenient to leave it in as part of the API, just like libebur128 already has it. https://tech.ebu.ch/docs/tech/tech3341.pdf https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-4-201510-I!!PDF-E.pdf > Also, I am not sure that everybody who wants to measure true > peak will want no oversampling at an above 192KHz. For EBU R128 / BS.1770, this is all the spec requires. There are already many other ways to measure true peak if you're after another flavor. > Have you considered the separete context idea? If we want our API to be > similar to the external lib, we still can use the separete true peak context > inside the EBUR128 context if the user wants true peak. I totally get what you're saying, but it seems to unnecessary to write this little abstraction on top of libswresample (I also don't know where else it'd be useful.) libswresample is already the separate context. :) Take a look at my patch, it should be good. I'll also be sending a patch (in a new thread) to update f_ebur128 for this new API soon. Thanks! Kyle > >>> >>> Since true peak calculation is so entirely different from loudness >>> calculation, you might also create a separate API/Context for it. Just >>> beacuse both loudness measurement and true peak is referenced in EBU R128 >>> recommendation, we don't necessarily have to use the same API for them. >>> For >>> example, for true peak measurement, you might want to specify the >>> oversampling factor, but not the channel layout... > > > Regards, > Marton > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi/af_ebur128: update filter to use new ebur128 API
Hi, Here's a couple of patches which update the ebur128 filter to use the recently added ebur128 API. This updated filter allows fine-tuned control over which EBU R128 parameters are measured, and provides modest speed increases over the previous ebur128 filter. Also noteworthy: this removes the video output option of the ebur128 filter. This is extraneous for an ebur128 measurement filter IMHO, but if we wanted to keep similar functionality in FFmpeg, we'd be better served by a new video source filter where custom meters could be created via exported frame metadata. The first patch adds true peak functionality to the ebur128 API using swresample (this was already discussed a little bit: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202583.html) The second patch is an update to the ebur128 filter. Kyle 0001-lavfi-ebur128-add-ebur128_check_true_peak.patch Description: Binary data 0002-lavfi-af_ebur128-update-filter-to-use-new-ebur128-AP.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/af_ebur128: update filter to use new ebur128 API
On Thu, Nov 17, 2016 at 6:55 PM, Michael Niedermayer wrote: > On Thu, Nov 17, 2016 at 11:04:46AM -0600, Kyle Swanson wrote: >> Hi, >> >> Here's a couple of patches which update the ebur128 filter to use the >> recently added ebur128 API. This updated filter allows fine-tuned >> control over which EBU R128 parameters are measured, and provides >> modest speed increases over the previous ebur128 filter. Also >> noteworthy: this removes the video output option of the ebur128 >> filter. This is extraneous for an ebur128 measurement filter IMHO, but >> if we wanted to keep similar functionality in FFmpeg, we'd be better >> served by a new video source filter where custom meters could be >> created via exported frame metadata. >> >> The first patch adds true peak functionality to the ebur128 API using >> swresample (this was already discussed a little bit: >> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202583.html) >> The second patch is an update to the ebur128 filter. >> >> Kyle > > src/libavfilter/af_ebur128.c: In function ‘write_strings’: > src/libavfilter/af_ebur128.c:121:9: error: variable length array > ‘sample_peak’ is used [-Werror=vla] > src/libavfilter/af_ebur128.c:133:9: error: variable length array ‘true_peak’ > is used [-Werror=vla] Thanks. Didn't realize this wasn't allowed. Easy fix. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > If you think the mosad wants you dead since a long time then you are either > wrong or dead since a long time. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/af_ebur128: update filter to use new ebur128 API
On Thu, Nov 17, 2016 at 11:04 AM, Kyle Swanson wrote: > Hi, > > Here's a couple of patches which update the ebur128 filter to use the > recently added ebur128 API. This updated filter allows fine-tuned > control over which EBU R128 parameters are measured, and provides > modest speed increases over the previous ebur128 filter. Also > noteworthy: this removes the video output option of the ebur128 > filter. This is extraneous for an ebur128 measurement filter IMHO, but > if we wanted to keep similar functionality in FFmpeg, we'd be better > served by a new video source filter where custom meters could be > created via exported frame metadata. > > The first patch adds true peak functionality to the ebur128 API using > swresample (this was already discussed a little bit: > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202583.html) > The second patch is an update to the ebur128 filter. > > Kyle Here's a v2 for the second patch. Fixes the vla error. 0002-lavfi-af_ebur128-update-filter-to-use-new-ebur128-AP.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/af_ebur128: update filter to use new ebur128 API
On Thu, Nov 17, 2016 at 11:04 AM, Kyle Swanson wrote: > Hi, > > Here's a couple of patches which update the ebur128 filter to use the > recently added ebur128 API. This updated filter allows fine-tuned > control over which EBU R128 parameters are measured, and provides > modest speed increases over the previous ebur128 filter. Also > noteworthy: this removes the video output option of the ebur128 > filter. This is extraneous for an ebur128 measurement filter IMHO, but > if we wanted to keep similar functionality in FFmpeg, we'd be better > served by a new video source filter where custom meters could be > created via exported frame metadata. > > The first patch adds true peak functionality to the ebur128 API using > swresample (this was already discussed a little bit: > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202583.html) > The second patch is an update to the ebur128 filter. > > Kyle Does anyone have any problems with the first patch? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] cmdutils: improve `-buildconf` for shell substitution
Hi, Always thought something like this might be useful, but I finally took the time to take a look. Useful when you want to configure a new FFmpeg build using the configuration string of a previously built version. True you could accomplish the same thing with sed, but I think this tweak is still useful. Example usage looks like this: ./configure $(ffmpeg -hide_banner -buildconf) && make install Kyle 0001-cmdutils-improve-buildconf-for-shell-substitution.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cmdutils: improve `-buildconf` for shell substitution
On Tue, Sep 27, 2016 at 4:37 PM, Clément Bœsch wrote: > > On Tue, Sep 27, 2016 at 04:25:52PM -0500, Kyle Swanson wrote: > > Hi, > > > > Always thought something like this might be useful, but I finally took the > > time to take a look. Useful when you want to configure a new FFmpeg build > > using the configuration string of a previously built version. True you > > could accomplish the same thing with sed, but I think this tweak is still > > useful. Example usage looks like this: > > > > ./configure $(ffmpeg -hide_banner -buildconf) && make install > > > > how about using make config? (－‸ლ) Thanks. Ignore this patch. > > -- > Clément B. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add loudnorm
Here's another audio filter. I hinted at this a few months ago, but I found out
that
finishing the last 5% took almost as long as the first 95%. This is an EBU R128
dynamic loudness normalization filter. This filter uses libebur128 v1.1.0[1]
and must be
configured with `--enable-libebur128'. Please also see the accompanying blog
post[2]
which has an algorithm description, as well as some usage instructions.
[1] https://github.com/jiixyj/libebur128
[2] http://k.ylo.ph/2016/04/04/loudnorm.html
Thanks!
Kyle
Signed-off-by: Kyle Swanson
---
Changelog | 1 +
MAINTAINERS | 1 +
configure | 5 +
doc/filters.texi | 42 +++
libavfilter/Makefile | 1 +
libavfilter/af_loudnorm.c | 905 ++
libavfilter/allfilters.c | 1 +
libavfilter/version.h | 4 +-
8 files changed, 958 insertions(+), 2 deletions(-)
create mode 100644 libavfilter/af_loudnorm.c
diff --git a/Changelog b/Changelog
index fa4edd4..602f6a2 100644
--- a/Changelog
+++ b/Changelog
@@ -20,6 +20,7 @@ version :
- bitstream filter for extracting DTS core
- ADPCM IMA DAT4 decoder
- musx demuxer
+- loudnorm filter
version 3.0:
- Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/MAINTAINERS b/MAINTAINERS
index a993a67..fb4b8fd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -358,6 +358,7 @@ Filters:
af_compand.c Paul B Mahol
af_firequalizer.c Muhammad Faiz
af_ladspa.c Paul B Mahol
+ af_loudnorm.c Kyle Swanson
af_pan.c Nicolas George
af_sidechaincompress.cPaul B Mahol
af_silenceremove.cPaul B Mahol
diff --git a/configure b/configure
index 94a66d8..024568a 100755
--- a/configure
+++ b/configure
@@ -219,6 +219,8 @@ External library support:
--enable-libcdio enable audio CD grabbing with libcdio [no]
--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
and libraw1394 [no]
+ --enable-libebur128 enable libebur128 for EBU R128 measurement,
+ needed for loudnorm filter [no]
--enable-libfaac enable AAC encoding via libfaac [no]
--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
--enable-libfliteenable flite (voice synthesis) support via libflite
[no]
@@ -1467,6 +1469,7 @@ EXTERNAL_LIBRARY_LIST="
libcdio
libcelt
libdc1394
+libebur128
libfaac
libfdk_aac
libflite
@@ -2948,6 +2951,7 @@ hwupload_cuda_filter_deps="cuda"
interlace_filter_deps="gpl"
kerndeint_filter_deps="gpl"
ladspa_filter_deps="ladspa dlopen"
+loudnorm_filter_deps="libebur128"
mcdeint_filter_deps="avcodec gpl"
movie_filter_deps="avcodec avformat"
mpdecimate_filter_deps="gpl"
@@ -5534,6 +5538,7 @@ enabled libcelt && require libcelt celt/celt.h
celt_decode -lcelt0 &&
{ check_lib celt/celt.h
celt_decoder_create_custom -lcelt0 ||
die "ERROR: libcelt must be installed and
version must be >= 0.11.0."; }
enabled libcaca && require_pkg_config caca caca.h caca_create_canvas
+enabled libebur128&& require ebur128 ebur128.h
ebur128_relative_threshold -lebur128
enabled libfaac && require2 libfaac "stdint.h faac.h"
faacEncGetVersion -lfaac
enabled libfdk_aac&& { use_pkg_config fdk-aac "fdk-aac/aacenc_lib.h"
aacEncOpen ||
{ require libfdk_aac fdk-aac/aacenc_lib.h
aacEncOpen -lfdk-aac &&
diff --git a/doc/filters.texi b/doc/filters.texi
index 592fc24..6c563d9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2711,6 +2711,48 @@ Modify the @var{N}-th control value.
If the specified value is not valid, it is ignored and prior one is kept.
@end table
+@section loudnorm
+
+EBU R128 loudness normalization. Includes both dynamic and linear
normalization modes.
+Support for both single pass (livestreams, files) and double pass (files)
modes.
+This algorithm can target IL, LRA, and maximum true peak. Requires libebur128.
+
+The filter accepts the following options:
+
+@table @option
+@item I, i
+Set integrated loudness target
+
+@item LRA, lra
+Set loudness range target
+
+@item TP, tp
+Set maximum true peak
+
+@item measured_I, measured_i
+Measured IL of input file
+
+@item measured_LRA, measured_lra
+Measured LRA of input file
+
+@item measured_TP, measured_tp
+Measured true peak of input file
+
+@item measured_thresh
+Measured threshold of input file
+
+@item offset
+Set offset gain. Gain is applied before the true-peak limiter.
+
+@item linear
+Normalize linearly if possible.
+measured_I, measur
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
> Here's another audio filter. I hinted at this a few months ago, but I found > out that > finishing the last 5% took almost as long as the first 95%. This is an EBU > R128 > dynamic loudness normalization filter. This filter uses libebur128 v1.1.0[1] > and must be > configured with `--enable-libebur128'. Please also see the accompanying blog > post[2] > which has an algorithm description, as well as some usage instructions. > > [1] https://github.com/jiixyj/libebur128 > [2] http://k.ylo.ph/2016/04/04/loudnorm.html > > Thanks! > Kyle Hi, First version had a couple of messed up tabs. New patch attached. 0001-avfilter-add-loudnorm.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Wed, Apr 6, 2016 at 12:45 AM, Clément Bœsch wrote: > On Tue, Apr 05, 2016 at 07:01:14PM -0500, Kyle Swanson wrote: >> Here's another audio filter. I hinted at this a few months ago, but I found >> out that >> finishing the last 5% took almost as long as the first 95%. This is an EBU >> R128 >> dynamic loudness normalization filter. This filter uses libebur128 v1.1.0[1] >> and must be >> configured with `--enable-libebur128'. Please also see the accompanying blog >> post[2] >> which has an algorithm description, as well as some usage instructions. >> >> [1] https://github.com/jiixyj/libebur128 >> [2] http://k.ylo.ph/2016/04/04/loudnorm.html >> >> Thanks! >> Kyle >> >> Signed-off-by: Kyle Swanson >> --- >> Changelog | 1 + >> MAINTAINERS | 1 + >> configure | 5 + >> doc/filters.texi | 42 +++ >> libavfilter/Makefile | 1 + >> libavfilter/af_loudnorm.c | 905 >> ++ >> libavfilter/allfilters.c | 1 + >> libavfilter/version.h | 4 +- >> 8 files changed, 958 insertions(+), 2 deletions(-) >> create mode 100644 libavfilter/af_loudnorm.c >> > > Mmh. That's nice and all but... why not use/adjust the native ebur128 > filter we have instead of relying on an external library? > > [...] > > -- > Clément B. This could be an option for the future. We'll need to break all the EBU R128 logic out into utility functions and update it to use the newest version BS.1770 so it can be used by both filters. Using libebur128 is a good option because it is widely used, actively developed, and updated whenever the spec changes. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Wed, Apr 6, 2016 at 10:02 AM, Clément Bœsch wrote: > On Wed, Apr 06, 2016 at 09:52:51AM -0500, Kyle Swanson wrote: >> On Wed, Apr 6, 2016 at 12:45 AM, Clément Bœsch wrote: >> > On Tue, Apr 05, 2016 at 07:01:14PM -0500, Kyle Swanson wrote: >> >> Here's another audio filter. I hinted at this a few months ago, but I >> >> found out that >> >> finishing the last 5% took almost as long as the first 95%. This is an >> >> EBU R128 >> >> dynamic loudness normalization filter. This filter uses libebur128 >> >> v1.1.0[1] and must be >> >> configured with `--enable-libebur128'. Please also see the accompanying >> >> blog post[2] >> >> which has an algorithm description, as well as some usage instructions. >> >> >> >> [1] https://github.com/jiixyj/libebur128 >> >> [2] http://k.ylo.ph/2016/04/04/loudnorm.html >> >> >> >> Thanks! >> >> Kyle >> >> >> >> Signed-off-by: Kyle Swanson >> >> --- >> >> Changelog | 1 + >> >> MAINTAINERS | 1 + >> >> configure | 5 + >> >> doc/filters.texi | 42 +++ >> >> libavfilter/Makefile | 1 + >> >> libavfilter/af_loudnorm.c | 905 >> >> ++ >> >> libavfilter/allfilters.c | 1 + >> >> libavfilter/version.h | 4 +- >> >> 8 files changed, 958 insertions(+), 2 deletions(-) >> >> create mode 100644 libavfilter/af_loudnorm.c >> >> >> > >> > Mmh. That's nice and all but... why not use/adjust the native ebur128 >> > filter we have instead of relying on an external library? >> > >> > [...] >> > >> > -- >> > Clément B. >> >> This could be an option for the future. We'll need to break all the >> EBU R128 logic out into utility functions > > why? what do you need exactly from the filter? The meta are exported in > each audio frame. That could work, but in this filter there is a second internal loudness measurement. Frame meta would only work for the input stream. > >> and update it to use the newest version BS.1770 so it can be used by >> both filters. Using libebur128 is a >> good option because it is widely used, actively developed, and updated >> whenever the spec changes. > > except it's an external dependency and we have code builtin available, > doing the same thing, and with no open issue (afaik). > > -- > Clément B. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Wed, Apr 6, 2016 at 5:31 PM, Paul B Mahol wrote: > On 4/6/16, Kyle Swanson wrote: >> On Wed, Apr 6, 2016 at 10:02 AM, Clement Boesch wrote: >>> On Wed, Apr 06, 2016 at 09:52:51AM -0500, Kyle Swanson wrote: >>>> On Wed, Apr 6, 2016 at 12:45 AM, Clement Boesch wrote: >>>> > On Tue, Apr 05, 2016 at 07:01:14PM -0500, Kyle Swanson wrote: >>>> >> Here's another audio filter. I hinted at this a few months ago, but I >>>> >> found out that >>>> >> finishing the last 5% took almost as long as the first 95%. This is an >>>> >> EBU R128 >>>> >> dynamic loudness normalization filter. This filter uses libebur128 >>>> >> v1.1.0[1] and must be >>>> >> configured with `--enable-libebur128'. Please also see the >>>> >> accompanying blog post[2] >>>> >> which has an algorithm description, as well as some usage >>>> >> instructions. >>>> >> >>>> >> [1] https://github.com/jiixyj/libebur128 >>>> >> [2] http://k.ylo.ph/2016/04/04/loudnorm.html >>>> >> >>>> >> Thanks! >>>> >> Kyle >>>> >> >>>> >> Signed-off-by: Kyle Swanson >>>> >> --- >>>> >> Changelog | 1 + >>>> >> MAINTAINERS | 1 + >>>> >> configure | 5 + >>>> >> doc/filters.texi | 42 +++ >>>> >> libavfilter/Makefile | 1 + >>>> >> libavfilter/af_loudnorm.c | 905 >>>> >> ++ >>>> >> libavfilter/allfilters.c | 1 + >>>> >> libavfilter/version.h | 4 +- >>>> >> 8 files changed, 958 insertions(+), 2 deletions(-) >>>> >> create mode 100644 libavfilter/af_loudnorm.c >>>> >> >>>> > >>>> > Mmh. That's nice and all but... why not use/adjust the native ebur128 >>>> > filter we have instead of relying on an external library? >>>> > >>>> > [...] >>>> > >>>> > -- >>>> > Clement B. >>>> >>>> This could be an option for the future. We'll need to break all the >>>> EBU R128 logic out into utility functions >>> >>> why? what do you need exactly from the filter? The meta are exported in >>> each audio frame. >> >> That could work, but in this filter there is a second internal >> loudness measurement. Frame meta would only work for the input stream. > > Couldn't code from ebur128 filter be refactored in such way so it > could be used by loudnorm? > Yeah, that's what I was saying. It could be done, but might take a little while. I figure libebur128 could work fine in the meantime. Would probably also be useful for filters like astats. >> >>> >>>> and update it to use the newest version BS.1770 so it can be used by >>>> both filters. Using libebur128 is a >>>> good option because it is widely used, actively developed, and updated >>>> whenever the spec changes. >>> >>> except it's an external dependency and we have code builtin available, >>> doing the same thing, and with no open issue (afaik). >>> >>> -- >>> Clement B. >>> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Tue, Apr 5, 2016 at 7:01 PM, Kyle Swanson wrote: > Here's another audio filter. I hinted at this a few months ago, but I found > out that > finishing the last 5% took almost as long as the first 95%. This is an EBU > R128 > dynamic loudness normalization filter. This filter uses libebur128 v1.1.0[1] > and must be > configured with `--enable-libebur128'. Please also see the accompanying blog > post[2] > which has an algorithm description, as well as some usage instructions. > > [1] https://github.com/jiixyj/libebur128 > [2] http://k.ylo.ph/2016/04/04/loudnorm.html > > Thanks! > Kyle Does anyone have any comments about this besides the fact that it links an external library? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Wed, Apr 6, 2016 at 8:09 PM, Carl Eugen Hoyos wrote: > Kyle Swanson ylo.ph> writes: > >> Does anyone have any comments about this besides the fact >> that it links an external library? > > It is not ok to add an additional dependency to FFmpeg if the > features of the new dependency are already available within > FFmpeg. > (Note that I cannot judge if this is the case for your patch.) > Any issues with breaking out the measurement logic from the ebur128 filter into utility functions? I can take a crack at it if no one thinks it's a horrible idea... > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Fri, Apr 8, 2016 at 4:07 PM, Kyle Swanson wrote: > On Wed, Apr 6, 2016 at 8:09 PM, Carl Eugen Hoyos wrote: >> Kyle Swanson ylo.ph> writes: >> >>> Does anyone have any comments about this besides the fact >>> that it links an external library? >> >> It is not ok to add an additional dependency to FFmpeg if the >> features of the new dependency are already available within >> FFmpeg. >> (Note that I cannot judge if this is the case for your patch.) >> > > Any issues with breaking out the measurement logic from the ebur128 > filter into utility functions? I can take a crack at it if no one > thinks it's a horrible idea... Or adapt the libebur128 code, which has a couple of nice features and an MIT license. Obviously the oversampling would have to be rewritten to use swresample. > >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Tue, Apr 5, 2016 at 7:01 PM, Kyle Swanson wrote: > > Here's another audio filter. I hinted at this a few months ago, but I found > out that > finishing the last 5% took almost as long as the first 95%. This is an EBU > R128 > dynamic loudness normalization filter. This filter uses libebur128 v1.1.0[1] > and must be > configured with `--enable-libebur128'. Please also see the accompanying blog > post[2] > which has an algorithm description, as well as some usage instructions. > > [1] https://github.com/jiixyj/libebur128 > [2] http://k.ylo.ph/2016/04/04/loudnorm.html > > Thanks! > Kyle Hi, I think there was a little bit of confusion about what this filter does, and why exactly it links libebur128. I'm not sure if anyone actually reviewed the patch, since all of the discussion was about libebur128. I didn't quite provide it the first time, so here's some background information and rationale for linking libebur128. Most broadcasters are now specifying mandatory loudness targets for source material, which is usually supplied as a target integrated loudness value and a target maximum true peak. Loudness normalization is easy for files with sufficient headroom for linear gain adjustments, difficult for files with not enough headroom, and even more difficult for live streams – this filter handles all these situations. The loudnorm algo is basically a loudness-tuned AGC which was designed to honor local dynamics, followed by a look-ahead true peak limiter. Using normal parameters the result is usually imperceptible, even with very dynamic source material such as classical music. This filter should be a major boon to broadcasters and digital distribution people, since the only software currently available that does this kind of thing is commercial, and for the most part very expensive (Minnetonka, Skylark, Nugen, etc.) FFmpeg has a native ebur128 filter which already has all the EBU R128 logic baked in, but I chose to link libebur128 with the loudnorm filter for a couple of reasons. If all it needed was an input measurement, it would certainly be easy to just export the frame meta from the ebur128 filter, but the loudnorm algorithm needs loudness measurements from a couple of different places in the signal chain making this solution impossible. I thought about extracting the FFmpeg ebur128 functions so they could be reused elsewhere in FFmpeg, but the R128 logic from the ebur128 filter is quite tangled, tied to filter functions, internal states are spread out between several structs, and is not easily extracted into a reusable API. Ideally, someone could take a crack at extracting the FFmpeg ebur128 logic, but in the meantime I chose to link libebur128 with the loudnorm filter. libebur128 is well known and used R128 library. True this adds a dependency and seems a little redundant, but this is a filter and not a core part of FFmpeg. Many filters link special libraries, users can choose to either configure and compile with the library or not, and if they don't then the filter won't be enabled on their builds. Maybe I'm wrong, but I don't see it as a huge issue. If I or someone else gets the time to rewrite FFmpeg's ebur128 filter down the road, it should be easy to update this filter to use FFmpeg's ebur128 measurements. Updated and rebased patch is attached, please review. Thanks! Kyle 0001-avfilter-add-loudnorm.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
Hi, Updated patch attached. Thanks! 0001-avfilter-add-loudnorm.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Tue, May 10, 2016 at 4:35 AM, Rostislav Pehlivanov wrote: > Then just copy the logic from libebur128 into the filter, the library > itself is smaller than some filters we have and it's under the MIT license. I think this is probably a good way to go. I'd need to rewrite the resampling bit to use libswresample, but that shouldn't be too hard. These functions would then be available for the ebur128 filter, the loudnorm filter, the astats filter, and whoever else wants to use it. I know its MIT licensed, but I'll get in touch with the original author and let him know. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Tue, May 10, 2016 at 4:33 AM, Paul B Mahol wrote:
> On 5/10/16, Kyle Swanson wrote:
>> Hi,
>>
>> Updated patch attached. Thanks!
>>
>
>
> [...]
>
>>
>> +@section loudnorm
>> +
>> +EBU R128 loudness normalization. Includes both dynamic and linear
>> normalization modes.
>> +Support for both single pass (livestreams, files) and double pass (files)
>> modes.
>> +This algorithm can target IL, LRA, and maximum true peak.
>> +
>> +To enable compilation of this filter you need to configure FFmpeg with
>> +@code{--enable-libebur128}.
>> +
>> +The filter accepts the following options:
>> +
>> +@table @option
>> +@item I, i
>> +Set integrated loudness target
>
> Could you document range and default values here and below?
>
> [...]
>
>> +ebur128_state *r128_in;
>> +ebur128_state *r128_out;
>> +} LoudNormContext;
>> +
>> +enum {
>> +FIRST_FRAME,
>> +INNER_FRAME,
>> +FINAL_FRAME,
>> +LINEAR_MODE
>> +};
>
> Can't you name those enums? And add NB as last one?
Sure, I'll do that. What do you mean by `NB' ?
>
> [...]
>
>> +static int config_input(AVFilterLink *inlink)
>> +{
>> +AVFilterContext *ctx = inlink->dst;
>> +LoudNormContext *s = ctx->priv;
>> +
>> +s->r128_in = av_malloc((size_t) sizeof(ebur128_state*));
>> +if (!s->r128_in)
>> +return AVERROR(ENOMEM);
>> +s->r128_in = ebur128_init(inlink->channels, inlink->sample_rate,
>> EBUR128_MODE_I | EBUR128_MODE_S | EBUR128_MODE_LRA |
>> EBUR128_MODE_SAMPLE_PEAK);
>> +
>
> Can this fail? One should check return value.
> Doesn't this leaks memory?
I already check the malloc, and it doesn't look like ebur128_init()
can fail in any way here.
>
>> +s->r128_out = av_malloc((size_t) sizeof(ebur128_state*));
>> +if (!s->r128_out)
>> +return AVERROR(ENOMEM);
>> +s->r128_out = ebur128_init(inlink->channels, inlink->sample_rate,
>> EBUR128_MODE_I | EBUR128_MODE_S | EBUR128_MODE_LRA |
>> EBUR128_MODE_SAMPLE_PEAK);
>
> ditto.
>
> [...]
>
>> +static const AVFilterPad avfilter_af_loudnorm_outputs[] = {
>> +{
>> +.name = "default",
>> +.request_frame = request_frame,
>> +.type = AVMEDIA_TYPE_AUDIO,
>
> Vertical alignment please.
>
> [...]
>
> rest LGTM
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Thanks for the review. If someone can answer my question about the
enum I'll send a new patch later today.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
Hi, Updated patch attached. 0001-avfilter-add-loudnorm.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
Hi, If nobody else has any changes, can this please be pushed? Thanks On Wed, May 11, 2016 at 1:35 PM, Kyle Swanson wrote: > Hi, > > Updated patch attached. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
On Sat, May 14, 2016 at 5:49 PM, Paul B Mahol wrote: > On 5/14/16, Kyle Swanson wrote: >> Hi, >> >> If nobody else has any changes, can this please be pushed? > > What about removal of libebur128 dependency? > I figured loudnorm can be pushed now, and porting libebur128 to ffmpeg and removing the dependency can be done next. Updates to the ebur128 and astats filter to use the new libebur128 ported code can be another patch after that. That makes sense to me, but maybe there's a more preferable way to do it. >> >> Thanks >> >> On Wed, May 11, 2016 at 1:35 PM, Kyle Swanson wrote: >>> Hi, >>> >>> Updated patch attached. >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm
> > Pushed. Waiting for libebur128 removal as dependency. Thanks. Working on porting libebur128 to FFmpeg now. Hopefully I can find some time to finish that patch soon. > > Can anything be done to make this filter faster? Probably, I'll do some profiling. The true peak limiter requires upsampling everything to 192kHz which is always going to be expensive. On my machine, a stereo file processes with a speed of about 16x. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/af_loudnorm: add dual_mono option
Signed-off-by: Kyle Swanson
---
doc/filters.texi | 7 +++
libavfilter/af_loudnorm.c | 7 +++
2 files changed, 14 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index d9330e3..439baf9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2765,6 +2765,13 @@ measured_I, measured_LRA, measured_TP, and
measured_thresh must also
to be specified in order to use this mode.
Options are true or false. Default is true.
+@item dual_mono
+Treat mono input files as "dual-mono". If a mono file is intended for playback
+on a stereo system, its EBU R128 measurement will be perceptually incorrect.
+If set to @code{true}, this option will compensate for this effect.
+Multi-channel input files are not affected by this option.
+Options are true or false. Default is false.
+
@item print_format
Set print format for stats. Options are summary, json, or none.
Default value is none.
diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c
index 9d27c16..604697e 100644
--- a/libavfilter/af_loudnorm.c
+++ b/libavfilter/af_loudnorm.c
@@ -60,6 +60,7 @@ typedef struct LoudNormContext {
double measured_thresh;
double offset;
int linear;
+int dual_mono;
enum PrintFormat print_format;
double *buf;
@@ -113,6 +114,7 @@ static const AVOption loudnorm_options[] = {
{ "measured_thresh", "measured threshold of input file",
OFFSET(measured_thresh), AV_OPT_TYPE_DOUBLE, {.dbl = -70.}, -99.,
0., FLAGS },
{ "offset", "set offset gain", OFFSET(offset),
AV_OPT_TYPE_DOUBLE, {.dbl = 0.},-99., 99., FLAGS },
{ "linear", "normalize linearly if possible",OFFSET(linear),
AV_OPT_TYPE_BOOL,{.i64 = 1},0, 1, FLAGS },
+{ "dual_mono","treat mono input as dual-mono",
OFFSET(dual_mono),AV_OPT_TYPE_BOOL,{.i64 = 0},0,
1, FLAGS },
{ "print_format", "set print format for stats",
OFFSET(print_format), AV_OPT_TYPE_INT, {.i64 = NONE}, NONE, PF_NB
-1, FLAGS, "print_format" },
{ "none", 0, 0,
AV_OPT_TYPE_CONST, {.i64 = NONE}, 0, 0, FLAGS,
"print_format" },
{ "json", 0, 0,
AV_OPT_TYPE_CONST, {.i64 = JSON}, 0, 0, FLAGS,
"print_format" },
@@ -731,6 +733,11 @@ static int config_input(AVFilterLink *inlink)
if (!s->r128_out)
return AVERROR(ENOMEM);
+if (inlink->channels == 1 && s->dual_mono) {
+ebur128_set_channel(s->r128_in, 0, EBUR128_DUAL_MONO);
+ebur128_set_channel(s->r128_out, 0, EBUR128_DUAL_MONO);
+}
+
s->buf_size = frame_size(inlink->sample_rate, 3000) * inlink->channels;
s->buf = av_malloc_array(s->buf_size, sizeof(*s->buf));
if (!s->buf)
--
2.5.4 (Apple Git-61)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_loudnorm: add dual_mono option
On Tue, Jun 7, 2016 at 11:55 AM, Kyle Swanson wrote:
> Signed-off-by: Kyle Swanson
> ---
> doc/filters.texi | 7 +++
> libavfilter/af_loudnorm.c | 7 +++
> 2 files changed, 14 insertions(+)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index d9330e3..439baf9 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -2765,6 +2765,13 @@ measured_I, measured_LRA, measured_TP, and
> measured_thresh must also
> to be specified in order to use this mode.
> Options are true or false. Default is true.
>
> +@item dual_mono
> +Treat mono input files as "dual-mono". If a mono file is intended for
> playback
> +on a stereo system, its EBU R128 measurement will be perceptually incorrect.
> +If set to @code{true}, this option will compensate for this effect.
> +Multi-channel input files are not affected by this option.
> +Options are true or false. Default is false.
> +
> @item print_format
> Set print format for stats. Options are summary, json, or none.
> Default value is none.
> diff --git a/libavfilter/af_loudnorm.c b/libavfilter/af_loudnorm.c
> index 9d27c16..604697e 100644
> --- a/libavfilter/af_loudnorm.c
> +++ b/libavfilter/af_loudnorm.c
> @@ -60,6 +60,7 @@ typedef struct LoudNormContext {
> double measured_thresh;
> double offset;
> int linear;
> +int dual_mono;
> enum PrintFormat print_format;
>
> double *buf;
> @@ -113,6 +114,7 @@ static const AVOption loudnorm_options[] = {
> { "measured_thresh", "measured threshold of input file",
> OFFSET(measured_thresh), AV_OPT_TYPE_DOUBLE, {.dbl = -70.}, -99.,
> 0., FLAGS },
> { "offset", "set offset gain",
> OFFSET(offset), AV_OPT_TYPE_DOUBLE, {.dbl = 0.},-99.,
> 99., FLAGS },
> { "linear", "normalize linearly if possible",
> OFFSET(linear), AV_OPT_TYPE_BOOL,{.i64 = 1},0,
> 1, FLAGS },
> +{ "dual_mono","treat mono input as dual-mono",
> OFFSET(dual_mono),AV_OPT_TYPE_BOOL,{.i64 = 0},0,
> 1, FLAGS },
> { "print_format", "set print format for stats",
> OFFSET(print_format), AV_OPT_TYPE_INT, {.i64 = NONE}, NONE, PF_NB
> -1, FLAGS, "print_format" },
> { "none", 0, 0,
> AV_OPT_TYPE_CONST, {.i64 = NONE}, 0, 0, FLAGS,
> "print_format" },
> { "json", 0, 0,
> AV_OPT_TYPE_CONST, {.i64 = JSON}, 0, 0, FLAGS,
> "print_format" },
> @@ -731,6 +733,11 @@ static int config_input(AVFilterLink *inlink)
> if (!s->r128_out)
> return AVERROR(ENOMEM);
>
> +if (inlink->channels == 1 && s->dual_mono) {
> +ebur128_set_channel(s->r128_in, 0, EBUR128_DUAL_MONO);
> +ebur128_set_channel(s->r128_out, 0, EBUR128_DUAL_MONO);
> +}
> +
> s->buf_size = frame_size(inlink->sample_rate, 3000) * inlink->channels;
> s->buf = av_malloc_array(s->buf_size, sizeof(*s->buf));
> if (!s->buf)
> --
> 2.5.4 (Apple Git-61)
>
Pushed. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
Hi all, Here's three patches. These are still WIP and not ready to be pushed. 0001-avfilter-add-libebur128-port.patch This first patch ports libebur128 to ffmpeg. I haven't re-indented these yet, so please diff `ebur128.c' and `ebur128.h' with the original libebur128 files[1][2] to see what has changed. Also included is `queue.h' which comes from BSD, which AFAIK should be distributable if we decide to go this route. All these files still need their license header, as libebur128 is MIT licensed and needs its own copyright message. One other thing to take a look at is the section with the sse2 optimizations - does FFmpeg already have a macro we could use for this? 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch This patch removes the libebur128 dependency for the loudnorm and uses the new internal ebur128 API. 0003-avfilter-af_astats-add-ebur128-stats.patch This patch adds ebur128 stats to the astats filter. Because of the extra computation required to calculate ebur128 stats, I decided that these modes should be explicitly specified via a few new filter parameters. From my perspective, it makes more sense for this to live in the astats filter instead of a completely separate filter (f_ebur128). I'd vote for removing the current ebur128 filter, but if we wanted to keep it it should be ported to use the new ebur128 code. Thanks, Kyle [1] https://raw.githubusercontent.com/jiixyj/libebur128/master/ebur128/ebur128.h [2] https://raw.githubusercontent.com/jiixyj/libebur128/master/ebur128/ebur128.c 0001-avfilter-add-libebur128-port.patch Description: Binary data 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch Description: Binary data 0003-avfilter-af_astats-add-ebur128-stats.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sun, Jun 12, 2016 at 8:07 PM, Rostislav Pehlivanov wrote: > On 13 June 2016 at 01:57, Michael Niedermayer > wrote: > >> On Sun, Jun 12, 2016 at 04:14:56PM -0500, Kyle Swanson wrote: >> > Hi all, >> > >> > Here's three patches. These are still WIP and not ready to be pushed. >> > >> > 0001-avfilter-add-libebur128-port.patch >> > This first patch ports libebur128 to ffmpeg. I haven't re-indented >> > these yet, so please diff `ebur128.c' and `ebur128.h' with the >> > original libebur128 files[1][2] to see what has changed. Also included >> > is `queue.h' which comes from BSD, which AFAIK should be distributable >> > if we decide to go this route. All these files still need their >> > license header, as libebur128 is MIT licensed and needs its own >> > copyright message. One other thing to take a look at is the section >> > with the sse2 optimizations - does FFmpeg already have a macro we >> > could use for this? >> > >> > >> > 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch >> > This patch removes the libebur128 dependency for the loudnorm and uses >> > the new internal ebur128 API. >> > >> > >> > 0003-avfilter-af_astats-add-ebur128-stats.patch >> > This patch adds ebur128 stats to the astats filter. Because of the >> > extra computation required to calculate ebur128 stats, I decided that >> > these modes should be explicitly specified via a few new filter >> > parameters. From my perspective, it makes more sense for this to live >> > in the astats filter instead of a completely separate filter >> > (f_ebur128). I'd vote for removing the current ebur128 filter, but if >> > we wanted to keep it it should be ported to use the new ebur128 code. >> > >> > Thanks, >> > Kyle >> > >> > [1] >> https://raw.githubusercontent.com/jiixyj/libebur128/master/ebur128/ebur128.h >> > [2] >> https://raw.githubusercontent.com/jiixyj/libebur128/master/ebur128/ebur128.c >> >> something needs to be updated to make fate-source pass: >> >> --- ./tests/ref/fate/source 2016-06-12 20:29:44.811132775 +0200 >> +++ tests/data/fate/source 2016-06-13 02:30:48.715589174 +0200 >> @@ -7,7 +7,10 @@ >> libavcodec/log2_tab.c >> libavcodec/reverse.c >> libavdevice/file_open.c >> +libavfilter/ebur128.c >> +libavfilter/ebur128.h >> libavfilter/log2_tab.c >> +libavfilter/queue.h >> libavformat/file_open.c >> libavformat/golomb_tab.c >> libavformat/log2_tab.c >> @@ -26,3 +29,5 @@ >> compat/avisynth/windowsPorts/windows2linux.h >> compat/float/float.h >> compat/float/limits.h >> +libavfilter/ebur128.h >> +libavfilter/queue.h >> Test source failed. Look at tests/data/fate/source.err for details. >> >> [...] >> >> >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> Complexity theory is the science of finding the exact solution to an >> approximation. Benchmarking OTOH is finding an approximation of the exact >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> >>something needs to be updated to make fate-source pass: > > It won't have to be once what I said in my first reply is done - just > append libebur128's license with a note. Yep, this appears to be related to the license header. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sun, Jun 12, 2016 at 4:32 PM, Rostislav Pehlivanov wrote: > On 12 June 2016 at 22:14, Kyle Swanson wrote: > >> Hi all, >> >> Here's three patches. These are still WIP and not ready to be pushed. >> >> 0001-avfilter-add-libebur128-port.patch >> This first patch ports libebur128 to ffmpeg. I haven't re-indented >> these yet, so please diff `ebur128.c' and `ebur128.h' with the >> original libebur128 files[1][2] to see what has changed. Also included >> is `queue.h' which comes from BSD, which AFAIK should be distributable >> if we decide to go this route. All these files still need their >> license header, as libebur128 is MIT licensed and needs its own >> copyright message. One other thing to take a look at is the section >> with the sse2 optimizations - does FFmpeg already have a macro we >> could use for this? >> >> >> 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch >> This patch removes the libebur128 dependency for the loudnorm and uses >> the new internal ebur128 API. >> >> >> 0003-avfilter-af_astats-add-ebur128-stats.patch >> This patch adds ebur128 stats to the astats filter. Because of the >> extra computation required to calculate ebur128 stats, I decided that >> these modes should be explicitly specified via a few new filter >> parameters. From my perspective, it makes more sense for this to live >> in the astats filter instead of a completely separate filter >> (f_ebur128). I'd vote for removing the current ebur128 filter, but if >> we wanted to keep it it should be ported to use the new ebur128 code. >> >> Thanks, >> Kyle >> >> [1] >> https://raw.githubusercontent.com/jiixyj/libebur128/master/ebur128/ebur128.h >> [2] >> https://raw.githubusercontent.com/jiixyj/libebur128/master/ebur128/ebur128.c >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> > Hi, > >>+#include > Intrinsics aren't allowed in the codebase. Looking at the patch it's only > used in a single place and I can't see how it would improve the > performance, so it should be safe to remove it. That's what I figured. I'll remove this part. > >>+#if CONFIG_SWRESAMPLE > What would happen if CONFIG_SWRESAMPLE wasn't enabled? > Good point, the only exported function that needs this is `ff_ebur128_true_peak'. Calls to this function should also include an `#if CONFIG_SWRESAMPLE.' I'll fix this for the next patch. >>+/* Those will be calculated when initializing the library */ >+static > double relative_gate_factor; >+static double minus_twenty_decibels; >>+static double histogram_energies[1000]; >+static double > histogram_energy_boundaries[1001]; > > Do you think it would be easy to put those inside the context? > Also you should probably define the big double arrays using DECLARE_ALIGNED. I'll take a look at this. > >>libebur128 is MIT licensed and needs its own copyright message > Had this discussion half a year ago, the correct thing to do in this case > is to use FFmpeg's license at the top, put a message saying "This file uses > code from 's codebase which has the following license", and > then paste libebur128's license beneath indented one level. > > So far apart from those things it looks good, will have time to look at > this a bit better later this week. > > Thanks > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] tools: update normalize script example to use loudnorm
Signed-off-by: Kyle Swanson
---
tools/normalize.py | 33 --
tools/normalize.rb | 60 ++
2 files changed, 60 insertions(+), 33 deletions(-)
delete mode 100755 tools/normalize.py
create mode 100644 tools/normalize.rb
diff --git a/tools/normalize.py b/tools/normalize.py
deleted file mode 100755
index 7d87c5e..000
--- a/tools/normalize.py
+++ /dev/null
@@ -1,33 +0,0 @@
-#!/usr/bin/env python2
-
-import sys, subprocess
-
-if len(sys.argv) > 2:
-ifile = sys.argv[1]
-encopt = sys.argv[2:-1]
-ofile = sys.argv[-1]
-else:
-print 'usage: %s [encode_options] ' % sys.argv[0]
-sys.exit(1)
-
-analysis_cmd = 'ffprobe -v error -of compact=p=0:nk=1 '
-analysis_cmd += '-show_entries frame_tags=lavfi.r128.I -f lavfi '
-analysis_cmd += "amovie='%s',ebur128=metadata=1" % ifile
-try:
-probe_out = subprocess.check_output(analysis_cmd, shell=True)
-except subprocess.CalledProcessError, e:
-sys.exit(e.returncode)
-loudness = ref = -23
-for line in probe_out.splitlines():
-sline = line.rstrip()
-if sline:
-loudness = sline
-adjust = ref - float(loudness)
-if abs(adjust) < 0.0001:
-print 'No normalization needed for ' + ifile
-else:
-print "Adjust %s by %.1fdB" % (ifile, adjust)
-norm_cmd = ['ffmpeg', '-i', ifile, '-af', 'volume=%fdB' % adjust]
-norm_cmd += encopt + [ofile]
-print ' => %s' % ' '.join(norm_cmd)
-subprocess.call(norm_cmd)
diff --git a/tools/normalize.rb b/tools/normalize.rb
new file mode 100644
index 000..53ea058
--- /dev/null
+++ b/tools/normalize.rb
@@ -0,0 +1,60 @@
+#!/usr/bin/env ruby
+
+require 'open3'
+require 'json'
+
+ffmpeg_bin = '/usr/local/bin/ffmpeg'
+target_il = -24.0
+target_lra = +11.0
+target_tp = -2.0
+samplerate = '48k'
+
+if ARGF.argv.count != 2
+ puts "Usage: #{$PROGRAM_NAME} input.wav output.wav"
+ exit 1
+end
+
+ff_string = "#{ffmpeg_bin} -hide_banner "
+ff_string += "-i #{ARGF.argv[0]} "
+ff_string += '-af loudnorm='
+ff_string += "I=#{target_il}:"
+ff_string += "LRA=#{target_lra}:"
+ff_string += "tp=#{target_tp}:"
+ff_string += 'print_format=json '
+ff_string += '-f null -'
+
+_stdin, _stdout, stderr, wait_thr = Open3.popen3(ff_string)
+
+if wait_thr.value.success?
+ stats = JSON.parse(stderr.read.lines[-12, 12].join)
+ loudnorm_string = '-af loudnorm='
+ loudnorm_string += 'print_format=summary:'
+ loudnorm_string += 'linear=true:'
+ loudnorm_string += "I=#{target_il}:"
+ loudnorm_string += "LRA=#{target_lra}:"
+ loudnorm_string += "tp=#{target_tp}:"
+ loudnorm_string += "measured_I=#{stats['input_i']}:"
+ loudnorm_string += "measured_LRA=#{stats['input_lra']}:"
+ loudnorm_string += "measured_tp=#{stats['input_tp']}:"
+ loudnorm_string += "measured_thresh=#{stats['input_thresh']}:"
+ loudnorm_string += "offset=#{stats['target_offset']}"
+else
+ puts stderr.read
+ exit 1
+end
+
+ff_string = "#{ffmpeg_bin} -y -hide_banner "
+ff_string += "-i #{ARGF.argv[0]} "
+ff_string += "#{loudnorm_string} "
+ff_string += "-ar #{samplerate} "
+ff_string += ARGF.argv[1].to_s
+
+_stdin, _stdout, stderr, wait_thr = Open3.popen3(ff_string)
+
+if wait_thr.value.success?
+ puts stderr.read.lines[-12, 12].join
+ exit 0
+else
+ puts stderr.read
+ exit 1
+end
--
2.5.4 (Apple Git-61)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tools: update normalize script example to use loudnorm
On Mon, Jun 13, 2016 at 3:23 AM, Clément Bœsch wrote: > On Sun, Jun 12, 2016 at 10:44:15PM -0500, Kyle Swanson wrote: >> Signed-off-by: Kyle Swanson >> --- >> tools/normalize.py | 33 -- >> tools/normalize.rb | 60 >> ++ >> 2 files changed, 60 insertions(+), 33 deletions(-) >> delete mode 100755 tools/normalize.py >> create mode 100644 tools/normalize.rb >> > > Please de not delete normalize.py We have a filter that does this now, if we're distributing a loudness normalization script it should be using the loudnorm filter. > > Regards, > > -- > Clément B. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: > > 0001-avfilter-add-libebur128-port.patch > This first patch ports libebur128 to ffmpeg. I haven't re-indented > these yet, so please diff `ebur128.c' and `ebur128.h' with the > original libebur128 files[1][2] to see what has changed. Also included > is `queue.h' which comes from BSD, which AFAIK should be distributable > if we decide to go this route. All these files still need their > license header, as libebur128 is MIT licensed and needs its own > copyright message. One other thing to take a look at is the section > with the sse2 optimizations - does FFmpeg already have a macro we > could use for this? > > > 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch > This patch removes the libebur128 dependency for the loudnorm and uses > the new internal ebur128 API. > Hi, Two updated patches attached. This is the libebur128 port and the af_loudnorm update. Please review if you can, as I'd like to try push these before v3.1. Updates to af_astats and f_ebur128 to use this new API will be coming in the near future as well. Thanks! Kyle 0001-avfilter-add-libebur128-port.patch Description: Binary data 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 3:49 AM, Hendrik Leppkes wrote: > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes wrote: >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: >>>> >>>> 0001-avfilter-add-libebur128-port.patch >>>> This first patch ports libebur128 to ffmpeg. I haven't re-indented >>>> these yet, so please diff `ebur128.c' and `ebur128.h' with the >>>> original libebur128 files[1][2] to see what has changed. Also included >>>> is `queue.h' which comes from BSD, which AFAIK should be distributable >>>> if we decide to go this route. All these files still need their >>>> license header, as libebur128 is MIT licensed and needs its own >>>> copyright message. One other thing to take a look at is the section >>>> with the sse2 optimizations - does FFmpeg already have a macro we >>>> could use for this? >>>> >>>> >>>> 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch >>>> This patch removes the libebur128 dependency for the loudnorm and uses >>>> the new internal ebur128 API. >>>> >>> >>> Hi, >>> >>> Two updated patches attached. This is the libebur128 port and the >>> af_loudnorm update. Please review if you can, as I'd like to try push >>> these before v3.1. Updates to af_astats and f_ebur128 to use this new >>> API will be coming in the near future as well. >>> >> >> The libebur128 port still contains global state (ie. static data >> initialized at runtime), as commented on in the earlier reviews can >> you get rid of those and move them into a library context (ie. not >> static globals)? >> We really don't like global state like this because of thread safety issues. >> > > Also, in general I must say I really don't like the idea or the > precedence this sets of porting complex external libraries into the > avfilter code. > Whats wrong with simply linking the library when you want to use it? > This is how it works for everything else, what makes this different to > warrant such a step? Hi, af_loudnorm currently links libebur128. The port makes sense because libebur128 is tiny, MIT-licensed, has a good API, and would be useful in several filters. Perceptual loudness has become an important topic in broadcasting and audio in general, and it'd be nice to provide these filters to everybody without having to link an external library. FFmpeg already has some ebur128 logic in f_ebur128, which I was initially interested in breaking out into something reusable, but found libebur128 was better suited for this. This was discussed last month when the loudnorm filter was pushed, and also with the expectation that libebur128 would be ported to FFmpeg. Briefly, libebur128 allows several modes of measurement, custom channel mappings, doesn't require resampling the input stream, is faster, and has a reusable API. Thanks, Kyle > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 6:00 AM, Clément Bœsch wrote: > On Sat, Jun 18, 2016 at 12:58:59PM +0200, Paul B Mahol wrote: >> On 6/18/16, Clement Boesch wrote: >> > On Sat, Jun 18, 2016 at 12:34:10PM +0200, Paul B Mahol wrote: >> >> On 6/18/16, Hendrik Leppkes wrote: >> >> > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes >> >> > wrote: >> >> >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: >> >> >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: >> >> >>>> >> >> >>>> 0001-avfilter-add-libebur128-port.patch >> >> >>>> This first patch ports libebur128 to ffmpeg. I haven't re-indented >> >> >>>> these yet, so please diff `ebur128.c' and `ebur128.h' with the >> >> >>>> original libebur128 files[1][2] to see what has changed. Also >> >> >>>> included >> >> >>>> is `queue.h' which comes from BSD, which AFAIK should be >> >> >>>> distributable >> >> >>>> if we decide to go this route. All these files still need their >> >> >>>> license header, as libebur128 is MIT licensed and needs its own >> >> >>>> copyright message. One other thing to take a look at is the section >> >> >>>> with the sse2 optimizations - does FFmpeg already have a macro we >> >> >>>> could use for this? >> >> >>>> >> >> >>>> >> >> >>>> 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch >> >> >>>> This patch removes the libebur128 dependency for the loudnorm and >> >> >>>> uses >> >> >>>> the new internal ebur128 API. >> >> >>>> >> >> >>> >> >> >>> Hi, >> >> >>> >> >> >>> Two updated patches attached. This is the libebur128 port and the >> >> >>> af_loudnorm update. Please review if you can, as I'd like to try push >> >> >>> these before v3.1. Updates to af_astats and f_ebur128 to use this >> >> >>> new >> >> >>> API will be coming in the near future as well. >> >> >>> >> >> >> >> >> >> The libebur128 port still contains global state (ie. static data >> >> >> initialized at runtime), as commented on in the earlier reviews can >> >> >> you get rid of those and move them into a library context (ie. not >> >> >> static globals)? >> >> >> We really don't like global state like this because of thread safety >> >> >> issues. >> >> >> >> >> > >> >> > Also, in general I must say I really don't like the idea or the >> >> > precedence this sets of porting complex external libraries into the >> >> > avfilter code. >> >> > Whats wrong with simply linking the library when you want to use it? >> >> > This is how it works for everything else, what makes this different to >> >> > warrant such a step? >> >> >> >> Because f_ebur128 is GPL and unlikely to get relicensed. >> > >> > 11:50 <@ubitux> nowadays i care much less about f_ebur128 being gpl or not >> >> But you are blocking other ebur128 implementation to be used in f_ebur128.c > > Yes but not because of licence issues. > Clément, you do great work here and I've used f_ebur128 for years. Understand, I'm just trying to make improvements. > -- > Clément B. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.1 name
On Thu, Jun 23, 2016 at 4:00 PM, Michael Niedermayer wrote: > Hi all > > what shall FFmpeg 3.1 be called ? > > I still have these ideas from past suggestions: > Von Neumann, Einstein, lorentz, poincaré, desitter, de broglie, Gauss, > Galois, Viterbi, Darwin > > Are there other suggestions? > Is something preferred ? > > In absence of any preferrance ill pick something randomly > > Thanks > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No great genius has ever existed without some touch of madness. -- Aristotle > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Should probably be a mathematician since 3.1 is just about pi. There's also been no FFmpeg version named after a woman. My suggestion is `Hypatia.`[1] [1] https://en.wikipedia.org/wiki/Hypatia Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sun, Jun 19, 2016 at 2:17 AM, Kyle Swanson wrote: > Hi, > > af_loudnorm currently links libebur128. The port makes sense because > libebur128 is tiny, MIT-licensed, has a good API, and would be useful > in several filters. Perceptual loudness has become an important topic > in broadcasting and audio in general, and it'd be nice to provide > these filters to everybody without having to link an external library. > > FFmpeg already has some ebur128 logic in f_ebur128, which I was > initially interested in breaking out into something reusable, but > found libebur128 was better suited for this. This was discussed last > month when the loudnorm filter was pushed, and also with the > expectation that libebur128 would be ported to FFmpeg. Briefly, > libebur128 allows several modes of measurement, custom channel > mappings, doesn't require resampling the input stream, is faster, and > has a reusable API. > > Thanks, > Kyle > Hi, I'm still not clear if I should pursue this or not, I've received `yes` and `no` from both sides on this issue. Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/af_ebur128: update filter to use new ebur128 API
On Mon, Nov 28, 2016 at 10:59 PM, Marton Balint wrote:
>
> On Mon, 28 Nov 2016, Kyle Swanson wrote:
>
> On Thu, Nov 17, 2016 at 11:04 AM, Kyle Swanson wrote:
>>
>>> Hi,
>>>
>>> Here's a couple of patches which update the ebur128 filter to use the
>>> recently added ebur128 API. This updated filter allows fine-tuned
>>> control over which EBU R128 parameters are measured, and provides
>>> modest speed increases over the previous ebur128 filter. Also
>>> noteworthy: this removes the video output option of the ebur128
>>> filter. This is extraneous for an ebur128 measurement filter IMHO, but
>>> if we wanted to keep similar functionality in FFmpeg, we'd be better
>>> served by a new video source filter where custom meters could be
>>> created via exported frame metadata.
>>>
>>> The first patch adds true peak functionality to the ebur128 API using
>>> swresample (this was already discussed a little bit:
>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202583.html)
>>> The second patch is an update to the ebur128 filter.
>>>
>>> Kyle
>>>
>>
>> Does anyone have any problems with the first patch?
>>
>
> From 6912ed3a03cd19f46e96f1f4b9eb3aa69b7ce4df Mon Sep 17 00:00:00 2001
>> From: Kyle Swanson
>> Date: Thu, 17 Nov 2016 10:32:45 -0600
>> Subject: [PATCH 1/2] lavfi/ebur128: add ebur128_check_true_peak()
>>
>> Signed-off-by: Kyle Swanson
>> ---
>> libavfilter/ebur128.c | 162 ++
>> +++-
>> libavfilter/ebur128.h | 17 ++
>> 2 files changed, 177 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavfilter/ebur128.c b/libavfilter/ebur128.c
>> index a46692e..dc16647 100644
>> --- a/libavfilter/ebur128.c
>> +++ b/libavfilter/ebur128.c
>> @@ -50,6 +50,9 @@
>> #include "libavutil/common.h"
>> #include "libavutil/mem.h"
>> #include "libavutil/thread.h"
>> +#include "libavutil/channel_layout.h"
>> +#include "libswresample/swresample.h"
>>
>
> Isn't this include needs an ifdef as well?
>
> +#include "libavutil/opt.h"
>>
>> #define CHECK_ERROR(condition, errorcode, goto_point)
>> \
>> if ((condition)) {
>>\
>> @@ -91,6 +94,16 @@ struct FFEBUR128StateInternal {
>> size_t short_term_frame_counter;
>> /** Maximum sample peak, one per channel */
>> double *sample_peak;
>> +/** Maximum true peak, one per channel */
>> +double* true_peak;
>> +#if CONFIG_SWRESAMPLE
>> +SwrContext *resampler;
>> +size_t oversample_factor;
>> +float* resampler_buffer_input;
>> +size_t resampler_buffer_input_frames;
>> +float* resampler_buffer_output;
>> +size_t resampler_buffer_output_frames;
>> +#endif
>> /** The maximum window duration in ms. */
>> unsigned long window;
>> /** Data pointer array for interleaved data */
>> @@ -214,12 +227,78 @@ static inline void init_histogram(void)
>> }
>> }
>>
>> +#if CONFIG_SWRESAMPLE
>> +static int ebur128_init_resampler(FFEBUR128State* st) {
>> +int64_t channel_layout;
>> +int errcode;
>> +
>> +if (st->samplerate < 96000) {
>> +st->d->oversample_factor = 4;
>> +} else if (st->samplerate < 192000) {
>> +st->d->oversample_factor = 2;
>> +} else {
>> +st->d->oversample_factor = 1;
>> +st->d->resampler_buffer_input = NULL;
>> +st->d->resampler_buffer_output = NULL;
>> +st->d->resampler = NULL;
>> +}
>> +
>> +st->d->resampler_buffer_input_frames = st->d->samples_in_100ms * 4;
>> +st->d->resampler_buffer_input =
>> av_malloc(st->d->resampler_buffer_input_frames
>> *
>> + st->channels *
>> + sizeof(float));
>>
>
> av_malloc_array
>
> +CHECK_ERROR(!st->d->resampler_buffer_input, 0, exit)
>> +
>> +st->d->resampler_buffer_output_frames =
>> +st->d->resampler_buffer_input_frames *
>> +st->d->oversample_factor;
>> +st->d->resampler_buffer_output =
>> av_malloc(st->d->resampler_buffer_output_frames
>> *
>> + st->channels *
>> +
Re: [FFmpeg-devel] [PATCH] lavfi/af_ebur128: update filter to use new ebur128 API
On Wed, Dec 28, 2016 at 9:51 AM, Kyle Swanson wrote:
> On Mon, Nov 28, 2016 at 10:59 PM, Marton Balint wrote:
>
>>
>> On Mon, 28 Nov 2016, Kyle Swanson wrote:
>>
>> On Thu, Nov 17, 2016 at 11:04 AM, Kyle Swanson wrote:
>>>
>>>> Hi,
>>>>
>>>> Here's a couple of patches which update the ebur128 filter to use the
>>>> recently added ebur128 API. This updated filter allows fine-tuned
>>>> control over which EBU R128 parameters are measured, and provides
>>>> modest speed increases over the previous ebur128 filter. Also
>>>> noteworthy: this removes the video output option of the ebur128
>>>> filter. This is extraneous for an ebur128 measurement filter IMHO, but
>>>> if we wanted to keep similar functionality in FFmpeg, we'd be better
>>>> served by a new video source filter where custom meters could be
>>>> created via exported frame metadata.
>>>>
>>>> The first patch adds true peak functionality to the ebur128 API using
>>>> swresample (this was already discussed a little bit:
>>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202583.html)
>>>> The second patch is an update to the ebur128 filter.
>>>>
>>>> Kyle
>>>>
>>>
>>> Does anyone have any problems with the first patch?
>>>
>>
>> From 6912ed3a03cd19f46e96f1f4b9eb3aa69b7ce4df Mon Sep 17 00:00:00 2001
>>> From: Kyle Swanson
>>> Date: Thu, 17 Nov 2016 10:32:45 -0600
>>> Subject: [PATCH 1/2] lavfi/ebur128: add ebur128_check_true_peak()
>>>
>>> Signed-off-by: Kyle Swanson
>>> ---
>>> libavfilter/ebur128.c | 162 ++
>>> +++-
>>> libavfilter/ebur128.h | 17 ++
>>> 2 files changed, 177 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavfilter/ebur128.c b/libavfilter/ebur128.c
>>> index a46692e..dc16647 100644
>>> --- a/libavfilter/ebur128.c
>>> +++ b/libavfilter/ebur128.c
>>> @@ -50,6 +50,9 @@
>>> #include "libavutil/common.h"
>>> #include "libavutil/mem.h"
>>> #include "libavutil/thread.h"
>>> +#include "libavutil/channel_layout.h"
>>> +#include "libswresample/swresample.h"
>>>
>>
>> Isn't this include needs an ifdef as well?
>>
>> +#include "libavutil/opt.h"
>>>
>>> #define CHECK_ERROR(condition, errorcode, goto_point)
>>> \
>>> if ((condition)) {
>>>\
>>> @@ -91,6 +94,16 @@ struct FFEBUR128StateInternal {
>>> size_t short_term_frame_counter;
>>> /** Maximum sample peak, one per channel */
>>> double *sample_peak;
>>> +/** Maximum true peak, one per channel */
>>> +double* true_peak;
>>> +#if CONFIG_SWRESAMPLE
>>> +SwrContext *resampler;
>>> +size_t oversample_factor;
>>> +float* resampler_buffer_input;
>>> +size_t resampler_buffer_input_frames;
>>> +float* resampler_buffer_output;
>>> +size_t resampler_buffer_output_frames;
>>> +#endif
>>> /** The maximum window duration in ms. */
>>> unsigned long window;
>>> /** Data pointer array for interleaved data */
>>> @@ -214,12 +227,78 @@ static inline void init_histogram(void)
>>> }
>>> }
>>>
>>> +#if CONFIG_SWRESAMPLE
>>> +static int ebur128_init_resampler(FFEBUR128State* st) {
>>> +int64_t channel_layout;
>>> +int errcode;
>>> +
>>> +if (st->samplerate < 96000) {
>>> +st->d->oversample_factor = 4;
>>> +} else if (st->samplerate < 192000) {
>>> +st->d->oversample_factor = 2;
>>> +} else {
>>> +st->d->oversample_factor = 1;
>>> +st->d->resampler_buffer_input = NULL;
>>> +st->d->resampler_buffer_output = NULL;
>>> +st->d->resampler = NULL;
>>> +}
>>> +
>>> +st->d->resampler_buffer_input_frames = st->d->samples_in_100ms * 4;
>>> +st->d->resampler_buffer_input =
>>> av_malloc(st->d->resampler_buffer_input_frames
>>> *
>>> + st->channels *
>>> + sizeof(float));
>>>
>>
>>
[FFmpeg-devel] [PATCH] avcodec/g722enc: force mono channel layout
Signed-off-by: Kyle Swanson
---
libavcodec/g722enc.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/libavcodec/g722enc.c b/libavcodec/g722enc.c
index 01a3db26fd..473646f45c 100644
--- a/libavcodec/g722enc.c
+++ b/libavcodec/g722enc.c
@@ -61,11 +61,6 @@ static av_cold int g722_encode_init(AVCodecContext * avctx)
G722Context *c = avctx->priv_data;
int ret;
-if (avctx->channels != 1) {
-av_log(avctx, AV_LOG_ERROR, "Only mono tracks are allowed.\n");
-return AVERROR_INVALIDDATA;
-}
-
c->band[0].scale_factor = 8;
c->band[1].scale_factor = 2;
c->prev_samples_pos = 22;
@@ -381,15 +376,15 @@ static int g722_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
}
AVCodec ff_adpcm_g722_encoder = {
-.name = "g722",
-.long_name = NULL_IF_CONFIG_SMALL("G.722 ADPCM"),
-.type = AVMEDIA_TYPE_AUDIO,
-.id = AV_CODEC_ID_ADPCM_G722,
-.priv_data_size = sizeof(G722Context),
-.init = g722_encode_init,
-.close = g722_encode_close,
-.encode2= g722_encode_frame,
-.capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME,
-.sample_fmts= (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16,
- AV_SAMPLE_FMT_NONE },
+.name= "g722",
+.long_name = NULL_IF_CONFIG_SMALL("G.722 ADPCM"),
+.type= AVMEDIA_TYPE_AUDIO,
+.id = AV_CODEC_ID_ADPCM_G722,
+.priv_data_size = sizeof(G722Context),
+.init= g722_encode_init,
+.close = g722_encode_close,
+.encode2 = g722_encode_frame,
+.capabilities= AV_CODEC_CAP_SMALL_LAST_FRAME,
+.sample_fmts = (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16,
AV_SAMPLE_FMT_NONE },
+.channel_layouts = (const uint64_t[]){ AV_CH_LAYOUT_MONO, 0},
};
--
2.12.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/g722enc: force mono channel layout
On Fri, Jun 23, 2017 at 5:46 PM, Paul B Mahol wrote: > On 6/23/17, Kyle Swanson wrote: >> Signed-off-by: Kyle Swanson >> --- >> libavcodec/g722enc.c | 27 +++ >> 1 file changed, 11 insertions(+), 16 deletions(-) >> > > Should be fine iff other than mono is really dissalowed. Spec says mono only. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/g722enc: force mono channel layout
On Fri, Jun 23, 2017 at 5:46 PM, Paul B Mahol wrote: > On 6/23/17, Kyle Swanson wrote: > > Signed-off-by: Kyle Swanson > > --- > > libavcodec/g722enc.c | 27 +++ > > 1 file changed, 11 insertions(+), 16 deletions(-) > > > > Should be fine iff other than mono is really dissalowed. > Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] filters.texi: explain audio upsampling in loudnorm
On Thu, Aug 17, 2017 at 1:27 PM, Lou Logan wrote: > On Wed, 16 Aug 2017 13:33:24 +0200 > Werner Robitza wrote: > >> From 35b49e497cac452c76ead8da4d618ab93216ad15 Mon Sep 17 00:00:00 2001 >> From: Werner Robitza >> Date: Wed, 16 Aug 2017 13:27:19 +0200 >> Subject: [PATCH] filters.texi: explain audio upsampling in loudnorm >> >> Explain that audio will be upsampled to 192 kHz. Addresses issues mentioned >> in >> issue 6570. >> >> Signed-off-by: Werner Robitza >> --- >> doc/filters.texi | 4 >> 1 file changed, 4 insertions(+) > > Pushed. Thanks for the patch. This is a good addition because I've actually had several questions about this. I missed the patch review window, I guess, but upsampling is actually a little more subtle than that now (since f3d8e0d369456113d1223cdf77072b52fc79eceb). No need to revert, I'll update and push another patch with a more complete explanation. Thanks, Kyle > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_libvmaf: Fix memory leak
Hi, On Sun, Mar 25, 2018 at 9:44 AM, enctac wrote: > Fixes ticket #6967 > --- > libavfilter/vf_libvmaf.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c > index dfe474c40c..42c6b66b69 100644 > --- a/libavfilter/vf_libvmaf.c > +++ b/libavfilter/vf_libvmaf.c > @@ -130,6 +130,8 @@ FRAMESYNC_DEFINE_CLASS(libvmaf, LIBVMAFContext, fs); > \ > ret = !s->frame_set; > \ > \ > +av_frame_unref(s->gref); > \ > +av_frame_unref(s->gmain); >\ > s->frame_set = 0; >\ > \ > pthread_cond_signal(&s->cond); > \ > -- > 2.16.2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Tested and pushed. Thanks! Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] Sega FILM: set dts and duration when demuxing
Hi,
On Sun, Apr 8, 2018 at 6:27 PM, wrote:
> From: Misty De Meo
>
> ---
> libavformat/segafilm.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/libavformat/segafilm.c b/libavformat/segafilm.c
> index 4c0cca0140..e72c26b144 100644
> --- a/libavformat/segafilm.c
> +++ b/libavformat/segafilm.c
> @@ -270,6 +270,8 @@ static int film_read_packet(AVFormatContext *s,
> FilmDemuxContext *film = s->priv_data;
> AVIOContext *pb = s->pb;
> film_sample *sample;
> +film_sample *next_sample = NULL;
> +int next_sample_id;
> int ret = 0;
>
> if (film->current_sample >= film->sample_count)
> @@ -277,6 +279,20 @@ static int film_read_packet(AVFormatContext *s,
>
> sample = &film->sample_table[film->current_sample];
>
> +/* Find the next sample from the same stream, assuming there is one;
> + * this is used to calculate the duration below */
> +next_sample_id = film->current_sample + 1;
> +while (next_sample == NULL) {
> +if (next_sample_id >= film->sample_count)
> +break;
> +
> +next_sample = &film->sample_table[next_sample_id];
> +if (next_sample->stream != sample->stream) {
> +next_sample = NULL;
> +next_sample_id++;
> +}
> +}
> +
> /* position the stream (will probably be there anyway) */
> avio_seek(pb, sample->sample_offset, SEEK_SET);
>
> @@ -285,8 +301,11 @@ static int film_read_packet(AVFormatContext *s,
> ret = AVERROR(EIO);
>
> pkt->stream_index = sample->stream;
> +pkt->dts = sample->pts;
> pkt->pts = sample->pts;
> pkt->flags |= sample->keyframe ? AV_PKT_FLAG_KEY : 0;
> +if (next_sample != NULL)
> +pkt->duration = next_sample->pts - sample->pts;
>
> film->current_sample++;
>
> --
> 2.17.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/segafilmenc: Do not mix variable declaration and code.
On Mon, Apr 9, 2018 at 3:50 PM, Carl Eugen Hoyos wrote:
> ffmpeg | branch: master | Carl Eugen Hoyos | Tue Apr
> 10 00:50:01 2018 +0200| [4d1d7263d8ff32e67710b41f24fe485818c87211] |
> committer: Carl Eugen Hoyos
>
> lavf/segafilmenc: Do not mix variable declaration and code.
>
> Fixes two warnings: ISO C90 forbids mixed declarations and code
>
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=
> 4d1d7263d8ff32e67710b41f24fe485818c87211
> ---
>
> libavformat/segafilmenc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
> index 86c0ab0d1c..5b0d7e69e8 100644
> --- a/libavformat/segafilmenc.c
> +++ b/libavformat/segafilmenc.c
> @@ -121,12 +121,12 @@ static int film_write_packet(AVFormatContext
> *format_context, AVPacket *pkt)
> if (encoded_buf_size != pkt->size && (pkt->size %
> encoded_buf_size) != 0) {
> avio_write(pb, pkt->data, pkt->size);
> } else {
> +uint8_t padding[2] = {0, 0};
> /* In Sega Cinepak, the reported size in the Cinepak header is
> * 8 bytes too short. However, the size in the STAB section
> of the header
> * is correct, taking into account the extra two bytes. */
> AV_WB24(&pkt->data[1], pkt->size - 8 + 2);
> metadata->size += 2;
> -uint8_t padding[2] = {0, 0};
>
> avio_write(pb, pkt->data, 10);
> avio_write(pb, padding, 2);
> @@ -158,6 +158,7 @@ static int get_audio_codec_id(enum AVCodecID codec_id)
>
> static int film_init(AVFormatContext *format_context)
> {
> +AVStream *audio = NULL;
> FILMOutputContext *film = format_context->priv_data;
> film->audio_index = -1;
> film->video_index = -1;
> @@ -165,7 +166,6 @@ static int film_init(AVFormatContext *format_context)
> film->packet_count = 0;
> film->start = NULL;
> film->last = NULL;
> -AVStream *audio = NULL;
>
> for (int i = 0; i < format_context->nb_streams; i++) {
> AVStream *st = format_context->streams[i];
>
> ___
> ffmpeg-cvslog mailing list
> ffmpeg-cvs...@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.
Hi,
Can you provide some context for this? Please add docs as well.
Can't really test this because it segfaults for me: ./ffmpeg -f lavfi
-i anoisesrc -af dumpwave -f null -
On Sun, Jan 7, 2018 at 4:36 PM, wrote:
>
> From: Dmytro Humeniuk
>
> Signed-off-by: Dmytro Humeniuk
> ---
> Changelog | 1 +
> libavfilter/Makefile | 1 +
> libavfilter/af_dumpwave.c | 273
> +
> libavfilter/allfilters.c | 1 +
> libavfilter/version.h | 4 +-
> tests/fate/filter-audio.mak| 5 +
> tests/ref/fate/filter-dumpwave | 1 +
> 7 files changed, 284 insertions(+), 2 deletions(-)
> create mode 100644 libavfilter/af_dumpwave.c
> create mode 100644 tests/ref/fate/filter-dumpwave
>
> diff --git a/Changelog b/Changelog
> index 61075b3392..40fd624449 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -38,6 +38,7 @@ version :
> - Removed the ffserver program
> - Removed the ffmenc and ffmdec muxer and demuxer
> - VideoToolbox HEVC encoder and hwaccel
> +- dumpwave audio filter
>
>
> version 3.4:
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 256dfabd66..020d90ee01 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -122,6 +122,7 @@ OBJS-$(CONFIG_TREMOLO_FILTER)+=
> af_tremolo.o
> OBJS-$(CONFIG_VIBRATO_FILTER)+= af_vibrato.o
> generate_wave_table.o
> OBJS-$(CONFIG_VOLUME_FILTER) += af_volume.o
> OBJS-$(CONFIG_VOLUMEDETECT_FILTER) += af_volumedetect.o
> +OBJS-$(CONFIG_DUMPWAVE_FILTER) += af_dumpwave.o
>
> OBJS-$(CONFIG_AEVALSRC_FILTER) += aeval.o
> OBJS-$(CONFIG_ANOISESRC_FILTER) += asrc_anoisesrc.o
> diff --git a/libavfilter/af_dumpwave.c b/libavfilter/af_dumpwave.c
> new file mode 100644
> index 00..493b5b7ff2
> --- /dev/null
> +++ b/libavfilter/af_dumpwave.c
> @@ -0,0 +1,273 @@
> +/*
> + * Copyright (c) 2017 Dmytro Humeniuk
> + *
> + * 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 the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +/**
> + * @file
> + * waveform audio filter – dumps RMS amplitude to JSON file like SoundCloud
> does
> + */
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/avstring.h"
> +#include "libavutil/channel_layout.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/parseutils.h"
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "audio.h"
> +#include "internal.h"
> +
> +typedef struct DumpWaveContext {
> +const AVClass *class;
> +int w, h;
> +AVRational rate;
> +int col;
> +char *json;
> +char *str;
> +double *values;
> +int64_t c, n, max_samples;
> +double sum; /* sum of the squared samples per segment */
> +} DumpWaveContext;
> +
> +#define OFFSET(x) offsetof(DumpWaveContext, x)
> +#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
> +
> +static const AVOption dumpwave_options[] = {
> +{ "s","set dump size", OFFSET(w), AV_OPT_TYPE_IMAGE_SIZE, {.str =
> "600x240"}, 0, 0, FLAGS },
> +{ "c", "set number of samples per item", OFFSET(c), AV_OPT_TYPE_INT64,
> {.i64 = 0}, 0, INT64_MAX, FLAGS },
Use more descriptive parameter names. Also, per item? What is an item?
> +{ "json", "set dump file", OFFSET(json), AV_OPT_TYPE_STRING, { .str =
> NULL }, 0, 0, FLAGS },
> +{ NULL }
> +};
> +
> +AVFILTER_DEFINE_CLASS(dumpwave);
> +
> +static int config_output(AVFilterLink *outlink)
> +{
> +DumpWaveContext *dumpwave = outlink->src->priv;
> +const int ch_width = dumpwave->w;
> +dumpwave->values = av_malloc(ch_width * sizeof(double));
> +dumpwave->str = av_malloc(ch_width*sizeof(int));
> +dumpwave->max_samples = dumpwave->c * outlink->channels;
> +
> +return 0;
> +}
> +
> +static av_cold void uninit(AVFilterContext *ctx)
> +{
> +DumpWaveContext *dumpwave = ctx->priv;
> +const int ch_height = dumpwave->h;
> +const int ch_width = dumpwave->w;
> +char *result = dumpwave->str;
> +FILE *dump_fp = NULL;
> +
> +if (dumpwave->json && !(dump_fp = av_fopen_utf8(dumpwave->json, "w")))
> +av_log(ctx, AV_LOG_WARNING, "dump failed.\n");
> +
> +if (dump_fp) {
> +fprintf(dump_fp, "{\"width\":%d,\"height\":%d,\"s
Re: [FFmpeg-devel] [PATCH] add dumpwave filter
Hi, On Tue, Jan 9, 2018 at 3:49 PM, wrote: > From: Dmytro Humeniuk > > Signed-off-by: Dmytro Humeniuk > --- > Changelog | 1 + > doc/filters.texi | 23 > libavfilter/Makefile | 1 + > libavfilter/af_dumpwave.c | 285 + > libavfilter/allfilters.c | 1 + > libavfilter/version.h | 4 +- > tests/fate/filter-audio.mak| 5 + > tests/ref/fate/filter-dumpwave | 1 + > 8 files changed, 319 insertions(+), 2 deletions(-) > create mode 100644 libavfilter/af_dumpwave.c > create mode 100644 tests/ref/fate/filter-dumpwave I could see this possibly being a useful filter, but I'm confused about where the JSON schema came from. The two JS libraries that do this type of thing (waveform.js, and wavesurer.js) both just load waveform data as an array of floats. If we're going to add something like this to libavfilter it should be as generic and extensible as possible. I'm not wild about the string stuff, and the big sample format switch isn't necessary. I could do a code review, but it might just be faster if I rewrite it and send another patch. Is that OK with you? Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add dumpwave filter
Hi,
For this to be a part of libavfilter the output needs to be more generic
than the just the Soundcloud format. If we want this to be generally useful
it should probably just output an array of floats between 0.0 and 1.0. The
consumer of this data (JS library, or whatever) can use this in whatever
way it wants. If you send another patch, just reply to this thread because
that makes it easier to follow (sending a patch as an attachment is OK).
Here are some critiques:
+typedef struct DumpWaveContext {
> +const AVClass *class; /**< class for AVOptions */
> +int w; /**< number of data values in json */
> +int h; /**< values will be scaled according to
> provided */
> +int is_disabled;/**< disable filter in case it's
> misconfigured */
> +int i; /**< index of value */
> +char *json; /**< path to json */
> +char *str; /**< comma separated values */, wha
> +double *values; /**< scaling factors */
> +int64_t s; /**< samples per value per channel */
> +int64_t n; /**< current number of samples counted */
> +int64_t max_samples;/**< samples per value */
> +double sum; /**< sum of the squared samples per value */
> +} DumpWaveContext;
Use more descriptive variable names for your struct members. They don't
have to be just one letter.
> +{ "d", "set width and height", OFFSET(w), AV_OPT_TYPE_IMAGE_SIZE,
> {.str = "640x480"}, 0, 0, FLAGS },
Get rid of this. We shouldn't care how this data is used/rendered. Our only
job should be to output an array of floats.
> +{ "s", "set number of samples per value per channel", OFFSET(s),
> AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX, FLAGS },
Maybe you can call this frame_size? 0 is not a useful value here, it
shouldn't be the lower bound or the default value.
> +static av_cold int init(AVFilterContext *ctx)
> +{
> +DumpWaveContext *dumpwave = ctx->priv;
> +if(!dumpwave->s) {
The filter should just fail if it's not configured correctly. You'll get
this behavior for free with better default values.
> +static int config_output(AVFilterLink *outlink)
> +{
> +AVFilterContext *ctx = outlink->src;
> +DumpWaveContext *dumpwave = ctx->priv;
> +const int width = dumpwave->w;
> +dumpwave->values = av_realloc(NULL, width * sizeof(double));
> +dumpwave->str = av_realloc(NULL, width * sizeof(int));
You don't need a giant buffer to hold the entire string. Just keep a file
open a write to it every frame. Maybe we could just write if to stdout
instead?
> +
> +/**
> + * Converts sample to dB and calculates root mean squared value
> + */
> +static inline void dbRms(DumpWaveContext *dumpwave, double smpl)
>
Just call this RMS and spit something out between 0.0 and 1.0. Avoid
camelcase for function names.
>
> +switch (inlink->format) {
> +case AV_SAMPLE_FMT_DBLP:
> +for (c = 0; c < channels; c++) {
> +const double *src = (const double *)buf->extended_data[c];
> +
> +for (i = 0; i < buf->nb_samples; i++, src++)
> +dbRms(dumpwave, *src);
> +}
> +break;
> +case AV_SAMPLE_FMT_DBL: {
> +const double *src = (const double *)buf->extended_data[0];
> +
> +for (i = 0; i < buf->nb_samples; i++) {
> +for (c = 0; c < channels; c++, src++)
> +dbRms(dumpwave, *src);
> +}}
> +break;
> +case AV_SAMPLE_FMT_FLTP:
> +for (c = 0; c < channels; c++) {
> +const float *src = (const float *)buf->extended_data[c];
> +
> +for (i = 0; i < buf->nb_samples; i++, src++)
> +dbRms(dumpwave, *src);
> +}
> +break;
> +case AV_SAMPLE_FMT_FLT: {
> +const float *src = (const float *)buf->extended_data[0];
> +
> +for (i = 0; i < buf->nb_samples; i++) {
> +for (c = 0; c < channels; c++, src++)
> +dbRms(dumpwave, *src);
> +}}
> +break;
> +case AV_SAMPLE_FMT_S64P:
> +for (c = 0; c < channels; c++) {
> +const int64_t *src = (const int64_t
> *)buf->extended_data[c];
> +
> +for (i = 0; i < buf->nb_samples; i++, src++)
> +dbRms(dumpwave, *src / (double)INT64_MAX);
> +}
> +break;
> +case AV_SAMPLE_FMT_S64: {
> +const int64_t *src = (const int64_t *)buf->extended_data[0];
> +
> +for (i = 0; i < buf->nb_samples; i++) {
> +for (c = 0; c < channels; c++, src++)
> +dbRms(dumpwave, *src / (double)INT64_MAX);
> +}}
> +break;
> +case AV_SAMPLE_FMT_S32P:
> +for (c = 0; c < channels; c++) {
> +const int32_t *src = (const int32
Re: [FFmpeg-devel] [PATCH v2] avfilter: add dumpwave filter.
Hi, Make sure you go back and read our comments. There were several things you didn't address in your most recent patch. Thanks, Kyle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
