| Message ID | 5A36697B-72BA-498C-A172-B8218AE086A5@thuuz.com |
|---|---|
| State | New |
| Headers | show |
On 10/15/19, Mark Niebur <mniebur@thuuz.com> wrote: > I just checked out master and I see the fix you mentioned. This does not > completely fix acrossfade for me. I also had to apply the following patch: What this patch fixes? > diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c > index 195fb65..446aa0a 100644 > --- a/libavfilter/af_afade.c > +++ b/libavfilter/af_afade.c > @@ -459,11 +459,11 @@ static int activate(AVFilterContext *ctx) > } else if (ff_inlink_acknowledge_status(ctx->inputs[1], &status, > &pts)) { > ff_outlink_set_status(ctx->outputs[0], status, pts); > return 0; > - } else { > - if (ff_outlink_frame_wanted(ctx->outputs[0]) && !in) { > + } else if (!in) { > + if (ff_outlink_frame_wanted(ctx->outputs[0])) { > ff_inlink_request_frame(ctx->inputs[1]); > - return 0; > } > + return 0; > } > in->pts = s->pts; > s->pts += av_rescale_q(in->nb_samples, > > Thanks, > Mark > >> On Oct 15, 2019, at 2:26 PM, Paul B Mahol <onemda@gmail.com> wrote: >> >> On 10/15/19, Mark Niebur <mniebur@thuuz.com> wrote: >>> Hello, >>> I'm trying to debug an issue I'm seeing where the filter "acrossfade" >>> produces a segfault. This seemingly only happens in docker containers, >>> and >>> I am seeing it when running a rather large filter chain. I'm trying to >>> get >>> to the bottom of it, but it would be really helpful to understand the >>> context around how libavfilter fills the filter input fifos. This is the >>> code where I'm seeing the segfault: >>> 449 AVFrame *in = NULL, *out, *cf[2] = { NULL }; >>> ... >>> 474 if (ff_inlink_queued_samples(ctx->inputs[0]) > s->nb_samples) { >>> 475 // consume some samples - this is not a crossfade overlap >>> 486 } else if (ff_inlink_queued_samples(ctx->inputs[1]) >= >>> s->nb_samples) { >>> 487 if (s->overlap) { >>> 488 out = ff_get_audio_buffer(outlink, s->nb_samples); >>> 489 if (!out) >>> 490 return AVERROR(ENOMEM); >>> 491 // NO CHECK IS DONE HERE THAT ENOUGH SAMPLES ARE PRESENT >>> 491 // In our case, there are 0 samples, so >>> ff_inlink_consume_samples returns early and does not set cf[0] >>> 492 ret = ff_inlink_consume_samples(ctx->inputs[0], >>> s->nb_samples, s->nb_samples, &cf[0]); >>> 493 if (ret < 0) { >>> 494 av_frame_free(&out); >>> 495 return ret; >>> 496 } >>> 497 // SEGFAULT HERE >>> 498 ret = ff_inlink_consume_samples(ctx->inputs[1], >>> s->nb_samples, s->nb_samples, &cf[1]); >>> 499 if (ret < 0) { >>> 500 av_frame_free(&out); >>> 501 return ret; >>> 502 } >>> >>> How does avfilter add samples to an inlink? Does it just fill it >>> randomly >>> or will it fill input 0 completely and then move on to input 1, 2, 3? >>> Even >>> when I fix this segfault by ensuring that >>> ff_inlink_queued_samples(ctx->inputs[0]) == s->nb_samples, I will still >>> get >>> additional segfaults in the acrossfade code where >>> ff_inlink_consume_samples >>> returns 0 and does not set the frame pointer. >> >> I think this was just reported and fixed very recently. >> >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@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-request@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-request@ffmpeg.org with subject "unsubscribe".
I'm sorry for not specifying. In the case that data is not ready from ctx->inputs[1] after crossfade is over, ff_inlink_consume_frame will return 0 and not set the frame pointer. If ff_outlink_frame_wanted is still 0, the function will fall through to the code filtering the frame, although the frame pointer is NULL. This is the affected code in af_afade.c:
455 if (s->crossfade_is_over) {
456 ret = ff_inlink_consume_frame(ctx->inputs[1], &in);
457 if (ret < 0) {
458 return ret;
459 } else if (ff_inlink_acknowledge_status(ctx->inputs[1], &status, &pts)) {
460 ff_outlink_set_status(ctx->outputs[0], status, pts);
461 return 0;
462 } else {
463 if (ff_outlink_frame_wanted(ctx->outputs[0]) && !in) {
464 ff_inlink_request_frame(ctx->inputs[1]);
465 return 0;
466 }
467 }
468 in->pts = s->pts;
469 s->pts += av_rescale_q(in->nb_samples,
470 (AVRational){ 1, outlink->sample_rate }, outlink->time_base);
471 return ff_filter_frame(outlink, in);
472 }
> On Oct 15, 2019, at 4:29 PM, Paul B Mahol <onemda@gmail.com> wrote:
>
> On 10/15/19, Mark Niebur <mniebur@thuuz.com <mailto:mniebur@thuuz.com>> wrote:
>> I just checked out master and I see the fix you mentioned. This does not
>> completely fix acrossfade for me. I also had to apply the following patch:
>
> What this patch fixes?
>
>> diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c
>> index 195fb65..446aa0a 100644
>> --- a/libavfilter/af_afade.c
>> +++ b/libavfilter/af_afade.c
>> @@ -459,11 +459,11 @@ static int activate(AVFilterContext *ctx)
>> } else if (ff_inlink_acknowledge_status(ctx->inputs[1], &status,
>> &pts)) {
>> ff_outlink_set_status(ctx->outputs[0], status, pts);
>> return 0;
>> - } else {
>> - if (ff_outlink_frame_wanted(ctx->outputs[0]) && !in) {
>> + } else if (!in) {
>> + if (ff_outlink_frame_wanted(ctx->outputs[0])) {
>> ff_inlink_request_frame(ctx->inputs[1]);
>> - return 0;
>> }
>> + return 0;
>> }
>> in->pts = s->pts;
>> s->pts += av_rescale_q(in->nb_samples,
>>
>> Thanks,
>> Mark
>>
>>> On Oct 15, 2019, at 2:26 PM, Paul B Mahol <onemda@gmail.com> wrote:
>>>
>>> On 10/15/19, Mark Niebur <mniebur@thuuz.com> wrote:
>>>> Hello,
>>>> I'm trying to debug an issue I'm seeing where the filter "acrossfade"
>>>> produces a segfault. This seemingly only happens in docker containers,
>>>> and
>>>> I am seeing it when running a rather large filter chain. I'm trying to
>>>> get
>>>> to the bottom of it, but it would be really helpful to understand the
>>>> context around how libavfilter fills the filter input fifos. This is the
>>>> code where I'm seeing the segfault:
>>>> 449 AVFrame *in = NULL, *out, *cf[2] = { NULL };
>>>> ...
>>>> 474 if (ff_inlink_queued_samples(ctx->inputs[0]) > s->nb_samples) {
>>>> 475 // consume some samples - this is not a crossfade overlap
>>>> 486 } else if (ff_inlink_queued_samples(ctx->inputs[1]) >=
>>>> s->nb_samples) {
>>>> 487 if (s->overlap) {
>>>> 488 out = ff_get_audio_buffer(outlink, s->nb_samples);
>>>> 489 if (!out)
>>>> 490 return AVERROR(ENOMEM);
>>>> 491 // NO CHECK IS DONE HERE THAT ENOUGH SAMPLES ARE PRESENT
>>>> 491 // In our case, there are 0 samples, so
>>>> ff_inlink_consume_samples returns early and does not set cf[0]
>>>> 492 ret = ff_inlink_consume_samples(ctx->inputs[0],
>>>> s->nb_samples, s->nb_samples, &cf[0]);
>>>> 493 if (ret < 0) {
>>>> 494 av_frame_free(&out);
>>>> 495 return ret;
>>>> 496 }
>>>> 497 // SEGFAULT HERE
>>>> 498 ret = ff_inlink_consume_samples(ctx->inputs[1],
>>>> s->nb_samples, s->nb_samples, &cf[1]);
>>>> 499 if (ret < 0) {
>>>> 500 av_frame_free(&out);
>>>> 501 return ret;
>>>> 502 }
>>>>
>>>> How does avfilter add samples to an inlink? Does it just fill it
>>>> randomly
>>>> or will it fill input 0 completely and then move on to input 1, 2, 3?
>>>> Even
>>>> when I fix this segfault by ensuring that
>>>> ff_inlink_queued_samples(ctx->inputs[0]) == s->nb_samples, I will still
>>>> get
>>>> additional segfaults in the acrossfade code where
>>>> ff_inlink_consume_samples
>>>> returns 0 and does not set the frame pointer.
>>>
>>> I think this was just reported and fixed very recently.
>>>
>>>> _______________________________________________
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel@ffmpeg.org
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>
>>>> To unsubscribe, visit link above, or email
>>>> ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org>
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-request@ffmpeg.org <mailto:ffmpeg-devel-request@ffmpeg.org> with subject "unsubscribe".
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org>
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org <mailto:ffmpeg-devel-request@ffmpeg.org> with subject "unsubscribe".
Should be fixed. On 10/16/19, Mark Niebur <mniebur@thuuz.com> wrote: > I'm sorry for not specifying. In the case that data is not ready from > ctx->inputs[1] after crossfade is over, ff_inlink_consume_frame will return > 0 and not set the frame pointer. If ff_outlink_frame_wanted is still 0, the > function will fall through to the code filtering the frame, although the > frame pointer is NULL. This is the affected code in af_afade.c: > > 455 if (s->crossfade_is_over) { > 456 ret = ff_inlink_consume_frame(ctx->inputs[1], &in); > 457 if (ret < 0) { > 458 return ret; > 459 } else if (ff_inlink_acknowledge_status(ctx->inputs[1], &status, > &pts)) { > 460 ff_outlink_set_status(ctx->outputs[0], status, pts); > 461 return 0; > 462 } else { > 463 if (ff_outlink_frame_wanted(ctx->outputs[0]) && !in) { > 464 ff_inlink_request_frame(ctx->inputs[1]); > 465 return 0; > 466 } > 467 } > 468 in->pts = s->pts; > 469 s->pts += av_rescale_q(in->nb_samples, > 470 (AVRational){ 1, outlink->sample_rate }, > outlink->time_base); > 471 return ff_filter_frame(outlink, in); > 472 } > >> On Oct 15, 2019, at 4:29 PM, Paul B Mahol <onemda@gmail.com> wrote: >> >> On 10/15/19, Mark Niebur <mniebur@thuuz.com <mailto:mniebur@thuuz.com>> >> wrote: >>> I just checked out master and I see the fix you mentioned. This does not >>> completely fix acrossfade for me. I also had to apply the following >>> patch: >> >> What this patch fixes? >> >>> diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c >>> index 195fb65..446aa0a 100644 >>> --- a/libavfilter/af_afade.c >>> +++ b/libavfilter/af_afade.c >>> @@ -459,11 +459,11 @@ static int activate(AVFilterContext *ctx) >>> } else if (ff_inlink_acknowledge_status(ctx->inputs[1], &status, >>> &pts)) { >>> ff_outlink_set_status(ctx->outputs[0], status, pts); >>> return 0; >>> - } else { >>> - if (ff_outlink_frame_wanted(ctx->outputs[0]) && !in) { >>> + } else if (!in) { >>> + if (ff_outlink_frame_wanted(ctx->outputs[0])) { >>> ff_inlink_request_frame(ctx->inputs[1]); >>> - return 0; >>> } >>> + return 0; >>> } >>> in->pts = s->pts; >>> s->pts += av_rescale_q(in->nb_samples, >>> >>> Thanks, >>> Mark >>> >>>> On Oct 15, 2019, at 2:26 PM, Paul B Mahol <onemda@gmail.com> wrote: >>>> >>>> On 10/15/19, Mark Niebur <mniebur@thuuz.com> wrote: >>>>> Hello, >>>>> I'm trying to debug an issue I'm seeing where the filter "acrossfade" >>>>> produces a segfault. This seemingly only happens in docker containers, >>>>> and >>>>> I am seeing it when running a rather large filter chain. I'm trying to >>>>> get >>>>> to the bottom of it, but it would be really helpful to understand the >>>>> context around how libavfilter fills the filter input fifos. This is >>>>> the >>>>> code where I'm seeing the segfault: >>>>> 449 AVFrame *in = NULL, *out, *cf[2] = { NULL }; >>>>> ... >>>>> 474 if (ff_inlink_queued_samples(ctx->inputs[0]) > s->nb_samples) { >>>>> 475 // consume some samples - this is not a crossfade overlap >>>>> 486 } else if (ff_inlink_queued_samples(ctx->inputs[1]) >= >>>>> s->nb_samples) { >>>>> 487 if (s->overlap) { >>>>> 488 out = ff_get_audio_buffer(outlink, s->nb_samples); >>>>> 489 if (!out) >>>>> 490 return AVERROR(ENOMEM); >>>>> 491 // NO CHECK IS DONE HERE THAT ENOUGH SAMPLES ARE >>>>> PRESENT >>>>> 491 // In our case, there are 0 samples, so >>>>> ff_inlink_consume_samples returns early and does not set cf[0] >>>>> 492 ret = ff_inlink_consume_samples(ctx->inputs[0], >>>>> s->nb_samples, s->nb_samples, &cf[0]); >>>>> 493 if (ret < 0) { >>>>> 494 av_frame_free(&out); >>>>> 495 return ret; >>>>> 496 } >>>>> 497 // SEGFAULT HERE >>>>> 498 ret = ff_inlink_consume_samples(ctx->inputs[1], >>>>> s->nb_samples, s->nb_samples, &cf[1]); >>>>> 499 if (ret < 0) { >>>>> 500 av_frame_free(&out); >>>>> 501 return ret; >>>>> 502 } >>>>> >>>>> How does avfilter add samples to an inlink? Does it just fill it >>>>> randomly >>>>> or will it fill input 0 completely and then move on to input 1, 2, 3? >>>>> Even >>>>> when I fix this segfault by ensuring that >>>>> ff_inlink_queued_samples(ctx->inputs[0]) == s->nb_samples, I will still >>>>> get >>>>> additional segfaults in the acrossfade code where >>>>> ff_inlink_consume_samples >>>>> returns 0 and does not set the frame pointer. >>>> >>>> I think this was just reported and fixed very recently. >>>> >>>>> _______________________________________________ >>>>> ffmpeg-devel mailing list >>>>> ffmpeg-devel@ffmpeg.org >>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>>>> >>>>> To unsubscribe, visit link above, or email >>>>> ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe". >>> >>> _______________________________________________ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel> >>> >>> To unsubscribe, visit link above, or email >>> ffmpeg-devel-request@ffmpeg.org <mailto:ffmpeg-devel-request@ffmpeg.org> >>> with subject "unsubscribe". >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel> >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@ffmpeg.org <mailto:ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe".
This should be fixed already on master? I checked a few hours ago and was able to repro. On Tue, Oct 15, 2019, 5:03 PM Paul B Mahol <onemda@gmail.com> wrote: > Should be fixed. > > On 10/16/19, Mark Niebur <mniebur@thuuz.com> wrote: > > I'm sorry for not specifying. In the case that data is not ready from > > ctx->inputs[1] after crossfade is over, ff_inlink_consume_frame will > return > > 0 and not set the frame pointer. If ff_outlink_frame_wanted is still 0, > the > > function will fall through to the code filtering the frame, although the > > frame pointer is NULL. This is the affected code in af_afade.c: > > > > 455 if (s->crossfade_is_over) { > > 456 ret = ff_inlink_consume_frame(ctx->inputs[1], &in); > > 457 if (ret < 0) { > > 458 return ret; > > 459 } else if (ff_inlink_acknowledge_status(ctx->inputs[1], > &status, > > &pts)) { > > 460 ff_outlink_set_status(ctx->outputs[0], status, pts); > > 461 return 0; > > 462 } else { > > 463 if (ff_outlink_frame_wanted(ctx->outputs[0]) && !in) { > > 464 ff_inlink_request_frame(ctx->inputs[1]); > > 465 return 0; > > 466 } > > 467 } > > 468 in->pts = s->pts; > > 469 s->pts += av_rescale_q(in->nb_samples, > > 470 (AVRational){ 1, outlink->sample_rate }, > > outlink->time_base); > > 471 return ff_filter_frame(outlink, in); > > 472 } > > > >> On Oct 15, 2019, at 4:29 PM, Paul B Mahol <onemda@gmail.com> wrote: > >> > >> On 10/15/19, Mark Niebur <mniebur@thuuz.com <mailto:mniebur@thuuz.com>> > >> wrote: > >>> I just checked out master and I see the fix you mentioned. This does > not > >>> completely fix acrossfade for me. I also had to apply the following > >>> patch: > >> > >> What this patch fixes? > >> > >>> diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c > >>> index 195fb65..446aa0a 100644 > >>> --- a/libavfilter/af_afade.c > >>> +++ b/libavfilter/af_afade.c > >>> @@ -459,11 +459,11 @@ static int activate(AVFilterContext *ctx) > >>> } else if (ff_inlink_acknowledge_status(ctx->inputs[1], > &status, > >>> &pts)) { > >>> ff_outlink_set_status(ctx->outputs[0], status, pts); > >>> return 0; > >>> - } else { > >>> - if (ff_outlink_frame_wanted(ctx->outputs[0]) && !in) { > >>> + } else if (!in) { > >>> + if (ff_outlink_frame_wanted(ctx->outputs[0])) { > >>> ff_inlink_request_frame(ctx->inputs[1]); > >>> - return 0; > >>> } > >>> + return 0; > >>> } > >>> in->pts = s->pts; > >>> s->pts += av_rescale_q(in->nb_samples, > >>> > >>> Thanks, > >>> Mark > >>> > >>>> On Oct 15, 2019, at 2:26 PM, Paul B Mahol <onemda@gmail.com> wrote: > >>>> > >>>> On 10/15/19, Mark Niebur <mniebur@thuuz.com> wrote: > >>>>> Hello, > >>>>> I'm trying to debug an issue I'm seeing where the filter "acrossfade" > >>>>> produces a segfault. This seemingly only happens in docker > containers, > >>>>> and > >>>>> I am seeing it when running a rather large filter chain. I'm trying > to > >>>>> get > >>>>> to the bottom of it, but it would be really helpful to understand the > >>>>> context around how libavfilter fills the filter input fifos. This is > >>>>> the > >>>>> code where I'm seeing the segfault: > >>>>> 449 AVFrame *in = NULL, *out, *cf[2] = { NULL }; > >>>>> ... > >>>>> 474 if (ff_inlink_queued_samples(ctx->inputs[0]) > > s->nb_samples) { > >>>>> 475 // consume some samples - this is not a crossfade overlap > >>>>> 486 } else if (ff_inlink_queued_samples(ctx->inputs[1]) >= > >>>>> s->nb_samples) { > >>>>> 487 if (s->overlap) { > >>>>> 488 out = ff_get_audio_buffer(outlink, s->nb_samples); > >>>>> 489 if (!out) > >>>>> 490 return AVERROR(ENOMEM); > >>>>> 491 // NO CHECK IS DONE HERE THAT ENOUGH SAMPLES ARE > >>>>> PRESENT > >>>>> 491 // In our case, there are 0 samples, so > >>>>> ff_inlink_consume_samples returns early and does not set cf[0] > >>>>> 492 ret = ff_inlink_consume_samples(ctx->inputs[0], > >>>>> s->nb_samples, s->nb_samples, &cf[0]); > >>>>> 493 if (ret < 0) { > >>>>> 494 av_frame_free(&out); > >>>>> 495 return ret; > >>>>> 496 } > >>>>> 497 // SEGFAULT HERE > >>>>> 498 ret = ff_inlink_consume_samples(ctx->inputs[1], > >>>>> s->nb_samples, s->nb_samples, &cf[1]); > >>>>> 499 if (ret < 0) { > >>>>> 500 av_frame_free(&out); > >>>>> 501 return ret; > >>>>> 502 } > >>>>> > >>>>> How does avfilter add samples to an inlink? Does it just fill it > >>>>> randomly > >>>>> or will it fill input 0 completely and then move on to input 1, 2, 3? > >>>>> Even > >>>>> when I fix this segfault by ensuring that > >>>>> ff_inlink_queued_samples(ctx->inputs[0]) == s->nb_samples, I will > still > >>>>> get > >>>>> additional segfaults in the acrossfade code where > >>>>> ff_inlink_consume_samples > >>>>> returns 0 and does not set the frame pointer. > >>>> > >>>> I think this was just reported and fixed very recently. > >>>> > >>>>> _______________________________________________ > >>>>> ffmpeg-devel mailing list > >>>>> ffmpeg-devel@ffmpeg.org > >>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >>>>> > >>>>> To unsubscribe, visit link above, or email > >>>>> ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe". > >>> > >>> _______________________________________________ > >>> ffmpeg-devel mailing list > >>> ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> > >>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >>> <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel> > >>> > >>> To unsubscribe, visit link above, or email > >>> ffmpeg-devel-request@ffmpeg.org <mailto: > ffmpeg-devel-request@ffmpeg.org> > >>> with subject "unsubscribe". > >> _______________________________________________ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org> > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel> > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-request@ffmpeg.org <mailto:ffmpeg-devel-request@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-request@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-request@ffmpeg.org with subject "unsubscribe".
On Tue, Oct 15, 2019, at 3:06 PM, Mark Niebur wrote: > This should be fixed already on master? I checked a few hours ago and was > able to repro. Yes. Paul made the commit less than 10 minutes ago. https://git.videolan.org/gitweb.cgi/ffmpeg.git/?p=ffmpeg.git;a=commit;h=29dac2927f5fa0b1f5c6b27a3ed32f2968ea9b00
diff --git a/libavfilter/af_afade.c b/libavfilter/af_afade.c index 195fb65..446aa0a 100644 --- a/libavfilter/af_afade.c +++ b/libavfilter/af_afade.c @@ -459,11 +459,11 @@ static int activate(AVFilterContext *ctx) } else if (ff_inlink_acknowledge_status(ctx->inputs[1], &status, &pts)) { ff_outlink_set_status(ctx->outputs[0], status, pts); return 0; - } else { - if (ff_outlink_frame_wanted(ctx->outputs[0]) && !in) { + } else if (!in) { + if (ff_outlink_frame_wanted(ctx->outputs[0])) { ff_inlink_request_frame(ctx->inputs[1]); - return 0; } + return 0; } in->pts = s->pts; s->pts += av_rescale_q(in->nb_samples,