On 5/10/13, Brad O'Hearne <[email protected]> wrote: > On May 10, 2013, at 3:44 AM, mohM <[email protected]> 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.
Look at encoder AVCodec .capabilities that holds flags. > - 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. No. that flag means encoder is capable of that. you can not change it. > - I do not know if a codec without CODEC_CAP_DELAY set can still buffer > frames, and if so, how it would be flushed. It should not buffer frames. > > 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 > [email protected] > http://ffmpeg.org/mailman/listinfo/libav-user > _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
