from:"Ulf Zibis"

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

2019-07-19 Thread Ulf Zibis


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 a bandaid at best.
I never have talked about a fix. What is the drawback of implementing
such a bandaid?

> The behavior will still depend on many outside factors, like the
> platform, if SSE or x87 FP math is being used, if fast or precise FP
> mode is used by the compiler, and who knows what - because you are
> expecting an equals comparison on a floating point value stemming from
> a division to be true, which will just fail sometimes if one doesn't
> round intentionally to get rid of the inaccuracy introduced by the
> calculation itself.
This is all correct. (the part about intentional rounding I don't
understand, may please give an example)

But keep in mind, that both calculations, the parsing from a string to a
double floating point and the transform oft an integer pts to a double
floating point value happen on the same machine with the same SSE and
x87 FP math and binaries from the same build with the same compiler
mode, so equality of both results is very very likely when doing only
exactly 1 approximation step on both sides.

The point is, that with e.g "10.2" the user is seeing a fixed point
value (= 10,200 ms) which is equivalent to an exact rational value, and
moreover FFmpeg claims to calculate with exact rationals where even
possible. So how should a user come to the idea, that "10.2" becomes
internally corrupted by "stupid" floating point
representation/conversion, and additionally in light of an exact time
base rational representation as e.g. 1/12800 s.
From my point of view it was a half-baked or "lousy" idea to internally
base all values of the select filter on a common double float array
instead on a multityped struct, so honouring that, my patch is indeed a
bandaid, but IMHO really helpful.

If FFmpeg engineers still want to persevere on the "just always
inaccurate" FP representation, why don't they provide a convenient
like(x, y) expression besides eq(x, y)?

-Ulf


___
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] filter select - avoid 2 times rounding

2019-07-19 Thread Ulf Zibis


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 always inaccurate.
> Floating point representation and arithmetic *is* "aproximating
> (=rounding) a real (and here a rational, wich is a subset of real)
> value", see 1st paragraph here:
> https://en.wikipedia.org/wiki/Floating-point_arithmetic

And if your concern is about the term "rounding" take "approximation"
for all places I've used "rounding", English is not my home language.

-Ulf

___
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] filter select - avoid 2 times rounding

2019-07-19 Thread 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 always inaccurate.

Floating point representation and arithmetic *is* "aproximating
(=rounding) a real (and here a rational, wich is a subset of real)
value", see 1st paragraph here:
https://en.wikipedia.org/wiki/Floating-point_arithmetic


> What this comes down to is this:
>
> a) 130560 / 12800
> b) 130560 * (1 / 12800)
>
> There is no rounding there, since everything is kept in full double
> precision. But anyone working with doubles should know that they are
> inherently inaccurate.
> Instead of re-ordering the floating point math to somehow give you a
> slightly more favorable result, maybe there should be actual rounding
> to something reasonable when its evaluating the conditions, so that
> such inaccuracies just don't matter in the first place?
$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.

-Ulf

___
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] filter select - avoid 2 times rounding

2019-07-19 Thread Ulf Zibis


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:
>>     printf("single rounding: %.40f\n", 130560LL * 1 / (double)12800);
>>     printf("twice rounding:  %.40f\n", 130560LL * (double)(1 /
>> (double)12800));
>> Result:
>> single rounding: 10.1992894572642398998141288757
>> twice rounding:  10.2010658141036401502788066864
>> The 1st result is closer to 10.2 as the 2nd.
> By a completely negligible difference. 
The wing beat of a butterfly can trigger a hurricane.
> And that is assuming it would hold for other values of 10.2, which I am not 
> convinced.
Then try this:
#define TIME_BASE 12800 // typical time base for 25 fps video
    int false_single = 0, false_twice = 0;
    for (int t = 0; t < 100 * 100; t += 4) {
    char expr_str[16], end, *end_p = &end;
    sprintf(expr_str, "%6g", t/(float)100); // simulate string from
command line
    double expr_parsed = strtod(expr_str, &end_p); //    ... to parse
    int64_t pts = t * TIME_BASE / 100;
    double t_single = pts * 1 / (double)TIME_BASE;
    double t_twice = pts * (double)(1 / (double)TIME_BASE);
    int r_single = expr_parsed == t_single;
    int r_twice = expr_parsed == t_twice;
/*
    printf("time:%6s, pts:%8ld, parsed:%22.18f, t_single:%22.18f=%s,
t_twice:%22.18f=%s\n",
    expr_str, pts, expr_parsed, t_single, r_single ? "true "
: "false", t_twice, r_twice ? "true " : "false");
*/
    false_single += !r_single;
    false_twice += !r_twice;
    }

    printf("single rounding fails: %d, twice rounding fails: %d, in %d
frames\n", false_single, false_twice, 100 * 100 / 4);

Result:
single rounding fails: 0, twice rounding fails: 327, in 2500 frames

> You are wasting your time and making the code less readable for no
> actual benefit.

Finding out, why the select filter doesn't work as I expected, wasted
enough time, so some time more doesn't matter ;-)

-Ulf

___
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] filter select - avoid 2 times rounding

2019-07-19 Thread Ulf Zibis


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 formula will give slightly different results. You were just lucky
> that this change made your use case work.

May be, but I believe single rounding over twice rounding is less fragile.

If I see right, the expression evaluation in libavutil/eval.c only
rounds once, so the chance of equal results against one rounding in
filter select should be higher.

>> In the current code there is a 1st rounding with "(double)(time_base.nom
>> / time_base.den)" and then a 2nd with multipliying this value with
>> "frame->pts". In my code there is only 1 rounding after division of
>> (int64_t)(frame->pts * time_base.nom) with "(double)time_base.den".
> There is no rounding, all is done in double.
Try this:
    printf("single rounding: %.40f\n", 130560LL * 1 / (double)12800);
    printf("twice rounding:  %.40f\n", 130560LL * (double)(1 /
(double)12800));
Result:
single rounding: 10.1992894572642398998141288757
twice rounding:  10.2010658141036401502788066864
The 1st result is closer to 10.2 as the 2nd.



___
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] filter select - avoid 2 times rounding

2019-07-19 Thread Ulf Zibis


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 is wrong

In the current code there is a 1st rounding with "(double)(time_base.nom
/ time_base.den)" and then a 2nd with multipliying this value with
"frame->pts". In my code there is only 1 rounding after division of
(int64_t)(frame->pts * time_base.nom) with "(double)time_base.den".

Additionally I think, the video must have millions of hours to trap into
integer overflow with int64_t.

-Ulf


___
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 v1] filter select - avoid 2 times rounding

2019-07-19 Thread Ulf Zibis

Hi,

I have seen, that filter select sometimes doesn't catch a frame
determined by t as cause of floating point rounding. I could experience
less problems after removing 2 times rounding in filter select. I'm
aware that there still is a chance to miss a catch, but I believe it
should be much more rare.

The patch works fine e.g. with:
$ ./ffmpeg in.mp4 -vf
select='eq(t\,10.16)+eq(t\,10.2)+eq(t\,10.24)+eq(t\,10.28)+eq(t\,10.32)+eq(t\,10.36)+eq(t\,10.4)+eq(t\,10.44)+eq(t\,17.52)+eq(t\,47.96)+eq(t\,49.08)+eq(t\,49.2)+eq(t\,55.72)+eq(t\,83.0)'
-vsync vfr out_%02d.png

Without the patch the frame 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 100644
--- a/libavfilter/f_select.c
+++ b/libavfilter/f_select.c
@@ -297,6 +297,7 @@
 
 #define D2TS(d)  (isnan(d) ? AV_NOPTS_VALUE : (int64_t)(d))
 #define TS2D(ts) ((ts) == AV_NOPTS_VALUE ? NAN : (double)(ts))
+#define TS2DT(ts, tb) (TS2D((ts) * (tb).num / (double)(tb).den))
 
 static void select_frame(AVFilterContext *ctx, AVFrame *frame)
 {
@@ -307,11 +308,11 @@
 if (isnan(select->var_values[VAR_START_PTS]))
 select->var_values[VAR_START_PTS] = TS2D(frame->pts);
 if (isnan(select->var_values[VAR_START_T]))
-select->var_values[VAR_START_T] = TS2D(frame->pts) * av_q2d(inlink->time_base);
+select->var_values[VAR_START_T] = TS2DT(frame->pts, inlink->time_base);
 
 select->var_values[VAR_N  ] = inlink->frame_count_out;
 select->var_values[VAR_PTS] = TS2D(frame->pts);
-select->var_values[VAR_T  ] = TS2D(frame->pts) * av_q2d(inlink->time_base);
+select->var_values[VAR_T  ] = TS2DT(frame->pts, inlink->time_base);
 select->var_values[VAR_POS] = frame->pkt_pos == -1 ? NAN : frame->pkt_pos;
 select->var_values[VAR_KEY] = frame->key_frame;
 select->var_values[VAR_CONCATDEC_SELECT] = get_concatdec_select(frame, av_rescale_q(frame->pts, inlink->time_base, AV_TIME_BASE_Q));
___
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] Add 2 timestamp print formats

2019-07-19 Thread Ulf Zibis


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 seeing the code of the select filter I'm wondering that there too
generally float values are used even when dealing with typically integer
values e.g. frame no.

-Ulf


___
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] Bug #8027 - Wrong result for FFSIGN(0)

2019-07-18 Thread Ulf Zibis


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 could check the usage over the time.

#define FFSGN(a) ((a) > 0 ? 1 : (a) < 0 ? -1 : 0)

-Ulf

___
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] Bug #8027 - Wrong result for FFSIGN(0)

2019-07-17 Thread Ulf Zibis


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 in floating
point arithmetics where sgn(0) is 1, see:
https://en.wikipedia.org/wiki/Floating-point_arithmetic#Signed_zero

But FFSIGN(0) results as -1, which is never correct.

-Ulf

___
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] Bug #8027 - Wrong result for FFSIGN(0)

2019-07-17 Thread Ulf Zibis


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 worthless.

-Ulf

___
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] Bug #8027 - Wrong result for FFSIGN(0)

