Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 01.04.19 um 22:08 schrieb Carl Eugen Hoyos: >> Can you please tell me more detailed, what is wrong with the indentations? > It’s correct as it is now. You are sure? line 125: there is a double space line 130: the indentation is not aligned with the upper square bracket lines 310..318: the

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 02.04.19 um 23:33 schrieb Carl Eugen Hoyos: >> I again could enhance the performance up to 20 %. >> >> Patch 11: Correction of version from 28.03.19 22:01 CET. Fixed compiler >> warning. >> Patch 12: Moved multiplication with linesize out of for loop for >> performance; side effect: reduces

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 03.04.19 um 00:32 schrieb Carl Eugen Hoyos: >> So please throw away the old one and use the new >> patch 11. > That patch does not apply: At my machine  all patches work fine: ich@T500:~/Projects/ffmpeg/test$ git clone git://source.ffmpeg.org/ffmpeg . Klone nach '.' ... remote: Counting

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 03.04.19 um 11:13 schrieb Ulf Zibis: > At my machine  all patches work fine: > > ich@T500:~/Projects/ffmpeg/test$ git clone git://source.ffmpeg.org/ffmpeg . > Klone nach '.' ... > remote: Counting objects: 565208, done. > remote: Compressing objects: 100% (117011/117011), don

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 17:12 schrieb Carl Eugen Hoyos: > I was under the impression that we exchanged all > these emails today only because you still hadn't > found a way to measure the performance of your > patch. As I had written, I found a way with "-vf loop=loop=1024:size=1:start=0", but I was

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Hi again, Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos: >> 122670 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1, >> 1 runs, 0 skips > One run is not good. > Either use the loop option to filter the same frame again and > again or feed a video to ffmpeg. Do you mean the following

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 15:42 schrieb Ulf Zibis: > Hi again, > > Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos: >>> 122670 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1, >>> 1 runs, 0 skips >> One run is not good. >> Either use the loop option to f

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 16:26 schrieb Nicolas George: > > Try testsrc2. Bad news: ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b testsrc2 -loop 1024 -vf fillborders=25:25:25:25:mirror -f null - ffmpeg version N-93458-g18429ce896 Copyright (c) 2000-2019 the FFmpeg developers   built with gcc 7 (Ubuntu

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos: > 2019-03-26 16:28 GMT+01:00, Ulf Zibis : >> Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos: >>> 2019-03-26 15:56 GMT+01:00, Ulf Zibis : >>> >>>> I'm trying to benchmark -vf fillborders (added the timer >>

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 16:00 schrieb Nicolas George: > Using the "color" filter source may be a little more efficient, and is > much more convenient. With ffplay -f lavfi color=green I only see a monotone picture. This is not apropriate to test the fillborders filter with mode=mirror. Also yuvtestsrc is

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 17:20 schrieb Carl Eugen Hoyos: > 2019-03-26 17:17 GMT+01:00, Ulf Zibis : >> Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos: >>> 2019-03-26 16:28 GMT+01:00, Ulf Zibis : >>>> Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos: >>>>> 2019-03-26

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 15:56 schrieb Ulf Zibis: > I'm trying to benchmark -vf fillborders (added the timer code in > vf_fillborders.c), so Carl Eugen's suggestion to use /dev/zero as input > would not make sense. I'll try with "-f null -". Again only 1 runs (also with "-s

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 16:10 schrieb Carl Eugen Hoyos: > 2019-03-26 15:56 GMT+01:00, Ulf Zibis : > >> I'm trying to benchmark -vf fillborders (added the timer >> code in vf_fillborders.c), so Carl Eugen's suggestion >> to use /dev/zero as input would not make sense. > Plea

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 16:34 schrieb Carl Eugen Hoyos: > 2019-03-26 16:23 GMT+01:00, Ulf Zibis : >> Am 26.03.19 um 16:00 schrieb Nicolas George: >>> Using the "color" filter source may be a little more >>> efficient, and is much more convenient. >> With &

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 15:48 schrieb Nicolas George: > Ulf Zibis (12019-03-26): >> Do you mean the following option? Unfortunately I still see only 1 run. >> >> I know, that it works with "-vf -loop=loop=1024:size=1:start=0", but I >> ask, because I want to underst

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 17:39 schrieb Carl Eugen Hoyos: > >> 1.) There may be a shortcut in CPU architecture for copying nulls in >> series (fillborders.c essentially does that) and more important ... > I am curious: > Which architecture are you thinking about that interprets > FFmpeg's inner structure? I

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 24.03.19 um 00:40 schrieb Carl Eugen Hoyos: > There are two patches "1", one with wrong indentation. I intentionally have provided 2 patches with the same number, one for the code base an one with additions for the benchmark. I've catched the wrong indentation, hopefully at the place you

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Hi again, Am 19.03.19 um 21:44 schrieb Ulf Zibis: > Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos: >>> 122670 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1, >>> 1 runs, 0 skips >> One run is not good. >> Either use the loop option to filter the same

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 03.04.19 um 14:25 schrieb Carl Eugen Hoyos: >> vf_fillborders_1.patch > As explained, this patch is not ok, I would say "determined". > There are two possibilities: > Either you rebase your remaining patchset and wait for a > review from Paul. In consideration of his in my judgement

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Hi Carl Eugen, Am 28.03.19 um 22:45 schrieb Carl Eugen Hoyos: >> Here they are, my new set of patches. > Patch 1 is wrong. Can you please tell me more detailed, what is wrong with the indentations? -Ulf ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 26.03.19 um 16:32 schrieb Carl Eugen Hoyos: >>> Please elaborate. >> It seems I'm doing something wrong: >> >> ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -stream_loop 1024 >> -i /dev/zero -vf fillborders=25:25:25:25:mirror -f null - > $ ffmpeg -f rawvideo -s hd1080 -i /dev/zero -vf ... -t

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Patch 2 is a slight enhancement in performance for cases, where only top and bottom borders are filled. Patch 3 beautifies the code an really enhances the performance. See the results included in the benchmark patch -Ulf >From d78d496c0ed7ba83bf113d3f9cf5d68ce62ce4eb Mon Sep 17 00:00:00 2001 Fro

