[Libav-user] Flushing Audio Frame Crash

[phuze koj]

Thanks for that response Brad, it was your question that I found. Yeah I've
found most of the same information from my digging as well and I'm also
unsure if AAC  supports CODEC_CAP_DELAY (thanks for the tip Paul, I'll
check it when I get a chance). I've tried to simplify my audio writing to
the absolute simplest case (encoding a single, albeit large frame) which is
why I'm doing this test that's leading to this problem. I'm not sure if the
code I posted in the OP is showing up or not, but I am looping the flush
although it's crashing on the first NULL encode saying 'Integer division by
zero', even though there's clearly still a frame to be flushed out. The
only thing that makes sense to me at this point is that AAC doesn't have
CODEC_CAP_DELAY capabilities and that's causing the run-time
error...Hopefully I can update with more information about that later.

for(got_packet = 1;got_packet;) {
     fflush(stdout);
     if(avcodec_encode_audio2(c,&pkt,NULL,&got_packet) || !got_packet) {
          fprintf(stderr,"Error encoding frame\n");
     }
     else {
          av_write_frame(oc,&pkt);
          av_free_packet(&pkt);
     }
}


On Fri, May 10, 2013 at 12:15 PM, Brad O'Hearne
<brado at bighillsoftware.com>wrote:

> On May 10, 2013, at 3:44 AM, mohM <phuze9 at gmail.com> wrote:
>
> > I saw another thread on here similar to this, but it didn't really solve
> my
> > problem. Basically, I'm still working on getting my audio encoding to
> work,
> > and I'm now having trouble getting a basic audio encode to work...What
> I'm
> > trying to do is get a single frame of audio to encode. The first call to
> > avcodec_encode_audio2() is successfull, and if I leave out the flush
> loop,
> > the console output tells me:
> >
> > As far as I can understand from the documentation and my experience with
> > video encoding, this is pretty normal. When I try to flush the frame by
> > passing NULL into avcodec_encode_audio2(), however, the program crashes
> and
> > says "Integer division by zero" in mlock.c. Am I doing something wrong
> here?
> > Any ideas?
>
> Hey there...I assume the "another thread" you are referring to is mine
> that was posted a few days ago on the same topic. I can identify where you
> are coming from. This issue, its proper handling, and surrounding
> implications are not outright documented as a whole in a single place, and
> where it is referred to in documentation (several places), there seems to
> be details that have to be inferred. Disclaimer -- I am no expert on this,
> and don't know if what I put here will help solve your problem, but it's
> the best of what I understand about it, for better or worse. Hopefully it
> will help.
>
> Here's where you can find some references to discussion of this:
>
>  - avcodec.h, line 4014, frame parameter. Here it mentions using NULL to
> flush. It doesn't mention exactly whether flushing is a bulk or repeated
> operation, nor the implications for pts or dts for flushed frames here. But
> it does reference CODEC_CAP_DELAY, and if you follow to to that parameter's
> doc, there's much more helpful info.
>
> - avcodec.h, line 737, CODEC_CAP_DELAY define. Explains that encoding
> needs to end with flushing, and says in so many words that you need to
> repeat the process of passing a NULL parameter until the encoder has no
> more frames. Make sure to read the NOTE, as it gives some important
> information about pts and dts.
>
> - decoding_encoding.h, line 447, flush loop -- it says "get the delayed
> frames" --  that's essentially flushing the encoder. It doesn't do anything
> with pts and dts (nor did it for anywhere in this example, but see the
> CODEC_CAP_DELAY doc for that detail).
>
> As I understand it, the general idea is this: when you execute
> avcodec_encode_audio2, you are giving the encoder an audio buffer of
> samples to encode. The encoder may optionally populate and output a packet
> for you to do further processing (presumably stream or write to drive).
> That part you probably know and have working. In the case where the encoder
> does not populate and output a packet in that call, it may have decided for
> some encoding reason to hold the data. What that means is that after you
> send the last of your sample data to the encoder in your last normal
> avcodec_encode_audio2 call, the encoder may still be holding on to data
> that you previously sent it.
>
> You need to flush this data out of the encoder so that you can process it
> like the rest of the encoded data by repeating calls to
> avcodec_encode_audio2 with NULL as the frame parameter to tell the codec to
> release a single buffered frame. That's important -- this isn't a single
> call, it may be several. Repeat the process until got_packet_ptr returns a
> 0 value, indicating that no packet has been returned. Note that the
> decoding_encoding.c example references a use case where all of the data is
> known at the time of encoding -- in a streaming scenario, it will usually
> be the input's attempt to close the stream which should trigger the
> flushing of the codec.
>
> Note there are a number of unknowns still for me:
>
> - I do not know what codecs support CODEC_CAP_DELAY, or if there's
> something significant which determines if a codec supports it, or if it is
> entirely arbitrary.
> - I do not know whether you can or what determines if you can change the
> CODEC_CAP_DELAY value for an encoder from what it is set at after you
> create the encoder.
> - I do not know if a codec without CODEC_CAP_DELAY set can still buffer
> frames, and if so, how it would be flushed.
>
> That's the best I've pieced together. I hope it helps. If not, I wish you
> the best of success solving the problem. If I encounter anything which
> might seem relevant, I'll post it.
>
> Cheers,
>
> Brad
>
>
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130510/30b6a96b/attachment.html>