GNOME Bugzilla – Bug 581292
LAME plugin doesn't correctly flush the encoder on EOS/FLUSH events
Last modified: 2009-05-06 08:17:30 UTC
+++ This bug was initially created as a clone of Bug #494528 +++ *on GST_EVENT_FLUSH_STOP, you are using a buffer of 7200. Why not always using the same buffer value, both when encoding and on closing? (mp3_buffer_size = 1.25 * num_samples + 7200) 7200 will sometimes not be big enough. The same issue is on EOS event. Also on FLUSH_START we should probably call encode_flush_nogap() and send the resulting data downstream and not just drop it in FLUSH_STOP. The problem now is, that we need to either provide a large enough buffer to the flush functions to keep all encoded data (otherwise we drop some audio) or to call it until no data is left.
Gabriel, any news on how to either get the required buffer size for flushing or how to check if there's still data queued up?
I asked Robert (current maintainer) about it, and here are the results: * the (mp3_buffer_size = 1.25 * num_samples + 7200) value for encoding is quite conservative, and should be more than enough as long as you don't feed more than Lame's internal buffer at once (about 144000 bytes large) * for the flush function, 7200 should be more than enough, provided you respected the upper condition. * flush will return -1 if the provided buffer was not big enough, but unfortunately there is NO way to retry. * the fact that the flushing function doesn't 0 after the first call is likely a bug, as it is not supposed to be called more than once Btw, in your case I don't think you should care about the xxx_nogap functions. So it seems to be that there is no flushing issue right now within your plugin (and it was a false report from my side). The only potential issue would be the very rare case where the gstreamer input buffer is bigger than Lame's internal buffer.
Thanks Gabriel, I'll close this bug then :)