[FFmpeg-devel] Patch for vf_fillborders.c – Bug?

>From f3513f992e0b5595f2644257b92fdea6189592de Mon Sep 17 00:00:00 2001 From: Ulf Zibis Date: 07.03.2019, 00:34:51 Correct usage of linesize and width in 16 bit depth routines. diff --git a/.gitignore b/.gitignore index 0e57cb0..7819c84 100644 --- a/.gitignore +++ b/.gitignore @@ -36,3 +36,5

Re: [FFmpeg-devel] How to filter private folders from GIT patch

Am 08.03.19 um 10:59 schrieb Tobias Rapp: > On 08.03.2019 10:49, Ulf Zibis wrote: >> [...] >> Can some other developer please give me a practical hint how to deal >> with private folders not to appear in GIT patches? > > I'm using .git/info/exclude to ignore files that

Re: [FFmpeg-devel] How to filter private folders from GIT patch

Am 08.03.19 um 21:26 schrieb Moritz Barsnick: >> Are there other possibilities which are directly project-bounded? > Hoe about not committing them in the first place? (Don't use "git > commit -A", but instead carefully inspect everything "git status" > offers you.) Or, if you must, for your

Re: [FFmpeg-devel] Patch for vf_fillborders.c – Bug?

Am 08.03.19 um 00:53 schrieb Michael Niedermayer: > On Thu, Mar 07, 2019 at 12:52:32AM +0100, Ulf Zibis wrote: >> Hi, >> >> I think there is a bug in vf_fillborders.c 16 bit routines. >> >> When using memset or memcopy, I think, correct linesize instead >> s

Re: [FFmpeg-devel] How to filter private folders from GIT patch

Hi Michael, Am 08.03.19 um 00:53 schrieb Michael Niedermayer: > On Thu, Mar 07, 2019 at 12:52:32AM +0100, Ulf Zibis wrote: >> diff --git a/.gitignore b/.gitignore >> index 0e57cb0..7819c84 100644 >> --- a/.gitignore >> +++ b/.gitignore >> @@ -36,3 +36,5 @@

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos: > This does not look like a command line but to avoid the encoding > time, "-f null -" can be used. > >> 122670 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1, >> 1 runs, 0 skips > One run is not good. > Either use the loop option to

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos: >> $ debug/fillborders.sh >> Test[0] ==> 3-plane 8-bit YUV-colour:CYD_1005.jpg <== >> ./ffmpeg-p1 : CYD_1005.jpg --> ZZ_CYD_1005_mirror-0-0-5-5.jpg > This does not look like a command line The command line is in the script file

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

bit-1x1,   1 runs,  0 skips  622350 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1 runs,  0 skips  693630 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1 runs,  0 skips ========== >Fro

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

hout a benchmark? -Ulf >From c51360f3b4be0dca597190da5c2128b45e9ee31b Mon Sep 17 00:00:00 2001 From: Ulf Zibis Date: 14.03.2019, 19:34:03 avfilter/fillborders: added comments; named more descriptive; corrected indentations; diff --git a/libavfilter/vf_fillborders.c b/libavfilter/vf_fillborders.c index 1344587.

[FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

development. -Ulf diff --git a/libavfilter/vf_fillborders.c b/libavfilter/vf_fillborders.c index 1344587..a7a074b 100644 --- a/libavfilter/vf_fillborders.c +++ b/libavfilter/vf_fillborders.c @@ -1,5 +1,7 @@ /* * Copyright (c) 2017 Paul B Mahol + * + * Contributors: Ulf Zibis * * This file

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Here is attached the "commit" patch, if you like this more. -Ulf Am 11.03.19 um 22:59 schrieb Ulf Zibis: > Hi, > > I have made some refactoring to vf_fillborders.c. > > My motivation came from using this filter as a template for a new > filter. Refactoring

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

Am 11.03.19 um 23:08 schrieb Carl Eugen Hoyos: > You are not supposed to mix cosmetic changes > like removing braces or moving variable declarations > with actual code changes. Hm difficult, because the code changes are dependent from different variables. But I'll give it a try to make some

[FFmpeg-devel] print pts as min:sec

Hi, is there a functionality in the ffmpeg library to print AVFrame pts values in respect to AVRational time_base in human readable form? Thanks -Ulf ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] frame->display_picture_number is always 0

Hi, in a filter context I'm reading AVFrame field display_picture_number. It is always 0. How can I get this field filled with valid data? The field AVFrame->coded_picture_number has valid data, but the numbers are slightly unordered, so I want to use field display_picture_number. Thanks, -Ulf

Re: [FFmpeg-devel] How to correctly use init and uninit

Am 19.04.19 um 14:35 schrieb Paul B Mahol: >>> You do not need to use loop filter on single png. >> I need real pictures to prove the correctness of my hacking. The >> smptebars is not appopriate to see errors in the output e.g. from mirroring. >> >>> Use something like this: >>> >>> ffmpeg -f

Re: [FFmpeg-devel] [DECISION] Ban Nicolas George from project

Am 19.05.19 um 15:09 schrieb talkvi...@talkvideo.net: > Any interest in hashing this out on YouTube? Perhaps with > some live discussion? > > I can set up a call-in line, and stream the discussion live. > > Documents, code, etc can be displayed on-screen in full 1080p > so they can be read just

Re: [FFmpeg-devel] [DECISION] Ban Nicolas George from project

Am 18.05.19 um 23:48 schrieb Alexander Strasser: > This is so sad :( > And I am looking at both of you Nicolas and Paul. > > From what I know libavfilter wouldn't be anywhere near where it is today > without you two! +1 > There needs to be room for discussion on the mailing list. If Nicolas >

Re: [FFmpeg-devel] How to correctly use init and uninit

Am 19.04.19 um 14:35 schrieb Paul B Mahol: >>> You do not need to use loop filter on single png. >> I need real pictures to prove the correctness of my hacking. The >> smptebars is not appopriate to see errors in the output e.g. from mirroring. >> >>> Use something like this: >>> >>> ffmpeg -f

[FFmpeg-devel] How to correctly use init and uninit

Hi, to libavfilter/vf_fillborders.c I've added the following: === typedef struct FillBordersContext {     [.]     uint16_t *filler;     void (*fillborders)(struct FillBordersContext *s, AVFrame *frame); } FillBordersContext; // following must

Re: [FFmpeg-devel] How to correctly use init and uninit

Am 19.04.19 um 13:38 schrieb Paul B Mahol: > > Use either av_freep(>filler) or av_free(s->filler). It works fine without 'p'. Thanks! Do I really need the init function, as it has to do nothing in my case? static av_cold int init(AVFilterContext *ctx) { FillBordersContext *s = ctx->priv;

Re: [FFmpeg-devel] How to correctly use init and uninit

Am 19.04.19 um 14:35 schrieb Paul B Mahol: >> Do I really need the init function, as it has to do nothing in my case? > If it does nothing, you can safely remove it. Thanks! >> For performance testing I use the like: >> -f rawvideo -pix_fmt gray16 -s 400x600 -i /dev/zero >> >> Are there doubts

Re: [FFmpeg-devel] [PATCH v4] Add 2 timestamp print formats

t; If this could be done without float/double that would be preferred as it >>> avoids inaccuracies / slight differences between platforms >> I too thought on that, but the existing functions too rely on >> float/double. Should I anyway provide a solution with integer arithmetic? &g

[FFmpeg-devel] [PATCH v1] Config files for NetBeans IDE

Hi, I have made excellent experience in using the NetBeans IDE for FFmpeg developement. So I like to share the customized configuration for this if people like to try it here: http://jugkoeln.de/Projects/ffmpeg/netbeans_1.patch The most impressing is the graphical debugger. The NetBeans IDE can

Re: [FFmpeg-devel] [PATCH v1] Config files for NetBeans IDE

It's not meant to apply to the tree, but you can put it somewhere on your site for people who like to work with NetBeans. -Ulf Am 06.07.19 um 00:03 schrieb Paul B Mahol: > If this is meant to be applied to our tree I'm against. > We do not need this bloat. > > On 7/5/19, Ulf Zibis

Re: [FFmpeg-devel] print pts as min:sec

Am 26.06.19 um 12:26 schrieb Moritz Barsnick: > This list is for the development *of* ffmpeg and its libraries. For the > use of the libraries and the development *with* them, please turn to > the mailing list "libav-user". Sorry, if I misunderstood. I'm in progress to develop a new filter and

Re: [FFmpeg-devel] [PATCH v4] Add 2 timestamp print formats

Am 03.07.19 um 16:49 schrieb Ulf Zibis: > Am 03.07.19 um 10:52 schrieb Michael Niedermayer: >>>>> -#define av_ts2timestr(ts, tb) >>>>> av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts, tb) >>>>> +#define av_ts2timestr(ts, tb) >>

Re: [FFmpeg-devel] [PATCH v4] Add 2 timestamp print formats

Am 03.07.19 um 16:52 schrieb Nicolas George: > The features you add here seem useful, but I wonder: have you considered > the option of making them a single function with a parameter to select > the format? That may make it easier to add new formats later, and have > them supported by any

Re: [FFmpeg-devel] [PATCH v2] Add 2 timestamp print formats

Am 29.06.19 um 18:12 schrieb Ulf Zibis: > Hi, > > for my developement of another filter I need additional timestamp print > formats. > > So I like to share my efforts. Are you interested to include them to the > project? > > For libavutil/timestamp.h I'm also wondering,

Re: [FFmpeg-devel] [PATCH v2] Add 2 timestamp print formats

Am 02.07.19 um 00:28 schrieb Ulf Zibis: >> If this could be done without float/double that would be preferred as it >> avoids inaccuracies / slight differences between platforms > I too thought on that, but the existing functions too rely on > float/double. Should I anyway

Re: [FFmpeg-devel] [PATCH v2] Add 2 timestamp print formats

52815151158c7af954d38ca6 timestamp_2.patch >> From 709cb4662132deff2d17a8700f58fa91b118c56d Mon Sep 17 00:00:00 2001 >> From: Ulf Zibis >> Date: 29.06.2019, 17:52:06 >> >> avutil/timestamp: added 2 new print formats >> >> diff --git a/libavutil/timestamp.h b/libavut

[FFmpeg-devel] [PATCH v1] Add 2 timestamp print formats

is always a little heavy job, an explicit function call would not change much for performance IMHO, but would save project footprint. Please review. -Ulf >From 3bf9cb526cb70fd0192918b6b1c1b049974ca8ec Mon Sep 17 00:00:00 2001 From: Ulf Zibis Date: 29.06.2019, 17:52:06 avutil/timestamp: 2 new

Re: [FFmpeg-devel] [PATCH v1] Bug #8027 - Wrong result for FFSIGN(0)

Am 17.07.19 um 19:21 schrieb Nicolas George: > Ulf Zibis (12019-07-17): >> Because anyone I ask including mathematicians, is the opinion that the >> sign of 0 is positive. > They were not very competent mathematicians. In normal arithmetic, yes, sgn(0) is 0, but here we are

Re: [FFmpeg-devel] [PATCH v1] Bug #8027 - Wrong result for FFSIGN(0)

Am 17.07.19 um 10:12 schrieb Hendrik Leppkes: > ..., the macro was defined the way it is, and changing it now has a > chance of breaking > random places that rely on the current behavior. OK, that would be risky. Maybe we could add another macro FFSGN. Then maintainers of individual code parts

Re: [FFmpeg-devel] [PATCH v2] Add 2 timestamp print formats

Am 03.07.19 um 10:52 schrieb Michael Niedermayer: > >> I too thought on that, but the existing functions too rely on >> float/double. Should I anyway provide a solution with integer arithmetic? > its indepedant of your patch but i think all these should use integers > unless its too messy Now

[FFmpeg-devel] [PATCH v1] filter select - avoid 2 times rounding

for eq(t\,10.2) was missing. -Ulf >From f14142a22d340cba48b3e2352a33026590dec3a5 Mon Sep 17 00:00:00 2001 From: Ulf Zibis Date: 19.07.2019, 18:27:51 avfilter/select: avoid twice rounding diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c index 1132375..39cc004 100

Re: [FFmpeg-devel] [PATCH v1] filter select - avoid 2 times rounding

Am 19.07.19 um 18:57 schrieb Nicolas George: > >> avfilter/select: avoid twice rounding > Maybe I a missing something, I see no change in rounding in this code. So please give an alternative theory than a rounding issue, why I actually experience a different result. > I suspect your diagnosis

Re: [FFmpeg-devel] [PATCH v1] filter select - avoid 2 times rounding

Am 19.07.19 um 19:23 schrieb Nicolas George: > Ulf Zibis (12019-07-19): >> So please give an alternative theory than a rounding issue, why I >> actually experience a different result. > Code with doubles is very fragile, changing anything in the structure of > your formu

Re: [FFmpeg-devel] [PATCH v1] filter select - avoid 2 times rounding

Am 19.07.19 um 20:01 schrieb Nicolas George: > Ulf Zibis (12019-07-19): >> May be, but I believe single rounding over twice rounding is less fragile. > Yes. And two plastic bags will slow your fall more than one when you > jump from a plane. > >> Try this: >>     pr

Re: [FFmpeg-devel] [PATCH v1] filter select - avoid 2 times rounding

Am 19.07.19 um 22:46 schrieb Hendrik Leppkes: > This has absolutely nothing to do with "rounding", since there is no > rounding being performed, but all to do with that floating point > arithmetic is just always inaccurate. Floating point representation and arithmetic *is* "aproximating

Re: [FFmpeg-devel] [PATCH v1] filter select - avoid 2 times rounding

Am 20.07.19 um 00:06 schrieb Ulf Zibis: > Am 19.07.19 um 22:46 schrieb Hendrik Leppkes: >> This has absolutely nothing to do with "rounding", since there is no >> rounding being performed, but all to do with that floating point >> arithmetic is just alwa

Re: [FFmpeg-devel] [PATCH v1] filter select - avoid 2 times rounding

Am 20.07.19 um 00:37 schrieb Hendrik Leppkes: >> $1 The captain is always right. >> >> $2 If the captain fails, see $1. >> >> 0 against 327 fails in 2500 frames is a "slightly more favorable >> result". See my last post from 22:23 CEST. >> > The entire point is that your change is not a fix, its

[FFmpeg-devel] [PATCH v1] Bug #8027 - Wrong result for FFSIGN(0)

Hi, I have a patch for bug #8027 (see attachment). But there is still a problem with -0.0, but FFABS(-0.0) works fine. Testcode:    av_log(NULL, AV_LOG_ERROR, "FFSIGN(0): %d\n", FFSIGN(0));     av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0): %d\n", FFSIGN(-0));    

Re: [FFmpeg-devel] [PATCH v1] Bug #8027 - Wrong result for FFSIGN(0)

Again with the patch attached ... Am 17.07.19 um 08:30 schrieb Ulf Zibis: > Hi, > > I have a patch for bug #8027 <https://trac.ffmpeg.org/ticket/8027> (see > attachment). > > But there is still a problem with -0.0, but FFABS(-0.0) works fine. > > Testcode: >    a

Re: [FFmpeg-devel] [PATCH v1] Bug #8027 - Wrong result for FFSIGN(0)

Am 17.07.19 um 08:57 schrieb Song, Ruiling: > Why do you think FFSIGN(0.0) should return +1? Because anyone I ask including mathematicians, is the opinion that the sign of 0 is positive. > What issue do you meet? I wanted to use the macro in my code, but with the current behaviour it is