&meshcastsupport; ideal for handling larger rooms or slow guests
&maxtotalscenebitrate, with aliases
&tsb. Mainly added to help offer another way to optimize performance and limit inbound bandwidth used, since why not.
&bitrateis also used,
&bitratebecomes a max limit on any individual video, so you can set
&bitrate=2000, to keep all videos below 2mbps each, but potentially go lower if more than 3 videos are present.
&fp), which will let you specify whether the video output is landscape or portrait, regardless of how the phone is rotated. You add this flag to the sender's side, and it applies to the sender and the viewers of that video stream. There's a short sub-second delay that it takes to counter-act any system-flipping. It can be used in conjunction with &rotate, if you need to do a 180 or something also.
&facingsetting, which lets you specify either the front or rear facing camera as the default camera. Passing one of rear, environment, back, front, and user are required to specify whether to select back or front. example usage:
&facingtakes priority over
&vd, but it will fail to
&vdor the default behaviour if the rear/front camera can't be selected automatically. If there are multiple rear or front cameras, it will use the first one.
&vd=0will disable the video outright.
&h264profileflag. This is added to the Viewer-side to tweak the h264 profile type. Use it as is if you wish to disable hardware h264 encoding, for example. Instead, OpenH264 software encoding will be used, if H264 is used. Open264 software encoding can actually use less CPU than the Windows-selected hardware encoder, and in some cases will suffer from less video glitching. Advanced users can also pass a 6-character h264 profile ID to the parameter to get used instead. This flag will not force H264 to be used, but rather configures it in case h264 gets used. You can still use
&codecto set the codec to h264. Example:
CTRL + ALT + F=> Open the file-sharing window
CTRL + ALT + C=> Cycle the camera to the next camera available
CTRL + ALT + S=> Open the screen-sharing window on macOS:
CMD + ALT + F=> Open the file-sharing window
CMD + ALT + C=> Cycle the camera to the next camera available
CMD + ALT + S=> Open the screen-sharing window
&slotsparameter, where you can pass a positive integer and it will force the auto-mixer to have that number of slots, even if there are more or less videos available to fill them. O
&slots, so videos will stick in place now (slot position wise at least), even if another video before it leaves.
&effectvalue(&ev) which can take an integer; this can set the amount of blur (or effect) applied. It's best to keep it under 10 and using this flag disables the option to use the slider.
&recordcodec(&rc), which lets you set the video recording codec (saving to disk mode; ala &record). The container format is still webm, and not all codecs are going to be supported, but things will fail back to vp8 if not supported. Main reason for this is because vp8 on chrome for android kind of stinks, so at least you have an option to tinker with things now.
&showperformeris active. If you want to share a website as a director with a scene, either do it via OBS, as a screen share, or open a new tab and share it as a guest.
&speakermute=falseas an option; this will have the director's mic not start muted. You can use
&autostartto auto-select the mic of course, also.
&autoaddparameter, which can be added to a scene link, passing to it a comma-separated list of stream IDs. If any of those streamIDs connect, they will be auto-added to that specific scene page.
&ssec , &ssdn , &ssag, and &sssflags that can be used to adjust the audio of a sub-screen share. echo-cancellation, denoise, autogain, stereo, respectively
&proxyflag. You can add it to the view/push/director/scene link or wherever. This simply forces your computer to try to connect to the handshake service via a different physical network end point and domain name, which might help if the Internet ever splits in two. The purposes of this flag is that sometimes ISPs / network routers mess up, and this is just a backup option to get around those errors. While this should try to connect to the closest edge node relative to your location, I don't recommend using this feature unless there are problems.
&cleanviewer(&cv). This is the exact same thing as &cleanoutput, except it only triggers if added to a view-only link.
&meterstyleparameter, which lets you customize the audio-loudness meter,
&screensharebitrate(aka &ssbitrate), which lets you manually set the video bitrate for screen-shares in kbps. This is a viewer-side command, and works with scenes link, view links, and guest links. This specified screen-share bitrate will not count towards the total room or scene bitrate, if those are being used. It also takes priority over most other bitrates parameters, with just a couple exceptions.
&sstype=3. You add it to the guest link. The new
&sstypeparameter in general can be used to specify which type of screen-sharing logic is used. Specifically,
sstype=1replaces the webcam screen with the screen share,
sstype=2creates a totally new connection for the screen share, and
sstype=3reuses the existing connection, adding a second video track. I hope to have type=3 become the standard for sharing screens eventually, but for now it will remain optional, until the issues are all worked out.
:sis appended to the end of the stream ID. This tells the system to ignore the webcam/mic feed, and just send over the screen share. You can do
&view=xxxx,xxxx:sto target both webcam and screen share though. I may change this syntax over time, but for now it works. The solo-links in the director's room has this
:sapplied already where needed. Note, the type-3 screen share is still not fully cooked for use in scenes, etc, and it won't yet work with &meshcast, &novideo or &noaudio.
&midichannel=Nas filtering options. These work in conjunction with &midi to allow for specifying which midi device (1 and up) and/or midi channel (1 to 16) to listen on. If you don't specify anything, it listens to all channels and/or all midi devices. Previously it was hard-coded to listen to just channel-1, but now it will listen to all channels unless filtered.
oin room as participantbutton, but join as a participant instead of a director, you are provided an invite link as a pop-up to that room's creator. Clicking it copies to clipboard.
&welcome(&entrymsg) option. You can set a message on the guest-invite link that appears as an overlay, appearing to be from the director, once the guest joins the stream.
https://vdo.ninja/?welcome=helloYou can also activate the welcome message as a director via a new toggle option; when selected, it offers the director an input text prompt and then auto-encodes the message for the director to the guest invite link.
&signalmeterto the URL to show it. You can also do
&signalmeter=falseto disable it.
&micdelaycan now delay your mic output for longer than a second now; I've tested 10-seconds but probably could go much longer.
&chunked=2on the sender side. . Using just &chunked will just enable viewing, and not saving, of the video.
&transparentflag will make the Electron App transparent now, although only on the desktop; not yet in OBS. In OBS, the background will appear as black.
&meshcastto 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 and reduces the theoretical privacy, but it implies the guest/director does not need to encode and upload multiple videos, lowering CPU load and bandwidth usage.
&noaudionow work with &meshcast streams. As in, you can block audio or video streams from appearing, but both streams will still be downloaded if either audio or video is still requested. You need both &novideo and &noaudio to block meshcast entirely, or just exclude it using &view or &exclude.
&meshcastwhere a race-condition caused the video to not load for some viewers. fixed a couple issues with the &meshcast feature; sometimes it would be audio-only or not work at all, which is now fixed
&meshcastparameter for VDO.Ninja Example usage:
h264, which is what the browser then sets. This could include hardware encoding, but that will not work with Firefox or Safari viewers then.
vp8is pretty compatible, so if the default codec doesn't work, you can try that.
vp9is also available, which has better compression/quality, but not fully compatible with all devices.
&noaudioto meshcast.io, which can be used in place of &mute when sharing a meshcast broadcast link into a VDO.Ninja room. Blocks audio from playing, which can help avoid feedback/echo issues
--multivieweras a CLI argument enables multiple viewers at a time. This mode reuses the same single encoded stream for all viewers, so it might have some frame loss on bad connections, but it allows even a Raspberry Pi 4 to share 1080p30 video with over 10-viewers
&meshcastto the guest invite link. This causes their video to be streamed via a server, instead of p2p, reducing CPU and Network bandwidth on that guest