2019-07-16 Thread Ulf Zibis

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:
>    av_log(NULL, AV_LOG_ERROR, "FFSIGN(0): %d\n", FFSIGN(0));
>     av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0): %d\n", FFSIGN(-0));
>     av_log(NULL, AV_LOG_ERROR, "FFSIGN(0.0D): %d\n", FFSIGN(0.0D));
>     av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0.0D): %d\n", FFSIGN(-0.0D));
>     av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0.0F): %d\n", FFSIGN(-0.0F));
>     av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0.0): %d\n", FFSIGN(-0.0));
>
>     av_log(NULL, AV_LOG_ERROR, "FFABS(0): %d\n", FFABS(0));
>     av_log(NULL, AV_LOG_ERROR, "FFABS(-0): %d\n", FFABS(-0));
>     av_log(NULL, AV_LOG_ERROR, "FFABS(0.0D): %f\n", FFABS(0.0D));
>     av_log(NULL, AV_LOG_ERROR, "FFABS(-0.0D): %f\n", FFABS(-0.0D));
>     av_log(NULL, AV_LOG_ERROR, "FFABS(-0.0F): %f\n", FFABS(-0.0F));
>     av_log(NULL, AV_LOG_ERROR, "FFABS(-0.0): %f\n", FFABS(-0.0));
>
> Results:
> FFSIGN(0): 1
> FFSIGN(-0): 1
> FFSIGN(0.0D): 1
> FFSIGN(-0.0D): 1
> FFSIGN(-0.0F): 1
> FFSIGN(-0.0): 1
> FFABS(0): 0
> FFABS(-0): 0
> FFABS(0.0D): 0.00
> FFABS(-0.0D): -0.00
> FFABS(-0.0F): -0.00
> FFABS(-0.0): -0.00
>
> -Ulf
>
> ___
> 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".
>From aa27ca089dafb3bc2f2c5aaa171856b235989ea4 Mon Sep 17 00:00:00 2001
From: Ulf Zibis 
Date: 16.07.2019, 23:36:51

avutil/common.h: Correct result for FFSIGN(0.0)

diff --git a/libavutil/common.h b/libavutil/common.h
index 8db0291..4b14e7b 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -70,7 +70,7 @@
  * @see FFNABS()
  */
 #define FFABS(a) ((a) >= 0 ? (a) : (-(a)))
-#define FFSIGN(a) ((a) > 0 ? 1 : -1)
+#define FFSIGN(a) ((a) >= 0 ? 1 : -1)
 
 /**
  * Negative Absolute value.
___
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 v1] Bug #8027 - Wrong result for FFSIGN(0)

2019-07-16 Thread Ulf Zibis

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));
    av_log(NULL, AV_LOG_ERROR, "FFSIGN(0.0D): %d\n", FFSIGN(0.0D));
    av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0.0D): %d\n", FFSIGN(-0.0D));
    av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0.0F): %d\n", FFSIGN(-0.0F));
    av_log(NULL, AV_LOG_ERROR, "FFSIGN(-0.0): %d\n", FFSIGN(-0.0));

    av_log(NULL, AV_LOG_ERROR, "FFABS(0): %d\n", FFABS(0));
    av_log(NULL, AV_LOG_ERROR, "FFABS(-0): %d\n", FFABS(-0));
    av_log(NULL, AV_LOG_ERROR, "FFABS(0.0D): %f\n", FFABS(0.0D));
    av_log(NULL, AV_LOG_ERROR, "FFABS(-0.0D): %f\n", FFABS(-0.0D));
    av_log(NULL, AV_LOG_ERROR, "FFABS(-0.0F): %f\n", FFABS(-0.0F));
    av_log(NULL, AV_LOG_ERROR, "FFABS(-0.0): %f\n", FFABS(-0.0));

Results:
FFSIGN(0): 1
FFSIGN(-0): 1
FFSIGN(0.0D): 1
FFSIGN(-0.0D): 1
FFSIGN(-0.0F): 1
FFSIGN(-0.0): 1
FFABS(0): 0
FFABS(-0): 0
FFABS(0.0D): 0.00
FFABS(-0.0D): -0.00
FFABS(-0.0F): -0.00
FFABS(-0.0): -0.00

-Ulf

___
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] Config files for NetBeans IDE

2019-07-05 Thread Ulf Zibis

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  wrote:
>> 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 be found here: https://netbeans.org
>> To run a C project one has add the NetBeans 8.2 Plugin Portal in the
>> Plugin Manager with following URL:
>> http://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz
>> and then install the C/C++ Plugin.
>>
>> Have fun with it
>>
>> -Ulf
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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 v1] Config files for NetBeans IDE

2019-07-05 Thread Ulf Zibis

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 be found here: https://netbeans.org
To run a C project one has add the NetBeans 8.2 Plugin Portal in the
Plugin Manager with following URL:
http://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz
and then install the C/C++ Plugin.

Have fun with it

-Ulf

___
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 v4] Add 2 timestamp print formats

2019-07-03 Thread Ulf Zibis


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 component where this is relevant.

I didn't have considerd that. If one of the project managers will agree
to, please make a suggestion for the parameters you want, and I can do
an additional patch.

-Ulf


___
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 v4] Add 2 timestamp print formats

2019-07-03 Thread Ulf Zibis


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) 
>>>>> av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
>>>>> +
>>>>> +/**
>>>>> + * Fill the provided buffer with a string containing a timestamp time
>>>>> + * representation in minutes and seconds.
>>>>> + *
>>>>> + * @param buf a buffer with size in bytes of at least 
>>>>> AV_TS_MAX_STRING_SIZE
>>>>> + * @param ts the timestamp to represent
>>>>> + * @param tb the timebase of the timestamp
>>>>> + * @return the buffer in input
>>>>> + */
>>>>> +static inline char *av_ts_make_minute_string(char *buf, int64_t ts, 
>>>>> AVRational *tb)
>>>>> +{
>>>>> +if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, 
>>>>> "NOPTS");
>>>>> +else {
>>>>> +double time = av_q2d(*tb) * ts;
>>>> 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?
>> its indepedant of your patch but i think all these should use integers
>> unless its too messy
> Thanks for you opinion.
>
> Here comes a new patch.

I missed to mark the big integer literal with 'L' and add "must be less
than 2**63/1,000,000/tb->num" to all 3 functions. So I attach a correction.

-Ulf

>From e8c42ed84492d495e506da30dc7163edafccc9e4 Mon Sep 17 00:00:00 2001
From: Ulf Zibis 
Date: 29.06.2019, 17:52:06

avutil/timestamp: 2 new print formats with av_ts2us()

diff --git a/libavutil/timestamp.h b/libavutil/timestamp.h
index e082f01..f442fc0 100644
--- a/libavutil/timestamp.h
+++ b/libavutil/timestamp.h
@@ -33,6 +33,17 @@
 #define AV_TS_MAX_STRING_SIZE 32
 
 /**
+ * Convert a time base scaled timestamp to micro seconds.
+ *
+ * @param ts the timestamp to convert, must be less than 2**63/1,000,000/tb->num
+ * @param tb the timebase of the timestamp
+ * @return the  timestamp in micro seconds
+ */
+static inline int64_t av_ts2us(int64_t ts, AVRational *tb) {
+return ts * 100 * tb->num / tb->den;
+}
+
+/**
  * Fill the provided buffer with a string containing a timestamp
  * representation.
  *
@@ -55,7 +66,7 @@
 
 /**
  * Fill the provided buffer with a string containing a timestamp time
- * representation.
+ * representation in seconds.
  *
  * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
  * @param ts the timestamp to represent
@@ -75,4 +86,60 @@
  */
 #define av_ts2timestr(ts, tb) av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts, tb)
 
+/**
+ * Fill the provided buffer with a string containing a timestamp time
+ * representation in minutes and seconds.
+ *
+ * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
+ * @param ts the timestamp to represent, must be less than 2**63/1,000,000/tb->num
+ * @param tb the timebase of the timestamp
+ * @return the buffer in input
+ */
+static char *av_ts_make_minute_string(char *buf, int64_t ts, AVRational *tb)
+{
+if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+else {
+int64_t us = av_ts2us(ts, tb);
+int len = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%3ld:%02d.%06d",
+us / 6000, (int)(us / 100 % 60), (int)(us % 100));
+while (buf[--len] == '0'); // search trailing zeros or ...
+buf[len + (buf[len] != '.')] = '\0'; // dot and strip them
+}
+return buf;
+}
+
+/**
+ * Convenience macro. The return value should be used only directly in
+ * function arguments but never stand-alone.
+ */
+#define av_ts2minutestr(ts, tb) av_ts_make_minute_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
+
+/**
+ * Fill the provided buffer with a string containing a timestamp time
+ * representation in hours, minutes and seconds.
+ *
+ * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
+ * @param ts the timestamp to represent, must be less than 2**63/1,000,000/tb->num
+ * @param tb the timebase of the timestamp
+ * @return the buffer in input
+ */
+static char *av_ts_make_hour_string(char *buf, int64_t ts, AVRational *tb)
+{
+if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+else {
+int64_t us = a

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

2019-07-03 Thread 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) 
>>>> av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
>>>> +
>>>> +/**
>>>> + * Fill the provided buffer with a string containing a timestamp time
>>>> + * representation in minutes and seconds.
>>>> + *
>>>> + * @param buf a buffer with size in bytes of at least 
>>>> AV_TS_MAX_STRING_SIZE
>>>> + * @param ts the timestamp to represent
>>>> + * @param tb the timebase of the timestamp
>>>> + * @return the buffer in input
>>>> + */
>>>> +static inline char *av_ts_make_minute_string(char *buf, int64_t ts, 
>>>> AVRational *tb)
>>>> +{
>>>> +if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, 
>>>> "NOPTS");
>>>> +else {
>>>> +double time = av_q2d(*tb) * ts;
>>> 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?
> its indepedant of your patch but i think all these should use integers
> unless its too messy

Thanks for you opinion.

Here comes a new patch.

-Ulf

From 5d62406366560cfab5711120c514a77867bd8c2e Mon Sep 17 00:00:00 2001
From: Ulf Zibis 
Date: 29.06.2019, 17:52:06

avutil/timestamp: added av_ts2us() and 2 new print formats

diff --git a/libavutil/timestamp.h b/libavutil/timestamp.h
index e082f01..8cb6e8f 100644
--- a/libavutil/timestamp.h
+++ b/libavutil/timestamp.h
@@ -33,6 +33,17 @@
 #define AV_TS_MAX_STRING_SIZE 32
 
 /**
+ * Convert a time base scaled timestamp to micro seconds.
+ *
+ * @param ts the timestamp to convert, must be less than 2**63/1,000,000/tb->num
+ * @param tb the timebase of the timestamp
+ * @return the  timestamp in micro seconds
+ */
+static inline int64_t av_ts2us(int64_t ts, AVRational *tb) {
+return ts * 100 * tb->num / tb->den;
+}
+
+/**
  * Fill the provided buffer with a string containing a timestamp
  * representation.
  *
@@ -55,7 +66,7 @@
 
 /**
  * Fill the provided buffer with a string containing a timestamp time
- * representation.
+ * representation in seconds.
  *
  * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
  * @param ts the timestamp to represent
@@ -75,4 +86,60 @@
  */
 #define av_ts2timestr(ts, tb) av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts, tb)
 
+/**
+ * Fill the provided buffer with a string containing a timestamp time
+ * representation in minutes and seconds.
+ *
+ * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
+ * @param ts the timestamp to represent
+ * @param tb the timebase of the timestamp
+ * @return the buffer in input
+ */
+static char *av_ts_make_minute_string(char *buf, int64_t ts, AVRational *tb)
+{
+if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+else {
+int64_t us = av_ts2us(ts, tb);
+int len = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%3ld:%02d.%06d",
+us / 6000, (int)(us / 100 % 60), (int)(us % 100));
+while (buf[--len] == '0'); // search trailing zeros or ...
+buf[len + (buf[len] != '.')] = '\0'; // dot and strip them
+}
+return buf;
+}
+
+/**
+ * Convenience macro. The return value should be used only directly in
+ * function arguments but never stand-alone.
+ */
+#define av_ts2minutestr(ts, tb) av_ts_make_minute_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
+
+/**
+ * Fill the provided buffer with a string containing a timestamp time
+ * representation in hours, minutes and seconds.
+ *
+ * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
+ * @param ts the timestamp to represent
+ * @param tb the timebase of the timestamp
+ * @return the buffer in input
+ */
+static char *av_ts_make_hour_string(char *buf, int64_t ts, AVRational *tb)
+{
+if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+else {
+int64_t us = av_ts2us(ts, tb);
+int len = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%ld:%02d:%02d.%06d",
+us / 36, (int)(us / 6000 % 60), (int)(us / 100 % 60), (int)(us % 100));
+while (buf[--len] == '0'); // search trailing zeros or ...
+buf[len + (buf[len] != '.')] = '\0'; // dot and strip them
+}
+return buf;
+}
+
+/**
+ * Convenie

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

2019-07-01 Thread Ulf Zibis


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 provide a solution with integer arithmetic?
Then there could be inconsistencies with the existing
av_ts_make_time_string function.

My current approach is result of this discussion:
https://stackoverflow.com/questions/56797715/which-format-string-to-use-with-printf-for-a-time-as-78901-234/56814382#

-Ulf

___
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] Add 2 timestamp print formats

2019-07-01 Thread Ulf Zibis

Thanks Michael for your review, answers inline ...

Am 01.07.19 um 17:16 schrieb Michael Niedermayer:
>>  timestamp.h |   78 
>> 
>>  1 file changed, 73 insertions(+), 5 deletions(-)
>> 3d1275421b1b8d4952815151158c7af954d38ca6  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/libavutil/timestamp.h
>> index e082f01..b94e5ce 100644
>> --- a/libavutil/timestamp.h
>> +++ b/libavutil/timestamp.h
>> @@ -48,14 +48,14 @@
>>  }
>>  
>>  /**
>> - * Convenience macro, the return value should be used only directly in
>> + * Convenience macro. The return value should be used only directly in
>>   * function arguments but never stand-alone.
>>   */
>> -#define av_ts2str(ts) av_ts_make_string((char[AV_TS_MAX_STRING_SIZE]){0}, 
>> ts)
>> +#define av_ts2str(ts) 
>> av_ts_make_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts)
>>  
>>  /**
>>   * Fill the provided buffer with a string containing a timestamp time
>> - * representation.
>> + * representation in seconds.
>>   *
>>   * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
>>   * @param ts the timestamp to represent
>> @@ -70,9 +70,77 @@
>>  }
>>  
>>  /**
>> - * Convenience macro, the return value should be used only directly in
>> + * Convenience macro. The return value should be used only directly in
>>   * function arguments but never stand-alone.
>>   */
> Unrelated change, belongs in a seperate patch
The following change I think should be part of the patch, as it helps to
distinguish between the existing timestamp functions and my new ones:
- * representation.
+ * representation in seconds.
The other above changes are cosmetic and can go in a separate patch. But
would you endorse them?

