&noap to the URLs to fix it as well; you can also enable chrome://flags/#chrome-wide-echo-cancellation, patch the code, or just use headphones.&waitimage, the specified 'waiting to connect' image will appear after all connections end. This is a bit different than the default behaviour of the spinner, which doesn't re-appear, but I assume if you're advanced enough to use the &waitimage option, you're okay with this.CTRL + ALT + D to toggle this as needed.
&stereo, &s , stereo=5, or &proaudio, I'm now showing a little check-box that the guests themselves can check to set their mic input to MONO mode.
While there's a few different ways to set a mic to mono mode, they aren't always obvious to people I'm finding, especially when using &proaudio/&stereo mode. For example, some guests will appear in the left or right-audio channel, due to their mic/interface setup. It's not always obvious on how to fix this when about to go live, so I'm hoping this helps avoids those situations.
-- It won't interfere with the screen share modes, so they will be stereo still
-- It won't show if using &stereo=1, as that is explicitly stereo since a value is passed.
-- The guest can toggle it on and off in the settings, without needing to go into any advanced audio settings
-- The remote director can still use the existing "channel count' in the advanced audio settings to override this button, unless the guest toggles it back on
-- There's several other ways to set mono mode of course, including &monomic, &inputchannels=1, &stereo=3, channelCount, &mono (playback), &ec&dn&ag, and within OBS/Windows itself.
&effects=7 (or &effects=zoom), which will provide a manual zoom option in the effects menu. (you can also select the zoom mode via the effects menu, if available)
&getfaces on the viewer link (or {getFaces:true} via the IFrame API), which will request a continuous stream of face bounding boxes, for all inbound videos and all faces contained within. The data is transmitted to the parent IFRAME, and this data can be used for moving the IFrame window around, if you wish to make your own custom face-tracker or whatever else.
&effects=1 on the sender side (or &effects=facetracking) will auto-center the user's face in the center of their video, zooming in as needed. It takes a moment to initiate, but it offers a gentle PTZ-like effect.
-- note: I previously had &effects=1, but it wasn't that good, so this is a more polished attempt. It's also available from the effects drop down menu now as a selectable option, as before I was hiding it.
&getfaces and &effects=1 requires the use of the Chromium experimental face detection API, as I'm using the built-in browser face-tracking model for this. You can enable the API flag here: chrome://flags/#enable-experimental-web-platform-features My hope is that this feature will eventually be enabled by default within Chromium, as loading a large ML model to do face detection otherwise is a bit heavy; you may need to enable this within the OBS CLI if wishing to use it there?
*** Changes on alpha at vdo.ninja/alpha/&autohide works better now; also on mobile, the &autohide makes the control bar transparent on timeout, to avoid conflicts with tap-to-zoom/focus logic.&sticky redirect confirmation prompt less ugly, and I now don't ask if the URL already matches the saved session's URL.&previewmode) function of the director room (hopefully no bugs?).
** changes on alpha @ vdo.ninja/alpha/&showconnections will display the total number of p2p connections of a remote stream. Works with the director's room and the automixer. Might help give comfort over privacy/security during a stream.&showconnections. Could be useful for debugging CPU/bandwidth issues.showChat and showDirectorChat as HTTP/WSS API options for sending messages to guest(s). Useful if you want to hotkey a streamdeck command with some welcome message for guests.&scene=0 link would look like. Useful if you want to switch to a guest-like mode as a director, and then switch back as needed to the director's room to make adjustments. - to enter this mode by default, &previewmode can be used by the director ** on alpha at vdo.ninja/alpha/
&noisegatesettings has been added to vdo.ninja/alpha/, which is used in conjunction with &noisegate. This feature lets you tweak the noise-gate's variables, making it more or less aggressive as needed. example:
https://vdo.ninja/alpha/?noisegate&noisegatesettings=10,25,3000
It takes a comma separated list:
-- First value is target gain (0 to 100), although 0 to 40 is probably the recommended range here
-- second value is the threshold value where the gate is triggered if below it. ~ 100 is loudly speaking, ~ 20 is light background noise levels, and under 5 is quiet background levels.
-- third value is how 'sticky' the gate-open position is, in milliseconds. Having this set to a few seconds should prevent someone from being cut off while speaking or if taking a short pause.&contenthint=detail
-- for screen-shares, &screensharecontenthint=motion, which will override &contenthint for just screen-shares if set also.
The two options for video are detail or motion. Screen shares generally tends towards detail by default, and camera sources are tend towards motion by default. detail will try to prioritize resolution over frame rate, so the frame rate may drop a lot used. motion will try to maximize frame rate, but may drop the resolution a lot. There's no way to force both on as there's no magic bullet if your CPU or network cannot keep up. note: If using &codec=vp9 on the viewer side, the frame rate may drop as low as even 5-fps.
-- Also for audio, I've added &audiocontenthint=music The two options are speech and music. No idea what it does exactly, but when using music there seems to be a fixed bitrate of 32-kbps sent out by default, where as with speech it is variable, using less bandwidth when not speaking.
These parameters have been tested on Chrome, but other browsers may vary in behavior. Safari seems to just ignore things, for example. ** changes on alpha&sharper and &sharpen are now aliases of &dpi=2, which should 'up to' double the amount of playback video resolution, if the dynamic resolution optimization is enabled at least, in certain cases. This is a lot like &scale=100, but perhaps slightly more efficient in some cases. This is mainly for when you intend to have a large screen-shares in a scene, where you don't want the tiny guest videos to be a 100% scale, but 50% scale is fine (up from 25% scale). &dpi already exists on production, but by adding these aliases, I hope it's more discoverable.&sharper, I've also added &sharperscreen, which sets &scale=100, but only for screen-shares. (virtual cameras not included). This is probably even more efficient than &scale=100 or &sharper, and it's designed for when screen-sharing a lot of text. Text looks a bit soft when streaming video at 1:1 pixel resolution.
It's recommended to only use these parameters within the context of a scene link, and not on guest links, due to the higher CPU / bandwidth it may use.&grid (&ruler/&thirds) effect by passing an image link. (can help center guests)
-- transparent PNG or an SVG file are the recommended options.
-- it will stretch to cover the camera preview-area, so probably best to keep things 16:9 aspect if needed.
-- URL can be URL-encoded, for more complex URLs. Simple URLs might work without.
-- technically this can be used as an overlay for other things, but it only works with the self-preview.
-- leave the passed value empty if you wish to have the white basic rule-of-thirds show as default.
example: https://vdo.ninja/alpha/?thirds=./media/thirdshead.svg
** on alpha.
proxy.vdo.ninja/alpha/ as an alternative to vdo.ninja/?proxy. If's a more user-friendly version of &proxy. ** Just on alpha for now&activespeaker=3 and 4 added; which are the same as 1 and 2, except it will not switch to show audio-only sources (just video only). As a recap, active speaker mode shows the person(s) who are actively speaking, and hides those who aren't.&activespeaker mode when viewed as a scene, in chrome, for example. Wasn't an issue in OBS)&solo instead of &scene now; it's the same outcome, except &solo tells the system not to apply custom 'layouts' to them. Links updates in the director's room and the mixer app.
** changes on the alpha version of VDO.Ninja at https://vdo.ninja/alpha/&screensharetype=3 have been resolved, I think. (this mode supports desktop-audio capture without echo issues)&aspectratio now works with screen shares, so you can force crop an incoming screen share to be a certain aspect ratio. If &screenshareaspectratio is used, (&ssar), it will apply to just screen shares. If &ssar does not have a value passed, it's assumed to be set as "default", which overrides &aspectratio option, if used also. ** on alpha, ie: vdo.ninja/alpha/?ar=2.0&hidecodirectors will hide the co-directors from appearing in the director's room. You might have a few co-directors join you, but they might be taking up space, so this is a way to prevent that. It simply hides the boxes; they are still there at a code level.&mobile and ¬mobile as a couple options to vdo.ninja/alpha/ I already have &flagship, &noscale, and &forceios as a few options to configure mobile devices, but mobile/notmobile are more generic options that will optimize a guest/push link based on whether VDO.Ninja thinks they are a smartphone or not. &mobile might help reduce CPU issues, and ¬mobile might be able to improve video quality (in case you want to override the automatic defaults, which already detects if a device is mobile or not).{bitrate: 2500, lock:true} for example. I also assume lock=true by default, so no changes are needed really to start benefiting from this. (previously you had to disable the auto-mixer to lock a bitrate).{manualBitrate: xxx} to the IFrame API , which is a bit like bitrate, but keeps track of what the current target bitrate should be. When you set manualBitrate=false, it will apply the expected target value. Also, it won't work when used in conjunction with custom audio bitrates, whereas bitrate will.targetBitrate, which lets the automixer keep doing its thing, but it sets a new max target bitrate. The target bitrate will still be applied when set, but the automixer may lower it if needed when it decides to, but it's the new target for 'unlocked' max speed. Some browser will ignore it though, if it's set higher than the bitrate that was manually set the via URL, so it's probably something you don't want to use along with &bitrate.&controlobs
-- &obsoff can be used to set permissions to fully off (also disables tally light and scene optimizations tho) when added to the OBS browser source link.
-- The OBS instance still needs &remote={optional-passcode-here} added to the URL for remote commands to work. If &remote is left blank, it gives anyone permissions to control it. If a value is passed to &remote, the sender needs to have a matching &remote value or manually enter they need to manually enter passcode in the pop up control menu.
-- If the OBS browser source has its permissions set to something other than full (lower than level 5), the control menu will still show what info it has -- current scene, recording/streaming state, etc; depending on level. The lower the level, the less info is available to show; can't remotely change anything though.
-- It supports multiple OBS instances and will label them according to the &label=xxx value set on the scene/view link, or whatever the unique connection ID is.
All this is on alpha, at https://vdo.ninja/alpha/
&webp mode has been modified a bit. Main change is that you now enable it by add &webp to the sender's URL, and &codec=webp to the viewer's URL (otherwise, it falls back to normal video mode). No need for &broadcast anymore. (as a reminder, this mode sends the video as a series of low-quality images, rather than a more efficient video stream).&webp feature, as &chunked mode is replacing its purpose there, but you might still want to use this mode when the viewer-side does not support video playback or hardware acceleration. Specifically, this option lets you bring motion images (aka, crude video) into the Streamlabs mobile app, as a browser source, where other forms of video decoding is not supported.&slideshow . This option decodes incoming video (first video to load), but plays them back as series of full-window images. That is, a single image element, that gets updated 24 times a second, instead of playing the video back within an efficient video element. I have no idea why you might want this option, as it pretty crude up and uses up a lot of CPU, but you can right-click to save a single frame from the video to disk, as a PNG file. This might be useful if you need to take a lot of snap shots of some video and don't want to have to hassle with cropping a window-grab. Quality of the images is pretty high; near lossless.
** on alpha
&smallshare as a new option, which makes the screen share behave like a webcam share. ie: not larger in size vs other windows, for the publisher or the viewers. This is a push-side parameter. This is useful if a VR guests screen sharing an app of themselves, versus using a virtual camera. It can also be useful for gaming, where a larger screen share might bog down the system of the sender more than needed.
*** on alpha at vdo.ninja/alpha/&noisegate or &noisegate=1 (&gating/&ng) will enable it by default (if using it in a room, currently); and &noisegate=0 will hide the option from the menu.
-- The older existing &noisegate=1 option I moved to &noisegate=4, as this new version is replacing it. I'm keeping the older version around as an option though.
https://vdo.ninja/alpha/?postimage=https%3A%2F%2Ftemp.vdo.ninja%2F&postinterval=30 posts to a sample test server I have up. The URL is URL encoded, but not always necessary.
If posting to my test server, the image can be accessed at https://temp.vdo.ninja/images/STREAMID.jpg. There's caching enabled mind you, so you'll want to post-fix the current timestamp to the URL to disable that per request.
For example, https://temp.vdo.ninja/images/yiMkpMg.jpg?t=3412341234
This feature could be useful to checking out a stream before actually connecting to it, as that's my intent with it, but it is also something you can use with Octoprint, where you need an IP camera jpeg source as input.
** on alpha, at https://vdo.ninja/alpha/&website function now lets you start/stop and change website sources; no longer is it just one site and that's it. (only the director previously could change websites constantly). I suppose you could use this to remotely change inputs in an OBS browser source via a remote website, as I think the YouTube implementation supports synced playback/scrubbing.&scale=100 to the scene links. Might improve sharpness a bit, at the cost of increased CPU/network load.&totalroombitrate value would be ignored by that guest until they exited the full-window mode.&totalroombitrate), the slider to adjust the TRB value will be extended so the max range is that of the URL value if higher than 4000.
** on vdo.ninja/alpha/ for testing.&screensharequality or &screenshare), I have the screen share resolution matching the webcam resolution now. This avoids a sudden CPU spike when screen sharing; still room for improvement tho.&limittotalbitrate only applying to guests, rather than all viewers. I need to revisit this at some point soon.
** changes on alpha&background, which accepts a URL-encoded image URL to make as the app's default background. For example, 
https://vdo.ninja/alpha/?appbg=./media/logo_cropped.png . The image will scale in size to cover the VDO.Ninja app's background. &chroma can still be used to set the background color, if using transparencies. There already exists &bgimage, which will set the default background image for videos; this however will set a background image for the entire page.
&statsinterval=100 not updating on sender side (only viewer side before). This updates how frequent the stats updates.&base64js, which lets a user add raw java script to the URL to run on page load. https://vdo.ninja/alpha/?jsb64=YWxlcnQoJ2hpJyk= to test.
** changes on alpha&buffer and &sync to the viewer when using &chunked mode on the sender. If on an unstable connection, setting the buffer to a few seconds can help avoid pauses in the video playback, as there will be some buffer to use. (a bit experimental still -- so it might be more a WIP still ).&include, which is like &view, except it's for including streams that do not exist in the room you are in, assuming those streams are not in another room and have matching passwords. So, useful for adding basic push-streams that you might want to be in multiple rooms at the same time, but not actually be locked to any room. (&view, conversely, is pretty exclusive; that or nothing.)&flagship, which will optimize the mobile experience for more capable smartphones; essentially, streaming higher quality video to other guests versus the normal mobile-performance mode.&limittotalbitrate flag by default (500-kbps). &limittotalbitrate hasn't been that heavily tested yet, but it's part of v22 and might be better than &totalroombitrate; currently I'll increasingly use them together I think though. They are both the same concept, except one is viewer-side controlled, and the other is sender-side controlled; both limit the bitrate that guests in the room see based on the number of guests in the room.
** changes to alpha, at https://vdo.ninja/alpha/&aspectratio + &crop (sender side options) has been updated to work with more camera/sources. If you do vdo.ninja/alpha/?webcam&aspectratio=0.5625 for example, you'll get portrait mode. Not compatible with Safari though.&chunked recording in the director's room works correctly
** These changes are on beta @ vdo.ninja/beta&scale=100). This should help with video sharpness (text, etc), when the added burden of slightly more CPU load is worth it. Won't snap if the different is great though.&scale=100, but is pretty inefficient and needlessly heavy on the CPU in most cases.&showdirector is used, it will not use the control-bar for group buttons 1 to 8
--- It technically is possible to use groups via the API or URL other than 1 to 8, but I only offer buttons to add guests to groups 1 to 8.
&api remote API option, you now can get STATE values as the reply to a GET/POST/WSS request.
So if you do https://api.vdo.ninja/c6sWHN9zzX/group/null/1, with &api=c6sWHN9zzX added to the director's URL, you will toggle the director in and out of GROUP 1.
The response of the HTTP GET request though will be true or false or timeout, based on whether the director was added to the group, removed from the group, or whether it failed. This new feature can be used with a Streamdeck (or other controller) to have the button's color of the Streamdeck match the state of the action.
https://github.com/steveseguin/Companion-Ninja/blob/main/README.md#callbacks--state-responses
CTRL and selecting multiple videos to record as a director (in control room), it won't ask for the video bitrates multiple times now; just once for all the selected videos. (this hot fix has been applied to production and beta). This feature is useful for recording multiple videos in sync.right-click -> record of a inbound-video, and then hung up without stopping the recording, the recording wouldn't stop and finalize. (on alpha)vdo.ninja/examples/sensoroverlay?view=STREAMID&sensor &sensorfilter=gyro,lin,acc,mag,pos,ori For the above demo, you can use &sensorfilter=pos,lin to just send the data you need, reducing the load on the phone/network. (on alpha)&meshcastscale (&mcscale) parameter; this will scale down the Meshcast video output via the URL, post camera capture setup. Because of how Meshcast works, this is a sender-side parameter. You may wish to use this to lower the resolution if your camera has a fixed capture resolution. (Alternatively, if you need to dynamically adjust the resolution, that option already exists via camera settings via width/height slider adjustments) https://vdo.ninja/alpha/?meshcast&mcscale=50&director parameter + &webcam/&website/&screenshare parameters at the same time (the later parameters get disabled now, avoiding conflicts)&stereo/&proaudio is added to the sender's URL and the sender supports +2-channels. So, if you're using &stereo on your guests, and you can only hear one of your guests on the left or right channel, you can use this to down-mix their microphone to a mono channel only.
Due to some tricky technical challenges, this feature involves down mixing with web-audio nodes, and stereo can't be enabled if &stereo isn't in the URL. It might also make all audio from that guest mono at the moment. (adding &mono to the view URL also works, but that will make all sources in the view link mono)
https://vdo.ninja/alphahttps://vdo.ninja/alpha/speedtest
&scale; &viewheight=180&viewwidth=320, (aka &vw/&vh) which effectively does the same thing as &scale, but instead you pass a resolution.
-- It's important to note, that due to flexibility to request width/heights that are not aspect-ratio compatible, and due to bitrate/quality resolution limitations, these values are just 'max' target resolution values; the actual resolution you get could be still less. They also do not impact the actual capture resolution of the remote sender's camera, so its purely for requesting a specific downscaled resolution. This command applies to all video elements in a view port, and it disables the auto-scaler functionality.
-- Similarly, also added the option to the IFRAME API to request different down-scaled resolutions dynamically, per connection, if you want greater programmatic control vs static URL options.
This is on alpha at vdo.ninja/alpha/?vw=300&imagelist=xxxx can be used to pass a list of images via the URL. Code to generate the list properly can be found here: https://jsfiddle.net/steveseguin/w7z28kgb/ (images must be cross origin enabled)
-- At the base of index.html, if self-hosting VDO.Ninja, you can hard-code the list of images as well.
-- Related: when selecting a background image, you'll get a gentle glow around the selected image now. There's also a horizontal scroll bar, if the number of images listed are too much to fit.
** changes on alpha at https://vdo.ninja/alpha/
&maxbandwidth, which differs from other commands as it leverages a chromium (chrome/edge/brave/electron) feature to judge the available bandwidth of a sender's connection. Passing a value to it as the sender (a percentage; 1 to 100 ideally), you can try to ensure the connection never uses more than that amount of the available reported bandwidth. (on alpha) So the notion is, if you want to set the invite link bitrate to 50-mbps, but one guest only has only a 20-mbps connection, &maxbandwidth=80 will try to limit the bitrate to around 16-mbps. I sometimes will tell people to set the bit rate to about 80% of what their connection can allow, as higher than that can result in some frame stutter when there is packet loss, since the connection lacks headroom to recover. This command will try to do it automatically, for all the viewers of a stream. My goal here is to use it with the mixer or stats app, so eSports users can crank out high bitrates with less tinkering per guest. I have no idea how well it will work in practice so far.&showall (or &style=7), which will include non-media-based push connections as video elements in a group room. This can include guests that joined without audio/video, directors, or a data-only connection, like maybe MIDI-output source. - to help avoid some types of connections showing up when using &showall, I've also added a &nopush mode, which blocks outbound publishing connections. This acts a bit like a &scene=1 link, so unless &showall is added, you'll need to use the IFRAME API to show/hide videos in it. (also just on alpha atm)&remote, if used on a push link without a password added, it will now allow the remote viewer limited control (hangup, focus, zoom, detailed stats), even if they don't have &remote added to their URL also.&remote, the option to "reload" the remote browser is now available, so you can potentially reload a remote unattended session that contains &autostart&webcam
** all changes on alpha @ vdo.ninja/alpha/&effects=2 for mirroring the actual video itself, so I've added two more modes that can flip and flip+mirror. Might be useful for teleprompter work.&record may work now, etc)&bgimage= can be used to set the default image avatar, when using &style=0 or &style=6. This only impacts what the person with the parameter added sees and must be either a URL or a base64 data image/SVG. URL-encoded values. on alpha ie: https://vdo.ninja/alpha/?view=aSmexM6&style=0&nocontrols&bgimage=https%3A%2F%2Fvdo.ninja%2Fmedia%2Fold_icon.png
CTRL+M can work in place of this still by default, but this lets you set a custom combo/key that doesn't act as a mute toggle at all (if just tapped accidentally) ** This is on alpha
&remote control option, the viewer can now remotely hang-up the sender via the right-click menu. The sender needs to remote control enabled for this to work of course. ** on local dev, coming to beta soon.
&totalbitrate (&tb) set both &totalscenebitrate and &totalroombitrate flags. Not quite sure how well it will work, but since a scene and a guest are exclusive possibilities, it's a bit of a flexible way to just learn one flag to do it all, as I realize all the options can get confusing.
&trb and &tsb limit the total incoming bitrate, dividing up the bandwidth available to each video being played back. There are nuances in differences, with the main one being &trb is for a guest link and &tsb is for a scene/view link.
(on local dev for now, pending more testing)&prompt to the push link to enable. (or &approve/&validate)
What it is: After a new peer viewer connection is established, but before the video/audio streams start getting sent to that new viewer, a prompt will appear asking the publisher if they wish to send their stream to that viewer. If they say no, the remote viewer is disconnected and no video/audio is sent to them. If they have &label=xxx added to their view link, that label will appear as the display name. Otherwise, if no label is available, a random ID representing that connection is shown.
There's nothing stopping a disconnected viewer from re-joining and re-asking, causing some grief, and spoofing an identify isn't too hard, but it gives you some control and warning to block unexpected viewers.
In the future, I can add this control to the director, rather than just the senders, and add additional ways to check identities. For now though, it's a start.
&sstype=3 screen share mode did not work as solo links; stats for it were not always cleaned up either, so that's fixed too. (on dev)