[gstreamer-bugs] [Bug 621018] rtppcmudepay cause crackling with a stream produced by an IP camera

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=621018
  GStreamer | gst-plugins-good | git

Mark Nauwelaerts <mnauw> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mnauw at users.sourceforge.net
         Resolution|                            |NOTABUG

--- Comment #4 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2010-06-09 09:16:49 UTC ---
It does not look like rtppcmudepay is causing anything here.

An excerpt of gdpdepay ! rtppcmudepay ! fakesink is:
----
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
( 1024 bytes, timestamp: 0:01:57.301932429, duration: 0:00:00.128000000,
offset: -1, offset_end: -1, flags: 1) 0x26de820"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
(  896 bytes, timestamp: 0:01:57.301932429, duration: 0:00:00.112000000,
offset: -1, offset_end: -1, flags: 33) 0x26deaa0"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
( 1024 bytes, timestamp: 0:01:57.560319509, duration: 0:00:00.128000000,
offset: -1, offset_end: -1, flags: 1) 0x26dec20"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
(  896 bytes, timestamp: 0:01:57.560319509, duration: 0:00:00.112000000,
offset: -1, offset_end: -1, flags: 33) 0x24f0680"
----
which indeed has duplicate timestamps, but it can not be blamed for that, since
the input is as follows (gdpdepay ! fakesink):
----
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
( 1036 bytes, timestamp: 0:01:57.301932429, duration: none, offset: -1,
offset_end: -1, flags: 0) 0x22fd940"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
(  908 bytes, timestamp: 0:01:57.301932429, duration: none, offset: -1,
offset_end: -1, flags: 0) 0x212c600"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
( 1036 bytes, timestamp: 0:01:57.560319509, duration: none, offset: -1,
offset_end: -1, flags: 0) 0x22fd9c0"
/GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain   ******* <
(  908 bytes, timestamp: 0:01:57.560319509, duration: none, offset: -1,
offset_end: -1, flags: 0) 0x22fdc40"
----

So it looks like the IP source produces 1920 (for rate 8000) samples in a
packet, which is then split during payloading (but still given identical ts). 
While the timestamp progress from one change to the next looks about ok for
corresponding samples (within sink drift tolerance).  However, buffers with
identical timestamp will likely trigger an implicit DISCONT at the sink, and
may as such cause distortion.

But, as illustrated, the root cause is in the incoming packets, and other
tricks/hacks might have be used to straighten out the timestamps (e.g.
audiorate with a large tolerance).

As such, closing, feel free to re-open with other data where applicable.

-- 
Configure bugmail: https://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.