>> -#define av_ts2timestr(ts, tb) 
>> av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts, tb)
>> +#define av_ts2timestr(ts, tb) 
>> av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
>> +
>> +/**
>> + * Fill the provided buffer with a string containing a timestamp time
>> + * representation in minutes and seconds.
>> + *
>> + * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
>> + * @param ts the timestamp to represent
>> + * @param tb the timebase of the timestamp
>> + * @return the buffer in input
>> + */
>> +static inline char *av_ts_make_minute_string(char *buf, int64_t ts, 
>> AVRational *tb)
>> +{
>> +if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
>> +else {
>> +double time = av_q2d(*tb) * ts;
> 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?

>> +const char *format = (time >= 0 ? "%3d:%09.6f" : "-%3d:%09.6f");
>> +time = (fabs(time) > INT_MAX * 60.0 ? INT_MAX * 60.0 : fabs(time));
>> +int len = snprintf(buf, AV_TS_MAX_STRING_SIZE, format, (int)(time / 
>> 60), fmod(time, 60));

Correct. I didn't bother on that for sake of readability and saving code
lines. This can be changed, if you want.

What's about "inline"? I think it's not helpful here as I argued in my
last post.

-Ulf


___
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] Add 2 timestamp print formats

2019-07-01 Thread Ulf Zibis


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, why these format functions
> are designated for "inline". As printing is always a little heavy job,
> an explicit function call would not change much for performance IMHO,
> but would save project footprint.
Because of a rounding issue I had to make a new version.

Please review patch v2.

-Ulf

>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/libavutil/timestamp.h
index e082f01..b94e5ce 100644
--- a/libavutil/timestamp.h
+++ b/libavutil/timestamp.h
@@ -48,14 +48,14 @@
 }
 
 /**
- * Convenience macro, the return value should be used only directly in
+ * Convenience macro. The return value should be used only directly in
  * function arguments but never stand-alone.
  */
-#define av_ts2str(ts) av_ts_make_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts)
+#define av_ts2str(ts) av_ts_make_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts)
 
 /**
  * Fill the provided buffer with a string containing a timestamp time
- * representation.
+ * representation in seconds.
  *
  * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
  * @param ts the timestamp to represent
@@ -70,9 +70,77 @@
 }
 
 /**
- * Convenience macro, the return value should be used only directly in
+ * Convenience macro. The return value should be used only directly in
  * function arguments but never stand-alone.
  */
-#define av_ts2timestr(ts, tb) av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts, tb)
+#define av_ts2timestr(ts, tb) av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
+
+/**
+ * Fill the provided buffer with a string containing a timestamp time
+ * representation in minutes and seconds.
+ *
+ * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
+ * @param ts the timestamp to represent
+ * @param tb the timebase of the timestamp
+ * @return the buffer in input
+ */
+static inline char *av_ts_make_minute_string(char *buf, int64_t ts, AVRational *tb)
+{
+if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+else {
+double time = av_q2d(*tb) * ts;
+const char *format = (time >= 0 ? "%3d:%09.6f" : "-%3d:%09.6f");
+time = (fabs(time) > INT_MAX * 60.0 ? INT_MAX * 60.0 : fabs(time));
+int len = snprintf(buf, AV_TS_MAX_STRING_SIZE, format, (int)(time / 60), fmod(time, 60));
+if (len - 9 >= 0 && buf[len - 9] > '5') // correct rare rounding issue
+len = snprintf(buf, AV_TS_MAX_STRING_SIZE, format, (int)(time / 60) + 1, .0);
+while (buf[--len] == '0'); // search trailing zeros or ...
+buf[len + (buf[len] != '.')] = '\0'; // dot and strip them
+}
+return buf;
+}
+
+/**
+ * Convenience macro. The return value should be used only directly in
+ * function arguments but never stand-alone.
+ */
+#define av_ts2minutestr(ts, tb) av_ts_make_minute_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
+
+/**
+ * Fill the provided buffer with a string containing a timestamp time
+ * representation in hours, minutes and seconds.
+ *
+ * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
+ * @param ts the timestamp to represent
+ * @param tb the timebase of the timestamp
+ * @return the buffer in input
+ */
+static inline char *av_ts_make_hour_string(char *buf, int64_t ts, AVRational *tb)
+{
+if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+else {
+double time = av_q2d(*tb) * ts;
+const char *format = (time >= 0 ? "%d:%02d:%09.6f" : "-%d:%02d:%09.6f");
+time = (fabs(time) > INT_MAX * 60.0 * 60.0 ? INT_MAX * 60.0 * 60.0 : fabs(time));
+int hours = time / 60 / 60, minutes = fmod(time / 60, 60);
+int len = snprintf(buf, AV_TS_MAX_STRING_SIZE, format, hours, minutes, fmod(time, 60));
+if (len - 9 >= 0 && buf[len - 9] > '5') { // correct rare rounding issue
+if (++minutes > 59) {
+minutes = 0;
+hours++;
+}
+len = snprintf(buf, AV_TS_MAX_STRING_SIZE, format, hours, minutes, .0);
+}
+while (buf[--len] == '0'); // search trailing zeros or ...
+buf[len + (buf[len] != '.')] = '\0'; // dot and strip them
+}
+return buf;
+}
+
+/**
+ * Convenience macro. The return value should be used only directly in
+ * function argument

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

2019-06-29 Thread 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, why these format functions
are designated for "inline". As printing 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 print formats

diff --git a/libavutil/timestamp.h b/libavutil/timestamp.h
index e082f01..43e8107 100644
--- a/libavutil/timestamp.h
+++ b/libavutil/timestamp.h
@@ -25,6 +25,7 @@
 #define AVUTIL_TIMESTAMP_H
 
 #include "common.h"
+#include "avassert.h"
 
 #if defined(__cplusplus) && !defined(__STDC_FORMAT_MACROS) && !defined(PRId64)
 #error missing -D__STDC_FORMAT_MACROS / #define __STDC_FORMAT_MACROS
@@ -51,11 +52,11 @@
  * Convenience macro, the return value should be used only directly in
  * function arguments but never stand-alone.
  */
