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 <one...@gmail.com> wrote: > > On 10/15/19, Mark Niebur <mnie...@thuuz.com <mailto:mnie...@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 <one...@gmail.com> wrote: >>> >>> On 10/15/19, Mark Niebur <mnie...@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-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 <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-requ...@ffmpeg.org <mailto:ffmpeg-devel-requ...@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-requ...@ffmpeg.org <mailto: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".