From: Dantas, T. <thi...@hp...> - 2009-04-30 13:28:21
|
Guys, Could you please take me out of these e-mails please. I did the request more than 3 times into your website, but I doesn't work. Thiago Dantas -----Original Message----- From: Daniel Steinberg [mailto:daniel@InstantHarmony.com] Sent: Thursday, April 30, 2009 10:24 AM To: lam...@li... Cc: robert; Gabriel Bouvigne Subject: Re: [Lame-dev] lame_encode_flush() emits too much data btw, ffmpeg always calls lame_encode_buffer() and lame_encode_flush() with a conservatively large buffer. If the fear is that lame_encode_buffer() may overrun its buffers, then perhaps the previous style of loop control is preferable, where the internal pointers are updated each time through the loop so that it may terminate at any point with consistent state. On Thu, Apr 30, 2009 at 6:17 AM, Daniel Steinberg <da...@in... > wrote: > Two things to note: > > 1) The style of flushing that i described was working in older versions of > lame, and it works perfectly with the changes i suggest. I don't think > there is any downside to those changes....they fix some cases where > lame_encode_flush() is called only once, as well. > > 2) That style of flushing was cribbed from ffmpeg sources, which do the > same thing. Ffmpeg does some additional buffering, and each call to > avcodec_encode_audio() with a NULL input buffer results in a call to > lame_encode_flush(), accumulating any returned samples, > until avcodec_encode_audio() returns zero. > > -daniel > > On Thu, Apr 30, 2009 at 2:39 AM, robert <Rob...@gm...> wrote: > >> Am 30.04.2009, 11:01 Uhr, schrieb Gabriel Bouvigne <bou...@mp... >> >: >> >> > robert a écrit : >> >> The lame_encode_flush function has to be called once and for all at >> >> the end of encoding. The buffer has to be large enough to get all >> >> data left in one go. If we wanted to support the way Daniel is using >> >> it, then we will have to add a new output buffer stage in LAME, or add >> >> a state machine for the possibility of several calls to >> >> lame_encode_flush. >> > >> > Then I have a question: >> > If flush should be called only once, which buffer size should be used, >> > and how to be sure the buffer was big enough? (flush doesn't report -1 >> > is the buffer is too small, does it?) >> >> lame_encode_flush does return -1 if the buffer *was* too small, there is >> no way to recover then. >> >> > It seems to me that the 7200 bytes is a "safe" value only if the user >> > provided buffers big enough during the last lame_encode_buffer calls. Am >> > I missing something there? >> >> If the buffer passed to lame_encode_buffer is constantly too small, then >> at some point LAME's internal buffer will overrun and this may result in >> a fatal error, meaning abort/exit. >> The internal buffer is round about 144000 bytes large. This is likely >> too small if you feed in all of your input data in one go. >> >> The estimation taken from lame.h is quite conservative: >> mp3buf_size in bytes = 1.25*num_samples + 7200 >> >> Compare that one with a single 640 kbps frame at 32 kHz samplerate: >> framesize = 2 * 72000 * 640 / 32000 + 1 = 2881; >> >> >> >> -- >> >> >> Ciao Robert >> >> >> ------------------------------------------------------------------------------ >> Register Now & Save for Velocity, the Web Performance & Operations >> Conference from O'Reilly Media. Velocity features a full day of >> expert-led, hands-on workshops and two days of sessions from industry >> leaders in dedicated Performance & Operations tracks. Use code vel09scf >> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf >> _______________________________________________ >> Lame-dev mailing list >> Lam...@li... >> https://lists.sourceforge.net/lists/listinfo/lame-dev >> > > ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Lame-dev mailing list Lam...@li... https://lists.sourceforge.net/lists/listinfo/lame-dev |