[gstreamer-bugs] [Bug 350723] New: [mad] Wrong output buffer timestamping

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=350723
 GStreamer | gst-plugins-ugly | Ver: 0.10.3

           Summary: [mad] Wrong output buffer timestamping
           Product: GStreamer
           Version: 0.10.3
          Platform: Other
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-ugly
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: michal.benes at itonis.tv
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


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 at 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()).


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.