SolutionsGame teams
Playtests that stay with the studio
A capture card or the game client publishes into Vasl. The people on the list watch closely enough that notes are about the moment that just happened. Public audiences are a different job.
Publish
Encoders, cameras, browsers and mobile apps open the session.
Vasl
One server you run transcodes, records, authorizes and fans the stream out.
Play
Interactive viewers stay on WebRTC. Broader audiences take HLS from the same publish.
Workflows
How studios use the room
QA sessions
A tester publishes the build. Producers watch and comment while the bug is still on screen.
Design reviews
A designer walks through a level. The recording is the note, not a memory of it.
Press and partner previews
A link that expires. The capture never has to sit on a public video site first.
Remote play
Someone offsite tries a build with interactive playback, when the session is meant to be played, not only watched.
Several builds at once
Each stream is an API object, so a test day is a list of rooms.
Archive the session
Keep the capture next to the build number. Delete it when the milestone is over.
On this workload
How Vasl is tuned here
Capture in, notes out
OBS, a hardware encoder, or a custom client can publish. Reviewers play in the browser. You do not need a creator platform in between.
- RTMP and WebRTC ingest
- Interactive playback for reviewers
- HLS if a larger group is only watching
- Recording tied to the session
The build does not leave the studio by accident
Tokens, a private network, and a server you run. When the preview is over, the link dies.
- Short-lived playback tokens
- Self-hosted option
- REST control of each test
- Web and native playback
Why teams choose Vasl for Gaming
- Previews that are not public by default
- Reviewers close to the action
- A recording per build
- No creator platform required
Same server
