Re: [FFmpeg-devel] [PATCH] swresample/resample: improve bessel function accuracy

On Tue, Nov 3, 2015 at 12:45 AM, Timothy Gu wrote: > On Mon, Nov 2, 2015 at 8:23 PM Rostislav Pehlivanov > wrote: > >> >if one removes the crippling >> >-fno-tree-vectorize >> Yes, I think a config option to turn this flag on (like the unsafe >>

Re: [FFmpeg-devel] [PATCH 2/2] all: use FFDIFFSIGN to resolve possible undefined behavior in comparators

On Sun, Nov 01, 2015 at 07:29:36PM -0500, Ganesh Ajjanagadde wrote: [...] > I believe vf_palettegen and libavformat/subtitles are the only ones > lacking review, but may be mistaken. > Those are probably fine. -- Clément B. signature.asc Description: PGP signature

Re: [FFmpeg-devel] [PATCH] swresample/resample: improve bessel function accuracy

On Tue, Nov 3, 2015 at 1:08 PM, Ganesh Ajjanagadde wrote: > On Tue, Nov 3, 2015 at 2:17 AM, Clément Bœsch wrote: >> On Mon, Nov 02, 2015 at 10:10:33PM -0500, Ganesh Ajjanagadde wrote: >>> On Mon, Nov 2, 2015 at 9:32 PM, Ganesh Ajjanagadde wrote:

Re: [FFmpeg-devel] [PATCH] swresample/resample: improve bessel function accuracy

On Tue, Nov 3, 2015 at 2:17 AM, Clément Bœsch wrote: > On Mon, Nov 02, 2015 at 10:10:33PM -0500, Ganesh Ajjanagadde wrote: >> On Mon, Nov 2, 2015 at 9:32 PM, Ganesh Ajjanagadde wrote: >> > On Mon, Nov 2, 2015 at 6:49 PM, Ganesh Ajjanagadde >> >

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote: > On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde wrote: >> On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer >> wrote: >>> On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh

Re: [FFmpeg-devel] [PATCH] fate: replace custom md5 tests with those from RFC 1321

On 11/3/2015 4:44 AM, Clément Bœsch wrote: > On Tue, Nov 03, 2015 at 04:09:43AM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavutil/md5.c| 23 ++- >> tests/ref/fate/md5 | 12 +++- >> 2 files changed, 17 insertions(+), 18

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

On Tue, Nov 3, 2015 at 9:21 AM, Hendrik Leppkes wrote: > On Tue, Nov 3, 2015 at 5:10 PM, Muhammad Faiz wrote: >> On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote: >>> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

On Tue, Nov 3, 2015 at 5:10 PM, Muhammad Faiz wrote: > On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote: >> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote: >>> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote: >>> > On Fri,

Re: [FFmpeg-devel] [PATCH] swresample/resample: improve bessel function accuracy

On Tue, Nov 3, 2015 at 11:53 AM, Timothy Gu wrote: > On Tue, Nov 3, 2015 at 4:47 AM Ganesh Ajjanagadde > - GCC vectorization > slows down compilation A LOT in all versions. The newer > >> > the worse. >> >> A ~ 20% slowdown on a build for a ~ 20% improvement in an overall

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

On Tue, Nov 3, 2015 at 3:47 AM, Ganesh Ajjanagadde wrote: > On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote: >> On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde >> wrote: >>> On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer >>>

Re: [FFmpeg-devel] [PATCH] swresample/resample: improve bessel function accuracy

On Tue, Nov 3, 2015 at 4:47 AM Ganesh Ajjanagadde > - GCC vectorization slows down compilation A LOT in all versions. The newer > > the worse. > > A ~ 20% slowdown on a build for a ~ 20% improvement in an overall FATE > bench - sounds like a win to me especially with ccache. Of course, but

[FFmpeg-devel] [PATCHv2] swresample/resample: improve bessel function accuracy and speed

This improves accuracy for the bessel function at large arguments, and this in turn should improve the quality of the Kaiser window. It also improves the performance of the bessel function and hence build_filter by ~ 20%. Details are given below. Algorithm: taken from the Boost project, who have

Re: [FFmpeg-devel] [PATCH 1/2] avutil/common: add FFDIFFSIGN macro

On Sun, Nov 1, 2015 at 5:54 PM, Michael Niedermayer wrote: > On Sun, Nov 01, 2015 at 12:19:47PM -0500, Ganesh Ajjanagadde wrote: >> This is of use for defining comparator callbacks. Common approaches like >> return x-y are not safe due to the risks of overflow. >>

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: remove yuv offset

On Tue, Nov 03, 2015 at 08:14:34AM -0800, Muhammad Faiz wrote: > this makes draw_bar faster > slightly different result with old version > > check result (with ~3 minutes audio file): > old: > real0m49.611s > user0m49.260s > sys 0m0.073s > new: > real0m47.606s >

Re: [FFmpeg-devel] [PATCH 2/2] all: use FFDIFFSIGN to resolve possible undefined behavior in comparators

On Tue, Nov 3, 2015 at 5:54 AM, Clément Bœsch wrote: > On Sun, Nov 01, 2015 at 07:29:36PM -0500, Ganesh Ajjanagadde wrote: > [...] >> I believe vf_palettegen and libavformat/subtitles are the only ones >> lacking review, but may be mistaken. >> > > Those are probably fine. Pushed,

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/aacsbr_template: replace qsort with AV_QSORT

LGTM. Tested the patch, doesn't change the output. On 28 October 2015 at 01:38, Ganesh Ajjanagadde wrote: > When sbr->reset is set in encode_frame, a bunch of qsort calls might get > made. > Thus, there is the potential of calling qsort whenever the spectral > contents

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/aacsbr_template: replace qsort with AV_QSORT

On Tue, Nov 3, 2015 at 3:24 PM, Rostislav Pehlivanov wrote: > LGTM. > Tested the patch, doesn't change the output. I am personally fine with this, but was hoping for an opinion on whether the perf increase here is important enough to justify the binary size increase. Hence

Re: [FFmpeg-devel] [PATCH 4/4] lavc/pngdec: set FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM capability

On Mon, Nov 02, 2015 at 11:45:08AM +0100, Matthieu Bouron wrote: > From: Matthieu Bouron > > --- > libavcodec/pngdec.c | 1 + > 1 file changed, 1 insertion(+) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

On Tue, Nov 3, 2015 at 12:54 PM, Muhammad Faiz wrote: > On Tue, Nov 3, 2015 at 3:47 AM, Ganesh Ajjanagadde wrote: >> On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote: >>> On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde

Re: [FFmpeg-devel] [PATCH 2/4] avfilter/vf_rotate: correct log message

On Sun, Nov 1, 2015 at 6:38 PM, Michael Niedermayer wrote: > On Sat, Oct 31, 2015 at 10:47:55AM -0400, Ganesh Ajjanagadde wrote: >> There seems to be some typos in the log messages that are fixed by this. > > probably ok Been 2 days and no objections, pushed. Thanks. > >

Re: [FFmpeg-devel] [PATCH 1/4] lavc/internal: add FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM

On Mon, Nov 02, 2015 at 11:45:05AM +0100, Matthieu Bouron wrote: > From: Matthieu Bouron > > Codec supporting FF_CODEC_SKIP_FRAME_FILL must still extract and fill > their parameters into AVCodecContext while honoring the skip_frame > flag. > --- >

Re: [FFmpeg-devel] [PATCH 3/4] lavc/mjpegdec: set FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM capability

On Mon, Nov 02, 2015 at 11:45:07AM +0100, Matthieu Bouron wrote: > From: Matthieu Bouron > > --- > libavcodec/mjpegdec.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint:

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/aacsbr_template: replace qsort with AV_QSORT

The binary increase is 16 kbytes per file * 2 (since it's a template for the fixed and float decoders) = 32 kbytes. This is not very significant at all, even for the most memory and storage-space constrained (with an MMU) device. (not to mention that this is using the default compiler

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

On Tue, Nov 3, 2015 at 1:20 PM, Ganesh Ajjanagadde wrote: > On Tue, Nov 3, 2015 at 12:54 PM, Muhammad Faiz wrote: >> On Tue, Nov 3, 2015 at 3:47 AM, Ganesh Ajjanagadde wrote: >>> On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz

[FFmpeg-devel] [PATCH] swresample/resample: speed up build_filter

This speeds up build_filter by ~ 50%. This gain should be pretty consistent across all architectures and platforms. Essentially, this relies on a observation that the filters have some even/odd symmetry that may be exploited during the construction of the polyphase filter bank. In particular,

Re: [FFmpeg-devel] [PATCH] avformat/cache: Use int64_t to avoid int overflow in cache_read

On Mon, Nov 02, 2015 at 10:20:39AM -0800, Bryan Huh wrote: > Fixes an issue where an int64_t ffurl_seek return-value was being stored > in an int (32-bit) "r" variable, leading to integer overflow when seeking > into a large file (>2GB), and ultimately a "Failed to perform internal > seek" error

Re: [FFmpeg-devel] [PATCHv2] swresample/resample: improve bessel function accuracy and speed

On Tue, Nov 3, 2015 at 4:49 PM, Ganesh Ajjanagadde wrote: > [...] Same as v1, except with appropriate Boost license included inline and commit message rework to include the perf numbers. ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] swresample/resample: improve bessel function accuracy

On Tue, Nov 03, 2015 at 07:20:39AM -0500, Ganesh Ajjanagadde wrote: [...] > This is an opinion, so I will state mine here: if you are developing > use ccache + GCC > ccache + clang > clang = gcc. Reason for the first > is due to the terrible interaction ccache has with clang. I'm curious; what

Re: [FFmpeg-devel] [PATCH] swresample/resample: improve bessel function accuracy

On Tue, Nov 3, 2015 at 8:36 AM, Clément Bœsch wrote: > On Tue, Nov 03, 2015 at 07:20:39AM -0500, Ganesh Ajjanagadde wrote: > [...] >> This is an opinion, so I will state mine here: if you are developing >> use ccache + GCC > ccache + clang > clang = gcc. Reason for the first >> is

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

On Tue, Nov 3, 2015 at 11:10 AM, Muhammad Faiz wrote: > On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote: >> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote: >>> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote: >>> > On Fri,

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote: > On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote: >> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote: >> > On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer >> > wrote:

[FFmpeg-devel] [PATCH] avfilter/showcqt: remove yuv offset

this makes draw_bar faster slightly different result with old version check result (with ~3 minutes audio file): old: real0m49.611s user0m49.260s sys 0m0.073s new: real0m47.606s user0m47.378s sys 0m0.068s PSNR between old and new: yuv444p PSNR

Re: [FFmpeg-devel] [PATCH] swresample/resample: improve bessel function accuracy

On Tue, Nov 3, 2015 at 8:43 AM, Clément Bœsch wrote: > On Tue, Nov 03, 2015 at 08:41:33AM -0500, Ganesh Ajjanagadde wrote: >> On Tue, Nov 3, 2015 at 8:36 AM, Clément Bœsch wrote: >> > On Tue, Nov 03, 2015 at 07:20:39AM -0500, Ganesh Ajjanagadde wrote: >> > [...] >> >>

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote: > On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote: > > On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer > > wrote: > > > From: Michael Niedermayer > > > > > > This

Re: [FFmpeg-devel] [PATCH] swresample/resample: improve bessel function accuracy

On Tue, Nov 03, 2015 at 08:41:33AM -0500, Ganesh Ajjanagadde wrote: > On Tue, Nov 3, 2015 at 8:36 AM, Clément Bœsch wrote: > > On Tue, Nov 03, 2015 at 07:20:39AM -0500, Ganesh Ajjanagadde wrote: > > [...] > >> This is an opinion, so I will state mine here: if you are developing > >>

Re: [FFmpeg-devel] [PATCH] configure+libm.h: add fmin/fmax/fminf/fmaxf emulation

On Tue, Nov 03, 2015 at 02:42:55PM +0100, Clément Bœsch wrote: [...] > > > Wasn't there a concern that these emulations don't behave identical to > > > the C library versions in regards to NaN handling? > > > I faintly remember something in the previous discussion. > > > > yes, i forgot about