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

Michael Niedermayer michaelni at gmx.at
Wed Jun 27 11:37:37 CEST 2012

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

> 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

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20120627/df9e6fa3/attachment.asc>

More information about the Libav-user mailing list