DOCSEARCHbyAlgolia
Submit Docs

Pion WebRTC

repository·main·Indexed 12 days ago

https://github.com/pion/webrtc

A pure Go implementation of the WebRTC API, providing a high-performance, cross-platform stack for real-time audio, video, and data communication without requiring Cgo. The library includes support for bandwidth estimation, custom logging via LoggerFactory, and idiomatic Go access to data channels through the io.ReadWriteCloser interface.

Tokens
61.8K
Snippets
259
Records
345
Agent score
96%

What's inside Pion

  1. Overview of Pion WebRTC features

    main

    Pion WebRTC is a pure Go implementation of the WebRTC API. Key capabilities include:

    PeerConnection API

    • Implementation of webrtc-pc and webrtc-stats.
    • Support for DataChannels and audio/video transmission.
    • Renegotiation and support for both Plan-B and Unified Plan.
    • SettingEngine for Pion-specific extensions.

    Connectivity

    • Full ICE Agent with support for ICE Restart, Trickle ICE, STUN, and TURN (UDP, TCP, DTLS, and TLS).
    • mDNS candidates.

    DataChannels

    • Support for Ordered/Unordered and Lossy/Lossless data.

    Media

    • Direct RTP/RTCP access.
    • Packetizers for Opus, PCM, H264, VP8, and VP9 (with support for custom packetizers).
    • Support for Simulcast, SVC, NACK, and Bandwidth Estimation.
    • Easy integration with x264, libvpx, GStreamer, and ffmpeg.

    Security

    • DTLS v1.2 with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA.
    • SRTP with SRTP_AEAD_AES_256_GCM and SRTP_AES128_CM_HMAC_SHA1_80.
    • Hardware acceleration for GCM suites.

    Platform Support

    • Pure Go: No Cgo required for core functionality.
    • Supported OS: Windows, macOS, Linux, FreeBSD, iOS, and Android.
    • WASM: Supports WebAssembly development and testing.

  2. Explore Pion WebRTC Data Channel API use-cases

    main

    The Data Channel examples demonstrate different ways to exchange non-media data:

    • Data Channels: Basic sending and receiving of DataChannel messages from a browser.
    • Data Channels Detach: Interacts with the underlying DataChannel implementation directly for a more idiomatic approach.
    • Data Channels Flow Control: Measures the rate at which the remote peer receives data to structure application logic efficiently.
    • ORTC: Uses the ORTC API for DataChannel communication.
    • Pion to Pion: Demonstrates direct communication between two Pion instances (no web page required).

  3. Explore Pion WebRTC Media API use-cases

    main

    The Media API examples demonstrate various ways to handle audio and video tracks:

    • Reflect: Sends back exactly what it receives using the same PeerConnection.
    • Play from Disk: Sends video from a local file to a browser.
    • Play from Disk Renegotiation: Demonstrates adding or removing video tracks from an existing negotiated PeerConnection.
    • Insertable Streams: Demonstrates E2E encrypted video using insertable streams in the browser.
    • Save to Disk: Records webcam footage and saves it to the server side.
    • Broadcast: Forwards a single video upload to multiple peers.
    • RTP Forwarder: Forwards audio/video streams using RTP.
    • RTP to WebRTC: Ingests RTP packets into a Pion process and sends them to a browser.
    • Simulcast: Accepts one track containing 3 Simulcast streams and returns them as 3 independent tracks.
    • Swap Tracks: Dynamically routes 3 incoming media streams back to the user as a single stream.
    • RTCP Processing: Accesses media statistics and control information via RTCP APIs.
    • Quick Switch: Uses WebRTC to switch quickly between different video feeds.

  4. Use vnet to simulate network conditions

    main

    vnet is a virtual network layer for Pion designed to simulate real-world network issues and topologies. It is used to test how WebRTC applications perform under adverse conditions or to validate network requirements (like STUN/TURN necessity).

    Key capabilities include:

    • Simulating Network Topologies: Assert when STUN/TURN servers are required.
    • Simulating Network Impairments: Inject packet loss, jitter, and packet re-ordering.
    • Bandwidth Measurement: Measure total bandwidth usage to estimate operational costs.

  5. Explore Pion WebRTC Miscellaneous and Networking use-cases

    main

    These examples cover specialized networking and system configurations:

    • Custom Logger: Overrides default logging to process messages instead of printing to stdout.
    • ICE Restart: Demonstrates WebRTC connection roaming between networks by restarting ICE in a loop.
    • ICE Single Port: Configures Pion to serve multiple PeerConnection instances from a single port (default is one port per connection).
    • ICE TCP: Configures Pion to use a TCP port instead of the default UDP.
    • ICE Proxy: Demonstrates using a proxy for TURN connections.
    • Trickle ICE: Demonstrates the Trickle ICE APIs to allow ICE gathering and connecting to happen concurrently.
    • VNet: Demonstrates Pion's network virtualization library by connecting two PeerConnection instances over a virtual network.

  6. Demonstrate Forward Error Correction (FlexFEC-03) with play-from-disk-fec

    main
    The play-from-disk-fec example demonstrates how to use FlexFEC-03 (Forward Error Correction) to send video from a file on disk to a Chrome-based browser. The example is specifically configured to simulate a high-loss environment where 40% of media packets are dropped, allowing the browser to recover the video using FEC packets and the successfully delivered packets.

  7. What is Trickle ICE?

    main

    ICE (Interactive Connectivity Establishment) is the subsystem WebRTC uses to establish connectivity between peers.

    Trickle ICE is a highly recommended optimization where ICE candidates are shared with the remote peer as soon as they are gathered, rather than waiting for the entire gathering process to complete. This significantly reduces the time required to establish a WebRTC connection by allowing the remote peer to start attempting connections with TURN servers and other addresses in parallel.

  8. What is ORTC in Pion WebRTC?

    main
    ORTC (Object Real-Time Communications) demonstrates Pion WebRTC's ability to use APIs for configuration and communication instead of the traditional Session Description Protocol (SDP). While SDP is commonly used to parse/emit session descriptions, ORTC provides a programmatic way to implement WebRTC. This allows developers to implement their own signaling protocols (such as the JSON-based protocol used in the ortc-media example) independently of the WebRTC implementation itself.

  9. How the data-channels signaling handshake works

    main

    Since this example does not use an automated signaling server, it uses manual SDP exchange:

    1. Browser Offer: The browser generates an SDP (Offer) and displays it in a text box. The user copies this string.
    2. Server SetRemote: The user provides this string to the Go server via stdin. The server calls SetRemoteDescription with this offer.
    3. Server Answer: The server creates an SDP (Answer), waits for ICE gathering to complete, and prints the resulting base64 string to stdout.
    4. Browser SetRemote: The user copies the server's string from the terminal and pastes it into the JSFiddle interface. The browser calls SetRemoteDescription with the server's answer, completing the handshake.
    5. Connection: Once the connection is established, the OnDataChannel handler triggers, allowing bidirectional message exchange.

  10. How to share a single port across multiple PeerConnections

    main
    By default, Pion WebRTC has no global state, meaning ports cannot be shared between different PeerConnection instances. To allow multiple PeerConnection objects to use the same port (e.g., for a single remote port), a developer must use the SettingEngine to manually share state between them. This is useful for scenarios where you want to serve many connections through a single network port.

  11. How WHIP/WHEP-like signaling works with DataChannels

    main

    This implementation uses a signaling pattern inspired by WHIP (WebRTC-HTTP Ingestion Protocol) and WHEP (WebRTC-HTTP Egress Protocol).

    In this pattern:

    1. An Offer is uploaded to the server via an HTTP request.
    2. The server responds with an Answer.

    While the official WHIP/WHEP specifications focus exclusively on media streaming (audio/video), this example extends the API contract to support WebRTC DataChannels, allowing for peer-to-peer chat functionality alongside the signaling flow. This approach provides a strong, simple API contract that is easy to integrate into web applications and tools like OBS.

  12. Detach a data channel to use the io.ReadWriteCloser interface

    main

    The data-channels-detach example shows how to detach a WebRTC data channel. Detaching allows you to interact with the underlying pion/datachannel using a more idiomatic Go API based on the io.ReadWriteCloser interface, rather than the standard WebRTC data channel API.

    To use this pattern, you typically pair it with a corresponding creation example (like data-channels-detach-create). In a manual testing scenario, you run both examples and exchange the SDP offer/answer text by copy-pasting them between terminals.