Skip to main content

Feedback Data Channels

CloudGaming uses a dedicated feedback channel for real-time performance monitoring and adaptive quality control. This channel enables round-trip time (RTT) measurement and video frame delivery tracking to optimize streaming quality.

Channel Configuration

videoFeedbackChannel

The feedback channel uses unordered, unreliable delivery with no retransmissions to minimize measurement overhead.
Source: Client/html-server/index.html:1409 Why unordered and unreliable?
  • Measurements must be instantaneous (old RTT values are useless)
  • Lost feedback packets don’t affect video delivery
  • Retransmission would invalidate latency measurements
  • Fresh data is more valuable than complete data

Message Protocols

Video Frame Ping/Pong

The host sends ping messages with encoded frames to measure delivery latency. The client immediately responds with pong messages.

Ping Message (Host → Client)

Example:

Pong Message (Client → Host)

Example:
Client implementation (Client/html-server/index.html:1416-1438):

RTT Update Message (Host → Client)

The host periodically sends calculated RTT measurements to the client for display.
Example:
Client display update (Client/html-server/index.html:1434-1437):

RTT Measurement

Calculation Method

Round-trip time is calculated by measuring the time between sending a ping and receiving the corresponding pong:
Where:
  • current_time = Host timestamp when pong is received
  • host_send_time = Host timestamp when ping was sent (echoed in pong)

Measurement Flow

Adaptive Quality Control

The feedback channel enables the host to dynamically adjust video quality based on network conditions.

Network Stats Collection

The host monitors multiple metrics beyond RTT (Host/AdaptiveQualityControl.cpp:17-44):

Network Condition Assessment

The controller categorizes network health into five levels (Host/AdaptiveQualityControl.cpp:78-118):

Adaptive Frame Dropping

Based on network conditions, the controller can drop frames to maintain smooth playback (Host/AdaptiveQualityControl.cpp:120-204):

Quality Thresholds

Default configuration values for network assessment:

Client-Side Performance Display

The client displays real-time performance metrics based on feedback data (Client/html-server/index.html:910-920):

Visual Quality Indicator

The client shows connection quality with colored bars (Client/html-server/index.html:898-909):

WebRTC Stats Integration

The client monitors WebRTC stats to measure actual network performance (Client/html-server/index.html:1238-1260):

Congestion Detection

The system detects network congestion through multiple signals (Host/AdaptiveQualityControl.cpp:240-244):
Congestion Indicators:
  • NACK (Negative Acknowledgment): Packet loss requiring retransmission
  • PLI (Picture Loss Indication): Decoder requests keyframe due to corruption
  • High pacer queue: Encoder producing faster than network can send
  • Increasing RTT: Network buffers filling up
  • Packet loss: Unreliable network path

Best Practices

For Implementers

  1. Keep feedback lightweight: Use minimal JSON to reduce overhead
  2. Never block on feedback: Use unreliable channel to avoid stalls
  3. Validate timestamps: Ensure monotonic time for accurate RTT
  4. Smooth measurements: Use moving average to filter noise
  5. React gradually: Don’t make drastic quality changes on single spikes

For Performance

  1. Minimize ping frequency: Only ping when quality decision needed
  2. Fast-path optimization: Skip mutex when network is excellent
  3. Batch updates: Send rtt_update only when value changes significantly
  4. Disable when not needed: Turn off adaptive quality on LAN

For Monitoring

Troubleshooting

High RTT Values

  • Check network path (local vs internet)
  • Verify no unnecessary proxies/VPNs
  • Test with ping to rule out host issues
  • Monitor CPU usage (processing delays)

Feedback Channel Not Opening

  • Verify WebRTC connection established first
  • Check data channel support in browser
  • Inspect signaling for channel negotiation
  • Try ordered:true if failing to open

Inaccurate Latency Display

  • Ensure client/host time sync (use relative deltas)
  • Check for clock drift on long sessions
  • Filter outliers (network hiccups)
  • Compare with WebRTC native RTT