GstKinesisWebRTC Functionality
| GstKinesisWebRTC Amazon Kinesis WebRTC GStreamer Plugin |
|---|
 |
| Context Overview |
| GstKinesisWebrtc Description |
| Evaluating GstKinesisWebRTC |
| Getting the code |
| Building GstKinesisWebRTC |
| Getting Started |
| Contact Us |
|
The kinesiswebrtcbin uses the Kinesis Video Streams with WebRTC signaling. When the element is starting it connects to the signaling using the AWS credentials. The element creates or uses an existing signaling channel to set up and configure a peer-to-peer connection with each of the viewers or the master connected to the same signaling channel.
Each peer will offer an SDP through the signaling channel with information about the session it wants to establish, the codec to use, whether it is audio or video session, and ICE candidates (IP and port pairs that the element can attempt to use to connect to peer). When the kinesiswebrtcbin is configured as Master and it receives an offer, it initiates a new session and starts setting up a peer connection. It uses the Amazon Kinesis STUN and TURN servers to gather the ICE candidates, and sends an answer message through the signaling channel. The answer defines a session that can send and receive audio and video, has a video track of VP8 format, and an audio track of OPUS format. In contrast, when kinesiswebrtcbin is configured as Viewer it creates the offer and the session and then it finishes setting up the peer connection once it receives the answer message from the Master.
After the SDP exchange, the Kinesis library ICE algorithm will check connectivity with the list of candidates, select a pair, and indicate that a peer-to-peer connection started.
The element starts pushing audio/video buffers to the RTC transceiver and waits for peer buffers to push them downstream in the pipeline. See the next section for more information of the element configurations.
When the peer disconnects the signaling informs through a message and the peer connection session is removed from the element.
