Uwe Freese (12019-01-25):
> may I ask again what the next step is to integrate my delogo patch?
>
> It was some effort to change the implementation in the way as discussed here
> and I really would like that the patch is finally added to the repository.
>
> Are there any problems, questions, or o
Hello again,
may I ask again what the next step is to integrate my delogo patch?
It was some effort to change the implementation in the way as discussed
here and I really would like that the patch is finally added to the
repository.
Are there any problems, questions, or other points blocking
Hello,
just a kind reminder. - What is the next step, is there anything more I
should improve, check, modify,...?
For me, the filter works as intended.
@Nicolas: Can you answer my remaining three questions below, please?
Regards,
Uwe
Am 02.01.19 um 23:34 schrieb Uwe Freese:
Hello,
Here's
Hello,
Here's a new version of the patch. Changes:
- My last version didn't compile because of moving code to config_input.
Don't know why I didn't see this, sorry.
I moved the code back to filter_frame because of two reasons. First,
I need the "sar" to init my tables and it seems I need th
Hi,
just an info: code didn't compile, don't know why I didn't see this...
New patch is in work...
Regards, Uwe
Am 01.01.19 um 22:14 schrieb Uwe Freese:
Hello,
here's a new version of the patch.
Thanks for the infos. I used the raw output of a small test video
(where delogo is applied in
Nicolas George (2019-01-02):
> Uwe Freese (2019-01-01):
> > > This can be optimized, and since it is the inner loop of the filter, I
> > > think it is worth it. You can declare a pointer that will stay the same
> > > for the whole y loop:
> > >
> > > double *xweight = uglarmtable + (y - logo_y1)
Uwe Freese (2019-01-01):
> > This can be optimized, and since it is the inner loop of the filter, I
> > think it is worth it. You can declare a pointer that will stay the same
> > for the whole y loop:
> >
> > double *xweight = uglarmtable + (y - logo_y1) * (logo_w - 1);
> >
> > and then use
Hello,
here's a new version of the patch.
Thanks for the infos. I used the raw output of a small test video (where
delogo is applied in both modes) before and after the changes to make
sure the output is bytewise identical (the changes don't change the output).
In general I want to say that
2018-12-30 14:02 GMT+01:00, Nicolas George :
> Uwe Freese (2018-12-29):
>> +(double*)av_malloc((logo_w - 1) * (logo_h - 1) *
>> sizeof(double));
>
> No casting of malloc returns in C, this is a c++ thing. Also, use
> av_malloc_array().
While there, please don't use sizeof(type
On 12/30/18, Nicolas George wrote:
> Uwe Freese (2018-12-29):
>> The downside is that the term "power" (or "strength") would be more
>> generic
>> and would probably be better reusable for other modes.
>>
>> What do you think? Is "exponent" now ok, or should I change it back to
>> "power", "streng
Helmut K. C. Tessarek (2018-12-30):
> > pow(sqrt(x * x * aspect2 + y * y), exponent / 2);
> There seems to be a mistake. You are taking the square root twice.
>
> Or am I missing something here?
Thanks, I wanted to remove the sqrt() and replace it with the /2, not
just add the /2.
Regards,
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2018-12-30 08:02, Nicolas George wrote:
>> +double d = pow(sqrt(x * x * aspect * aspect + y
>> * y), exponent);
> pow(sqrt(x * x * aspect2 + y * y), exponent / 2);
>
There seems to be a mistake. You are taking the square root t
Uwe Freese (2018-12-29):
> The downside is that the term "power" (or "strength") would be more generic
> and would probably be better reusable for other modes.
>
> What do you think? Is "exponent" now ok, or should I change it back to
> "power", "strength" or something alike?
I would say: do not
Hello,
here's a new version of the patch.
Changes since the last version of the patch (mail from 27.12. 13:00),
according the comments from Moritz and Carl Eugen:
- using av_assert0 instead of throwing an error if planes > MAX_PLANES
- using av_freep with the reference operator in uninit
- c
2018-12-27 22:02 GMT+01:00, Uwe Freese :
> Am 27.12.18 um 20:25 schrieb Carl Eugen Hoyos:
>>
>>> I have now added as error handling:
>>>
>>> av_log(inlink->src, AV_LOG_ERROR, "More planes in frame than
>>> expected.\n");
>>> return AVERROR(ENOMEM);
>>>
>>> Is this ok, or how should this be impleme
Hello,
Am 27.12.18 um 20:25 schrieb Carl Eugen Hoyos:
I have now added as error handling:
av_log(inlink->src, AV_LOG_ERROR, "More planes in frame than expected.\n");
return AVERROR(ENOMEM);
Is this ok, or how should this be implemented instead?
Not sure I understand: How can plane get >= MA
2018-12-27 13:00 GMT+01:00, Uwe Freese :
> > The "10" should be a #define, [...]
>
> I have now added as error handling:
>
> av_log(inlink->src, AV_LOG_ERROR, "More planes in frame than expected.\n");
> return AVERROR(ENOMEM);
>
> Is this ok, or how should this be implemented instead?
Not sure I
On Thu, Dec 27, 2018 at 13:00:29 +0100, Uwe Freese wrote:
These were just some remarks from me, still pending other, better
reviews.
> > The "10" should be a #define, [...]
>
> I have now added as error handling:
>
> av_log(inlink->src, AV_LOG_ERROR, "More planes in frame than expected.\n");
>
Hello,
thanks for the comments. Most points were clear and I've changed the
code accordingly (see attached new patch).
Here are the remaining questions / points to discuss:
You can start writing it now already, because it needs to go into
doc/filters.texi.
I've added the first version in t
Hello,
attached you can find a new patch, with no trailing spaces and avoiding
additional indentation in existing code.
Regards,
Uwe
Am 26.12.18 um 16:48 schrieb Uwe Freese:
Hello,
so now I've taken the time to integrate the alternative
interpolation algorithm 'uglarm' into the delogo filte
On Wed, Dec 26, 2018 at 15:23:58 +0100, Uwe Freese wrote:
Just some initial remarks (no full review):
> Can someone please review and add the code? Who would be primarily
> responsible to add this to libavfilter?
> ./ffmpeg -i "yourtestvideo.mkv" -map 0:v:0 -vframes 100 -filter_complex
> "crop
Uwe Freese (2018-12-26):
> Parts of the previous code are now in an "if" statement block (function
> apply_delogo), so indentation is correct. Even it would maybe be better to
> read the diff, it wouldn't be correctly indented.
>
> In the parameter lists, spaces are added to have the same layout o
Hello,
so now I've taken the time to integrate the alternative interpolation algorithm
'uglarm' into the delogo filter.
Please do not re-indent existing code in this patch as this makes reviewing the
changes more difficult
Parts of the previous code are now in an "if" statement block (functi
> Am 26.12.2018 um 15:23 schrieb Uwe Freese :
> so now I've taken the time to integrate the alternative interpolation
> algorithm 'uglarm' into the delogo filter.
Please do not re-indent existing code in this patch as this makes reviewing the
changes more difficult and please do not add trail
Hello,
so now I've taken the time to integrate the alternative interpolation
algorithm 'uglarm' into the delogo filter.
I took the code from ffdshow's logoaway, which took over the code from
LogoAway for VirtualDub, where I originally added it 2001. :)
I tested the code with several differe
25 matches
Mail list logo