-#define av_ts2str(ts) av_ts_make_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts)
+#define av_ts2str(ts) av_ts_make_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts)
 
 /**
  * Fill the provided buffer with a string containing a timestamp time
- * representation.
+ * representation in seconds.
  *
  * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
  * @param ts the timestamp to represent
@@ -73,6 +74,63 @@
  * Convenience macro, the return value should be used only directly in
  * function arguments but never stand-alone.
  */
-#define av_ts2timestr(ts, tb) av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts, tb)
+#define av_ts2timestr(ts, tb) av_ts_make_time_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
+
+/**
+ * Fill the provided buffer with a string containing a timestamp time
+ * representation in minutes and seconds.
+ *
+ * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
+ * @param ts the timestamp to represent
+ * @param tb the timebase of the timestamp
+ * @return the buffer in input
+ */
+static inline char *av_ts_make_minute_string(char *buf, int64_t ts, AVRational *tb)
+{
+if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+else {
+double time = av_q2d(*tb) * ts;
+int len = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%3d:%09.6f", (int)time / 60, fabs(fmod(time, 60)));
+av_assert1(len < MAX_BUF_SZ && len >= 0);
+while (buf[--len] == '0'); // strip trailing zeros and dot.
+buf[len + ((buf[len] != '.') & 1)] = '\0'; // terminate
+}
+return buf;
+}
+
+/**
+ * Convenience macro, the return value should be used only directly in
+ * function arguments but never stand-alone.
+ */
+#define av_ts2minutestr(ts, tb) av_ts_make_minute_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
+
+/**
+ * Fill the provided buffer with a string containing a timestamp time
+ * representation in hours, minutes and seconds.
+ *
+ * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
+ * @param ts the timestamp to represent
+ * @param tb the timebase of the timestamp
+ * @return the buffer in input
+ */
+static inline char *av_ts_make_hour_string(char *buf, int64_t ts, AVRational *tb)
+{
+if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+else {
+double time = av_q2d(*tb) * ts;
+int len = snprintf(buf, AV_TS_MAX_STRING_SIZE, "%d:%02d:%09.6f",
+(int)time / 60 / 60,  (int)time / 60 % 60, fabs(fmod(time, 60)));
+av_assert1(len < MAX_BUF_SZ && len >= 0);
+while (buf[--len] == '0'); // strip trailing zeros and dot.
+buf[len + ((buf[len] != '.') & 1)] = '\0'; // terminate
+}
+return buf;
+}
+
+/**
+ * Convenience macro, the return value should be used only directly in
+ * function arguments but never stand-alone.
+ */
+#define av_ts2hourstr(ts, tb) av_ts_make_hour_string((char[AV_TS_MAX_STRING_SIZE]){'\0'}, ts, tb)
 
 #endif /* AVUTIL_TIMESTAMP_H */
___
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] print pts as min:sec

2019-06-26 Thread Ulf Zibis


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 will provide a patch if I'm
ready. So I'm wrong on this list?

> Regarding your request, you can look at libavfilter/vf_showinfo.c.
> filter_frame() has an av_log() line which should show the calculation
> you are looking for:
>
> av_log(ctx, AV_LOG_INFO,
>"n:%4"PRId64" pts:%7s pts_time:%-7s pos:%9"PRId64" "
> [...]
> av_ts2str(frame->pts), av_ts2timestr(frame->pts, &inlink->time_base), 
> frame->pkt_pos,

Great! Much thanks!

-Ulf

___
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] frame->display_picture_number is always 0

2019-06-25 Thread Ulf Zibis

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


___
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] print pts as min:sec

2019-06-25 Thread Ulf Zibis

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
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] [DECISION] Ban Nicolas George from project

2019-05-19 Thread Ulf Zibis


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
> has a comment that "blocks" one of your patches Paul, you should be
> polite and try to implement it or to find convincing argument that
> shows that it is better to do things differently. Yes, the process
> can be weary and demotivating at times.
>
> OTOH Nicolas should accept that often perfect is the enemy of good and
> having a solution now can be better than having it later or never. Also
> I think it is required to provide help and pointers and not only to say
> it is blocked because of X. Just less black and white. The world isn't
> ideal and there are advantages and drawbacks to each and every thing.

OTOH contrarily I know Paul as consistently blocking my patches without
any explaining comment except such as "is a mess". Also sad!

-Ulf

___
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] [DECISION] Ban Nicolas George from project

2019-05-19 Thread Ulf Zibis


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 like they were on one's own desktop.
>
> Personally I think it would be great.


+1

-Ulf

___
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] How to correctly use init and uninit

2019-05-14 Thread Ulf Zibis


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 lavfi -i smptebars=size=hd720 -vf fillborders=... -f null -
>> For performance testing I use the like:
>> -f rawvideo -pix_fmt gray16 -s 400x600 -i /dev/zero
>>
>> Are there doubts if that is good either?
> Use ffmpeg -f lavfi -i color=color=black:size=400x600 ...
>
> Thing about /dev/zero and -f rawvideo is that it will decode zeroes
> over and over again and thus use more CPU for that.

Unfortunately I can not confirm that. :-(

My benchmark needs 60 seconds with
ffmpeg -f lavfi -i
color=color=black:size=400x600,format=rgba64/gray/gray16 ...
but only 25 seconds with
ffmpeg -f rawvideo -pix_fmt rgba64/gray/gray16 -s 400x600 -i /dev/zero ...

-Ult


___
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] How to correctly use init and uninit

2019-05-13 Thread Ulf Zibis


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 lavfi -i smptebars=size=hd720 -vf fillborders=... -f null -
>> For performance testing I use the like:
>> -f rawvideo -pix_fmt gray16 -s 400x600 -i /dev/zero
>>
>> Are there doubts if that is good either?
> Use ffmpeg -f lavfi -i color=color=black:size=400x600 ...
>
> Thing about /dev/zero and -f rawvideo is that it will decode zeroes
> over and over again and thus use more CPU for that.

I can not confirm that. :-(

My benchmark needs 60 seconds with
ffmpeg -f lavfi -i
color=color=black:size=400x600,format=rgba64/gray/gray16 ...
but only 25 seconds with
ffmpeg -f rawvideo -pix_fmt rgba64/gray/gray16 -s 400x600 -i /dev/zero ...

-Ult

___
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] How to correctly use init and uninit

2019-04-19 Thread Ulf Zibis


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 if that is good either?
> Use ffmpeg -f lavfi -i color=color=black:size=400x600 ...
>
> Thing about /dev/zero and -f rawvideo is that it will decode zeroes
> over and over again and thus use more CPU for that.
Thanks again for the hint. For my tests I use different formats:
test[i++]="3-plane 8-bit  YUV-420:   -pix_fmt yuv420p"
test[i++]="3-plane 16-bit YUV-420:   -pix_fmt yuv420p16"
test[i++]="3-plane 16-bit YUV-444:   -pix_fmt yuv444p16"
test[i++]="1-plane 8-bit  Y-400: -pix_fmt gray"
test[i++]="1-plane 16-bit Y-400: -pix_fmt gray16"

test[i++]="4-plane 16-bit RGBA-444:  -pix_fmt rgba64"

What could be the expressions with "-f lavfi"?

-Ulf

___
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] How to correctly use init and uninit

2019-04-19 Thread Ulf Zibis


Am 19.04.19 um 13:38 schrieb Paul B Mahol:
>
> Use either av_freep(&s->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;
return 0;
}
 

> 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 lavfi -i smptebars=size=hd720 -vf fillborders=... -f null -
For performance testing I use the like:
-f rawvideo -pix_fmt gray16 -s 400x600 -i /dev/zero

Are there doubts if that is good either?

-Ulf

___
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] How to correctly use init and uninit

2019-04-19 Thread Ulf Zibis

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 be moved up to compile correctly with STOP_TIMER(testcase)

#define OFFSET(x) offsetof(FillBordersContext, x)
#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM

static const AVOption fillborders_options[] = {
    [.]
};

AVFILTER_DEFINE_CLASS(fillborders);

[.]

static char testcase[128];

static av_cold int init(AVFilterContext *ctx)
{
    FillBordersContext *s = ctx->priv;
    return 0;
}

static int config_init(AVFilterLink *inlink)
{
    [.]
    int fill_sz = FFMAX3(s->left, s->right, s->top != 0 || inlink->h -
s->bottom != 0 ? inlink->w : 0);
    printf("fill_sz: %d\n", fill_sz);
    s->filler = av_malloc(fill_sz * sizeof(uint16_t));
/*
    for (int i = 0; i < fill_sz; i++)
    s->filler[i] = s->fill[p] << (s->depth - 8);
*/

    sprintf(testcase, "fillborders=%d:%d:%d:%d:%s %dp-%dbit-%dx%d",
    s->left, s->right, s->top, s->bottom, fillborders_options[5
+ s->mode].name,
    s->nb_planes, s->depth, desc->log2_chroma_w,
desc->log2_chroma_h);

    return 0;
}

static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
{
    FillBordersContext *s = inlink->dst->priv;

    START_TIMER

    s->fillborders(s, frame);

    STOP_TIMER(testcase)

    return ff_filter_frame(inlink->dst->outputs[0], frame);
}

static av_cold void uninit(AVFilterContext *ctx)
{
    FillBordersContext *s = ctx->priv;
    av_freep(s->filler);
}

[.]

AVFilter ff_vf_fillborders = {
    [.]
    .init  = init,
    .uninit    = uninit,
    [.]
};
===

When running the filter with (1-plane 16-bit GRAY) I get "free():
invalid pointer" :

$ ./ffmpeg -y -i debug/16.jpg -vf
loop=1:1:0:start=0,fillborders=25:25:0:0:fixed:green -update 1
debug/16_fixed_25-25-0-0.jpg
ffmpeg version N-93468-g6e6f598ae2 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
Input #0, image2, from 'debug/16.jpg':
  Duration: 00:00:00.04, start: 0.00, bitrate: 103852 kb/s
    Stream #0:0: Video: mjpeg (Lossless),
