&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.
&videobitrateis also used,
&videobitratebecomes 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
&videodeviceor 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.
&videodevice=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.
&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.
&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.
CTRL(cmd) while changing values though, it will lock the width/height together, allowing for scaling without having to crop first. The director will have remote control access as well. The "preview" for the guest will still appear HD even at low resolutions selected, as the width/height change will only apply to the outbound video stream. Cropping is still applied to the preview though. It should be possible to increase the width/height to something HIGHER than what was set with
&quality, if the camera supports it. So you can join at 720p (
&quality=1), you can then increase it to 1080p or 4K or whatever after joining.
&minipreviewor what not). If you drag the mini preview around, the icon remains stationary in the top-right; I preferred this over it moving with the video, but I'm open to feedback on where it should be placed.
&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.
&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.
&view=to auto-add a guest to a scene, as
&viewfilters out non-listed stream IDs as well, while &autoadd will not.
&directorparameters added. I'm hoping this adds to the discovery of the function, since I get asked about this feature a lot. it will not show up though if those parameter are present, unless
&effectsis explicitly added, so directors are still in control.
&ssec, &ssdn, &ssag, and &sssflags that can be used to adjust the audio of a sub-screen share. echo-cancellation, denoise, autogain, stereo, respectively
&43as a viewer-side aspect ratio option; previously there was just 16:9, 9:16 and 1:1.
&quality=0(1080p mode), and it will actually work at 1080p now. On older iOS versions, I still limit you to 720p30 to avoid things crashing.
&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.
&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,
&meter=1will show the VU-style meter that the director has by default already.
&meter=2will show a green-border around the guest's video when they are talking.
&meter=3will show a little green dot in the top-right corner when the guest's talking. This is default for the guest's view already.
&meterstyleparameter on a scene link, it will work there too.
&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.
&ssvo) ; this lets you disable the option to select audio when screen sharing. It will not impact the microphone or other audio options.
&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
sstype=3become the standard for sharing screens eventually, but for now it will remain optional, until the issues are all worked out.
&sstype=3screen-share, you can now use
: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,
&midioutforwarding function to also include the channel-ID. Before all channels were sent to all remote channels, but now, for example, if channel 15 is used locally, it will be forwarded to channel 15 remotely also. Had to upgrade to v3 of webmidi-beta to get this to work.
&midichannel=Nas filtering options. These work in conjunction with
&midito 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.
&stylecan now take values 1 to 6 now. Previously only &style=2 worked, and even that was a bit buggy.
&style=1hides audio-only windows from appearing. The default is for guests to see audio-only boxes for guests that do not have a video feed; the director is excluded.
&style=2still just shows an animated audio waveform of the speaker's voice, although I made the quality HD now.
&style=3shows the audio meter, which you can customize using &meterstyle. You can conversely just use &meterstyle on its own, and mix it with a different style, and it will still work.
&style=4will just show a black background for any audio-only source.
&style=5will show a random color for a background, instead of just black.
&style=6will show the first letter of the guest's display name, in a colored circle, with a black background. If no display name is provided, it will just be a colored circle on a black background.
Join 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.
&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.
&broadcastmode, so change whether the guest is in broadcast mode or not be in broadcast mode.
&micdelaycan now delay your mic output for longer than a second now; I've tested 10-seconds but probably could go much longer.
&miconlywill block the cycle-camera button and hotkey option now on mobile; also added a fail-safe to ensure camera can't become active now when
&autostartmay have caused incoming video bitrates to be higher than desired in the director's view.
&pw=falseneeded for it to work.
&webpbroadcast mode, which streamed a series of images as a custom-made video protocol, but the
&webphas poor compression and quality, and would drop frames if the connection couldn't keep up.
&chunked=2on the sender side. . Using just
&chunkedwill just enable viewing, and not saving, of the video.
&maxbitrateto less than 2500, on the sender side, it switches to a low bitrate and lower latency mode (500ms chunk size). The default is otherwise 3500 with a 2-second chunk size. Obviously the quality will be worse.
&mixbitratewill likely get changed up and moved to the viewer side eventually; currently doing this just for convenience of development/testing. Multiple viewers is not recommended. There seems to be an issue with audio clicking that I'm trying to solve currently.
&chunkedon the publisher side of things. It does not yet work in group rooms, just basic push/view links. It also does not work with Meshcast.
&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
&meshcaststreams. 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
&noaudioto block meshcast entirely, or just exclude it using
CTRL (or cmd) + clickon the video.
&meshcast, I don't bother to show the viewer count, as it won't be accurate currently anyways; instead I just say you're broadcasting. I'll try to improve this in the future.
&meshcastwhere a race-condition caused the video to not load for some viewers. fixed a couple issues with the
&meshcastfeature; sometimes it would be audio-only or not work at all, which is now fixed.
&meshcastfrom like 500-kbps to max of 3200-kbps; will probably change as the feature evolves and becomes more customizable.
&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
&mutewhen sharing a meshcast broadcast link into a VDO.Ninja room. Blocks audio from playing, which can help avoid feedback/echo issues
&meshcastflag as well. Should improve quality and global coverage of streams.
--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.
&darkmodeoption for the chat stream, that changes the color to match a black/transparent-background in OBS.