Fix EUD/plugin video hairpin-NAT pull + add optional playback HLS URL override

[dfndr13]

Problem

Two related bugs prevent EUD/ATAK-plugin video from playing in some deployments:

1. Hairpin-NAT on the RTSP proxy source. When an off-host EUD or ATAK plugin publishes video, lease.proxy is set to the media service's own public hostname (media::url) — correct, since the EUD needs to reach it publicly. But when the media service itself pulls that same URL as a relay source (source in the MediaMTX path config), it's asking to reach its own public hostname from inside its own network. On networks/NAT setups that don't support hairpinning, that pull just hangs — no error at the MediaMTX layer, no timeout — and surfaces client-side as an HLS manifestLoadTimeOut.

2. No way to route HLS playback through a standard port. The media service's dedicated port (9997) is blocked outright on some networks (guest wifi, restrictive agency networks), with no way to work around it short of changing the media service's own listen port.

Fix

• A new ingestSource() helper rewrites an RTSP/RTSPS proxy source to an internal alias when its hostname matches media::url's own hostname — but only when an operator has opted in via a new media::ingest_internal_host setting. Left unset (the default), this is a complete no-op.
• A new optional media::playback_url setting lets operators serve the browser-facing HLS URL through a different host/port (e.g. a standard-port reverse proxy) without touching RTSP/RTMP/SRT/WebRTC URLs or affecting deployments that don't set it.

Both settings default to empty and are strictly additive — behavior for any deployment that doesn't configure them is unchanged.

On the ingestSource() design

The obvious version of this fix is to hardcode the internal alias to rewrite to. We deliberately didn't do that: which internal hostname (if any) is reachable is entirely deployment-specific — it depends on how an operator's media/ingest containers are networked relative to each other, which varies a lot between a plain single-container media-infra deployment, ECS, and setups with a separate ingest tier in front of it. A hardcoded value would be meaningless (or actively wrong) for anyone whose topology differs from ours, so we made it an opt-in setting that's a no-op by default instead. Open to other approaches if maintainers see a better way to express "this deployment needs a hairpin workaround" — this is the smallest one we found that can't silently misbehave for anyone who doesn't ask for it.

Validation

Both issues (the hairpin hang and the port-9997 block) were reproduced and confirmed fixed in an independent deployment running current media-infra main, separately from the environment these patches were originally written against.

Testing

• tsc --noEmit clean
• New unit tests for ingestSource() (opt-in rewrite, no-op default, non-matching hosts, non-RTSP sources, malformed URLs)
• Full existing video-lease/profile-video/connection-video-lease/schema suites pass unchanged

[Nick (ingalls)]

Thanks for the PR,

One catch to a further review/merge, The Env vars don't appear to actually work as intended from my initial test as _ maps to ::. You'll need to either namespace these config changes or change the actual name of the config value to avoid the namespace replacement from env var => internal value

[dfndr13]

Fixed the config key names — media::playback::url and media::ingest::internal::host — to match the existing ::-per-word convention in the codebase. The underscores in the original names were getting converted to :: by the config translation, splitting them into extra namespace levels the settings never actually applied to. No env var or docker-compose changes needed. Verified with full build/typecheck/test pass.