gray16le(bt470bg/unknown/unknown), 640x480 [SAR 96:96 DAR 4:3],
lossless, 25 tbr, 25 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg (native) -> mjpeg (native))
Press [q] to stop, [?] for help
fill_sz: 640
[swscaler @ 0x55e255ec6980] deprecated pixel format used, make sure you
did set range correctly
 481140 decicycles in fillborders=25:25:0:0:fixed 1p-16bit-0x0,   1
runs,  0 skips
Output #0, image2, to 'debug/16_fixed_25-25-0-0.jpg':
  Metadata:
    encoder : Lavf58.26.101
    Stream #0:0: Video: mjpeg, yuvj444p(pc), 640x480 [SAR 1:1 DAR 4:3],
q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
  encoder : Lavc58.47.105 mjpeg
    Side data:
  cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: -1
 480645 decicycles in fillborders=25:25:0:0:fixed 1p-16bit-0x0,   2
runs,  0 skips
frame=    2 fps=0.0 q=3.9 Lsize=N/A time=00:00:00.08 bitrate=N/A
speed=1.56x    
video:75kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown
free(): invalid pointer
Abgebrochen (Speicherabzug geschrieben)
===

When running the filter with "-v error" AND (1-plane 8-bit GRAY) I don't
get the error, but again with 16-bit, weird :

$ ./ffmpeg -y -v error -i debug/8.jpg -vf
loop=1:1:0:start=0,fillborders=25:25:0:0:fixed:green -update 1
debug/8_fixed_25-25-0-0.jpg
fill_sz: 640
 227340 decicycles in fillborders=25:25:0:0:fixed 1p-8bit-0x0,   1
runs,  0 skips
 226575 decicycles in fillborders=25:25:0:0:fixed 1p-8bit-0x0,   2
runs,  0 skips
$ ./ffmpeg -y -v error -i debug/16.jpg -vf
loop=1:1:0:start=0,fillborders=25:25:0:0:fixed:green -update 1
debug/16_fixed_25-25-0-0.jpg
fill_sz: 640
 447750 decicycles in fillborders=25:25:0:0:fixed 1p-16bit-0x0,   1
runs,  0 skips
 449775 decicycles in fillborders=25:25:0:0:fixed 1p-16bit-0x0,   2
runs,  0 skips
free(): invalid pointer
Abgebrochen (Speicherabzug geschrieben)
===

The complete file is in the attachment.

Does one have any hints for me?

-Ulf

/*
 * Copyright (c) 2017 Paul B Mahol
 *
 * 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

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

2019-04-03 Thread Ulf Zibis


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 impolite 1-line comments it
seems unlikely to me that rebasing would be worth the effort.

> Patches are big mess.
> You showed very little skills.
> You obviously lack git skills.
Even your question from 28.03.19, 23:22 CET is still open.

> Or only send the patch that improves the filter performance.

I'll consider that when I'm complete with my investigation with tuning.
I also could provide a final patch to rework the remaining indentations
which is much less work.

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-04-03 Thread Ulf Zibis


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), done.
> remote: Total 565208 (delta 453761), reused 556701 (delta 447046)
> Empfange Objekte: 100% (565208/565208), 100.39 MiB | 1.04 MiB/s, Fertig.
> Löse Unterschiede auf: 100% (453761/453761), Fertig.
> ich@T500:~/Projects/ffmpeg/test$ git checkout -b vf_fillborders
> Zu neuem Branch 'vf_fillborders' gewechselt
> [.]
> ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_1.patch
> Wende an: avfilter/fillborders: corrected indentations on
> line-continuation to 8
> [.]

The similar you can do with the benchmark patches:

$ git branch master
$ git checkout -b vf_fillbd_benchmark
$ git am vf_fillbd_benchmark_1.patch
$ git am vf_fillbd_benchmark_2.patch
[.]

-Ulf


___
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] beautified + accelerated vf_fillborders – Please review

2019-04-03 Thread Ulf Zibis


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 objects: 565208, done.
remote: Compressing objects: 100% (117011/117011), done.
remote: Total 565208 (delta 453761), reused 556701 (delta 447046)
Empfange Objekte: 100% (565208/565208), 100.39 MiB | 1.04 MiB/s, Fertig.
Löse Unterschiede auf: 100% (453761/453761), Fertig.
ich@T500:~/Projects/ffmpeg/test$ git checkout -b vf_fillborders
Zu neuem Branch 'vf_fillborders' gewechselt
ich@T500:~/Projects/ffmpeg/test$ git status
Auf Branch vf_fillborders
Unversionierte Dateien:
  (benutzen Sie "git add ...", um die Änderungen zum Commit
vorzumerken)

    vf_fillborders_1.patch
    vf_fillborders_10.patch
    vf_fillborders_11.patch
    vf_fillborders_12.patch
    vf_fillborders_2.patch
    vf_fillborders_3.patch
    vf_fillborders_4.patch
    vf_fillborders_5.patch
    vf_fillborders_6.patch
    vf_fillborders_7.patch
    vf_fillborders_8.patch
    vf_fillborders_9.patch

nichts zum Commit vorgemerkt, aber es gibt unversionierte Dateien
(benutzen Sie "git add" zum Versionieren)
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_1.patch
Wende an: avfilter/fillborders: corrected indentations on
line-continuation to 8
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_2.patch
Wende an: avfilter/fillborders: added comments; removed separation in
commented blocks
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_3.patch
Wende an: avfilter/fillborders: named more descriptive
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_4.patch
Wende an: avfilter/fillborders: moved fillborders_options[] more up,
needed for STOP_TIMER(testcase);
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_5.patch
Wende an: avfilter/fillborders: removed obsolete includes
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_6.patch
Wende an: avfilter/fillborders: reduced scope of local variables, also
saves code lines
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_7.patch
Wende an: avfilter/fillborders:renamed config_props; avoid needless
calculations there and order more logical
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_8.patch
Wende an: avfilter/fillborders: aligned pointer to array addressing style
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_9.patch
Wende an: avfilter/fillborders: enhanced readability;
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_10.patch
Wende an: avfilter/fillborders: shortened linesize name to allow more
1-line code; removed braces
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_11.patch
Wende an: avfilter/fillborders: move definitions to their context, also
to reduce their scope
ich@T500:~/Projects/ffmpeg/test$ git am vf_fillborders_12.patch
Wende an: avfilter/fillborders: moved multiplication with linesize out
of for loop for performance;
ich@T500:~/Projects/ffmpeg/test$

> The patch wants to remove "enum" from line 27, but that is an include in 
> current FFmpeg.
If you already have applied the old version of vf_fillborders_11.patch
you may first remove it from the repository with:
git reset --hard HEAD~1

... and then apply the new patch again.

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-04-02 Thread Ulf Zibis


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 footprint again.
> Does not apply / patches to change patches are not ok.

Sorry, I do not have the original commit anymore, because I have amended
the change to it. So I can't provide a revert patch on base of the
original patch 11. So please throw away the old one and use the new
patch 11.

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-04-02 Thread Ulf Zibis


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 code is hard to read without highlighting the
line-continuation by extra indentation

All other cases are surly matter of taste, but I prefer unified
line-continuation indentation of 8. This has the advantage, that
renaming a variable, e.g. "ptr" -> "data", does not entail an additional
correction of the indentations each time and all line-continuations are
clearly distinguishable from new lines.

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-04-01 Thread Ulf Zibis

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
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] beautified + accelerated vf_fillborders – Please review

2019-03-27 Thread Ulf Zibis


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 curious how I could use the
shorter options -loop or -stream_loop from your suggestion of 19.03.19,
17:31 CET.
This does not mean, that I unlike your new suggestion with "-f rawvideo
".

> I hoped you had already tested the functional correctness.

Until this state of changes yes. But it is more convenient in my IDE
configuration to have only 1 script for both purposes.

Thanks for all your help

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread Ulf Zibis


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 1000 -f null -
Thanks. With "-t 1000" it loops endless, but it works fine with:

$ ffmpeg -f rawvideo -s 300x200 -i /dev/zero -vf ... -frames 1024 -f null -

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread Ulf Zibis


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 was inspired of your suspicion. ;-) From Java code I know, that such
things happen as cause of the JIT "just in time compiler" optimization,
don't know, if modern C compilers assemble similar effects.

>> 2.) Additionally I want to test on different ...
>> - number of planes
>> - color model /resolution
>> - bit depth
> Use the input option -pix_fmt

Ok, I'll look on that.

And I'm still curious to read something on my initial question
(following your suggestion from 19.03.19, 17:31 CET to use "-loop"):
... I ask, because I want to understand the purpose of the shorter
options "-loop number" and "-stream_loop number" (or how to apply them
correctly in the command line to get the wanted effect on single picture
input).

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread Ulf Zibis


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 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.
>>>>> 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 1000 -f null -
>>>
>>> It may be that the performance of the filter cannot be
>>> tested like this, I don't know.
>> I suspect, you are right on not suitable for performance test.
> (I did not claim that, on the contrary.)
> Why not?
1.) There may be a shortcut in CPU architecture for copying nulls in
series (fillborders.c essentially does that) and more important ...
2.) Additionally I want to test on different ...
- number of planes
- color model /resolution
- bit depth

-Ulf
___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread 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 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.
>>> 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 1000 -f null -
>
> It may be that the performance of the filter cannot be
> tested like this, I don't know.

Thanks for your help!

I suspect, you are right on not suitable for performance test.
... and for sure not for algorithmic tests.

Unfortunately my initial question is still open:
... but I ask, because I want to understand the purpose of the shorter
options "-loop number" and "-stream_loop number" (or how to apply them
correctly in the command line to get the wanted effect).

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread Ulf Zibis


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
>> ffplay -f lavfi color=green
>> I only see a monotone picture. This is not apropriate
>> to test the fillborders filter with mode=mirror.
> Why not?
Well, it may be good for the performance test, but can't test the
algorithmic correctness of the tweaked vf_fillborders.c code.
Additionally I want to test on different ...
- number of planes
- color model
- bit depth

-Ulf


___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread Ulf Zibis


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 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
[NULL @ 0x5636e78ba900] Unable to find a suitable output format for
'testsrc2'
testsrc2: Invalid argument
ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -f lavfi 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 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
[NULL @ 0x564b7e1fb940] Requested output format 'lavfi' is not a
suitable output format
testsrc2: Invalid argument

Anyway this test video is not really appropriate for my tests with
fillborders filter:
1.) The edges are mostly monotone, so I would hardly see an effect after
mirroring the borders
2.) I still want to see the performance on single pictures.

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread 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
>> code in vf_fillborders.c), so Carl Eugen's suggestion
>> to use /dev/zero as input would not make sense.
> 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 version N-93458-g18429ce896 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
/dev/zero: Invalid data found when processing input
ich@T500:~/Projects/ffmpeg/dev$ ./ffmpeg-p7b -y -i /dev/zero -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 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
/dev/zero: Invalid data found when processing input

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread 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
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 not really helpfull on that.

-Ulf


___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread Ulf Zibis


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 "-stream_loop 1024").

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread Ulf Zibis


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 understand the purpose of the shorter option
>> "-loop number".
>>
>> ./ffmpeg-p7b -y -i debug/8.jpg -loop 1024 -vf
>> fillborders=25:25:25:25:mirror debug/ZZ_8_mirror-25-25-25-25.jpg
> Are you trying to benchmark the JPEG encoder? If not, do not use the
> JPEG encoder, use no encoder at all.
>
> Are you trying to benchmark the image2 muxer? If not, do not use the
> image2 muxer, use no muxer at all.
>
> Are you trying to benchmark the JPEG decoder? If not, do not use the
> JPEG decoder, use the "color" filter source, or, if the test requires
> non-trivial content to be relevant, prepare a rawvideo input.

Thanks for your hints.

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 -".

-Ulf


___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread Ulf Zibis


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 filter the same frame again and
>> again or feed a video to ffmpeg.
> 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 understand the purpose of the shorter option
> "-loop number".

Also  "-stream_loop 1024" doesn't work as I would expect.

-Ulf


___
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] beautified + accelerated vf_fillborders – Please review

2019-03-26 Thread 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 filter the same frame again and
> again or feed a video to ffmpeg.

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 understand the purpose of the shorter option
"-loop number".

./ffmpeg-p7b -y -i debug/8.jpg -loop 1024 -vf
fillborders=25:25:25:25:mirror debug/ZZ_8_mirror-25-25-25-25.jpg
ffmpeg version N-93458-g18429ce896 Copyright (c) 2000-2019 the FFmpeg
developers
  built with gcc 7 (Ubuntu 7.3.0-27ubuntu1~18.04)
  configuration:
  libavutil  56. 26.100 / 56. 26.100
  libavcodec 58. 47.105 / 58. 47.105
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  7.100 / 58.  7.100
  libavfilter 7. 48.100 /  7. 48.100
  libswscale  5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
Input #0, image2, from 'debug/8.jpg':
  Duration: 00:00:00.04, start: 0.00, bitrate: 39119 kb/s
    Stream #0:0: Video: mjpeg (Lossless), gray(bt470bg/unknown/unknown),
640x480 [SAR 96:96 DAR 4:3], lossless, 25 tbr, 25 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (mjpeg (native) -> mjpeg (native))
Press [q] to stop, [?] for help
[swscaler @ 0x560c9b036400] deprecated pixel format used, make sure you
did set range correctly
 968130 decicycles in fillborders=25:25:25:25:mirror 1p-8bit-0x0,  
1 runs,  0 skips
Output #0, image2, to 'debug/ZZ_8_mirror-25-25-25-25.jpg':
  Metadata:
    encoder : Lavf58.26.101
    Stream #0:0: Video: mjpeg, yuvj444p(pc), 640x480 [SAR 1:1 DAR 4:3],
q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
  encoder : Lavc58.47.105 mjpeg
    Side data:
  cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: -1
frame=    1 fps=0.0 q=6.0 Lsize=N/A time=00:00:00.04 bitrate=N/A
speed=1.69x   
video:34kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: unknown

___
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] beautified + accelerated vf_fillborders – Please review

2019-03-25 Thread Ulf Zibis


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 meant.

> Iiuc, the patch mixes the following:
> Renaming of a variable
> Moving of blocks
> Adding commented code that is removed in a later patch
> Replacing constants with harder to read calculations
This is an argument. There are several places in the code using "* 2".
At some places this is an algorithmic purpose, at others to serve the
16-bit logic. I wanted to set this in clear view.

> Adding comments
>
> I don't maintain the file but in general not all of these are
> acceptable and it any case should be separate changes.
>
> This also removes outcommented code which should
> not be part of a performance enhancement.
> How much "slight enhancement" were you able to measure?
> Iiuc, some cases get slower, no?
> Some people prefer that patches like this do not change the
> indentation to make it more readable.
>
> Again: Please do not mix functional and cosmetic changes.
I'm preparing a new set of patches to follow your advice.

> Do I read the results correctly that for all patches some cases
> get faster and others get slower?

Correct. I'm wondering about the cases, where it gets such slower. So
I'm interested in an answer from you experienced developers to
understand this. Maybe a compiler option would help.

-Ulf

___
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] beautified + accelerated vf_fillborders – Please review

2019-03-25 Thread Ulf Zibis

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 frame again and
>> again or feed a video to ffmpeg.
> With:
> ./ffmpeg -y -v error -stream_loop 100 -i input.jpg -vf
> fillborders=5:5:5:5:mirror -f null -
> I still see only 1 run. What I'm doing wrong?
As I was not able to find a loop option I used -stream_loop. Now I'm
wondering, that it doesn't work as I expect.

Do I misinterpret the purpose of -stream_loop?

-Ulf


___
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] beautified + accelerated vf_fillborders – Please review

2019-03-23 Thread Ulf Zibis

Hi again,

Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos:
> One run is not good.
> Either use the loop option to filter the same frame again and
> again or feed a video to ffmpeg.

I have new patches.

Patch 1 is just a little renaming and a preparation for the benchmark
timer code.

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
From: Ulf Zibis 
Date: 14.03.2019, 19:34:03

avfilter/fillborders: added comments; named more descriptive; corrected indentations;
moved fillborders_options[] more up, needed for STOP_TIMER(testcase);

diff --git a/libavfilter/vf_fillborders.c b/libavfilter/vf_fillborders.c
index 1344587..ce768d4 100644
--- a/libavfilter/vf_fillborders.c
+++ b/libavfilter/vf_fillborders.c
@@ -19,14 +19,16 @@
  */
 
 #include "libavutil/colorspace.h"
