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.
Regards,
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.
>
> In
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 impol
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 t
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 object
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 mailing
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 foo
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 16-b
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
> 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 do
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@ffmpe
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 comment
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 go
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
ffmpeg-devel@
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 curiou
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 -
>> $ ffmp
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 int
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:
>> 2019-03-2
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 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 monot
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-
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 fill
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 mak
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 w
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
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.
A
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 m
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
https:
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 fee
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 -i
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 opt
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.
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 prep
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 s
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 filte
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/fill
2019-03-19 15:57 GMT+01:00, Ulf Zibis :
> $ 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 but to avoid the encoding
time, "-f null -" can be used.
>
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 thi
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 *)fra
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
___
f
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, an
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 arguments
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 harness
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:
avfilter/fillbord
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 sepa
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. Re
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 understa
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
62 matches
Mail list logo
