Ulf Zibis (12019-04-03):
> In consideration of his in my judgement impolite 1-line comments it
> seems unlikely to me that rebasing would be worth the effort.
You are right, these comments are completely unacceptable.
But that does not mean you should not strive to improve your patches.
On 4/3/19, Ulf Zibis wrote:
>
> 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.
>
>
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
2019-04-03 11:13 GMT+02:00, Ulf Zibis :
> vf_fillborders_1.patch
As explained, this patch is not ok, therefore the patchset
as-is can not be applied.
There are two possibilities:
Either you rebase your remaining patchset and wait for a
review from Paul.
Or only send the patch that improves
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
On 4/3/19, Ulf Zibis wrote:
>
> 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 .
>
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
2019-04-03 0:25 GMT+02:00, Ulf Zibis :
> So please throw away the old one and use the new
> patch 11.
That patch does not apply:
The patch wants to remove "enum" from line 27, but that
is an include in current FFmpeg.
Carl Eugen
___
ffmpeg-devel
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
2019-04-02 22:26 GMT+02:00, Ulf Zibis :
> Hi again,
>
> Am 28.03.19 um 22:01 schrieb Ulf Zibis:
>> As you can see from the benchmark log included in the
>> vf_fillbd_benchmark_9.patch I have attained a performance gain up to 45
>> %.
>> It is remarkable, that in several cases the processing of
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
> Am 01.04.2019 um 21:39 schrieb 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?
It’s correct as it is now, please
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
2019-03-28 23:18 GMT+01:00, Paul B Mahol :
> On 3/28/19, Carl Eugen Hoyos wrote:
>> 2019-03-28 22:45 GMT+01:00, Carl Eugen Hoyos :
>>
>>> Patch 1 is wrong.
>>>
>>> I don't understand the benchmarks
>>
>> Ok, numer 9 looks like a good idea, either send only this patch or wait
>> for another
On 3/28/19, Carl Eugen Hoyos wrote:
> 2019-03-28 22:45 GMT+01:00, Carl Eugen Hoyos :
>
>> Patch 1 is wrong.
>>
>> I don't understand the benchmarks
>
> Ok, numer 9 looks like a good idea, either send only this patch or wait
> for another comment.
Patches are big mess. Until this is fixed I not
2019-03-28 22:45 GMT+01:00, Carl Eugen Hoyos :
> Patch 1 is wrong.
>
> I don't understand the benchmarks
Ok, numer 9 looks like a good idea, either send only this patch or wait
for another comment.
Carl Eugen
___
ffmpeg-devel mailing list
2019-03-28 22:01 GMT+01:00, Ulf Zibis :
> Hi again,
>
> Am 25.03.19 um 12:31 schrieb Ulf Zibis:
>>> 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
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
2019-03-26 23:33 GMT+01:00, 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 -
>> $
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
On 3/26/19, Ulf Zibis wrote:
>
> 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
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
2019-03-26 17:36 GMT+01:00, 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:
>>
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
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
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
2019-03-26 17:09 GMT+01:00, 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
>>>
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
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
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
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
Ulf Zibis (12019-03-26):
> 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 -
Obviously. Please stop putting options randomly together and wasting
everybody's time when they do not
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
Ulf Zibis (12019-03-26):
> With
> ffplay -f lavfi color=green
> I only see a monotone picture. This is not apropriate to test the
> fillborders filter with mode=mirror.
Ok. Then it is not suitable. And neither would be /dev/zero.
> Also yuvtestsrc is not really helpfull on that.
Try testsrc2.
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
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.
Carl Eugen
___
ffmpeg-devel
Ulf Zibis (12019-03-26):
> Again only 1 runs (also with "-stream_loop 1024").
You are obviously doing something wrong.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Ulf Zibis (12019-03-26):
> 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 -".
Using the "color" filter source may be a little more efficient, and is
much more
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
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
>>
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
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
2019-03-26 15:42 GMT+01:00, Ulf Zibis :
> 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
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
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
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
2019-03-24 0:13 GMT+01:00, 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
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
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
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
Hi again,
Am 12.03.19 um 00:37 schrieb Carl Eugen Hoyos:
> 2019-03-12 0:25 GMT+01:00, Moritz Barsnick :
>> Ideally, you use the START_TIMER/STOP_TIMER macros to
>> profile the actual functions you changed. (Check this mailing list's
>> archives for some examples, and play with the code.)
> But
On Fri, Mar 15, 2019 at 01:08:33AM +0100, Ulf Zibis wrote:
[...]
> static void fixed_borders16(FillBordersContext *s, AVFrame *frame)
> {
> -int p, y, x;
> -
> -for (p = 0; p < s->nb_planes; p++) {
> +for (int p = 0; p < s->nb_planes; p++) {
> uint16_t *data = (uint16_t
2019-03-15 1:08 GMT+01:00, Ulf Zibis :
> Can you give a rating if a performance win could be expected compaired
> to the original code from your experienced knowledge without a benchmark?
Just post the numbers that your tests produced.
Carl Eugen
___
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,
2019-03-12 0:25 GMT+01:00, Moritz Barsnick :
> On Mon, Mar 11, 2019 at 23:23:15 +0100, Ulf Zibis wrote:
>> >> 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
On Mon, Mar 11, 2019 at 23:23:15 +0100, Ulf Zibis wrote:
> >> 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
On Mon, 11 Mar 2019 23:07:37 +0100
Ulf Zibis wrote:
> From 74dda304bf7a0a31873518187438815d08533934 Mon Sep 17 00:00:00 2001
> From: Ulf Zibis
> Date: 11.03.2019, 23:04:15
>
> Beautified + accelerated
Commit message title prefix for filter patches are usually in the form
of:
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
2019-03-11 22:59 GMT+01:00, Ulf Zibis :
> I have made some refactoring to vf_fillborders.c.
You are not supposed to mix cosmetic changes
like removing braces or moving variable declarations
with actual code changes.
> My motivation came from using this filter as a template
> for a new filter.
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
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:
-
61 matches
Mail list logo
