swr_convert crash

[TheSHEEEP]

Summary of the bug:
When I call swr_convert() I get a crash somewhere inside .

Here is a stack trace:

#0  0x1413ad9a in ff_float_to_int16_a_sse2 ()
   from C:\MyProject\bin\Debug_Win\libFFmpegVideoPlugin_d.dll
#1  0x141379ec in swri_audio_convert (ctx=0x3fba2e40, out=out@entry=0x4029136c, in=in@entry=0x4029110c, len=len@entry=5
    at libswresample/audioconvert.c:203
#2  0x141315a8 in swr_convert_internal (in_count=576, in=0x4029110c, out_count=576, out=0x4029136c, s=0x4028fac0)
    at libswresample/swresample.c:618
#3  swr_convert (s=0x4028fac0, out_arg=0x477dfd30, out_count=2048, in_arg=0x3fd29ae0, in_count=576)
    at libswresample/swresample.c:817

This is the line that calls the sse2 function:

ctx->simd_f(out->ch+ch, (const uint8_t **)in->ch+ch, off * (out->planar ? 1 :out->ch_count));

How to reproduce:

Here is how I initialize the context and the output buffer:

SwrContext* swrContext = swr_alloc_set_opts(NULL, 
                audioCodecContext->channel_layout, AV_SAMPLE_FMT_S16P, audioCodecContext->sample_rate,
                audioCodecContext->channel_layout, audioCodecContext->sample_fmt, audioCodecContext->sample_rate, 
                0, NULL);
int result = swr_init(swrContext);

// Create destination sample buffer
uint8_t** destBuffer = NULL;
int destBufferLinesize;
av_samples_alloc_array_and_samples( &destBuffer,
        &destBufferLinesize,
        videoInfo.audioNumChannels,
        2048,
        AV_SAMPLE_FMT_S16P,
        0);

And here is the call to convert:

int outputSamples = swr_convert(swrContext, 
                                destBuffer, 2048, 
                                (const uint8_t**)frame->extended_data, frame->nb_samples);

Also, I do not get any FFmpeg errors in the log and av_samples_alloc, swr_alloc_set_opts and swr_init do not return any errors, either.

I am using a self compiled version of FFmpeg on Windows with MinGW (www.mingw.org).

[TheSHEEEP]

Not sure if this helps, but here is the disassembly I get for the sse2 function:

ff_float_to_int16_a_sse2()
ff_float_to_int16_a_sse2+106: movdqa %xmm0,(%eax,%edx,2)
ff_float_to_int16_a_sse2+111: movdqa %xmm1,0x10(%eax,%edx,2)
ff_float_to_int16_a_sse2+117: add    $0x10,%edx
ff_float_to_int16_a_sse2+120: jl     0x1410ad5f <ff_float_to_int16_a_sse2+47>
ff_float_to_int16_a_sse2+122: repz ret 
ff_float_to_int16_a_sse2+124: nopl   0x0(%eax)

[TheSHEEEP]

I disabled sse (--disable-sse, sse2 and sse3) to see if that was the issue and I think it is not. I do now get a crash in the same function (swri_audio_convert), but the part that is called when sse is not available:

ctx->conv_f(po+off*os, pi+off*is, is, os, end);

And conv_f seems to point to this:

conv_AV_SAMPLE_FMT_FLT_to_AV_SAMPLE_FMT_S16 (po=0x1000 <Address 0x1000 out of bounds>, pi=0x3f25b680 \"\3708J8\331\225\\036\\070\362@\3527\317$\\f8\360\242L8\334oz88\250\2248]\\033\\271\\070v&\3258l\276\3448\275T\3738\353b\\004\\071\\262\\037\3628\\f.\3108\341\\215\2278\\201\267\\016\\070.|\237\267\\aL\227\270\255\332\\005\\271\252\314K\271\\230\265\\210\\271\356\\025\246\271U\320\304\271d\\231\350\271\271P\\004\272\234\203\\017\272\324\\230\\027\272\322\365\\033\272V\\006\\032\272\245_\\024\272\241Y\\016\272\236\317\\004\272\310\267\353\271A+\313\2711\376\246\271\", is=4, os=2, end=0x1480 <Address 0x1480 out of bounds>)

And GDB tells to look at line 70 inside audioconvert.c, which would be this:

CONV_FUNC(AV_SAMPLE_FMT_S16, int16_t, AV_SAMPLE_FMT_FLT, av_clip_int16(  lrintf(*(const float*)pi * (1<<15))))

Hmm... Nope. No idea.

[TheSHEEEP]

I was able to convert from FLTP to FLT without a crash.

Are there conversions that simply do not work? If so, I consider it a bug that the user is not informed about this when trying.

[Clément Bœsch]

Replying to TheSHEEEP:

I was able to convert from FLTP to FLT without a crash.

Are there conversions that simply do not work? If so, I consider it a bug that the user is not informed about this when trying.

FLTP is planar, FLT is packed. swresample definitely supports all of them, and it's actually tested. You probably didn't allocate or passed the buffers properly. But we can't guess since you didn't share a complete code. Ask the ​libav-api@ffmpeg.org mailing list to make sure your code is valid before submitting or reopening the bug though.

[Carl Eugen Hoyos]

Replying to ubitux:

swresample definitely supports all of them, and it's actually tested. You probably didn't allocate or passed the buffers properly. But we can't guess since you didn't share a complete code. Ask the ​libav-api@ffmpeg.org mailing list to make sure your code is valid before submitting or reopening the bug though.

(Does this mailing list really exist?)
He did: ​http://thread.gmane.org/gmane.comp.video.ffmpeg.libav.user/12393