Ninja Docs
Most common Parameters
Cheat sheet of the basic URL-based settings
VDO.Ninja makes heavy use of URL-based parameters to configure settings. Some of the most commonly used ones are listed below, with a brief explanation of what they are for and links to more detail.
Sender-side parameter
The stream ID you wish to publish your video under; it must be unique. The value can be defined manually and reused. If left blank, a value will be generated automatically.
Sets the default target resolution and frame rate. If not used, the system default is 720p60. Setting&quality=0will result in 1080p60 being the new target default, but this may significantly increase the CPU load on the sender's computer.
Specify an video device to auto-select on load. If left blank, the system's default audio device will be selected.
Specify an audio device to auto-select on load. If left blank, the system's default audio device will be selected.
This parameter will allow for digital effects to be applied to the video, including background-blurring and a digital greenscreen. You can preset which effect is loaded by setting this value to a corresponding number, such as &effects=4
Allows the guest connection to be assigned a display name, which will be used in chat and if overlays are turned on. If left blank, the guest will be prompted to enter a display name.
Adding &meshcast to a guest or director link will trigger the service, causing the outbound audio/video stream to be transferred to a hosted server, which then distributes the stream to all the viewers. This adds a bit of latency to the stream, but it implies the guest/director does not need to encode and upload multiple videos, lowering CPU load and bandwidth usage.
Viewer-side parameter
The stream ID you wish to view/hear; a comma-separated list can be passed as well to view multiple at a time. This isn't required if using a group room, but it can be used in conjunction with the &push parameter to create faux-rooms. Using &view without passing any values to it will prevent any incoming peer connections. It technically is responsible for allowing inbound connections, and not explicitly in control of whether video or audio is requested.
The video bitrate you wish to view a video at, in kbps. The default is 2500-kbps and is well-suited for interviews and talking-heads, but you may need to increase it if video contains significant motion and scene changes. This parameter will not work for guests in a group room, but should work elsewhere.
Sets the audio bitrate, in kbps. The system default is 32-kbps, with the max limit being between 300 to 510-kbps, based on other factors. Too high and you may actually introduce clicking noise issues.
h264, vp9, vp8, and sometimes av1 are options. Setting &codec=h264 can sometimes trigger the sender's hardware encoder to be used, but this can often have unexpected consequences. The default is left up to the browsers to decide.
This flag will disable incoming video streams. Connections will still be established, allowing for data and audio still. You can pass a list of stream IDs to exempt streams from this filter.
This flag will disable incoming audio streams. Connections will still be established, allowing for data and video still. You can pass a list of stream IDs to exempt streams from this filter.
If the sender has set a display name, you can overlay that name by using this parameter. Different styles of labels are available, which can be set by passing their corresponding style ID to this parameter.
Director, room, and general parameters
Defines a room for guests to chat in. If used, everyone in a room will auto-connect to each other on joining, unless &view is used. Rooms benefit from allowing for echo-free conversation and rooms can be managed by a director.
Guests in a room have limited control and will see videos at reduced quality; this is intentional.
The director flag should be set to whatever the room name is. The first director to join a room then becomes the controller of the room. They have the ability to remotely control guest's settings, such as microphone volume of a guest, and they can add and remove guests to scenes.
several other parameters into one, designed to quick-start applications needing high-quality audio. This parameter can be considered pretty heavy duty, so it's primarily designed for professional users needing near-raw audio quality, such as music DJs. If used on the sender's side, it disable echo-cancellation, noise-reduction, and auto-volume leveling. It also requests stereo audio from the microphone source.
When applied to the viewer's side as well, it will increase the connection's audio bitrate to 256-kbps and request stereo-audio from the sender, if it is available.
If using a room, then to view a specific stream or collection of streams, the &scene and &roomparameter must be added to any view link. The scene parameter lets the system know the connection is not a guest, but rather designed for capture.
Different scenes and scene types are available, and since a director can add and remove streams from scenes from their control room, multiple scenes can be used together to act as media slots in complex show layouts.
This parameter can be added to a guest's invite link to reduce the maximum video bandwidth they will make available to each other guest.
On mobile devices, outbound bandwidth to other guest is already set very low, but if a guest is still struggling to participate in a group room, adding &roombitrate=0 to their invite link will disable their outbound video to other guests and free up even more CPU. See &totalroombitrate for another option.
Specifies the custom password to be used. If left blank, the user will be prompted for the password on page load. Passwords are not stored and used purely client-side. They are used to encrypt the initial connection handshake between peers and to obfuscate room names. The &hash parameter is system-generated and is a bit like the &password parameter, except it has the ability to validate a user-entered password.
Adding this flag will have guests only accept video connections from the director, but still share audio and accept audio-connections from other guests. This reduces the CPU and network load on guests, allowing for larger rooms, so long as the director can also support those larger rooms.
Copy link