[FFmpeg-devel] segfault in af_afade.c::activate
Mark Niebur
mniebur at thuuz.com
Wed Oct 16 01:51:41 EEST 2019
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 at gmail.com> wrote:
>
> On 10/15/19, Mark Niebur <mniebur at thuuz.com <mailto:mniebur at 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 at gmail.com> wrote:
>>>
>>> On 10/15/19, Mark Niebur <mniebur at 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 at ffmpeg.org
>>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>
>>>> To unsubscribe, visit link above, or email
>>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>>
>> _______________________________________________
>> ffmpeg-devel mailing list
>> ffmpeg-devel at ffmpeg.org <mailto:ffmpeg-devel at 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 at ffmpeg.org <mailto:ffmpeg-devel-request at ffmpeg.org> with subject "unsubscribe".
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org <mailto:ffmpeg-devel at 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 at ffmpeg.org <mailto:ffmpeg-devel-request at ffmpeg.org> with subject "unsubscribe".
More information about the ffmpeg-devel
mailing list