[Bug 746032] New: audiomixer doesn't handle buffers with repeating pts properly

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Wed Mar 11 06:50:08 PDT 2015


https://bugzilla.gnome.org/show_bug.cgi?id=746032

            Bug ID: 746032
           Summary: audiomixer doesn't handle buffers with repeating pts
                    properly
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: nirbheek.chauhan at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 299097
  --> https://bugzilla.gnome.org/attachment.cgi?id=299097&action=edit
Comparison of the output audio stream with and without audiomixer

If one sends a stream of buffers with duplicate pts to audiomixer, it happily
takes those as sequential buffers and increments the pts on the output buffers.
This is not how audio sinks handle buffers with duplicate pts, and causes
audio-video to go out of sync.

Tim is investigating this; pasting his findings below:

----

gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay !
rtpjitterbuffer ! rtpmp4adepay ! decodebin ! audiomixer ! audiorate !
wavenc ! filesink location=with.wav

gst-launch-1.0 filesrc location=output-gdp-audio.bin ! gdpdepay !
rtpjitterbuffer ! rtpmp4adepay ! decodebin ! audiorate ! wavenc !
filesink location=without.wav

(see attachment for how the two look like in audacity)

Basically the code that checks for discontinuities is an echo chamber, it
doesn't track divergence from actual position, but just compares each buffer
with the next.

And then after mixing a buffer it does

   pad->next_offset = buffer_end_offset;

so if you send as input:

 0-1  1-2  1-2  1-2  2-3

then it will happily increase the audiomixer output offset every time, and
next_offset will be reset on the second/third buffer (so here we lost sync to
the output offset and are now systematically behind), and we'll never exceed
any discont thresholds.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list