[Libav-user] I can't get audio decoding to work.

[Robin Stevens]

On Friday, 17 June 2016, Bill Messenger <apothemmusic at gmail.com> wrote:

> Update: I found out that it only crashes in debug mode. When I build it in
> release mode, it doesn't crash. It must be a bug in MSVC 2015 or something.
>
> On Fri, Jun 17, 2016 at 4:06 PM, Bill Messenger <apothemmusic at gmail.com
> <javascript:_e(%7B%7D,'cvml','apothemmusic at gmail.com');>> wrote:
>
>> I'm trying to create a class that uses FFmpeg to decode any audio file
>> and store it into memory. Then it has a function that returns a float value
>> of any sample in that buffer. The code I wrote works perfectly for wav and
>> flac files, produces weird audio for mp3 and ogg files, and crashes on
>> certain mp3 files. I spent days trying to figure out why it isn't working,
>> but I can't come up with anything.
>>
>> I think the reason why the audio is weird for mp3 and ogg files is that
>> it uses planar audio instead of interleaved audio, but I don't see what's
>> wrong with the code I wrote. I may be missing something though. For
>> example, to get a sample for 16 bit interleaved audio I use:
>>
>> int16_t tmp = ((int16_t*)sampleBuffer)[numChannels*sample + channel];
>> rv = (float)tmp / 32767.0f;
>>
>> and to get a sample for 16 bit planar audio I use:
>>
>> int16_t tmp = ((int16_t*)sampleBuffer)[sample + numSamples*channel];
>> rv = (float)tmp / 32767.0f;
>>
>> And I have no clue why it crashes on certain mp3 files. I paid close
>> attention to make sure there is enough memory allocated in the buffer.
>> What's even weirder is that the file I created "Chiptune 15 2.mp3" didn't
>> crash, but when I renamed it to "test.mp3", it crashed! These crashes
>> happen on line 139 of "AudioDecoder.cpp":
>>
>> std::memcpy(sampleBuffer + totalBufferSize, frame->extended_data[0],
>> dataSize);
>>
>> with an "Access violation reading location" error in vcruntime140d.dll.
>> It says it isn't with location 0x0000000000000000 or 0xFFFFFFFFFFFFFFFF
>> though, it's a different random location.
>>
>> I attached a zip file with the c++ code and two mp3's. Oh yeah, I should
>> also mention that I'm using MSVC 2015 Community in Windows 10.
>>
>
>
No, it's not a bug in MSVC.

You will be overwriting memory somewhere. In debug mode there is additional
protection which means some invalid reads and writes are detected and you
get told about them (access violation).

If you're not seeing it in release its because there is less protection and
so far you're getting unlucky and not overwriting anything important. Yes:
unlucky.

It will come back and bite you... Which is why changing the file name is
making the bug come and go: different length of name is causing a different
memory layout which is masking/revealing the bug.

The address isn't random: it's the address at which the violation was
detected. You may find it's some point after extended_data[0]. You are
trying to read more data than is there. Or the error occurred much earlier
and is only becoming symptomatic now.

Why are you using extended_data instead of data? How are you calculating
dataSize?

Investigate the CRT memory debugging functions, especially heapchk. Pepper
your code with it - after every statement if you need to. It will tell you
when the heap corruption is detected, then you can try to fix.

Finally: search for dr memory and use it.

Cheers
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20160618/984cfca7/attachment.html>