[Libav-user] Crash/access violation when flushing when encoding audio

[Michael Bradshaw]

On Wed, Jun 27, 2012 at 3:37 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Tue, Jun 26, 2012 at 03:38:47PM -0600, Michael Bradshaw wrote:
>> On Tue, Jun 26, 2012 at 2:16 PM, Michael Bradshaw
>> <mbradshaw at sorensonmedia.com> wrote:
>> > Hi,
>> >
>> > I'm encoding an AMR-NB stream, and I see that the libopen-core-amrnb
>> > encoder has the CODEC_CAP_DELAY capability set. If I call
>> > avcodec_encode_audio2() with a NULL frame (like the docs say to when
>> > flushing the stream) more than once, I get an access violation and a
>> > crash (it works the first time though). I have to call
>> > av_init_packet() on the packet I pass to avcodec_encode_audio2() in
>> > order to avoid the crash (despite the fact that the docs say
>> > avcodec_encode_audio2() will call av_init_packet() for me (and I am
>> > setting the data and size fields of the packet to my own buffer, if
>> > that matters)). Is this behavior expected and lacking documentation,
>> > or is it likely a bug? I can, of course, provide greater details if it
>> > looks like a bug.
>>
>> I've dug around and it looks like avcodec_encode_audio2() is failing
>> (which is fine, since there aren't any more buffered frames queued
>> up), so it tries to call avpkt->destruct since the data is
>> user-supplied by me. I was assuming av_init_packet() would be called
>> _before_ any of this, but it does not look like it is (which I suppose
>> makes sense, since it would overwrite avpkt->destruct (but it
>> overwrites this anyway later, which seems weird to me)).
>
> where is avpkt->destruct overwritten ?
> there should be code to restore it after av_init_packet

Turns out it's not overwritten. I just thought it would be because of
how the documentation is worded.

>> Anyway, I guess this is just a misunderstanding of the documentation,
>> and not necessarily a real lack thereof or a bug.
>
> yes, i think so too, a patch that documents that ->destruct has to be
> set is welcome

Okay, I'll work on one.

Thanks,

--Michael