HydraIssues

Issues / #129
Investigate adaptive bitrate + cross-venue path lessons for hydraheadwebstream
open improvement Project: hydraheadwebstream Reporter: cederik 29 Apr 2026 21:50

Description

Background

While debugging cross-venue streaming on the native (Moonlight) head path today, we hit two issues that turned out to apply to any head ↔ body stream over hydraguard-air:

  1. Cosmic-pretzel firewall popup blocking first-peer Sunshine connections (resolved in #126: WG interface set to Private + NotifyOnListen=False + reboot).
  2. Cross-venue UDP packet loss at the hardcoded 150 Mbps native-Moonlight bitrate, saturating the venue's consumer-ISP uplink (resolved in hydraheadflatscreen v2.0.32: adaptive bitrate, 150 Mbps LAN / 25 Mbps WG, route-derived from 10.10.0.0/16 membership).

hydraheadwebstream is the WebRTC variant of the head — different transport (WebRTC over hydraneckwebrtc, not Sunshine/Moonlight directly), different defaults (per memory: WebRTC defaults to 720p30 @ 5 Mbps, much more conservative than native), but it streams the same bodies over potentially the same network paths.

This issue is to investigate whether either lesson translates and whether code changes are warranted.

Questions to answer

  1. Does hydraheadwebstream traverse hydraguard-air for cross-venue cases, or does it always go through the hydraneckwebrtc relay (and therefore over a server-grade uplink, not consumer)? If always via relay, neither fix likely applies.

  2. Does the WebRTC pipeline have a hardcoded bitrate anywhere upstream of the negotiated session (e.g. an offer constraint, an encoder preset), or is it fully adaptive via WebRTC's congestion control (REMB / GCC)?

  3. Does the body firewall popup affect WebRTC pairing? Sunshine's pairing protocol is what got prompted by Windows Defender — WebRTC may have a different pairing path (or none at all if the relay is a long-lived peer). If WebRTC pairing reuses Sunshine, the fix in #126 was a fleet-wide fix; if not, web-streams were never affected.

  4. Cross-venue eligibility (#116): the agent's discoverBody failover loop now does same-owner cross-venue. Does hydraheadwebstream have an equivalent or does it rely on a single configured body?

Files / starting points

  • /home/claude-user/hydraheadwebstream/ — repo root
  • Search for bitrate|150000|5000|kbps to find any hardcoded transport limits
  • Search for wireguard|hydraguard-air|10.10 to find route-awareness
  • Check whether the WebRTC offer constraints adapt to peer location

Out of scope

  • Migrating native heads to WebRTC (that's a separate architecture decision)
  • Replacing hydraguard-air with native WebRTC peer-to-peer (orthogonal)

Suggested approach

A 30-minute read-only audit: grep for the four signals above, sketch the data flow head ↔ relay ↔ body, decide whether anything from hydraheadflatscreen v2.0.32 (pkg/client/moonlight.go:moonlightStreamArgs) applies to the WebRTC offer/answer construction. File a follow-up issue with concrete code changes if anything is actionable.