I work for the IT department of my school and I am currently re-doing the IP audio system that is used for announcements or the school bell. My school uses devices from the company "2N" for this. The audio transmission is done via multicast.
Until now, all devices used the same multicast address, which made it impossible to address only one building. So, in order to be able to address the buildings independently, I use different multicast addresses for each building.
For example:
Building A: 224.0.0.5:8910
Building B: 224.0.0.6:8910
Until now, one device was the "master" sending the school chime via the single multicast address. Unfortunately, the device is not able to address more than four multicast addresses simultaneously. Therefore I thought I could use GStreamer for this.
However, I do not manage to address the 2N devices via GStreamer. The devices are configured to a specific multicast address as shown in the example above and all use UDP port 8910. As codec I am offered PCMU, PCMA, L16 / 16kHz, G.729, G.722 in the interface. Unfortunately, the manufacturer does not publish more information.
I currently use the codec "L16 / 16kHz", because it provides the best audio quality. I can also send sounds over it via the master, but not with GStreamer.
I have tried these commands without success:
# Using "L16 / 16kHz"
gst-launch-1.0.exe -v audiotestsrc ! audioconvert ! rtpL16pay ! udpsink host=224.0.0.8 port=8910
# Using PCMU
gst-launch-1.0.exe -v filesrc location=Pausengong.wav ! decodebin ! audioconvert ! audioresample ! mulawenc ! rtppcmupay ! udpsink host=224.0.0.8 port=8910
Another complicating factor is that the 2N devices are completely silent when they receive "false data" - no crackling or noise.
I'm sorry I can't contribute more information. To be honest, I'm a bit out of my depth and can't work well with the small amount of information and the insufficient support from the manufacturer. Maybe someone here has a bright idea!
Thanks in advance!
With kind regards
Linus
I still can't believe but I solved my problem! By using Wireshark to analyse the packets sent by the original 2N master device, I discovered important parameters that have to be passed to GStreamer.
When using PCMU (G.711u) codec:
gst-launch-1.0.exe -vv filesrc location="test.wav" ! decodebin ! audioconvert ! audioresample ! mulawenc ! rtppcmupay mtu=172 ! udpsink host=224.0.0.8 port=8910 multicast-iface=192.168.52.151
If your sender device (in my case a windows PC) has multiple network interfaces, make sure that you set the multicast-iface to the IP-address of your device. When not specified the data might be sent to the wrong network interface and will never actually reach the target device.
The next thing to specify was the mtu (maximum transfer unit). As far as I could analyse with Wireshark the 2N devices require an MTU of 172 when using PCMU (G.711u).
When using L16/16kHz codec:
gst-launch-1.0.exe -vv filesrc location="test.wav" ! decodebin ! audioconvert ! audioresample ! rtpL16pay mtu=652 pt=98 ! udpsink host=224.0.0.8 port=8910 multicast-iface=192.168.52.151
Again, make sure that you have your multicast-iface set correctly. Besides that, the L16/16kHz codec in 2N devices requires an MTU of 652 and pt=98 (payload type).
I hope that this information might help others and I'm glad that the problem is solved now. The necessary values for 2N devices were reverse-engineered using Wireshark. Helpful documentation for GStreamer: https://thiblahute.github.io/GStreamer-doc/rtp-1.0/rtpL16pay.html
Related
I'm trying to build a pipeline which I'll give him 2 wav files and stream those 2 as a single RTP, which has 2 channels that each channel is composed of the relative wav file.
I want to send the RTP using RTSP as well in order to do authentication for the RTSP connection.
I've tried using this pipeline
gst-launch-1.0 interleave name=i ! audioconvert ! wavenc ! filesink location=file.wav filesrc location=first_audio_file.wav ! decodebin ! audioconvert ! "audio/x-raw,channels=1,channel-mask=(bitmask)0x1" ! queue ! i.sink_0 filesrc location=second_audio_file.wav ! decodebin ! audioconvert ! "audio/x-raw,channels=1,channel-mask=(bitmask)0x2" ! queue ! i.sink_1
Which helps to take 2 wav files and saves them as a new file.wav in the same directory.
The output of file.wav is the mixing between them and as well he has 2 channels.
I've tried manipulating this pipeline in order to achieve what I've described but the main issue is making the sink to be RTSP with RTP split to 2 channels.
If anyone has a suggestion to solve this, that would be great!
Thanks :)
RTSP is not a streaming transport protocol but a session protocol, so it's completely different from the actual streaming logic (which you can implement with a GStreamer pipeline). That's also why you have a rtpsink (which you can use to stream to RTP), but not an rtspsink for example.
To get a working RTSP server, you can use for example gst-rtsp-server, of which you can find multiple example to set it up in their repo, like this small example. Although the examples are all in C, GStreamer also provides bindings to other languages like Python, Javascript, ...
Using gstreamer I want to stream images from several Logitech C920 webcams to a Janus media server in RTP/h.264 format. The webcams produce h.264 encoded video streams, so I can send the streams to a UDP sink without re-encoding data, only payloading it.
I'm using the gst-interpipe plugin to switch between the different webcams, so that the video stream received by Janus stays the same, but with images coming from whatever webcam I choose.
It works but I'm experiencing some problems with broken frames where the colors are gray and details are blurred away, mainly the first 5 - 10 seconds after I switch between webcam source streams. After that the images correct themselves.
First frames
After 5 - 10 seconds or more
First I thought it was a gst-interpipe specific problem, but I can reproduce it by simply setting up two pipelines - one sending a video stream to a UDP sink and one reading from a UDP source:
gst-launch-1.0 -v -e v4l2src device=/dev/video0 ! queue ! video/x-
h264,width=1280,height=720,framerate=30/1 ! rtph264pay
config-interval=1 ! udpsink host=127.0.0.1 port=8004
gst-launch-1.0 -v udpsrc port=8004 caps = "application/x-rtp,
media=video, clock-rate=90000, encoding-name=H264, payload=96" !
rtph264depay ! decodebin ! videoconvert ! xvimagesink
NB: I'm not experiencing this problem if I send the video stream directly to an xvimagesink, i.e. when not using UDP streaming.
Am I missing some important parameters in my pipelines? Is this a buffering issue? I really have no idea how to correct this.
Any help is greatly appreciated.
Due to the nature of temporal dependencies of video streams you cannot just tune in into stream and expect it to be decode-able immediately. Correct decoding can only start at Random-Access-Point frames (e.g. I- or IDR-frames). before that you will get image data that rely on video frames you haven't received - so they will look broken. Some decoders offers some control on what to do on these cases. libavdec_h264 for example has a output-corrupt option. (But actually I don't how it behaves for "correct" frames which just are missing reference frames). Or they may have options to skip everything until a RAP-frame occurs. This depends on your specific decoder implementation. Note however that on any of these options the initial delay before you will see any image will increase.
I want to use Gstreamer to receive audio streams from multiple points on the same port.
Indeed I want to stream audio from different nodes on the network to one device that listen to incoming audio streams, and it should mix multiple audios before playback.
I know that I should use audiomixer or liveadder to do such a task.
But I can't do it, and the mixer doesn't act correctly and when two audio streams came, the output sound would be so noisy and corrupted.
I used the following command :
gst-launch-1.0.exe -v udpsrc port=5001 caps="application/x-rtp" !
queue ! rtppcmudepay ! mulawdec ! audiomixer name=mix mix. !
audioconvert ! audioresample ! autoaudiosink
but it doesn't work.
Packets on a same port couldn't demux from each other as normal way you wrote in your command, to receive multiple audio streams from same port you should use SSRC and rtpssrcdemux demux.
However to receive multiple audio streams on multiple ports and mix them, you could use liveadder element. An example to receive two audio streams from two ports and mix them is as follows:
gst-launch-1.0 -v udpsrc name=src5001 caps="application/x-rtp"
port=5001 ! rtppcmudepay ! mulawdec ! audioresample ! liveadder
name=m_adder ! alsasink device=hw:0,0 udpsrc name=src5002
caps="application/x-rtp" port=5002 ! rtppcmudepay ! mulawdec !
audioresample ! m_adder.
First, you probably want to use audiomixer over liveadder as the first guarantees synchronization of the different audio streams.
Then, about your mixing problem, you mention that the output sound is "noisy and corrupted", which makes me think of problem with audio levels. Though audiomixer clips the output audio to the maximum allowed amplitude range, it can result in audio artefacts if your sources are too loud. Thus, you might want to play with the volume property on both sources. See here and there for more information.
For a VoIP speech quality monitoring application I need to compare an incoming RTP audio stream to a reference signal. For the signal comparison itself I use pre-existing, special-purpose tools. For the other parts (except packet capture) the Gstreamer library seemed to be a good choice. I use the following pipeline to simulate a bare-bones VoIP client:
filesrc location=foobar.pcap ! pcapparse ! "application/x-rtp, payload=0, clock-rate=8000"
! gstrtpjitterbuffer ! rtppcmudepay ! mulawdec ! audioconvert
! audioresample ! wavenc ! filesink location=foobar.wav
The pcap file contains a single RTP media stream. I crafted a capture file that's missing 50 of the original 400 UDP datagrams. For the given audio sample (8s long for my example):
[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]
with a certain amount of consecutive packet loss I'd expect an audio signal like this to be output ('-' denotes silence):
[XXXXXXXXXXXXXXXXXXXXXXXX-----XXXXXXXXXXX]
however what is actually saved in the audio file is this (1s shorter for my example):
[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]
It seems that the jitter buffer, a crucial part for this application, is not working properly. Could this be an incompatibility with / a shortcoming of the pcapparse element? Am I missing a key part in the pipeline to ensure time synchronization? What else could be causing this?
The issue could be solved by slightly altering the pipeline:
An audiorate element needs to be added before wavenc that "produces a perfect stream by inserting or dropping samples as needed".
However this works only if audiorate receives the packet-loss events. For this the do-lost property of gstjitterbuffer needs to be set to true.
Here's the corrected pipeline:
filesrc location=foobar.pcap ! pcapparse
! "application/x-rtp, payload=0, clock-rate=8000"
! gstrtpjitterbuffer do-lost=true ! rtppcmudepay ! mulawdec
! audioconvert ! audioresample ! audiorate ! wavenc
! filesink location=foobar.wav
GStreamer may just use the dejitter buffer to smooth out the packets on the way to the (audio) output. This wouldn't be unusual, its the bare minimum definition of dejittering.
It may go so far as reordering out-of-order packets or deleting duplicates, but packet loss concealment (your scenario) can be quite complex.
Basic implementations just duplicate the last received packet, whilst more advanced implementation analyse and reconstruct the tone of the last received packets to smooth out the audio.
It sounds like your application performance will depend on the exact implementation of loss concealment, so even if GStreamer does do "something", you may have a hard time quantifying its impact on your results unless you understand it in great detail.
Perhaps you could try a pcap with a couple of out-of-order and duplicate packets and check if GStreamer at least reorders/deletes them, that would go someway to clarifying what is happening.
Ive got a project to make for a party, its called in holland a "Babbelbox".
its a computer with a webcam and microphone that can be used to make a kind of video log of everyone who wants to say something about the party.
But the problem is that i dont know where to start. ive made a kind of video show system in c but i cant save any data to a good format so it wont jam my harddisk in one hour full.
Requirements:
Record video + audio
Recoding has to start after pressing a button
Good compression over the recorded
videos (would be even better if it
can to be read by final cut pro or
premiere pro)
Light wight programm would be nice
but i could scale up the computer
power
We built one from soup to nuts. That includes software, hardware, a full booth, touch-screen, and even themed it as a cultish confessional in honor of our boss. See http://www.cultoftom.com for the gory details.
a solution for linux using gstreamer:
in ubuntu install the gstreamer-tools package
then you can record with a command similar to:
gst-launch v4l2src ! 'video/x-raw-yuv,width=640,height=480,framerate=30/1' ! tee name=t_vid ! queue ! videoflip method=horizontal-flip ! xvimagesink sync=false t_vid. ! queue ! ffmpegcolorspace ! theoraenc ! queue ! mux. autoaudiosrc ! queue ! audioconvert ! vorbisenc ! queue ! mux. oggmux name=mux ! filesink location=filename.ogv
you can adjust the resolution, framerate, filename etc as you prefer.
from there it would be fairly straighforward to write it out in python and knock up a simple gtk gui for starting / stopping. you could use a multifilesink to handle the filenames for successive recordings.
references:
http://noraisin.net/~jan/diary/?p=40
http://www.twm-kd.com/computers/software/webcam-and-linux-gstreamer-tutorial/
http://pygstdocs.berlios.de/pygst-tutorial/index.html