-#include "libavutil/common.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
-#include "avfilter.h"
 #include "drawutils.h"
-#include "formats.h"
 #include "internal.h"
+/*
+#include "libavutil/common.h"
+#include "avfilter.h"
+#include "formats.h"
 #include "video.h"
+*/
 
 enum { Y, U, V, A };
 enum { R, G, B };
@@ -53,6 +55,22 @@
 
 void (*fillborders)(struct FillBordersContext *s, AVFrame *frame);
 } FillBordersContext;
+
+#define OFFSET(x) offsetof(FillBordersContext, x)
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption fillborders_options[] = {
+{ "left",   "set the left fill border",   OFFSET(left),   AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
+{ "right",  "set the right fill border",  OFFSET(right),  AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
+{ "top","set the top fill border",OFFSET(top),AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
+{ "bottom", "set the bottom fill border", OFFSET(bottom), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
+{ "mode",   "set the fill borders mode",  OFFSET(mode),   AV_OPT_TYPE_INT, {.i64=FM_SMEAR}, 0, FM_NB_MODES-1, FLAGS, "mode" },
+{ "smear",  NULL, 0, AV_OPT_TYPE_CONST, {.i64=FM_SMEAR},  0, 0, FLAGS, "mode" },
+{ "mirror", NULL, 0, AV_OPT_TYPE_CONST, {.i64=FM_MIRROR}, 0, 0, FLAGS, "mode" },
+{ "fixed",  NULL, 0, AV_OPT_TYPE_CONST, {.i64=FM_FIXED},  0, 0, FLAGS, "mode" },
+{ "color",  "set the color for the fixed mode", OFFSET(rgba_color), AV_OPT_TYPE_COLOR, {.str = "black"}, .flags = FLAGS },
+{ NULL }
+};
 
 static int query_formats(AVFilterContext *ctx)
 {
@@ -87,27 +105,28 @@
 int p, y;
 
 for (p = 0; p < s->nb_planes; p++) {
-uint8_t *ptr = frame->data[p];
+uint8_t *data = frame->data[p];
 int linesize = frame->linesize[p];
 
+/* fill left and right borders from top to bottom border */
 for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
-memset(ptr + y * linesize,
-   *(ptr + y * linesize + s->borders[p].left),
-   s->borders[p].left);
-memset(ptr + y * linesize + s->planewidth[p] - s->borders[p].right,
-   *(ptr + y * linesize + s->planewidth[p] - s->borders[p].right - 1),
-   s->borders[p].right);
+memset(data + y * linesize,
+*(data + y * linesize + s->borders[p].left),
+s->borders[p].left);
+memset(data + y * linesize + s->planewidth[p] - s->borders[p].right,
+*(data + y * linesize + s->planewidth[p] - s->borders[p].right - 1),
+s->borders[p].right);
 }
 
+/* fill top and bottom borders */
 for (y = 0; y < s->borders[p].top; y++) {
-memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p]);
+memcpy(data + y * linesize,
+data + s->borders[p].top * linesize, s->planewidth[p]);
 }
-
 for (y = s->planeheight[p] - s->borders[p].bottom; y < s->planeheight[p]; y++) {
-memcpy(ptr + y * linesize,
-   ptr + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
-   s->planewidth[p]);
+memcpy(data + y * linesize,
+data + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
+s->pla

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

2019-03-19 Thread Ulf Zibis


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 filter the same frame again and
> again or feed a video to ffmpeg.
With:
./ffmpeg -y -v error -stream_loop 100 -i input.jpg -vf
fillborders=5:5:5:5:mirror -f null -
I still see only 1 run. What I'm doing wrong?

-Ulf

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2019-03-19 Thread Ulf Zibis


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 debug/fillborders.sh.
This echo comment line with ./ffmpeg-p1 means that the following runs
were done with the build from patch 1 and with ./ffmpeg-2 from patch 2
for comparison.

>  but to avoid the encoding
> time, "-f null -" can be used.
You mean this as answer for using the -benchmark option? Thanks for the
hint. But the CPU time for the decoding would still be there, which i'm
afraid, it will too much overflow the little CPU time for the filter.

>>  122670 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,
>> 1 runs,  0 skips
> One run is not good.
I did 6 runs for each command line pattern by loop in
debug/fillborders.sh (included in vf_fillbd_benchmark_2.patch).

> Either use the loop option to filter the same frame again and
> again or feed a video to ffmpeg.

Ok, I'll try this.

-Ulf

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2019-03-19 Thread Ulf Zibis

rs=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 630090 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
=
$ 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
 131220 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 141030 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 135900 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 133380 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 148230 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 119880 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
./ffmpeg-p2 : CYD_1005.jpg --> ZZ_CYD_1005_mirror-0-0-5-5.jpg
 165870 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 120960 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 126450 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 122310 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 132660 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 122940 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
./ffmpeg-p1 : CYD_1005.jpg --> ZZ_CYD_1005_mirror-5-5-0-0.jpg
 578160 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
 571140 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
 652320 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
 571500 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
 756810 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
 515880 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
./ffmpeg-p2 : CYD_1005.jpg --> ZZ_CYD_1005_mirror-5-5-0-0.jpg
 625140 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
 595260 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
 552600 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
 636390 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
 687960 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
 648900 decicycles in fillborders=5:5:0:0:mirror 3p-8bit-1x1,   1
runs,  0 skips
./ffmpeg-p1 : CYD_1005.jpg --> ZZ_CYD_1005_mirror-5-5-5-5.jpg
 578610 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 552060 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 604980 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 486900 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 498780 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 549900 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
./ffmpeg-p2 : CYD_1005.jpg --> ZZ_CYD_1005_mirror-5-5-5-5.jpg
 642240 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 658710 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
1701630 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-1x1,   1
runs,  0 skips
 676350 decicycles in fillborders=5:5:5:5:mirror 3p-8bit-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
======


>From b07ff408d579c49fef93041bedb3b894d914f2b8 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..8b7ad18 100644
--- a/libavfilter/vf_fillborders.c
+++ b/libavfilter/vf_fillborders.c
@@ -19,14 +19,16 @@
  */
 
 #include "libavutil/colorspace.h"
-#include "libavutil/common.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
-#include "avfilter.h"
 #include "drawutils.h"
-#include "formats.h"
 #include "internal.h"
+/*
+#include "libavutil/common.h"
+#include "avfilter.h"
+#include "formats.h"
 #include "video.h"
+*/
 
 enum { Y, U, V, A };
 enum { R, G, B };
@@ -87,27 +89,28 @@
 int p, y;
 
 for (p = 0; p < s->nb_planes; p++) {
-uint8

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

2019-03-14 Thread Ulf Zibis


Am 11.03.19 um 23:29 schrieb Lou Logan:
> Commit message title prefix for filter patches are usually in the form
> of:
>
> avfilter/fillborders:
> or
> lavfi/fillborders: 
>
> Trailing whitespace. This should always be avoided.
>
> Use av_malloc.

I now have separted the changes into 4 patches, and mergerd your hints.

So you can clearly see, which calculations I have skipped or moved out
of inner for loops.
Can you give a rating if a performance win could be expected compaired
to the original code from your experienced knowledge without 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..820aa2d 100644
--- a/libavfilter/vf_fillborders.c
+++ b/libavfilter/vf_fillborders.c
@@ -87,26 +87,27 @@
 int p, y;
 
 for (p = 0; p < s->nb_planes; p++) {
-uint8_t *ptr = frame->data[p];
+uint8_t *data = frame->data[p];
 int linesize = frame->linesize[p];
 
+/* fill left and right borders from top to bottom border */
 for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
-memset(ptr + y * linesize,
-   *(ptr + y * linesize + s->borders[p].left),
+memset(data + y * linesize,
+   *(data + y * linesize + s->borders[p].left),
s->borders[p].left);
-memset(ptr + y * linesize + s->planewidth[p] - s->borders[p].right,
-   *(ptr + y * linesize + s->planewidth[p] - s->borders[p].right - 1),
+memset(data + y * linesize + s->planewidth[p] - s->borders[p].right,
+   *(data + y * linesize + s->planewidth[p] - s->borders[p].right - 1),
s->borders[p].right);
 }
 
+/* fill top and bottom borders */
 for (y = 0; y < s->borders[p].top; y++) {
-memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p]);
+memcpy(data + y * linesize,
+   data + s->borders[p].top * linesize, s->planewidth[p]);
 }
-
 for (y = s->planeheight[p] - s->borders[p].bottom; y < s->planeheight[p]; y++) {
-memcpy(ptr + y * linesize,
-   ptr + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
+memcpy(data + y * linesize,
+   data + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
s->planewidth[p]);
 }
 }
@@ -117,29 +118,29 @@
 int p, y, x;
 
 for (p = 0; p < s->nb_planes; p++) {
-uint16_t *ptr = (uint16_t *)frame->data[p];
-int linesize = frame->linesize[p] / 2;
+uint16_t *data = (uint16_t *)frame->data[p];
+int linesize = frame->linesize[p] / sizeof(uint16_t);
 
+/* fill left and right borders from top to bottom border */
 for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
 for (x = 0; x < s->borders[p].left; x++) {
-ptr[y * linesize + x] =  *(ptr + y * linesize + s->borders[p].left);
+data[y * linesize + x] =  *(data + y * linesize + s->borders[p].left);
 }
-
 for (x = 0; x < s->borders[p].right; x++) {
-ptr[y * linesize + s->planewidth[p] - s->borders[p].right + x] =
-   *(ptr + y * linesize + s->planewidth[p] - s->borders[p].right - 1);
+data[y * linesize + s->planewidth[p] - s->borders[p].right + x] =
+   *(data + y * linesize + s->planewidth[p] - s->borders[p].right - 1);
 }
 }
 
+/* fill top and bottom borders */
 for (y = 0; y < s->borders[p].top; y++) {
-memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p] * 2);
+memcpy(data + y * linesize,
+   data + s->borders[p].top * linesize, s->planewidth[p] * sizeof(uint16_t));
 }
-
 for (y = s->planeheight[p] - s->borders[p].bottom; y < s->planeheight[p]; y++) {
-memcpy(ptr + y * linesize,
-   ptr + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
-   s->planewidth[p] * 2);
+memcpy(data + y * linesize,
+   data + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
+   s->planewidth[p] * sizeof(uint16_t));
 }
 }
 }
@@ -149,29 +150,29 @@
 int p, y, x;
 
 for (p = 0; p < s->nb_planes

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

2019-03-11 Thread Ulf Zibis


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 separated patches.

>> I believe, it's faster because of:
> Please post some numbers if your patch is supposed to
> speed up the filter.

Hm, I have no clue how to do this. I thing the listed arguments speak
for themselves. Is there a kind of harness, template or framework for this?

Thanks for your first review.

-Ulf

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2019-03-11 Thread Ulf Zibis

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 the code was a good exercise to understand FFmpeg's
> data models.
>
> I think, the code is now much better readable and I believe, it's faster
> because of:
> - more use of memset() and memcpy()
> - less calculations in the inner for loops
> - skip the looping for right/left filling when there is nothing to do
>
> I would be appreciated, if one would review my proposed changes.
>
> Hopefully I've used the right format for the patch. Please honour, that
> I'm new in FFmpeg development.
>
> -Ulf
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From 74dda304bf7a0a31873518187438815d08533934 Mon Sep 17 00:00:00 2001
From: Ulf Zibis 
Date: 11.03.2019, 23:04:15

Beautified + accelerated

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 is part of FFmpeg.
  *
@@ -18,6 +20,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include 
 #include "libavutil/colorspace.h"
 #include "libavutil/common.h"
 #include "libavutil/opt.h"
@@ -84,187 +87,176 @@
 
 static void smear_borders8(FillBordersContext *s, AVFrame *frame)
 {
-int p, y;
+for (int p = 0; p < s->nb_planes; p++) {
+uint8_t *data = frame->data[p];
+int lz = frame->linesize[p];
+int width = s->planewidth[p];
+int height = s->planeheight[p] * lz;
+int left = s->borders[p].left;
+int right = width - s->borders[p].right;
+int top = s->borders[p].top * lz;
+int bottom = height - s->borders[p].bottom * lz;
 
-for (p = 0; p < s->nb_planes; p++) {
-uint8_t *ptr = frame->data[p];
-int linesize = frame->linesize[p];
+/* fill left and right borders from top to bottom border */
+if (left != 0 || right != width) // in case skip for performance
+for (int y = top; y < bottom; y += lz) {
+memset(data + y, *(data + y + left), left);
+memset(data + y + right, *(data + y + right - 1), width - right);
+}
 
-for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
-memset(ptr + y * linesize,
-   *(ptr + y * linesize + s->borders[p].left),
-   s->borders[p].left);
-memset(ptr + y * linesize + s->planewidth[p] - s->borders[p].right,
-   *(ptr + y * linesize + s->planewidth[p] - s->borders[p].right - 1),
-   s->borders[p].right);
-}
-
-for (y = 0; y < s->borders[p].top; y++) {
-memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p]);
-}
-
-for (y = s->planeheight[p] - s->borders[p].bottom; y < s->planeheight[p]; y++) {
-memcpy(ptr + y * linesize,
-   ptr + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
-   s->planewidth[p]);
-}
+/* fill top and bottom borders */
+for (uint8_t *y = data + top; y > data; )
+memcpy(y -= lz, data + top, width);
+for (uint8_t *y = data + bottom; y < data + height; y += lz)
+memcpy(y, data + bottom - lz, width);
 }
 }
 
 static void smear_borders16(FillBordersContext *s, AVFrame *frame)
 {
-int p, y, x;
+for (int p = 0; p < s->nb_planes; p++) {
+uint16_t *data = (uint16_t *)frame->data[p];
+int lz = frame->linesize[p] / sizeof(uint16_t);
+int width = s->planewidth[p];
+int height = s->planeheight[p] * lz;
+int left = s->borders[p].left;
+int right = width - s->borders[p].right;
+int top = s->borders[p].top * lz;
+int bottom = height - s->borders[p].bottom * lz;
 
-for (p = 0; p < s->nb_planes; p++) {
-uint16_t *ptr = (uint16_t *)frame->data[p];
-int linesize = frame->linesize[p] / 2;
-
-for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
-for (x = 0; x < s->borders[p].left; x++) {
-ptr[y * linesize + x] =  *(ptr + y * linesize + s->borders[p].left);
+/* fill left and

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

2019-03-11 Thread 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 the code was a good exercise to understand FFmpeg's
data models.

I think, the code is now much better readable and I believe, it's faster
because of:
- more use of memset() and memcpy()
- less calculations in the inner for loops
- skip the looping for right/left filling when there is nothing to do

I would be appreciated, if one would review my proposed changes.

Hopefully I've used the right format for the patch. Please honour, that
I'm new in FFmpeg 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 is part of FFmpeg.
  *
@@ -18,6 +20,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include 
 #include "libavutil/colorspace.h"
 #include "libavutil/common.h"
 #include "libavutil/opt.h"
@@ -84,187 +87,176 @@
 
 static void smear_borders8(FillBordersContext *s, AVFrame *frame)
 {
-int p, y;
+for (int p = 0; p < s->nb_planes; p++) {
+uint8_t *data = frame->data[p];
+int lz = frame->linesize[p];
+int width = s->planewidth[p];
+int height = s->planeheight[p] * lz;
+int left = s->borders[p].left;
+int right = width - s->borders[p].right;
+int top = s->borders[p].top * lz;
+int bottom = height - s->borders[p].bottom * lz;
 
-for (p = 0; p < s->nb_planes; p++) {
-uint8_t *ptr = frame->data[p];
-int linesize = frame->linesize[p];
+/* fill left and right borders from top to bottom border */
+if (left != 0 || right != width) // in case skip for performance
+for (int y = top; y < bottom; y += lz) {
+memset(data + y, *(data + y + left), left);
+memset(data + y + right, *(data + y + right - 1), width - right);
+}
 
-for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
-memset(ptr + y * linesize,
-   *(ptr + y * linesize + s->borders[p].left),
-   s->borders[p].left);
-memset(ptr + y * linesize + s->planewidth[p] - s->borders[p].right,
-   *(ptr + y * linesize + s->planewidth[p] - s->borders[p].right - 1),
-   s->borders[p].right);
-}
-
-for (y = 0; y < s->borders[p].top; y++) {
-memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p]);
-}
-
-for (y = s->planeheight[p] - s->borders[p].bottom; y < s->planeheight[p]; y++) {
-memcpy(ptr + y * linesize,
-   ptr + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
-   s->planewidth[p]);
-}
+/* fill top and bottom borders */
+for (uint8_t *y = data + top; y > data; )
+memcpy(y -= lz, data + top, width);
+for (uint8_t *y = data + bottom; y < data + height; y += lz)
+memcpy(y, data + bottom - lz, width);
 }
 }
 
 static void smear_borders16(FillBordersContext *s, AVFrame *frame)
 {
-int p, y, x;
+for (int p = 0; p < s->nb_planes; p++) {
+uint16_t *data = (uint16_t *)frame->data[p];
+int lz = frame->linesize[p] / sizeof(uint16_t);
+int width = s->planewidth[p];
+int height = s->planeheight[p] * lz;
+int left = s->borders[p].left;
+int right = width - s->borders[p].right;
+int top = s->borders[p].top * lz;
+int bottom = height - s->borders[p].bottom * lz;
 
-for (p = 0; p < s->nb_planes; p++) {
-uint16_t *ptr = (uint16_t *)frame->data[p];
-int linesize = frame->linesize[p] / 2;
-
-for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
-for (x = 0; x < s->borders[p].left; x++) {
-ptr[y * linesize + x] =  *(ptr + y * linesize + s->borders[p].left);
+/* fill left and right borders from top to bottom border */
+if (left != 0 || right != width) // in case skip for performance
+for (int y = top; y < bottom; y += lz) {
+for (int x = left; x >= 0; x--)
+data[y + x] =  data[y + left];
+for (int x = right; x < width; x++)
+data[y + x] = data[y + right - 1];
 }
 
-for (x = 0; x < s->borders[p].right; x++) {
-ptr[y * linesize + s->

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

2019-03-09 Thread Ulf Zibis

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 development desire, then commit
> them in a separate commit which you then don't include in your exported
> patch(es).
>
> I don't know about Netbeans, but e.g. Qt Creator offers me to add its
> projects files to a detected revision control, but I can click "no
> thanks" (or un-add them later, before committing).

I don't see this in NetBeans, but I've found a solution. Thanks for your hints!

I was in error about the interpretion of .git/info/exclude. I thought it was 
meant as path in $HOME folder. In the project's folder it does what I want, 
thanks Tobias.

-Ulf

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2019-03-08 Thread Ulf Zibis


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 are only found within
> my private developing environment.
This is a valuable hint, thanks. But  I suspect it is easy to manage
ignores project-wise with this approach.

Are there other possibilities which are directly project-bounded?

-Ulf

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2019-03-08 Thread Ulf Zibis

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 @@
>>  /lcov/
>>  /src
>>  /mapfile
>> +/nbproject
>> +/debug
> this shouldnt be in the patch

Thanks for your note.

/nbproject is automatically created by NetBeans IDE I'm using to develop.
I think this ignore tag could be useful for other developers using
NetBeans IDE.

/debug is a private folder for my testing.
Can some other developer please give me a practical hint how to deal
with private folders not to appear in GIT patches?

-Ulf

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2019-03-08 Thread Ulf Zibis


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->planewidth[p] should be used.
>> When using arrray syntax, I think, correct s->planewidth[p] instead
>> linesize should be used.
>>
>> See my proposed patch.
>>
>> -Ulf

Please ignore the patch.
In the meantime I've found a misunderstanding from my side.

-Ulf



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

2019-03-06 Thread Ulf Zibis

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->planewidth[p] should be used.
When using arrray syntax, I think, correct s->planewidth[p] instead
linesize should be used.

See my proposed patch.

-Ulf

>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 @@
 /lcov/
 /src
 /mapfile
+/nbproject
+/debug
diff --git a/libavfilter/vf_fillborders.c b/libavfilter/vf_fillborders.c
index 1344587..019cdff 100644
--- a/libavfilter/vf_fillborders.c
+++ b/libavfilter/vf_fillborders.c
@@ -89,25 +89,27 @@
 for (p = 0; p < s->nb_planes; p++) {
 uint8_t *ptr = frame->data[p];
 int linesize = frame->linesize[p];
+int nb_leftbytes = s->borders[p].left * linesize / s->planewidth[p];
+int nb_rightbytes = s->borders[p].right * linesize / s->planewidth[p];
 
 for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
 memset(ptr + y * linesize,
-   *(ptr + y * linesize + s->borders[p].left),
-   s->borders[p].left);
-memset(ptr + y * linesize + s->planewidth[p] - s->borders[p].right,
-   *(ptr + y * linesize + s->planewidth[p] - s->borders[p].right - 1),
-   s->borders[p].right);
+   *(ptr + y * linesize + nb_leftbytes),
+   nb_leftbytes);
+memset(ptr + y * linesize + linesize - nb_rightbytes,
+   *(ptr + y * linesize + linesize - nb_rightbytes - 1),
+   nb_rightbytes);
 }
 
 for (y = 0; y < s->borders[p].top; y++) {
 memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p]);
+   ptr + s->borders[p].top * linesize, linesize);
 }
 
 for (y = s->planeheight[p] - s->borders[p].bottom; y < s->planeheight[p]; y++) {
 memcpy(ptr + y * linesize,
ptr + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
-   s->planewidth[p]);
+   linesize);
 }
 }
 }
@@ -118,28 +120,28 @@
 
 for (p = 0; p < s->nb_planes; p++) {
 uint16_t *ptr = (uint16_t *)frame->data[p];
-int linesize = frame->linesize[p] / 2;
+int linesize = frame->linesize[p];
 
 for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
 for (x = 0; x < s->borders[p].left; x++) {
-ptr[y * linesize + x] =  *(ptr + y * linesize + s->borders[p].left);
+ptr[y * s->planewidth[p] + x] =  *(ptr + y * s->planewidth[p] + s->borders[p].left);
 }
 
 for (x = 0; x < s->borders[p].right; x++) {
-ptr[y * linesize + s->planewidth[p] - s->borders[p].right + x] =
-   *(ptr + y * linesize + s->planewidth[p] - s->borders[p].right - 1);
+ptr[y * s->planewidth[p] + s->planewidth[p] - s->borders[p].right + x] =
+   *(ptr + y * s->planewidth[p] + s->planewidth[p] - s->borders[p].right - 1);
 }
 }
 
 for (y = 0; y < s->borders[p].top; y++) {
 memcpy(ptr + y * linesize,
-   ptr + s->borders[p].top * linesize, s->planewidth[p] * 2);
+   ptr + s->borders[p].top * linesize, linesize);
 }
 
 for (y = s->planeheight[p] - s->borders[p].bottom; y < s->planeheight[p]; y++) {
 memcpy(ptr + y * linesize,
ptr + (s->planeheight[p] - s->borders[p].bottom - 1) * linesize,
-   s->planewidth[p] * 2);
+   linesize);
 }
 }
 }
@@ -154,25 +156,25 @@
 
 for (y = s->borders[p].top; y < s->planeheight[p] - s->borders[p].bottom; y++) {
 for (x = 0; x < s->borders[p].left; x++) {
-ptr[y * linesize + x] = ptr[y * linesize + s->borders[p].left * 2 - 1 - x];
+ptr[y * s->planewidth[p] + x] = ptr[y * s->planewidth[p] + s->borders[p].left * 2 - 1 - x];
 }
 
 for (x = 0; x < s->borders[p].right; x++) {
-ptr[y * linesize + s->planewidth[p] - s->borders[p].right + x] =
-ptr[y * linesize + s->planewidth[p] - s->borders[p].right - 1 - x];
+ptr[y * s->planewidth[p] + s->planewidth[p] - s->borders[p].right + x] =
+ptr[y * s->planewidth

66 matches

Mail list logo