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

Michael Bradshaw mbradshaw at sorensonmedia.com
Tue Jun 26 23:38:47 CEST 2012


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)).

Anyway, I guess this is just a misunderstanding of the documentation,
and not necessarily a real lack thereof or a bug.

--Michael


More information about the Libav-user mailing list