GNOME Bugzilla – Bug 350723
[mad] Wrong output buffer timestamping
Last modified: 2006-08-16 10:35:37 UTC
This may be the cause bug 349719 but I am not sure about this so I am opening a new bug. This bug was resolved and fixed by Martin Zlomek (martin.zlomek@itonis.tv) There is a bug in mad plugin caused by curious behaviour of libmad. The plugin joins incoming buffers to a temporary buffer in its _chain function. When an incoming buffer has a valid timestamp (input timestamp), the plugin uses it for timestamping of the outgoing buffer (output timestamp), otherwise "interpolates" the output timestamp from the previous input timestamp and the number of samples decoded. The activation of the new input timestamp is postponed if any data remains in the temporary buffer from the previous iteration of the chain function. The libmad decodes the data frame after frame. There is a check in the libmad call if the input buffer (i.e. the temporary buffer) has enough data. If the input buffer has not required amount of data, libmad call fails and the chain function returns to gather more data in the next iteration. The libmad call requires frame_size + MAD_BUFFER_GUARD bytes of input data. The problem occurs when the input buffer has just between frame_size and frame_size + MAD_BUFFER_GUARD bytes. In the next interation of the chain function, if the incoming buffer has a valid timestamp, then this timestamp is used just after decoding of the first frame (frame_size bytes) from the temporary buffer. This causes the timestamp hole. The input timestamp is activated too early because there is another frame which begins in the previous iteration (it has < MAD_BUFFER_GUARD bytes from the prev. iter.) and should have output timestamp "interpolated" still from the previous input timestamp. On the other hand, because of the hole, there are duplicated timestamps a few frames later. Included patch fixes this bug - it waits with the activation untill the second frame is decoded. It also fixes dropping of the exactly first frame of the whole decoding when the plugin is detecting MP3 (see the block containing mpg123_parse_xing_header()).
Created attachment 70631 [details] [review] Patch to fix wrong buffer timestamping It would be also nice to lover some GST_WARNING messages on mad decode error to GST_DEBUG since mad decoder too often warns about not having enough data to decode
Created attachment 70633 [details] Sample file to illustrate the problem This is a sample to illustrate the problem, when running the pipe gst-launch -v filesrc location=sample.mpg ! mpegdemux name=d d.audio_00 ! mad ! fakesink I see timestamp gap at 0:00:00.675989184 (next timestamp 0:00:00.723988416) and duplicated timestamp 0:00:00.795987264 With the patch applied the timestamps rise smoothly (each buffer has duration 0:00:00.023999616)
Ahh I forgot to add, the I see a bunch of WARN (0x5429f0 - 0:00:00.091057000) mad(11431) gstmad.c(1413):gst_mad_chain: mad_header_decode had an error: input buffer too small (or EOF) This is confusing since the file decodes correctly and this is actually no error.
Thanks! Patch by: Michal Benes <michal dot benes at itonis dot tv> * ext/mad/gstmad.c: (gst_mad_chain): Fix timestamping in mad by only activating a new timestamp when the previous frame has been decoded. Fixes #350723. Also clean up some of the non fatal warnings when the input buffer is too small to decode a header.