Project Stream

The Problem

Professional streaming tools offer control, but that control often comes with extensive setup. Simpler experiences can move much of that complexity into proprietary services for coordination, composition and distribution.

Project Stream asks how much of that simplicity can be explored while keeping core audiovisual processing on the host computer. The goal is to keep capture, composition, rendering, encoding, recording and transmission close to the person producing the stream, avoiding proprietary cloud video infrastructure.

My Role

At this stage, my work focuses on product vision, candidate architecture, PoC scope, trade-offs and risk reduction. Before building an MVP, I am defining which decisions need evidence and which promises cannot yet be made.

That includes the intended experience for hosts and guests, the limits of local hardware, connectivity, stack alternatives and distribution implications.

Local Control, Simpler Experience

The proposal is to give the host control over a streaming studio without exposing the full complexity of an audiovisual pipeline in the product experience. Layouts, templates and automation are planned possibilities, subject to what the PoC confirms about integration, performance and operation.

The core processing principle is local-first. It does not imply an absence of external services.

The Biggest Risk Is Connectivity

Remote guests may require signaling, STUN, TURN, relay or other auxiliary services. NAT, CGNAT, firewalls and changing network conditions make connectivity one of the project’s main uncertainties.

No cloud video processing does not mean no external services. The candidate architecture needs to show when a direct connection is viable and when assisted connectivity becomes necessary.

The scenarios under consideration are local network, direct internet connection and assisted connectivity. They are architecture hypotheses, not implemented modes.

Candidate Architecture

Technical hypothesis to be validated through the PoC.

Tauri + Rust is the candidate for the desktop layer. Qt + C++ remains an alternative if the PoC shows that preview, native integration or source control carry too much cost in this proposal.

libobs is a candidate because it provides a mature foundation for capture, composition, encoding, recording and streaming. The intention is not to rebuild a media engine from scratch. The choice needs assessment alongside the distribution model before a commercial launch, including GPL licensing implications.

What the PoC Needs to Prove

The next step is not to add features. It is to reduce the uncertainties that determine whether the architecture is worth pursuing.

1. Can libobs be integrated reliably within the desktop application?
2. Is Tauri + Rust + C++ sustainable for preview and source control?
3. Can one WebRTC guest be received and composed in a controlled environment?
4. Can the composition be recorded or streamed over RTMP with enough stability to justify further investment?
5. What is the actual CPU and GPU cost before setting guest or resolution limits?
6. Which network conditions require auxiliary infrastructure?

These are risk questions, not a list of delivered capabilities. The PoC succeeds when it provides enough evidence to decide whether the technical direction deserves the next investment.

Key Risks

The first PoC is guided by the integration of libobs and WebRTC, connectivity in real networks, CPU and GPU load, audio and video synchronization, and technology distribution implications. Each one affects the product experience and needs testing before the scope expands.

High-Level Roadmap

Discovery / Pre-PoC → Audiovisual PoC → MVP → Advanced Capabilities → Commercial Readiness

This is the current plan, not a delivery commitment. Progress depends on what the PoC reveals about feasibility, development cost and the user experience.

Where Project Stream Stands Today

Project Stream is in Discovery / Pre-PoC. The product vision, candidate architecture, main flows and technical risks are mapped. There is no functional MVP yet, and the central decisions around audiovisual integration and connectivity still need to be proven in the first PoC.

For that reason, no planned capability is presented here as delivered, and there are no user, performance or impact metrics yet.

What I Want to Learn First

I want to learn whether native integration, hardware cost, guest connectivity, audiovisual stability, development complexity and distribution constraints can support a sustainable product foundation.

What This Project Demonstrates

• Technical Product: translating a product vision into technical decisions and testable questions.
• Product Architecture: defining boundaries between interface, control, media, connectivity and persistence.
• Risk Reduction: identifying technical uncertainty before investing in an MVP.
• PoC Scoping: defining the smallest experiment that can test the riskiest decisions.
• Product × Engineering: connecting the desired experience to technical limits and implementation trade-offs.