GNOME Bugzilla – Bug 652150
[lamemp3enc] Lame encoder generates incorrect timestamps
Last modified: 2011-12-26 17:50:50 UTC
Created attachment 189507 [details] [review] Initial patch The encoder takes timestamp from input buffer and calculates the duration according to number of samples in input buffer and then sets these on output buffer. This is wrong however as Lame output is always (unless flushed) shorter than the length of input buffer. Lame buffers certain number of samples, those will be outputted in next iteration, however the timesamp and duration on output buffer don't reflect this. Attached a patch fixing this.
I apologize for the formatting. I can upload correctly formatted patch on request.
Also I'm not sure how well this works for VBR (I only tested it for CBR). On the other hand the current state is that timestamps are broken for both CBR and VBR.
The patch only fixes timestamps with constant bitrate. I guess the proper solution is not to just try fix the timestamps but make sure that the encoder outputs entire frame instead of what it does now.
The first step is to fix up what the lame library is creating, and push only properly framed buffers. Timestamps for framed buffers are well-defined.
Review of attachment 189507 [details] [review]: Same as what I said in the previous comment.
*** Bug 652154 has been marked as a duplicate of this bug. ***
lame(mp3enc) has been ported to audioencoder by now, and following has lame(mp3enc) perform some parsing on lame library provided date to ensure framed output (which will then have meaningful and correct ts as arranged by audioencoder base class): commit e21ba604a4205fd6bf58bfa040cf26ff1e56397b Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon Dec 26 18:23:52 2011 +0100 lamemp3enc: ensure parsed output ... by doing some basic parsing of encoded lame data. Fixes #652150.