<div dir="ltr"><div>Hi,<br><br>For weeks I've been having trouble combining 2 audio streams into a single stream, but I narrowed the problem down as much as possible and now I realize I can't even record mono audio from a single IP camera to disk without significant audio loss!<br></div><br>Here is my pipeline, the generated AVI file has roughly 1 audio drop per second, even when running on an x86 Core i7 PC using today's Git "master" branch of Gstreamer built from source:<br><br>gst-launch-1.0 -e  rtspsrc location=rtsp://cam protocols=tcp latency=2000 ! queue ! application/x-rtp, media=audio ! rtppcmudepay ! mulawdec ! audiorate silent=false ! avimux ! filesink location=out.avi<br><div><div><div class="gmail_extra"><br></div><div class="gmail_extra">I looked at the Gstreamer source and tried to figure out if Gstreamer is getting correct timestamps from my IP camera but due to the complexity of timestamps in the code I couldn't figure out anything useful. I did notice a large number of log messages that I think indicate that perhaps timestamps weren't obtained from the camera:<br><br>GST_SCHEDULING gstpad.c:4194:gst_pad_chain_data_unchecked:<rtpsession0:recv_rtp_sink> calling chainfunction &0x7f3018aad5e0 with buffer buffer: 0x7f3014060060, pts 99:99:99.999999999, dts 99:99:99.999999999, dur 99:99:99.999999999, size 1472, offset none, offset_end none, flags 0x4000<br><br></div><div class="gmail_extra">But I don't understand the code well enough to know if this really means Gstreamer couldn't get correct timestamps from my camera or if those messages are normal.<br></div><div class="gmail_extra"><br>I ran a full GST_DEBUG=5 to get all log messages, that I've uploaded 
some of it to "<a href="https://db.tt/lE3U4f5G">https://db.tt/lE3U4f5G</a>", surrounding the audio drop that 
occurred at time "0:00:08.183688522". (Indicated in the log by "gstaudiorate.c:551:gst_audio_rate_chain:<audiorate0> inserting 342 samples")<br><br></div><div class="gmail_extra">Note that the audio is PCM mulaw format G.711 (Mono, 8KHz sampling rate, 16-bit samples compressed as 8-bit data). I get the same results when using Gstreamer 1.2.4, Gstreamer 1.8.2 or today's Gstreamer git "master", and the same results whether I run it on an x86 or a Jetson TK1 ARM CPU, and I get the same results with my 2 different brands of IP cameras. So I get the impression that either I'm simply not using Gstreamer correctly, or Gstreamer doesn't know how to get timestamps from IP cameras.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">And note that if I remove the "audiorate" element from the pipeline, there aren't any audio drops at all, but the audio is grossly out-of-sync with any other stream I integrate to the pipeline.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Cheers,<br>Shervin Emami.<br><a href="http://www.shervinemami.info/Robotics_Engineer.html" target="_blank">http://www.shervinemami.info/Robotics_Engineer.html</a><br></div></div></div></div></div>
<br></div></div></div></div>