# Real-time video as the product: consultations, commerce, events and broadcasts that have to work first time For products where the live session is what you sell rather than a feature of a classroom: telehealth, live commerce, auctions, webinars, fitness and creator platforms. We choose the protocol by format and cost, then build ingest, delivery, recording and playback that hold up in production. ## Who this is for - A telehealth or advisory product where the consultation is the service - A commerce or auction platform where a live session drives the sale - An events or webinar product that must scale to thousands at once - A creator, fitness or coaching platform selling live sessions directly - A team whose existing video feature is unreliable and nobody owns it ## What you get - A format-by-format cost model and a provider recommendation, in writing - The rooms or broadcast surface itself, with roles and admission control - A recording pipeline with confirmed uploads and monitored failures - Playback with access control, on web and mobile - Load-test results at your expected concurrency, and a failover plan ## What we build ### Interactive rooms Small, low-latency sessions where everyone can speak. The hard parts are roles and permissions, not the video itself. - WebRTC over a selective forwarding unit, sized for the room - Explicit roles: host, participant, moderator, viewer, enforced at token issue - Screen share, active-speaker detection, mute and remove controls - Waiting rooms, admission control and identity carried in the join link - Network degradation that drops video before it drops the call ### One-to-many broadcast A different product from a meeting, with different economics. Thousands watch, one or two speak. - RTMP and SRT ingest from software encoders and hardware - HLS and low-latency HLS delivery, so any device can play it - Chat at audience scale, with per-person rate limits and moderation - DVR and catch-up, so a late viewer is not locked out - Host-side ingest health, so a broken stream is visible before viewers complain ### Recording, transcoding and video on demand Most live video failures are really recording failures. We design the confirmation step, not just the capture. - Composite recording of the whole session, not one participant's feed - An explicit upload-confirmation step, monitored, so nothing silently vanishes - Adaptive-bitrate transcoding and CDN delivery for replay - Thumbnails, chapters, transcripts and captions - Retention policies and legal hold where the sector requires them ### Delivery, access control and rights Who may watch, from where, and for how long. - Signed, expiring URLs and token-authenticated playback - Geographic and referrer restrictions where licensing requires them - Widevine and FairPlay DRM for premium content - Watermarking and session-level access logs ### Scale, cost and reliability Live video is the line item that surprises people. We model it before you commit. - Cost per stream-hour modelled per format before a provider is chosen - Usage ceilings and alerts, per tenant and per day - Load tests at the concurrency you actually expect, not a demo of five - Multi-region strategy and failover when a provider degrades ### Provider selection and migration We have shipped on several, retired one, and migrated live traffic between them. That experience is the service. - An evaluation of Agora, AWS IVS, LiveKit, Daily, Cloudflare Stream and Mux against your formats - An adapter layer, so a provider change is a configuration change rather than a rewrite - Migration of live traffic without losing recordings or history - An exit plan written down before you are locked in ## How the engagement runs 1. **Format and cost assessment** — What each session type actually is, how many people are in it, and what it costs per hour. 2. **Provider selection** — A recommendation with the numbers behind it, and an adapter so the choice is reversible. 3. **Build and load test** — Ingest, delivery, recording and playback, proven at the concurrency you expect. 4. **Run and monitor** — Stream health, recording success rate and cost per hour, watched and reported. ## Technology we work with - **Real-time:** WebRTC, SFU architectures, Agora, LiveKit, Daily - **Broadcast and ingest:** RTMP, SRT, HLS, Low-latency HLS, MPEG-DASH, AWS IVS, Cloudflare Stream, Mux - **Processing:** FFmpeg, Composite recording, Adaptive-bitrate transcoding, Thumbnails and captions - **Delivery and rights:** Amazon CloudFront, Cloudflare, Cloudflare R2, Amazon S3, Signed URLs, Widevine, FairPlay - **Clients:** hls.js, Video.js, React, React Native, Native iOS and Android SDKs ## What you gain - A provider chosen on numbers, with an adapter so you are not married to it - Recordings that appear every time, because the confirmation step is monitored - A cost per stream-hour you can put in a pricing model - A session that survives a weak connection instead of dropping the customer ## Related work [Building Jversity: a multi-tenant educational LMS platform](https://matiforge.com/work/building-jversity): Live classes, courses, interview preparation, blogs, video recordings and much more built and operated by us as our own product. ## Questions we get asked ### Which provider should we use? It depends on the format. Broadcast to a large audience favours a managed streaming service such as AWS IVS or Cloudflare Stream; small interactive rooms favour a real-time provider such as Agora or LiveKit. We price both per session-hour before recommending either. ### Why do recordings fail so often on other platforms? Usually one of two causes: nothing was actually recording because the participant roles were wrong, or the upload was never confirmed. We design both explicitly and monitor the success rate rather than trusting it. ### Can you work with the video provider we already pay for? Yes. We build behind an adapter, so we can keep your current provider, fix what is broken around it, and leave you able to change later without a rewrite. ### How low can the latency go? Interactive rooms over WebRTC run in the hundreds of milliseconds. Broadcast over low-latency HLS typically lands between two and five seconds, and standard HLS higher again. The right answer depends on whether the audience needs to talk back. ## What does success look like for your project? [Start a project](https://matiforge.com/contact) · hello@matiforge.com