Appearance
How Vabu Streams works
Vabu Streams puts live video and replays in your own app. You keep your login, your payments and your player page. Vabu takes the video side: it receives the broadcast, prepares it for weak phones, hands out protected playback links, counts viewer sessions and tells you what happens.
It suits a nightlife app that streams a DJ set, a church that streams its services, a league that sells match passes and an events company that adds a stream to a ticket.
What you do and what Vabu does
| You | Vabu |
|---|---|
| Keep your app, your login and your checkout | Gives each venue a stable stream to send video to (RTMP and SRT, WHIP where the network offers it) |
| Make one call when a fan has paid | Checks that call every time someone presses play |
| Show the video on your own page | Prepares video in several qualities so it plays on weak phones |
| Listen for events and update your own records | Issues playback links that stop working when access ends |
| Decide the price and who gets in | Limits devices, keeps replays and cuts clips, and sends an event for every change |
One API, with the video network behind it
You call one API. It does not matter which network carries the video: every live stream and every asset has a read-only provider field that tells you, and your code never needs to read it. Test mode uses a simulated network that cannot bill.
Right now each account runs on one network that Vabu picks for it. A live stream can also have a second network on standby: see Staying on air. Choosing a network for your audience's region, with Nairobi first, is listed on What's coming. Read delivery networks and capabilities to see how to write code that keeps working when more networks arrive.
A night, step by step
- A venue points its encoder at the live stream's ingest URL. The URL and the key stay the same for every broadcast.
- A fan pays in your own checkout.
- Your server tells Vabu the fan may watch:
POST /v1/access/entitlements. See paid access. - The fan opens your page. Your server signs a short customer token for them. See customer tokens.
- The browser asks Vabu to open a viewing session, using a publishable key and the customer token. Vabu checks the access and the device limit, and returns a protected playback link. See playback and sessions.
- The player plays the link. A heartbeat every 30 seconds keeps the session alive and returns a fresh link.
- Your server gets events as the stream goes live, drops and ends. See stream events.
Why use Vabu Streams
Here is what you get next to building the pipes yourself, and next to wiring one video provider straight into your app.
Staying on air
Built by yourself, the video travels one path that you watch through the show. With one provider you have a stronger pipe, and you still handle reconnects and alerts. With Vabu Streams each stream has a reconnect window, a backup ingest address and an event the moment the encoder drops, so your app can react.
Viewers on weak data
A pipeline you build is often one quality, and a viewer on a weak phone sees a spinner. A provider gives you a quality ladder. Vabu Streams gives you the ladder too, and audio-only streams for audiences who need the smallest data use.
Paid access that cannot be shared by link
With your own pipeline the video is often a file link that anyone can pass on. A provider gives you signed links, and you write the access rules around them. With Vabu Streams the rules come with it: entitlements, device limits and links that expire, so a shared link stops working within minutes.
Data
Your own pipeline leaves you server logs. A provider gives you video numbers that know nothing about your sales. Vabu Streams sends every grant, session and stream change to your server as an event, tied to your own customer ids.
Your team's time
Building it yourself means running video at night. Wiring a provider means an integration, plus everything around the video. With Vabu Streams it is one API and a short list of calls.
What you still build
Vabu does not replace your product. You build your login, your checkout and the page that holds the video. You choose your player: any player that plays HLS works, and the quickstart uses hls.js.
Where to go next
- Quickstart: create a stream, give a customer access and play it.
- Going live: encoder settings, a checklist and what happens when the connection drops.
- Paid access: grant access after payment, limit devices, revoke and sell replays.
- Series, subscriptions and certificates: on-demand video for creators.
- Concepts: live streams and ingest, assets and recordings, playback and sessions, customer tokens, signed playback, delivery networks and capabilities and stream events.
- What's coming.