Olivier Crête
April 25, 2017
Share this post:
Reading time:
GStreamer is great for all kinds of multimedia applications, but did you know it could also be used to create studio grade professional audio applications? For example, with GStreamer you can easily receive a AES67 stream, the standard which allows inter-operability between different IP based audio networking systems and transfers of live audio between profesionnal grade systems.
 |
| Figure 1. AES67 at the NAB Show in Las Vegas, April 22-27. |
Receiving an AES67 stream requires two main components, the first being the reception of the media itself. AES67 is simple because it's just a stream of RTP packets containing uncompressed PCM data. In other words, this means it can be received with a simple pipeline, such as "udpsrc ! rtpjitterbuffer latency=5 ! rtpL24depay ! ...". There isn't much more needed, as this pipeline will receive the stream and introduce 5ms of latency, which, as long as the network is uncongested, should already sound great.
The second component is the clock synchronization, one of the important things in Pro Audio. The goal of this component is for the sender and the receiver of the audio to use the same clock so that there aren't any glitches introduced by a clock running to fast or too slow. The standard used for this is called the Precise Time Protocol version 2 (PTP), defined by the IEEE 1588-2008 standard. While there are a number of free implementations that can be used as master or slave PTP clocks, GStreamer provides the GstPTPClock class that can act as a slave that can synchronize itself from a PTP clock master on the network.
The AES67 standard also defines a SDP based format to describe all of these elements in a concise format. What it does not describe however, is how to transfer this file from the sender of the audio to the receiver, which is left to an application specific system. Assuming that we can just download the file, there is another very useful GStreamer element that can help us, called "sdpdemux". This is not really a demultiplexer like mp4demux or oggdemux, it is instead an element that reads a SDP file and then creates the appropriate sources based on the information it contains. Basically, this means if the sdp file if downloaded, it can be "played" like any other media file with "gst-play-1.0 file.sdp".
GStreamer is a powerful multimedia framework that can be easily used to create powerful profesionnal multimedia applications. Whether its audio/video playback, capture, editing, transcoding, calling or streaming, Collabora has been working on GStreamer for over a decade and is uniquely positioned to provide the expertise you need to create your A/V device. Let's talk and see how we can help!
19/12/2024
In the world of deep learning optimization, two powerful tools stand out: torch.compile, PyTorch’s just-in-time (JIT) compiler, and NVIDIA’s…
08/10/2024
Having multiple developers work on pre-merge testing distributes the process and ensures that every contribution is rigorously tested before…
15/08/2024
After rigorous debugging, a new unit testing framework was added to the backend compiler for NVK. This is a walkthrough of the steps taken…
01/08/2024
We're reflecting on the steps taken as we continually seek to improve Linux kernel integration. This will include more detail about the…
27/06/2024
With each board running a mainline-first Linux software stack and tested in a CI loop with the LAVA test framework, the Farm showcased Collabora's…
26/06/2024
WirePlumber 0.5 arrived recently with many new and essential features including the Smart Filter Policy, enabling audio filters to automatically…
Whether writing a line of code or shaping a longer-term strategic software development plan, we'll help you navigate the ever-evolving world of Open Source.
한국어 버전의 Collabora.com 보기
Acesse Collabora.com em Português
Comments (12)
Gordon Luk:
Apr 27, 2017 at 07:44 AM
Like AES67 topic very much. Please write more detail steps/commands on play AES67 streaming. Thanks.
Reply to this comment
Reply to this comment
radiorob :
Mar 13, 2018 at 06:35 AM
For AES67 to work with gstreamer, there needs to be a SIP component. Is there any updates on having a SIP solution with gstreamer?
Reply to this comment
Reply to this comment
Olivier Crête:
Mar 13, 2018 at 04:01 PM
SIP is a pretty awful protocol, so all implementations are pretty nasty and we generally declared it to be outside the scope of GStreamer. So normally what you would do is use an existing SIP stack such as pjsip or sofiasip and then do the media streaming with GStreamer. That said, I'm not sure exactly how AES67 does that as the spec is not publicly available which makes Open Source implementations difficult. Or you can just download the SDP over HTTP like Ravenna does.
Reply to this comment
Reply to this comment
EGF TECH MAN:
Sep 27, 2018 at 10:12 PM
SIP is not awful protocol, it is an extensible messaging protocol...Yes I would recommend integrating something like PJSIP if you don't want to write your own SIP stack (in fact Asterisk is dumping their chan_sip in favor of pjsip in current and future releases), in the context of AES67, it is a universal method of exchanging SDPs and managing a unicast connection. See slide 27 of https://archive.fosdem.org/2017/schedule/event/om_aes67/attachments/slides/1399/export/events/attachments/om_aes67/slides/1399/AES67_Slides.pdf
Reply to this comment
Reply to this comment
Olivier Crête:
Oct 01, 2018 at 07:32 PM
I'm actually working with PJSIP as we speak, it's kind of ok, but when you look deeper into it, the nastier bits of SIP quickly come into view. And I have the same experience with other SIP libraries. They always seem to abstract too little (sofia-sia expects the application developer to be familiar with all of the SIP status codes), or too much (PJSIP hardcodes RFC 2833 telephone-event as an example).
Having DNS-SD/mDNS sounds much saner for multicast type applications.
Reply to this comment
Reply to this comment
EGF TECH MAN:
Sep 28, 2018 at 04:17 PM
AES70 specifies using mDNS and DNS-SD (combination also known as Bonjour ) to advertise SDP, among other control and monitoring - but AES67 specifies no method (other than SIP for unicast) for advertising SDPs and each vendor has their own solutions making it not the holy grail of interoperability that it is promised to be
Reply to this comment
Reply to this comment
Emir Onat:
Nov 06, 2019 at 03:11 AM
Can Gstreamer be used for 2110-20 (Video)
Reply to this comment
Reply to this comment
Olivier Crête:
Nov 06, 2019 at 03:17 PM
In theory, GStreamer works just fine with ST2110-20 video. In practice, you'll find that the performance makes it useless beyond SD video. You really need userspace network stacks right now for high bitrate video and GStreamer currently isn't suitable for that.
Reply to this comment
Reply to this comment
Emir Onat:
Dec 11, 2019 at 07:04 AM
What other PC based applications are out there that can play back ST2110?
Reply to this comment
Reply to this comment
Jacques Navarre:
Dec 16, 2019 at 06:27 AM
Does your comment apply to a wide st2110-21 sender as well ? Are you aware of any active work to optimize the network stack in order to address this limitation ?
Reply to this comment
Reply to this comment
Olivier Crête:
Dec 16, 2019 at 04:23 PM
Yes, sadly, the performance of the Linux kernel stack is completely inadequate for high bitrate video streaming over UDP. The solution is to use a userspace networking stack. There are a couple of solutions out there. But anything not bypassing the Linux kernel is probably many many years away. The whole networking stack in Linux was really not designed for that.
Reply to this comment
Reply to this comment
Jacques Navarre:
Dec 16, 2019 at 06:29 AM
Does your comment apply to a wide st2110-21 sender as well ? Are you aware of any active stack work NIC driver optimization to reduce the number of copies help ? Thanks
Reply to this comment
Reply to this comment
Add a Comment