GNOME Bugzilla – Bug 508595
[lame] wrong output caps in mono encoding mode
Last modified: 2008-01-14 09:17:40 UTC
In mono encoding mode of non-mono input, lame encoder performs downmixing (resulting in 1-channel output). However, the sink caps still retains most of the source caps (such as #channels).
Created attachment 102534 [details] [review] Possible patch. * Indicate 1 channel in source caps in mono-encoding mode. * Also fix calculation of duration of (last) buffer sent at EOS-time.
Why is this changed duration calculation correct? (and why is the old still correct for the return of lame_encode_buffer?)
lame_encode_buffer/flush (lame API calls) return number of mp3 (encoded) bytes, so a calculation based on it using samplerate (etc) does not make sense. However, (assuming CBR) based on bitrate (etc) does make sense (as it has been changed to in EOS event handling). On the other hand, in gst_lame_chain, duration calculation is based on the input buffer size (not mp3 buffer), so it makes sense there to use samplerate. [Using (possibly delayed) input buffer sizes for output buffer ones seems more or less approximate but OK, and can also handle VBR cases, but minor errors might accumulate up to the last-to-be-flushed buffer. There is also no input buffer that can be used when receiving EOS, hence best shot fall-back to mp3 buffer size]
Ok, committed. But if you're going with _bit_ rate you should divide that value by 8 again to get the correct result. Changed that... 2008-01-14 Sebastian Dröge <slomo@circular-chaos.org> Patch by: Mark Nauwelaerts <manauw at syknet dot be> * ext/lame/gstlame.c: (gst_lame_sink_setcaps), (gst_lame_sink_event): Correctly set number of channels when using mono-encoding mode and fix the duration calculation of the EOS buffer.