Approach

Start with the media problem, not the framework.

The first goal is to understand where complexity belongs. The second is to build the prototype that can provide the correct architecture.

Intuition

Mapping the inputs, outputs, codecs, timing, target devices, privacy constraints and deployment model - Easily thorugh this webassembled stream player.

Prototype

Build the hard media path first. Make the pipeline observable and measure it on the real target platform rather than assuming desktop behaviour transfers to the browser.

Measure

Compare CPU time, memory use, latency, file size, quality and operational complexity. The result should make the next technical decision easier.

Integrate

Only after the media path is proven should it be wrapped in the web interface, Qt/QML application or backend system your product needs.

Where this is heading

Client-side media is the product feature, not just a technical trick.

WebAssembly makes it possible to move selected deterministic processing into the browser. That can reduce data movement for some workloads, while still leaving room for server-side processing when it is the better fit.

A useful pilot

Two streams in. One controlled output.

Start with one reproducible use case: choose a video track, choose an audio track, preview the result, export it, then benchmark the same pipeline natively and in the browser.

Another use case free of charge under the work page: choose up to 12 video / audio tracks, choose the overlaying text yourself, and watch the magic unfold. Download the assembled stream easily.

Native C++ / FFmpeg reference
Emscripten / WASM implementation
Browser UI and worker model
Export and validation
Performance comparison