On 10/15/19, Mark Niebur <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 > 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".