[FFmpeg-devel] [PATCH 2/2] avfilter/vf_gblur: remove unnecessary check
From: Zhao Zhili
---
libavfilter/vf_gblur.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavfilter/vf_gblur.c b/libavfilter/vf_gblur.c
index e057937fb7..0d7d5438d1 100644
--- a/libavfilter/vf_gblur.c
+++ b/libavfilter/vf_gblur.c
@@ -189,9 +189,6 @@ static void gaussianiir2d(AVFilterContext *ctx, int plane)
const int nb_threads = ff_filter_get_nb_threads(ctx);
ThreadData td;
-if (s->sigma <= 0 || s->steps < 0)
-return;
-
td.width = width;
td.height = height;
ctx->internal->execute(ctx, filter_horizontally, &td, NULL, FFMIN(height,
nb_threads));
@@ -301,7 +298,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
uint16_t *dst16 = (uint16_t *)out->data[plane];
int y, x;
-if (!s->sigma || !(s->planes & (1 << plane))) {
+if (!(s->planes & (1 << plane))) {
if (out != in)
av_image_copy_plane(out->data[plane], out->linesize[plane],
in->data[plane], in->linesize[plane],
--
2.22.0
___
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 1/2] avfilter/vf_gblur: fix divide by zero
From: Zhao Zhili
./ffmpeg -i ~/Pictures/test.jpg -vf 'gblur=sigma=0' -f null -
...
src/libavfilter/vf_gblur.c:260:59: runtime error: division by zero
src/libavfilter/vf_gblur.c:261:26: runtime error: division by zero
---
libavfilter/vf_gblur.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_gblur.c b/libavfilter/vf_gblur.c
index 2e587f6a0a..e057937fb7 100644
--- a/libavfilter/vf_gblur.c
+++ b/libavfilter/vf_gblur.c
@@ -37,11 +37,17 @@
#define OFFSET(x) offsetof(GBlurContext, x)
#define FLAGS
AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
+/* Consider the three-sigma rule, for minimum radius of 1 sigma should not
+ * be smaller than 1/3. Relax it to 0.25 if the user want to try.
+ */
+#define SIGMA_MIN 0.25
+#define SIGMA_MAX 1024.0
+
static const AVOption gblur_options[] = {
-{ "sigma", "set sigma",OFFSET(sigma), AV_OPT_TYPE_FLOAT,
{.dbl=0.5}, 0.0, 1024, FLAGS },
+{ "sigma", "set sigma",OFFSET(sigma), AV_OPT_TYPE_FLOAT,
{.dbl=0.5}, SIGMA_MIN, SIGMA_MAX, FLAGS },
{ "steps", "set number of steps", OFFSET(steps), AV_OPT_TYPE_INT,
{.i64=1}, 1,6, FLAGS },
{ "planes", "set planes to filter", OFFSET(planes), AV_OPT_TYPE_INT,
{.i64=0xF}, 0, 0xF, FLAGS },
-{ "sigmaV", "set vertical sigma", OFFSET(sigmaV), AV_OPT_TYPE_FLOAT,
{.dbl=-1}, -1, 1024, FLAGS },
+{ "sigmaV", "set vertical sigma", OFFSET(sigmaV), AV_OPT_TYPE_FLOAT,
{.dbl=-1}, -1, SIGMA_MAX, FLAGS },
{ NULL }
};
@@ -244,7 +250,7 @@ static int config_input(AVFilterLink *inlink)
if (!s->buffer)
return AVERROR(ENOMEM);
-if (s->sigmaV < 0) {
+if (s->sigmaV < SIGMA_MIN) {
s->sigmaV = s->sigma;
}
ff_gblur_init(s);
--
2.22.0
___
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] lavfi/buffersrc: Remove redundancy free after ff_filter_frame fail
Jun Zhao:
> From: Jun Zhao
>
> ff_filter_frame always free the frame in case of error, so we don't
> need to free the frame after ff_filter_frame fail.
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/buffersrc.c |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
> index 64940d9..bf30f54 100644
> --- a/libavfilter/buffersrc.c
> +++ b/libavfilter/buffersrc.c
> @@ -240,10 +240,8 @@ static int
> av_buffersrc_add_frame_internal(AVFilterContext *ctx,
> }
>
> ret = ff_filter_frame(ctx->outputs[0], copy);
> -if (ret < 0) {
> -av_frame_free(©);
> +if (ret < 0)
> return ret;
> -}
>
> if ((flags & AV_BUFFERSRC_FLAG_PUSH)) {
> ret = push_frame(ctx->graph);
>
Given that ff_filter_frame can't reset copy to NULL upon freeing it,
this actually fixes a double-free. Coverity just complained about this
(it's CID 1457230).
- Andreas
___
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 1/2] avfilter/vf_gblur: fix divide by zero
I do not like this "fix"
On 1/4/20, quinkbl...@foxmail.com wrote:
> From: Zhao Zhili
>
> ./ffmpeg -i ~/Pictures/test.jpg -vf 'gblur=sigma=0' -f null -
> ...
> src/libavfilter/vf_gblur.c:260:59: runtime error: division by zero
> src/libavfilter/vf_gblur.c:261:26: runtime error: division by zero
> ---
> libavfilter/vf_gblur.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_gblur.c b/libavfilter/vf_gblur.c
> index 2e587f6a0a..e057937fb7 100644
> --- a/libavfilter/vf_gblur.c
> +++ b/libavfilter/vf_gblur.c
> @@ -37,11 +37,17 @@
> #define OFFSET(x) offsetof(GBlurContext, x)
> #define FLAGS
> AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
>
> +/* Consider the three-sigma rule, for minimum radius of 1 sigma should not
> + * be smaller than 1/3. Relax it to 0.25 if the user want to try.
> + */
> +#define SIGMA_MIN 0.25
> +#define SIGMA_MAX 1024.0
> +
> static const AVOption gblur_options[] = {
> -{ "sigma", "set sigma",OFFSET(sigma), AV_OPT_TYPE_FLOAT,
> {.dbl=0.5}, 0.0, 1024, FLAGS },
> +{ "sigma", "set sigma",OFFSET(sigma), AV_OPT_TYPE_FLOAT,
> {.dbl=0.5}, SIGMA_MIN, SIGMA_MAX, FLAGS },
> { "steps", "set number of steps", OFFSET(steps), AV_OPT_TYPE_INT,
> {.i64=1}, 1,6, FLAGS },
> { "planes", "set planes to filter", OFFSET(planes), AV_OPT_TYPE_INT,
> {.i64=0xF}, 0, 0xF, FLAGS },
> -{ "sigmaV", "set vertical sigma", OFFSET(sigmaV), AV_OPT_TYPE_FLOAT,
> {.dbl=-1}, -1, 1024, FLAGS },
> +{ "sigmaV", "set vertical sigma", OFFSET(sigmaV), AV_OPT_TYPE_FLOAT,
> {.dbl=-1}, -1, SIGMA_MAX, FLAGS },
> { NULL }
> };
>
> @@ -244,7 +250,7 @@ static int config_input(AVFilterLink *inlink)
> if (!s->buffer)
> return AVERROR(ENOMEM);
>
> -if (s->sigmaV < 0) {
> +if (s->sigmaV < SIGMA_MIN) {
> s->sigmaV = s->sigma;
> }
> ff_gblur_init(s);
> --
> 2.22.0
>
> ___
> 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".
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_gblur: remove unnecessary check
Invalid, sigma can be 0.
On 1/4/20, quinkbl...@foxmail.com wrote:
> From: Zhao Zhili
>
> ---
> libavfilter/vf_gblur.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/libavfilter/vf_gblur.c b/libavfilter/vf_gblur.c
> index e057937fb7..0d7d5438d1 100644
> --- a/libavfilter/vf_gblur.c
> +++ b/libavfilter/vf_gblur.c
> @@ -189,9 +189,6 @@ static void gaussianiir2d(AVFilterContext *ctx, int
> plane)
> const int nb_threads = ff_filter_get_nb_threads(ctx);
> ThreadData td;
>
> -if (s->sigma <= 0 || s->steps < 0)
> -return;
> -
> td.width = width;
> td.height = height;
> ctx->internal->execute(ctx, filter_horizontally, &td, NULL,
> FFMIN(height, nb_threads));
> @@ -301,7 +298,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> uint16_t *dst16 = (uint16_t *)out->data[plane];
> int y, x;
>
> -if (!s->sigma || !(s->planes & (1 << plane))) {
> +if (!(s->planes & (1 << plane))) {
> if (out != in)
> av_image_copy_plane(out->data[plane], out->linesize[plane],
> in->data[plane], in->linesize[plane],
> --
> 2.22.0
>
>
>
> ___
> 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".
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_gblur: fix divide by zero
> On Jan 4, 2020, at 7:04 PM, Paul B Mahol wrote:
>
> I do not like this “fix"
What do you suggest? It’s numerical unstable for small sigma.
>
> On 1/4/20, quinkbl...@foxmail.com wrote:
>> From: Zhao Zhili
>>
>> ./ffmpeg -i ~/Pictures/test.jpg -vf 'gblur=sigma=0' -f null -
>> ...
>> src/libavfilter/vf_gblur.c:260:59: runtime error: division by zero
>> src/libavfilter/vf_gblur.c:261:26: runtime error: division by zero
>> ---
>> libavfilter/vf_gblur.c | 12 +---
>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavfilter/vf_gblur.c b/libavfilter/vf_gblur.c
>> index 2e587f6a0a..e057937fb7 100644
>> --- a/libavfilter/vf_gblur.c
>> +++ b/libavfilter/vf_gblur.c
>> @@ -37,11 +37,17 @@
>> #define OFFSET(x) offsetof(GBlurContext, x)
>> #define FLAGS
>> AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
>>
>> +/* Consider the three-sigma rule, for minimum radius of 1 sigma should not
>> + * be smaller than 1/3. Relax it to 0.25 if the user want to try.
>> + */
>> +#define SIGMA_MIN 0.25
>> +#define SIGMA_MAX 1024.0
>> +
>> static const AVOption gblur_options[] = {
>> -{ "sigma", "set sigma",OFFSET(sigma), AV_OPT_TYPE_FLOAT,
>> {.dbl=0.5}, 0.0, 1024, FLAGS },
>> +{ "sigma", "set sigma",OFFSET(sigma), AV_OPT_TYPE_FLOAT,
>> {.dbl=0.5}, SIGMA_MIN, SIGMA_MAX, FLAGS },
>> { "steps", "set number of steps", OFFSET(steps), AV_OPT_TYPE_INT,
>> {.i64=1}, 1,6, FLAGS },
>> { "planes", "set planes to filter", OFFSET(planes), AV_OPT_TYPE_INT,
>> {.i64=0xF}, 0, 0xF, FLAGS },
>> -{ "sigmaV", "set vertical sigma", OFFSET(sigmaV), AV_OPT_TYPE_FLOAT,
>> {.dbl=-1}, -1, 1024, FLAGS },
>> +{ "sigmaV", "set vertical sigma", OFFSET(sigmaV), AV_OPT_TYPE_FLOAT,
>> {.dbl=-1}, -1, SIGMA_MAX, FLAGS },
>> { NULL }
>> };
>>
>> @@ -244,7 +250,7 @@ static int config_input(AVFilterLink *inlink)
>> if (!s->buffer)
>> return AVERROR(ENOMEM);
>>
>> -if (s->sigmaV < 0) {
>> +if (s->sigmaV < SIGMA_MIN) {
>> s->sigmaV = s->sigma;
>> }
>> ff_gblur_init(s);
>> --
>> 2.22.0
>>
>> ___
>> 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".
Re: [FFmpeg-devel] [PATCH V1] lavfi/buffersrc: Remove redundancy free after ff_filter_frame fail
LGTM
On 1/1/20, Jun Zhao wrote:
> From: Jun Zhao
>
> ff_filter_frame always free the frame in case of error, so we don't
> need to free the frame after ff_filter_frame fail.
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/buffersrc.c |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
> index 64940d9..bf30f54 100644
> --- a/libavfilter/buffersrc.c
> +++ b/libavfilter/buffersrc.c
> @@ -240,10 +240,8 @@ static int
> av_buffersrc_add_frame_internal(AVFilterContext *ctx,
> }
>
> ret = ff_filter_frame(ctx->outputs[0], copy);
> -if (ret < 0) {
> -av_frame_free(©);
> +if (ret < 0)
> return ret;
> -}
>
> if ((flags & AV_BUFFERSRC_FLAG_PUSH)) {
> ret = push_frame(ctx->graph);
> --
> 1.7.1
>
> ___
> 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".
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_gblur: fix divide by zero
On 1/4/20, zhilizhao wrote:
>
>
>> On Jan 4, 2020, at 7:04 PM, Paul B Mahol wrote:
>>
>> I do not like this “fix"
>
> What do you suggest? It’s numerical unstable for small sigma.
For small sigma return frames unchanged as it currently does.
>
>>
>> On 1/4/20, quinkbl...@foxmail.com wrote:
>>> From: Zhao Zhili
>>>
>>> ./ffmpeg -i ~/Pictures/test.jpg -vf 'gblur=sigma=0' -f null -
>>> ...
>>> src/libavfilter/vf_gblur.c:260:59: runtime error: division by zero
>>> src/libavfilter/vf_gblur.c:261:26: runtime error: division by zero
>>> ---
>>> libavfilter/vf_gblur.c | 12 +---
>>> 1 file changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/libavfilter/vf_gblur.c b/libavfilter/vf_gblur.c
>>> index 2e587f6a0a..e057937fb7 100644
>>> --- a/libavfilter/vf_gblur.c
>>> +++ b/libavfilter/vf_gblur.c
>>> @@ -37,11 +37,17 @@
>>> #define OFFSET(x) offsetof(GBlurContext, x)
>>> #define FLAGS
>>> AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
>>>
>>> +/* Consider the three-sigma rule, for minimum radius of 1 sigma should
>>> not
>>> + * be smaller than 1/3. Relax it to 0.25 if the user want to try.
>>> + */
>>> +#define SIGMA_MIN 0.25
>>> +#define SIGMA_MAX 1024.0
>>> +
>>> static const AVOption gblur_options[] = {
>>> -{ "sigma", "set sigma",OFFSET(sigma),
>>> AV_OPT_TYPE_FLOAT,
>>> {.dbl=0.5}, 0.0, 1024, FLAGS },
>>> +{ "sigma", "set sigma",OFFSET(sigma),
>>> AV_OPT_TYPE_FLOAT,
>>> {.dbl=0.5}, SIGMA_MIN, SIGMA_MAX, FLAGS },
>>> { "steps", "set number of steps", OFFSET(steps), AV_OPT_TYPE_INT,
>>> {.i64=1}, 1,6, FLAGS },
>>> { "planes", "set planes to filter", OFFSET(planes), AV_OPT_TYPE_INT,
>>> {.i64=0xF}, 0, 0xF, FLAGS },
>>> -{ "sigmaV", "set vertical sigma", OFFSET(sigmaV),
>>> AV_OPT_TYPE_FLOAT,
>>> {.dbl=-1}, -1, 1024, FLAGS },
>>> +{ "sigmaV", "set vertical sigma", OFFSET(sigmaV),
>>> AV_OPT_TYPE_FLOAT,
>>> {.dbl=-1}, -1, SIGMA_MAX, FLAGS },
>>> { NULL }
>>> };
>>>
>>> @@ -244,7 +250,7 @@ static int config_input(AVFilterLink *inlink)
>>> if (!s->buffer)
>>> return AVERROR(ENOMEM);
>>>
>>> -if (s->sigmaV < 0) {
>>> +if (s->sigmaV < SIGMA_MIN) {
>>> s->sigmaV = s->sigma;
>>> }
>>> ff_gblur_init(s);
>>> --
>>> 2.22.0
>>>
>>> ___
>>> 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 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] Workaround to build ffmpeg on MacOs 10.15
On Sat, Jan 04, 2020 at 12:06:55AM +0100, Henrik Gramner wrote: > On Fri, Jan 3, 2020 at 7:37 PM Moritz Barsnick wrote: > > On Fri, Jan 03, 2020 at 11:05:25 +0100, Timo Rothenpieler wrote: > > > I think this was discussed on this list in the past. > > > Not sure what the conclusion was, but I think an unconditional flag like > > > this being added wasn't all that well received. > > > > Yes, discussed in this thread in November: > > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253193.html > > Lmao "security feature". Just disable that flag and call it a day, it > adds nothing of value (unless you consider crashing to be a "security > feature"?). I dont know how effective this is or what exactly this option does, i couldnt find documentation for it quickly what it does in clang on macosx. google keeps pointing to gcc but a crash is better than arbitrary code execution, which IIUC is the idea here, if the stack of a thread grows too much, crash instead of overwriting something that comes after it. Not crashing when the stack overlapps another threads stack or heap is unlikely to be better. That said, thats when things work, IIUC theres some kind of bug in the apple compiler. If that is true the workaround of disablng the flag should only be enabled when a affected compiler is used Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: PGP signature ___ 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 1/2] avfilter/vf_gblur: fix divide by zero
> On Jan 4, 2020, at 9:09 PM, Paul B Mahol wrote:
>
> On 1/4/20, zhilizhao wrote:
>>
>>
>>> On Jan 4, 2020, at 7:04 PM, Paul B Mahol wrote:
>>>
>>> I do not like this “fix"
>>
>> What do you suggest? It’s numerical unstable for small sigma.
>
> For small sigma return frames unchanged as it currently does.
Then which valud should be selected as the threshold:
1. A value from which it becomes unstable (it’s not fun to figure it out).
2. A reasonable (and random) selected value like 0.25
>
>>
>>>
>>> On 1/4/20, quinkbl...@foxmail.com wrote:
From: Zhao Zhili
./ffmpeg -i ~/Pictures/test.jpg -vf 'gblur=sigma=0' -f null -
...
src/libavfilter/vf_gblur.c:260:59: runtime error: division by zero
src/libavfilter/vf_gblur.c:261:26: runtime error: division by zero
---
libavfilter/vf_gblur.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_gblur.c b/libavfilter/vf_gblur.c
index 2e587f6a0a..e057937fb7 100644
--- a/libavfilter/vf_gblur.c
+++ b/libavfilter/vf_gblur.c
@@ -37,11 +37,17 @@
#define OFFSET(x) offsetof(GBlurContext, x)
#define FLAGS
AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
+/* Consider the three-sigma rule, for minimum radius of 1 sigma should
not
+ * be smaller than 1/3. Relax it to 0.25 if the user want to try.
+ */
+#define SIGMA_MIN 0.25
+#define SIGMA_MAX 1024.0
+
static const AVOption gblur_options[] = {
-{ "sigma", "set sigma",OFFSET(sigma),
AV_OPT_TYPE_FLOAT,
{.dbl=0.5}, 0.0, 1024, FLAGS },
+{ "sigma", "set sigma",OFFSET(sigma),
AV_OPT_TYPE_FLOAT,
{.dbl=0.5}, SIGMA_MIN, SIGMA_MAX, FLAGS },
{ "steps", "set number of steps", OFFSET(steps), AV_OPT_TYPE_INT,
{.i64=1}, 1,6, FLAGS },
{ "planes", "set planes to filter", OFFSET(planes), AV_OPT_TYPE_INT,
{.i64=0xF}, 0, 0xF, FLAGS },
-{ "sigmaV", "set vertical sigma", OFFSET(sigmaV),
AV_OPT_TYPE_FLOAT,
{.dbl=-1}, -1, 1024, FLAGS },
+{ "sigmaV", "set vertical sigma", OFFSET(sigmaV),
AV_OPT_TYPE_FLOAT,
{.dbl=-1}, -1, SIGMA_MAX, FLAGS },
{ NULL }
};
@@ -244,7 +250,7 @@ static int config_input(AVFilterLink *inlink)
if (!s->buffer)
return AVERROR(ENOMEM);
-if (s->sigmaV < 0) {
+if (s->sigmaV < SIGMA_MIN) {
s->sigmaV = s->sigma;
}
ff_gblur_init(s);
--
2.22.0
___
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 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".
Re: [FFmpeg-devel] [PATCH] Workaround to build ffmpeg on MacOs 10.15
On 04.01.2020 14:37, Michael Niedermayer wrote: I dont know how effective this is or what exactly this option does, i couldnt find documentation for it quickly what it does in clang on macosx. google keeps pointing to gcc but a crash is better than arbitrary code execution, which IIUC is the idea here, if the stack of a thread grows too much, crash instead of overwriting something that comes after it. Not crashing when the stack overlapps another threads stack or heap is unlikely to be better. That said, thats when things work, IIUC theres some kind of bug in the apple compiler. If that is true the workaround of disablng the flag should only be enabled when a affected compiler is used This seems to be a known bug for quite a while now, why did it not get fixed in the compiler yet? ___ 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] Workaround to build ffmpeg on MacOs 10.15
On Sat, Jan 4, 2020 at 3:27 PM Timo Rothenpieler wrote: > > On 04.01.2020 14:37, Michael Niedermayer wrote: > > I dont know how effective this is or what exactly this option does, i > > couldnt find documentation for it quickly what it does in clang on macosx. > > google keeps pointing to gcc > > but > > > > a crash is better than arbitrary code execution, which IIUC is the idea > > here, if the stack of a thread grows too much, crash instead of overwriting > > something that comes after it. > > Not crashing when the stack overlapps another threads stack or heap is > > unlikely to be better. > > > > That said, thats when things work, IIUC theres some kind of bug in the > > apple compiler. > > If that is true the workaround of disablng the flag should only be > > enabled when a affected compiler is used > > This seems to be a known bug for quite a while now, why did it not get > fixed in the compiler yet? Because it doesn't affect Apple themselves, and reaction time to external bug reports is in months at best. - Hendrik ___ 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] avformat/image2: Upon request, make available extra metadata, fields related to input path to be used by filters.
Hi there! I'm just writing to make sure this patch wasn't forgotten. :)
Best wishes to you all!
Alex.
On 01/01/2020 17:17, Alexandre Heitor Schmidt wrote:
The patch follows attached, to avoid formatting issues. The
commit message is as follows:
avformat/image2: Upon request, make available extra metadata
fields related to input path to be used by filters.
libavformat/img2.h: New field export_path_metadata to
VideoDemuxData to only allow the use of the extra metadata
upon explicit user request, for security reasons.
libavformat/img2dec.c: Modify image2 demuxer to make available
two special metadata entries called lavf.image2dec.source_path
and lavf.image2dec.source_basename, which represents, respectively,
the complete path to the source image for the current frame and
the basename i.e. the file name related to the current frame.
These can then be used by filters like drawtext and others. The
metadata fields will only be available when explicitly enabled
with image2 option -export_path_metadata 1.
doc/demuxers.texi: Documented the new metadata fields available
for image2 and how to use them.
doc/filters.texi: Added an example on how to use the new metadata
fields with drawtext filter, in order to plot the input file path
to each output frame.
Usage example:
ffmpeg -f image2 -export_path_metadata 1 -pattern_type glob
-framerate 18 -i '/path/to/input/files/*.jpg'
-filter_complex drawtext="fontsize=40:fontcolor=white:
fontfile=FreeSans.ttf:borderw=2:bordercolor=black:
text='%{metadata\:lavf.image2dec.source_basename\:NA}':x=5:y=50"
output.avi
Fixes #2874.
Signed-off-by: Alexandre Heitor Schmidt
___
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] lavc/ffv1: Properly check that the 4th and 5th quant tables are zeroes
On 03/01/2020 21:59, Derek Buitenhuis wrote: > Is this guaranteed somehow? It isn't mentioned in the spec. Looks like it's inherent to how it's stored. I'll send a v2 with this. Thanks, - Derek ___ 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] avcodec/bsf: replace ctx->internal-> with bsfi-> for better readability
ping?
On Mon, Dec 16, 2019 at 01:01:49PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/bsf.c | 49 +++--
> 1 file changed, 27 insertions(+), 22 deletions(-)
>
> diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
> index c1653cd..c6dce93 100644
> --- a/libavcodec/bsf.c
> +++ b/libavcodec/bsf.c
> @@ -82,6 +82,7 @@ const AVClass *av_bsf_get_class(void)
> int av_bsf_alloc(const AVBitStreamFilter *filter, AVBSFContext **pctx)
> {
> AVBSFContext *ctx;
> +AVBSFInternal *bsfi;
> int ret;
>
> ctx = av_mallocz(sizeof(*ctx));
> @@ -98,14 +99,15 @@ int av_bsf_alloc(const AVBitStreamFilter *filter,
> AVBSFContext **pctx)
> goto fail;
> }
>
> -ctx->internal = av_mallocz(sizeof(*ctx->internal));
> -if (!ctx->internal) {
> +bsfi = av_mallocz(sizeof(*bsfi));
> +if (!bsfi) {
> ret = AVERROR(ENOMEM);
> goto fail;
> }
> +ctx->internal = bsfi;
>
> -ctx->internal->buffer_pkt = av_packet_alloc();
> -if (!ctx->internal->buffer_pkt) {
> +bsfi->buffer_pkt = av_packet_alloc();
> +if (!bsfi->buffer_pkt) {
> ret = AVERROR(ENOMEM);
> goto fail;
> }
> @@ -175,9 +177,11 @@ int av_bsf_init(AVBSFContext *ctx)
>
> void av_bsf_flush(AVBSFContext *ctx)
> {
> -ctx->internal->eof = 0;
> +AVBSFInternal *bsfi = ctx->internal;
>
> -av_packet_unref(ctx->internal->buffer_pkt);
> +bsfi->eof = 0;
> +
> +av_packet_unref(bsfi->buffer_pkt);
>
> if (ctx->filter->flush)
> ctx->filter->flush(ctx);
> @@ -185,26 +189,27 @@ void av_bsf_flush(AVBSFContext *ctx)
>
> int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt)
> {
> +AVBSFInternal *bsfi = ctx->internal;
> int ret;
>
> if (!pkt || (!pkt->data && !pkt->side_data_elems)) {
> -ctx->internal->eof = 1;
> +bsfi->eof = 1;
> return 0;
> }
>
> -if (ctx->internal->eof) {
> +if (bsfi->eof) {
> av_log(ctx, AV_LOG_ERROR, "A non-NULL packet sent after an EOF.\n");
> return AVERROR(EINVAL);
> }
>
> -if (ctx->internal->buffer_pkt->data ||
> -ctx->internal->buffer_pkt->side_data_elems)
> +if (bsfi->buffer_pkt->data ||
> +bsfi->buffer_pkt->side_data_elems)
> return AVERROR(EAGAIN);
>
> ret = av_packet_make_refcounted(pkt);
> if (ret < 0)
> return ret;
> -av_packet_move_ref(ctx->internal->buffer_pkt, pkt);
> +av_packet_move_ref(bsfi->buffer_pkt, pkt);
>
> return 0;
> }
> @@ -216,38 +221,38 @@ int av_bsf_receive_packet(AVBSFContext *ctx, AVPacket
> *pkt)
>
> int ff_bsf_get_packet(AVBSFContext *ctx, AVPacket **pkt)
> {
> -AVBSFInternal *in = ctx->internal;
> +AVBSFInternal *bsfi = ctx->internal;
> AVPacket *tmp_pkt;
>
> -if (in->eof)
> +if (bsfi->eof)
> return AVERROR_EOF;
>
> -if (!ctx->internal->buffer_pkt->data &&
> -!ctx->internal->buffer_pkt->side_data_elems)
> +if (!bsfi->buffer_pkt->data &&
> +!bsfi->buffer_pkt->side_data_elems)
> return AVERROR(EAGAIN);
>
> tmp_pkt = av_packet_alloc();
> if (!tmp_pkt)
> return AVERROR(ENOMEM);
>
> -*pkt = ctx->internal->buffer_pkt;
> -ctx->internal->buffer_pkt = tmp_pkt;
> +*pkt = bsfi->buffer_pkt;
> +bsfi->buffer_pkt = tmp_pkt;
>
> return 0;
> }
>
> int ff_bsf_get_packet_ref(AVBSFContext *ctx, AVPacket *pkt)
> {
> -AVBSFInternal *in = ctx->internal;
> +AVBSFInternal *bsfi = ctx->internal;
>
> -if (in->eof)
> +if (bsfi->eof)
> return AVERROR_EOF;
>
> -if (!ctx->internal->buffer_pkt->data &&
> -!ctx->internal->buffer_pkt->side_data_elems)
> +if (!bsfi->buffer_pkt->data &&
> +!bsfi->buffer_pkt->side_data_elems)
> return AVERROR(EAGAIN);
>
> -av_packet_move_ref(pkt, ctx->internal->buffer_pkt);
> +av_packet_move_ref(pkt, bsfi->buffer_pkt);
>
> return 0;
> }
> --
> 2.9.5
>
--
Thanks,
Limin Wang
___
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] Workaround to build ffmpeg on MacOs 10.15
On Sat, Jan 04, 2020 at 03:35:42PM +0100, Hendrik Leppkes wrote: > On Sat, Jan 4, 2020 at 3:27 PM Timo Rothenpieler > wrote: > > > > On 04.01.2020 14:37, Michael Niedermayer wrote: > > > I dont know how effective this is or what exactly this option does, i > > > couldnt find documentation for it quickly what it does in clang on macosx. > > > google keeps pointing to gcc > > > but > > > > > > a crash is better than arbitrary code execution, which IIUC is the idea > > > here, if the stack of a thread grows too much, crash instead of > > > overwriting > > > something that comes after it. > > > Not crashing when the stack overlapps another threads stack or heap is > > > unlikely to be better. > > > > > > That said, thats when things work, IIUC theres some kind of bug in the > > > apple compiler. > > > If that is true the workaround of disablng the flag should only be > > > enabled when a affected compiler is used > > > > This seems to be a known bug for quite a while now, why did it not get > > fixed in the compiler yet? > > Because it doesn't affect Apple themselves, and reaction time to > external bug reports is in months at best. https://trac.macports.org/ticket/58776 > > - Hendrik > ___ > 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". -- Thanks, Limin Wang ___ 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] [aarch64] improve performance of ff_yuv2planeX_8_neon
On Tue, Dec 10, 2019 at 04:38:25PM -0600, Sebastian Pop wrote: > Hi, > > This patch rewrites the innermost loop of ff_yuv2planeX_8_neon to avoid zips > and > horizontal adds by using fused multiply adds. The patch also uses ld1r to load > one element and replicate it across all lanes of the vector. The patch also > improves the clipping code by removing the shift right instructions and > performing the shift with the shift-right narrow instructions. > > I see 8% better performance on an m6g instance with neoverse-n1 CPUs: > $ ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf > bench=start,scale=1024x1024,bench=stop -f null - > before: t:0.014015 avg:0.014096 max:0.015018 min:0.013971 > after: t:0.012985 avg:0.013013 max:0.013996 min:0.012818 > > Tested with `make check` on aarch64-linux. > > Please let me know how I can improve the patch. > Looks nice. I can't test currently but LGTM. If you're still looking for room of improvement, maybe it makes sense to increase the filterAlign for NEON and process more at once (seems to be set at 2 currently for the vertical filter): const int filterAlign = X86_MMX(cpu_flags) ? 2 : PPC_ALTIVEC(cpu_flags) ? 8 : have_neon(cpu_flags) ? 2 : 1; I can't tell if it would open room for improvement, but might be something to experiment with eventually. Thanks for your work, sorry for the delay, and happy new year. -- Clément B. ___ 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] lavfi/buffersrc: Remove redundancy free after ff_filter_frame fail
Jun Zhao (12020-01-01): > From: Jun Zhao > > ff_filter_frame always free the frame in case of error, so we don't > need to free the frame after ff_filter_frame fail. > > Signed-off-by: Jun Zhao > --- > libavfilter/buffersrc.c |4 +--- > 1 files changed, 1 insertions(+), 3 deletions(-) Thanks for the fix. Pushed with a few amendments to the commit message. Regards, -- Nicolas George signature.asc Description: PGP signature ___ 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] lavu/buffer: forward av_buffer_realloc() error code.
Fix CID 1457235.
Signed-off-by: Nicolas George
---
libavutil/buffer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 6d9cb7428e..2f33e5ebb6 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -171,6 +171,7 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
{
AVBufferRef *buf = *pbuf;
uint8_t *tmp;
+int ret;
if (!buf) {
/* allocate a new buffer with av_realloc(), so it will be reallocatable
@@ -197,9 +198,9 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
/* cannot realloc, allocate a new reallocable buffer and copy data */
AVBufferRef *new = NULL;
-av_buffer_realloc(&new, size);
+ret = av_buffer_realloc(&new, size);
if (!new)
-return AVERROR(ENOMEM);
+return ret;
memcpy(new->data, buf->data, FFMIN(size, buf->size));
--
2.24.1
___
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] lavc/avpacket: forward av_buffer_realloc() error code.
Fix CID 1457229.
Signed-off-by: Nicolas George
---
libavcodec/avpacket.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 858f827a0a..4da832c53c 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -170,7 +170,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
#define ALLOC_MALLOC(data, size) data = av_malloc(size)
#define ALLOC_BUF(data, size)\
do { \
-av_buffer_realloc(&pkt->buf, size); \
+ret = av_buffer_realloc(&pkt->buf, size); \
data = pkt->buf ? pkt->buf->data : NULL; \
} while (0)
@@ -197,6 +197,8 @@ do { \
/* Makes duplicates of data, side_data, but does not copy any other fields */
static int copy_packet_data(AVPacket *pkt, const AVPacket *src, int dup)
{
+int ret = AVERROR_BUG;
+
pkt->data = NULL;
pkt->side_data = NULL;
pkt->side_data_elems = 0;
@@ -220,7 +222,8 @@ static int copy_packet_data(AVPacket *pkt, const AVPacket
*src, int dup)
failed_alloc:
av_packet_unref(pkt);
-return AVERROR(ENOMEM);
+av_assert1(ret != AVERROR_BUG);
+return ret;
}
int av_copy_packet_side_data(AVPacket *pkt, const AVPacket *src)
--
2.24.1
___
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] lavu/buffer: forward av_buffer_realloc() error code.
On 1/4/20, Nicolas George wrote:
> Fix CID 1457235.
>
> Signed-off-by: Nicolas George
> ---
> libavutil/buffer.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/buffer.c b/libavutil/buffer.c
> index 6d9cb7428e..2f33e5ebb6 100644
> --- a/libavutil/buffer.c
> +++ b/libavutil/buffer.c
> @@ -171,6 +171,7 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
> {
> AVBufferRef *buf = *pbuf;
> uint8_t *tmp;
> +int ret;
>
> if (!buf) {
> /* allocate a new buffer with av_realloc(), so it will be
> reallocatable
> @@ -197,9 +198,9 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
> /* cannot realloc, allocate a new reallocable buffer and copy data
> */
> AVBufferRef *new = NULL;
>
> -av_buffer_realloc(&new, size);
> +ret = av_buffer_realloc(&new, size);
> if (!new)
> -return AVERROR(ENOMEM);
> +return ret;
>
> memcpy(new->data, buf->data, FFMIN(size, buf->size));
>
> --
> 2.24.1
>
OK
> ___
> 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".
Re: [FFmpeg-devel] [PATCH] lavu/buffer: forward av_buffer_realloc() error code.
Nicolas George:
> Fix CID 1457235.
>
> Signed-off-by: Nicolas George
> ---
> libavutil/buffer.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/buffer.c b/libavutil/buffer.c
> index 6d9cb7428e..2f33e5ebb6 100644
> --- a/libavutil/buffer.c
> +++ b/libavutil/buffer.c
> @@ -171,6 +171,7 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
> {
> AVBufferRef *buf = *pbuf;
> uint8_t *tmp;
> +int ret;
>
> if (!buf) {
> /* allocate a new buffer with av_realloc(), so it will be
> reallocatable
> @@ -197,9 +198,9 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
> /* cannot realloc, allocate a new reallocable buffer and copy data */
> AVBufferRef *new = NULL;
>
> -av_buffer_realloc(&new, size);
> +ret = av_buffer_realloc(&new, size);
> if (!new)
Shouldn't you check for (ret < 0) instead of (!new)? I am unsure
whether Coverity will really count this as a fix.
- Andreas
> -return AVERROR(ENOMEM);
> +return ret;
>
> memcpy(new->data, buf->data, FFMIN(size, buf->size));
>
>
___
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] lavu/buffer: forward av_buffer_realloc() error code.
Andreas Rheinhardt (12020-01-04):
> Shouldn't you check for (ret < 0) instead of (!new)? I am unsure
> whether Coverity will really count this as a fix.
I hesitated and went for the minimalist patch. New version.
Regards,
--
Nicolas George
From 8ef49a7c86e108ed9e6981d482ae892e6f62c0f5 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Sat, 4 Jan 2020 19:52:08 +0100
Subject: [PATCH 1/2] lavu/buffer: forward av_buffer_realloc() error code.
Fix CID 1457235.
Signed-off-by: Nicolas George
---
libavutil/buffer.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavutil/buffer.c b/libavutil/buffer.c
index 6d9cb7428e..d9552e3b24 100644
--- a/libavutil/buffer.c
+++ b/libavutil/buffer.c
@@ -171,6 +171,7 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
{
AVBufferRef *buf = *pbuf;
uint8_t *tmp;
+int ret;
if (!buf) {
/* allocate a new buffer with av_realloc(), so it will be reallocatable
@@ -197,9 +198,9 @@ int av_buffer_realloc(AVBufferRef **pbuf, int size)
/* cannot realloc, allocate a new reallocable buffer and copy data */
AVBufferRef *new = NULL;
-av_buffer_realloc(&new, size);
-if (!new)
-return AVERROR(ENOMEM);
+ret = av_buffer_realloc(&new, size);
+if (ret < 0)
+return ret;
memcpy(new->data, buf->data, FFMIN(size, buf->size));
--
2.24.1
signature.asc
Description: PGP signature
___
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] lavc/avpacket: forward av_buffer_realloc() error code.
Nicolas George:
> Fix CID 1457229.
>
> Signed-off-by: Nicolas George
> ---
> libavcodec/avpacket.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index 858f827a0a..4da832c53c 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -170,7 +170,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
> #define ALLOC_MALLOC(data, size) data = av_malloc(size)
> #define ALLOC_BUF(data, size)\
> do { \
> -av_buffer_realloc(&pkt->buf, size); \
> +ret = av_buffer_realloc(&pkt->buf, size); \
You do not change the check, so the same comment as to your other
patch applies: Do you think that Coverity will think that this is a
real check? (I don't think so, otherwise it wouldn't have raised the
issue in the first place.)
> data = pkt->buf ? pkt->buf->data : NULL; \
> } while (0)
>
> @@ -197,6 +197,8 @@ do { \
> /* Makes duplicates of data, side_data, but does not copy any other fields */
> static int copy_packet_data(AVPacket *pkt, const AVPacket *src, int dup)
> {
> +int ret = AVERROR_BUG;
> +
> pkt->data = NULL;
> pkt->side_data = NULL;
> pkt->side_data_elems = 0;
> @@ -220,7 +222,8 @@ static int copy_packet_data(AVPacket *pkt, const AVPacket
> *src, int dup)
>
> failed_alloc:
> av_packet_unref(pkt);
> -return AVERROR(ENOMEM);
> +av_assert1(ret != AVERROR_BUG);
There is an overflow check that could also trigger going to
failed_alloc. The overflow check is very weird: It is only triggered
if pkt->size is in the range -AV_INPUT_BUFFER_PADDING_SIZE..-1 and so
doesn't do its job (should be replaced by (unsigned)(size) > INT_MAX -
AV_INPUT_BUFFER_PADDING_SIZE). But if it were fixed, one could run
into this assert. How about initializing ret to 0 and setting ret to
AVERROR(ERANGE) if it is still zero in failed_alloc?
- Andreas
> +return ret;
> }
>
> int av_copy_packet_side_data(AVPacket *pkt, const AVPacket *src)
>
___
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] Workaround to build ffmpeg on MacOs 10.15
On Sat, 4 Jan 2020, Michael Niedermayer wrote: On Sat, Jan 04, 2020 at 12:06:55AM +0100, Henrik Gramner wrote: On Fri, Jan 3, 2020 at 7:37 PM Moritz Barsnick wrote: On Fri, Jan 03, 2020 at 11:05:25 +0100, Timo Rothenpieler wrote: I think this was discussed on this list in the past. Not sure what the conclusion was, but I think an unconditional flag like this being added wasn't all that well received. Yes, discussed in this thread in November: http://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253193.html Lmao "security feature". Just disable that flag and call it a day, it adds nothing of value (unless you consider crashing to be a "security feature"?). I dont know how effective this is or what exactly this option does, i couldnt find documentation for it quickly what it does in clang on macosx. google keeps pointing to gcc but a crash is better than arbitrary code execution, which IIUC is the idea here, if the stack of a thread grows too much, crash instead of overwriting something that comes after it. Not crashing when the stack overlapps another threads stack or heap is unlikely to be better. The point here is, disabling this "feature" is not a security regression - it's a new feature in apple's clang, which only is enabled when you target a new enough version of macOS. And that new security feature is broken to the point that the process crashes before you even get to code which may be misbehaving. So disabling it isn't a regression, it just takes things back to how things were before, before this was introduced. // Martin ___ 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] avcodec/bsf: replace ctx->internal-> with bsfi-> for better readability
On Mon, Dec 16, 2019 at 01:01:49PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavcodec/bsf.c | 49 +++-- > 1 file changed, 27 insertions(+), 22 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ 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] [aarch64] improve performance of ff_yuv2planeX_8_neon
On Sat, Jan 04, 2020 at 05:53:34PM +0100, Clément Bœsch wrote: > On Tue, Dec 10, 2019 at 04:38:25PM -0600, Sebastian Pop wrote: > > Hi, > > > > This patch rewrites the innermost loop of ff_yuv2planeX_8_neon to avoid > > zips and > > horizontal adds by using fused multiply adds. The patch also uses ld1r to > > load > > one element and replicate it across all lanes of the vector. The patch also > > improves the clipping code by removing the shift right instructions and > > performing the shift with the shift-right narrow instructions. > > > > I see 8% better performance on an m6g instance with neoverse-n1 CPUs: > > $ ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf > > bench=start,scale=1024x1024,bench=stop -f null - > > before: t:0.014015 avg:0.014096 max:0.015018 min:0.013971 > > after: t:0.012985 avg:0.013013 max:0.013996 min:0.012818 > > > > Tested with `make check` on aarch64-linux. > > > > Please let me know how I can improve the patch. > > > > Looks nice. I can't test currently but LGTM. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: PGP signature ___ 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] Workaround to build ffmpeg on MacOs 10.15
On Sat, Jan 04, 2020 at 09:25:40PM +0200, Martin Storsjö wrote: > On Sat, 4 Jan 2020, Michael Niedermayer wrote: > > >On Sat, Jan 04, 2020 at 12:06:55AM +0100, Henrik Gramner wrote: > >>On Fri, Jan 3, 2020 at 7:37 PM Moritz Barsnick wrote: > >>>On Fri, Jan 03, 2020 at 11:05:25 +0100, Timo Rothenpieler wrote: > I think this was discussed on this list in the past. > Not sure what the conclusion was, but I think an unconditional flag like > this being added wasn't all that well received. > >>> > >>>Yes, discussed in this thread in November: > >>>http://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253193.html > >> > >>Lmao "security feature". Just disable that flag and call it a day, it > >>adds nothing of value (unless you consider crashing to be a "security > >>feature"?). > > > >I dont know how effective this is or what exactly this option does, i > >couldnt find documentation for it quickly what it does in clang on macosx. > >google keeps pointing to gcc > >but > > > >a crash is better than arbitrary code execution, which IIUC is the idea > >here, if the stack of a thread grows too much, crash instead of overwriting > >something that comes after it. > >Not crashing when the stack overlapps another threads stack or heap is > >unlikely to be better. > > The point here is, disabling this "feature" is not a security regression - > it's a new feature in apple's clang, which only is enabled when you target a > new enough version of macOS. And that new security feature is broken to the > point that the process crashes before you even get to code which may be > misbehaving. > > So disabling it isn't a regression, it just takes things back to how things > were before, before this was introduced. Is it difficult to detect if the compiler has this bug ? Iam asking because disabling this feature only when needed avoids the questions related to "what happens when it is fixed". We could wait for it being fixed and then add a check on the version number and then backport that to any release which may need it. If it is difficult to add a check now Also what is your oppinion about limiting disabling the flag for only apple/clang ? Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: PGP signature ___ 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] Workaround to build ffmpeg on MacOs 10.15
On Sat, Jan 04, 2020 at 10:35:59PM +0100, Michael Niedermayer wrote: > On Sat, Jan 04, 2020 at 09:25:40PM +0200, Martin Storsjö wrote: > > On Sat, 4 Jan 2020, Michael Niedermayer wrote: > > > > >On Sat, Jan 04, 2020 at 12:06:55AM +0100, Henrik Gramner wrote: > > >>On Fri, Jan 3, 2020 at 7:37 PM Moritz Barsnick wrote: > > >>>On Fri, Jan 03, 2020 at 11:05:25 +0100, Timo Rothenpieler wrote: > > I think this was discussed on this list in the past. > > Not sure what the conclusion was, but I think an unconditional flag like > > this being added wasn't all that well received. > > >>> > > >>>Yes, discussed in this thread in November: > > >>>http://ffmpeg.org/pipermail/ffmpeg-devel/2019-November/253193.html > > >> > > >>Lmao "security feature". Just disable that flag and call it a day, it > > >>adds nothing of value (unless you consider crashing to be a "security > > >>feature"?). > > > > > >I dont know how effective this is or what exactly this option does, i > > >couldnt find documentation for it quickly what it does in clang on macosx. > > >google keeps pointing to gcc > > >but > > > > > >a crash is better than arbitrary code execution, which IIUC is the idea > > >here, if the stack of a thread grows too much, crash instead of overwriting > > >something that comes after it. > > >Not crashing when the stack overlapps another threads stack or heap is > > >unlikely to be better. > > > > The point here is, disabling this "feature" is not a security regression - > > it's a new feature in apple's clang, which only is enabled when you target a > > new enough version of macOS. And that new security feature is broken to the > > point that the process crashes before you even get to code which may be > > misbehaving. > > > > So disabling it isn't a regression, it just takes things back to how things > > were before, before this was introduced. > > Is it difficult to detect if the compiler has this bug ? > Iam asking because disabling this feature only when needed avoids the > questions related to "what happens when it is fixed". > > We could wait for it being fixed and then add a check on the > version number and then backport that to any release which may need it. > If it is difficult to add a check now Clarifying this slightly as re-reading sounds ambigous What i meant is to disable it for apple/clang now and then if its fixed replace that by a version check. (if adding a check now is difficult) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ 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 1/2] avcodec/pgssubdec: Free subtitle on error
Fixes: Assertion failure
Fixes:
19753/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGSSUB_fuzzer-5688461843759104
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pgssubdec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/pgssubdec.c b/libavcodec/pgssubdec.c
index 8c10f6d573..7fadcb8b4b 100644
--- a/libavcodec/pgssubdec.c
+++ b/libavcodec/pgssubdec.c
@@ -691,8 +691,11 @@ static int decode(AVCodecContext *avctx, void *data, int
*data_size,
ret = AVERROR_INVALIDDATA;
break;
}
-if (ret < 0 && (avctx->err_recognition & AV_EF_EXPLODE))
+if (ret < 0 && (avctx->err_recognition & AV_EF_EXPLODE)) {
+avsubtitle_free(data);
+*data_size = 0;
return ret;
+}
buf += segment_length;
}
--
2.24.0
___
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 2/2] avcodec/dca_lbr: Fix some error codes and error passing
Signed-off-by: Michael Niedermayer
---
libavcodec/dca_lbr.c | 162 +--
1 file changed, 93 insertions(+), 69 deletions(-)
diff --git a/libavcodec/dca_lbr.c b/libavcodec/dca_lbr.c
index 3b50a99cf6..747fdafd3e 100644
--- a/libavcodec/dca_lbr.c
+++ b/libavcodec/dca_lbr.c
@@ -154,7 +154,7 @@ static int parse_lfe_24(DCALbrDecoder *s)
step_i = get_bits(&s->gb, 8);
if (step_i > step_max) {
av_log(s->avctx, AV_LOG_ERROR, "Invalid LFE step size index\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
step = ff_dca_lfe_step_size_24[step_i];
@@ -208,7 +208,7 @@ static int parse_lfe_16(DCALbrDecoder *s)
step_i = get_bits(&s->gb, 8);
if (step_i > step_max) {
av_log(s->avctx, AV_LOG_ERROR, "Invalid LFE step size index\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
step = ff_dca_lfe_step_size_16[step_i];
@@ -246,14 +246,17 @@ static int parse_lfe_16(DCALbrDecoder *s)
static int parse_lfe_chunk(DCALbrDecoder *s, LBRChunk *chunk)
{
+int ret;
+
if (!(s->flags & LBR_FLAG_LFE_PRESENT))
return 0;
if (!chunk->len)
return 0;
-if (init_get_bits8(&s->gb, chunk->data, chunk->len) < 0)
-return -1;
+ret = init_get_bits8(&s->gb, chunk->data, chunk->len);
+if (ret < 0)
+return ret;
// Determine bit depth from chunk size
if (chunk->len >= 52)
@@ -262,7 +265,7 @@ static int parse_lfe_chunk(DCALbrDecoder *s, LBRChunk
*chunk)
return parse_lfe_16(s);
av_log(s->avctx, AV_LOG_ERROR, "LFE chunk too short\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
static inline int parse_vlc(GetBitContext *s, VLC *vlc, int max_depth)
@@ -291,13 +294,13 @@ static int parse_tonal(DCALbrDecoder *s, int group)
for (freq = 1;; freq++) {
if (get_bits_left(&s->gb) < 1) {
av_log(s->avctx, AV_LOG_ERROR, "Tonal group chunk too
short\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
diff = parse_vlc(&s->gb, &ff_dca_vlc_tnl_grp[group], 2);
if (diff >= FF_ARRAY_ELEMS(ff_dca_fst_amp)) {
av_log(s->avctx, AV_LOG_ERROR, "Invalid tonal frequency
diff\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
diff = get_bitsz(&s->gb, diff >> 2) + ff_dca_fst_amp[diff];
@@ -307,7 +310,7 @@ static int parse_tonal(DCALbrDecoder *s, int group)
freq += diff - 2;
if (freq >> (5 - group) > s->nsubbands * 4 - 6) {
av_log(s->avctx, AV_LOG_ERROR, "Invalid spectral line
offset\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
// Main channel
@@ -358,19 +361,21 @@ static int parse_tonal(DCALbrDecoder *s, int group)
static int parse_tonal_chunk(DCALbrDecoder *s, LBRChunk *chunk)
{
-int sb, group;
+int sb, group, ret;
if (!chunk->len)
return 0;
-if (init_get_bits8(&s->gb, chunk->data, chunk->len) < 0)
-return -1;
+ret = init_get_bits8(&s->gb, chunk->data, chunk->len);
+
+if (ret < 0)
+return ret;
// Scale factors
if (chunk->id == LBR_CHUNK_SCF || chunk->id == LBR_CHUNK_TONAL_SCF) {
if (get_bits_left(&s->gb) < 36) {
av_log(s->avctx, AV_LOG_ERROR, "Tonal scale factor chunk too
short\n");
-return -1;
+return AVERROR_INVALIDDATA;
}
for (sb = 0; sb < 6; sb++)
s->tonal_scf[sb] = get_bits(&s->gb, 6);
@@ -378,20 +383,25 @@ static int parse_tonal_chunk(DCALbrDecoder *s, LBRChunk
*chunk)
// Tonal groups
if (chunk->id == LBR_CHUNK_TONAL || chunk->id == LBR_CHUNK_TONAL_SCF)
-for (group = 0; group < 5; group++)
-if (parse_tonal(s, group) < 0)
-return -1;
+for (group = 0; group < 5; group++) {
+ret = parse_tonal(s, group);
+if (ret < 0)
+return ret;
+}
return 0;
}
static int parse_tonal_group(DCALbrDecoder *s, LBRChunk *chunk)
{
+int ret;
+
if (!chunk->len)
return 0;
-if (init_get_bits8(&s->gb, chunk->data, chunk->len) < 0)
-return -1;
+ret = init_get_bits8(&s->gb, chunk->data, chunk->len);
+if (ret < 0)
+return ret;
return parse_tonal(s, chunk->id);
}
@@ -404,7 +414,7 @@ static int ensure_bits(GetBitContext *s, int n)
{
int left = get_bits_left(s);
if (left < 0)
-return -1;
+return AVERROR_INVALIDDATA;
if (left < n) {
skip_bits_long(s, left);
return 1;
@@ -433,7 +443,7 @@ static int parse_scale_factors(DCALbrDecoder *s, uint8_t
*scf)
dist = parse_vlc(&s->gb, &ff_dca_vlc_rsd_apprx, 1) + 1;
if (dist > 7 - sf) {
av_log(s->avctx, AV_LOG_ERROR, "Invalid scale factor distance\n");
-return
Re: [FFmpeg-devel] [PATCH] Fix spelling in ID3v1 genres and extend the list of Winamp extensions.
On Wed, Dec 25, 2019 at 09:45:47PM +0100, Michael Niedermayer wrote: > On Wed, Dec 25, 2019 at 04:44:51PM +0100, Ulrich Spörlein wrote: > > On Tue, 24 Dec 2019, 00:42 Michael Niedermayer, > > wrote: > > > > > On Mon, Dec 23, 2019 at 11:43:10AM +0100, Ulrich Spörlein wrote: > > > > On Sun, 2019-12-22 at 18:44:01 +0100, Michael Niedermayer wrote: > > > > > a reference to a VCS should include the version > > > > > similarly for wikipedia some revission of the page should be mentioned > > > in > > > > > the commit message > > > > > > > > Heh, this is already a defunct standard, I doubt it will ever change > > > > again. I've updated the commit message to provide more direct links to > > > > fixed versions in time, hth, please see attached. > > > > > > > > > > > > > > > id3v1.c | 58 > > > +++--- > > > > id3v1.h |2 +- > > > > 2 files changed, 52 insertions(+), 8 deletions(-) > > > > 18bb5fc86701a138c90c9bc95737d5a18299c6ea > > > 0001-libavformat-fix-spelling-in-ID3v1-genres-and-extend-.patch > > > > From 55601483bdc8c002f3b8c19f830ab6ebbf4586cd Mon Sep 17 00:00:00 2001 > > > > From: =?UTF-8?q?Ulrich=20Sp=C3=B6rlein?= > > > > Date: Thu, 19 Dec 2019 16:12:46 +0100 > > > > Subject: [PATCH] libavformat: fix spelling in ID3v1 genres and extend > > > the list > > > > of Winamp extensions. > > > > > > > > Sources include various lists on the Internet, as well as the current > > > > Wikipedia page at > > > > > > > https://en.wikipedia.org/w/index.php?title=List_of_ID3v1_Genres&oldid=896774343 > > > > but most importantly the list as used by taglib at > > > > > > > https://github.com/taglib/taglib/commit/3e60e339a4bc46e2a1a7aea782502480561a8acf#diff-f86455366624350770f41b4940925dde > > > > > > > > Further patches to harmonize the spelling have been sent to taglib and > > > > libid3tag. See also https://github.com/taglib/taglib/pull/942/ > > > > --- > > > > libavformat/id3v1.c | 58 +++-- > > > > libavformat/id3v1.h | 2 +- > > > > 2 files changed, 52 insertions(+), 8 deletions(-) > > > > > > patch may be ok, but spelling is not my strong side ;) > > > > > > > Heh ;) > > The main thing really is the extension of the genre list. So where do we go > > from here, who can commit this? Is there anything else for me to do? > > i guess, ping it in a 1-2 weeks and ill apply it if noone else commented a week passed, will apply this soon thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: PGP signature ___ 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] ffmpeg: remove premature rescaling of forced_keyframe times
On 04-01-2020 10:02 am, Gyan wrote: On 02-01-2020 09:21 pm, Gyan Doshi wrote: The user-set forced KF times are parsed *after* this deleted loop and rescaled right after parsing. --- fftools/ffmpeg.c | 4 1 file changed, 4 deletions(-) diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 9af2bc2fb5..2c5fcc0532 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -3367,10 +3367,6 @@ static int init_output_stream_encode(OutputStream *ost) av_log(oc, AV_LOG_WARNING, "Frame rate very high for a muxer not efficiently supporting it.\n" "Please consider specifying a lower framerate, a different muxer or -vsync 2\n"); } - for (j = 0; j < ost->forced_kf_count; j++) - ost->forced_kf_pts[j] = av_rescale_q(ost->forced_kf_pts[j], - AV_TIME_BASE_Q, - enc_ctx->time_base); enc_ctx->width = av_buffersink_get_w(ost->filter->filter); enc_ctx->height = av_buffersink_get_h(ost->filter->filter); Will push tonight. Pushed as fa3ad7bbc68d33a08f6b3a03d097ecf37670059d Gyan ___ 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] ffmpeg: don't force source-tracked keyframes for duplicates
On 04-01-2020 10:02 am, Gyan wrote: On 03-01-2020 04:05 pm, Gyan wrote: On 03-01-2020 03:30 pm, Michael Niedermayer wrote: On Fri, Jan 03, 2020 at 12:35:22PM +0530, Gyan Doshi wrote: Prevents a run of consecutive duplicate frames from all being encoded as keyframes, when force_key_frames is set to source. --- fftools/ffmpeg.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) maybe ok (i wonder if this would be expected behavior with intra only input) If user wants intra-only output, they can use an intra-coded encoder or -g 1. If they want to preserve same seek points as source, then the non-duplicated frame has the closest pts sync to the source timestamp. Will push tonight. Pushed as 5d82c078ea93d7eee12ff863a4f9eb5fb2d30d16 Gyan ___ 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 1/2] avcodec/pgssubdec: Free subtitle on error
lgtm
On 1/5/20, Michael Niedermayer wrote:
> Fixes: Assertion failure
> Fixes:
> 19753/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGSSUB_fuzzer-5688461843759104
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pgssubdec.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/pgssubdec.c b/libavcodec/pgssubdec.c
> index 8c10f6d573..7fadcb8b4b 100644
> --- a/libavcodec/pgssubdec.c
> +++ b/libavcodec/pgssubdec.c
> @@ -691,8 +691,11 @@ static int decode(AVCodecContext *avctx, void *data,
> int *data_size,
> ret = AVERROR_INVALIDDATA;
> break;
> }
> -if (ret < 0 && (avctx->err_recognition & AV_EF_EXPLODE))
> +if (ret < 0 && (avctx->err_recognition & AV_EF_EXPLODE)) {
> +avsubtitle_free(data);
> +*data_size = 0;
> return ret;
> +}
>
> buf += segment_length;
> }
> --
> 2.24.0
>
> ___
> 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".
