GNOME Bugzilla – Bug 621018
rtppcmudepay cause crackling with a stream produced by an IP camera
Last modified: 2010-06-09 10:46:17 UTC
I've an IP camera (Swann IP-3G ConnectCam 1000) capable to produce an rtsp stream with mpeg4 part 2 video and mulaw audio. When I run gst-launch-0.10 playbin2 uri=rtsp://ip/mpeg4 I'm getting some crackling sound. I've tried to track it and I've observed that the depayloader is creating pairs of buffers with the same pts. I think that this might be related to the issue. Crackling is reproducible with mulaw decoder and with the pulsesink decoder.
I've captured a portion of stream into a file with the following pipeline: gst-launch-0.10 -v rtsp://192.168.1.10/mpeg4 ! gdppay ! identity ! filesink location=bruna_cam.gdp The crackling sound is reproducible with the following pipeline. gst-launch-0.10 filesrc -v location=bruna_cam.gdp ! gdpdepay ! rtppcmudepay ! queue ! pulsesink
Created attachment 163101 [details] Small clip to reproduce the issue
Created attachment 163102 [details] Log showing the duplicated pts
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.
This is played correctly in mplayer and other players. So yes, the input timestamps in payloading may be screwed up but we should be able to detect at some point down the line this case where we have the following buffers: ts a duration x ts a duration y ts a+x+y duration z . . . and adjust to: ts a duration x ts a+x duration y ts a+x+y duration z without the application having to worry about adding audiorate with relevant tolerance values.
If one would run the sink with a larger drift-tolerance, this should automagically work. Alternatively, if detecting a 'ts a' twice sequence would have to be added to (e.g.) sinks, then it might start with that case, but where it would end ... ?