Dynamic Switching between WebRTC and HLS

Native Frame's dynamic switching feature provides both WebRTC and HLS streaming options in a single manifest, giving you control over which protocol to use based on your specific needs.

Strategic Protocol Selection

WebRTC: For Real-time Interaction

WebRTC provides ultra-low latency streaming that's ideal for:

• Live gaming streams where viewers interact with the broadcaster
• Virtual classrooms with real-time questions
• Live Q&A sessions
• Small group interactions

For Cloud customers, WebRTC connections are currently limited to 50 concurrent viewers per stream.

HLS: For Large Audiences

HLS works best for reaching large audiences:

• Native Frame's HLS has low latency (around 4-5 seconds)
• Supports thousands of concurrent viewers
• Works on almost all devices and browsers
• More efficient bandwidth usage and caching

Smart Switching Logic Examples

You can implement various switching strategies:

1. Engagement-Based Switching: Move users who are actively engaging (through chat, reactions, etc.) to WebRTC for a better interactive experience.
2. Premium Feature Offering: Reserve WebRTC for subscribers while free users access the stream via HLS.
3. Automatic Failover: The Native Frame SDK automatically switches to HLS if WebRTC connectivity fails, ensuring continuous playback regardless of network conditions.

Resource Optimization

For Private Cloud customers with dedicated hardware:

WebRTC requires more server resources than HLS because real-time streams can't be cached as effectively. By using WebRTC only for viewers who need real-time interaction, you can serve more total viewers with your infrastructure.

Implementation Guidelines

When implementing dynamic switching:

1. Define Clear Switching Rules: Create specific conditions that trigger protocol switches.
2. Collect and Monitor Viewer Metrics: Implement analytics to track quality metrics, connection types, and viewing behavior to refine your switching logic.
3. Consider UI Feedback: When switching protocols (especially for user-initiated upgrades), notify users about changes in their experience.
4. Test Failover Scenarios: Ensure smooth transitions between protocols during network issues.
5. Working with Manifests: Clients like the Native Frame SDK typically poll the JSON manifest on a regular interval. The manifest contains details of all available formats (WebRTC, HLS, etc.) with their respective encodings and endpoints.

{
  "formats": {
    "mp4-hls": {
      "manifest": "https://example.platform.nativeframe.com/live/stream-id.m3u8",
      "videoCodec": "h264",
      "audioCodec": "aac",
      "encodings": [
        {
          "videoWidth": 768,
          "videoHeight": 432,
          "videoKbps": 1100,
          "audioKbps": 128,
          "location": "https://example.platform.nativeframe.com/hls/live/stream-id_1100_768x432_128/index.m3u8"
        }
      ]
    },
    "webrtc": {
      "origin": {
        "location": "https://nativeframe.com/lb/v2/calls/stream-id/join",
        "callId": "stream-id",
        "uri": "wss://platform.nativeframe.com/sfu/sfu_id"
      }
    }
  }
}

You can parse this manifest directly or use Native Frame SDK methods to select the appropriate streaming format based on your application's requirements. When broadcasting starts or stops, or when a stream changes authorization status, the manifest is updated accordingly.

Availability

For Cloud customers interested in expanding beyond the current 50-viewer WebRTC limit or wanting more control over resource allocation, the Private Cloud solution offers additional capabilities. Contact your Native Frame sales representative for more information.