When the broadcast goes live, viewers shouldn't think about codecs

Viewers expect television. Browsers expect user gestures, muted autoplay, and strict cross-origin rules. Mobile OSes suspend iframes on lock and cheerfully redraw YouTube's native chrome on wake.

This project ships a single black 16:9 frame, a labeled Ativar som button, and infrastructure so boring an operator only configures OBS once. The engineering depth lives beneath intentional silence — that is the cognitive distance collapse.

I owned the live-video product end to end: product strategy, UX state model, Next.js viewer, health API, hls.js integration, YouTube fallback behavior, mobile wake handling, nginx-rtmp VM setup, TLS, OBS settings, operator page, and runbook. The assignment was not “embed a video.” It was to make a small broadcaster feel operationally credible with almost no recurring infrastructure cost.

The audience never asked for RTMP, HLS, MSE, native Safari playback, stale segment detection, iframe postMessage, or autoplay policy. They asked for television. The product challenge was to preserve that simple mental model while acknowledging every browser constraint underneath.

The final architecture is small because earlier versions were deliberately simplified. A hiring manager should care about this: senior product engineering is often the discipline of deleting plausible solutions that make operations worse.

OBS (Mac, x264, keyframe = 1s)
  rtmp://video-origin…:1935/live  (stream key: live)
    → nginx-rtmp module
        hls_fragment 1s
        hls_playlist_length 2s
        writes /var/www/hls/live.m3u8 + live-N.ts
    → HTTPS + CORS on video-origin…/hls/

Vercel Next.js (video.radioalvoradatv.com.br)
  GET /api/health → hasFreshLiveHls()
  Viewer:
    if Hls.isSupported() → hls.js MSE pipeline
    else → <video src="live.m3u8"> (Safari native)
  Off-air → cropped YouTube iframe + IFrame API postMessage

The viewer does not switch modes on a single request. It uses a small hysteresis model: two positive health checks before entering live, and two to three failures before leaving live depending on whether playback had already started. This avoids flapping when the origin or mobile network hiccups.

In plain language: the product is slightly cautious when claiming “we are live,” and slightly patient before interrupting a live viewer. That patience is a UX decision implemented as counters and polling intervals.

Off-air plays a looped YouTube VOD (not a live stream ID — loop=1 on live IDs shows “recording not available”). Embed params strip chrome: controls=0, modestbranding=1, iv_load_policy=3, enablejsapi=1, mute=1.

CSS scales the iframe 1.48× centered — cropping title bar and logo inside the same 16:9 box as live HLS. Unmute uses IFrame API postMessage (unMute, setVolume, playVideo) — never iframe src changes, which caused reload flashes.

YouTube's embed parameters can reduce chrome, but they cannot guarantee that the center play glyph, title bar, or post-lock native controls never flash. The black mask is the visual contract: the user should either see the station frame or an intentional loading state, never raw platform UI.

Initial fallback load keeps the mask for at least six seconds and waits for YouTube to report playing or buffering. Screen unlock re-applies a shorter mask, sends playVideo and mutecommands repeatedly, and then reveals the frame only after the player is active or the maximum wait is reached.

This is the featured case study because it shows the full range of work: product strategy, interaction design, browser policy research, frontend state management, streaming infrastructure, deployment, and operational documentation. It is also honest about the trade-off: HLS is not the lowest-latency technology possible, but it is the best fit for a $0, volunteer-operated broadcast stack.

If you're hiring for a remote Design Engineer, Frontend Developer, Full Stack Developer, or Product Engineer role, this page shows how I handle real-world constraints: browser policy, mobile lifecycle, infrastructure trade-offs, and clear UX.

This page is written to rank for the actual work I want to do again: HLS live streaming product design, OBS RTMP nginx architecture, mobile autoplay UX, hls.js implementation, Safari native HLS, YouTube fallback UX, low-cost broadcast infrastructure, design engineering for media platforms, and end-to-end product design for streaming tools.