Trouble simply recording mono audio from IP camera!

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Trouble simply recording mono audio from IP camera!

Shervin Emami
Hi,

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!

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:

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

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:

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

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.

I ran a full GST_DEBUG=5 to get all log messages, that I've uploaded some of it to "https://db.tt/lE3U4f5G", 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")

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.

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.


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel