Tom

it's not possible to compare Talkshow vs WebRTC with vMix.

Talkshow is a dedicated and proprietary hardware device, worth $3500. It's a client for Skype for Business with SDI i/o ports (thus requiring SDI i/o plugs on the switcher aswell). Nevertheless it also requires a special attention to audio routing. It doesn't work out of the box by magic without you taking care of what you send to it. It's not plug and play. You also need to use AUX outputs in your switcher to select what your remote guest will see and hear, else he will get his audio back with a delay. So the terms and the cabling are different but the logic (or the complexity if you prefer) is the same.

WebRTC is an opensource protocol to serve various versions of Real Time Communications through dedicated web pages. Because it is open source, there are many versions which are usually not fully compatible with each other. The way it works, the way it is implemented by providers/platforms is totally different from Skype. But the logic remains the same:

- route audio and video from this web-application to vMix (NDI is the easiest way)
- route audio and video from vMix to this web-app (a virtual audio cable is still needed unless you have many audio buses on your soundcard)

This way you can choose which WebRTC platform you want to use. Try them, there are plenty, and make a choice according to your needs.

If ever Martin somehow decides to integrate a WebRTC service the way you expect (as a special input, which ihmo is technically impossible considering the way vMix handles audio so far as we cannot route audio Bus A or B towards an INPUT), he will need to choose 1 WebRTC platform (amongst hundreds) and to develop specifically for it. And if this platforms updates its service someday, it may not work anymore in vMix. And this is normal because WebRTC is designed to be served through web pages as a cloud service maintained by the platform itself.

So Tom, just try WebRTC. It's not more complicated than Skype, except you deal with a webpage and not a traditional software. You'll simply need to define inputs and outputs and use a virtual cable. You already know that. I'd be pleased to help if you wish...

Guillaume
Another streaming idiot...

PS : Unless you already did, have a look on NDI Transmit. This might help you to setup configs with 2 PCs as it provides virtual devices like vMix external or VAC but over the network and for NDI sources...

Yes I know this Livestream feature but :

what is Livestream main business? To be an OVP, meaning they have their own data center, tons of servers, a CDN and many people to deal with it.
So they interfaced their OWN WebRTC server in the cloud with Studio.

Martin is not in a position to do so (that's why I said yesterday that Martin would have to choose 1 platform to rely on)
Thats' also why I said if you want WebRTC on your network build your own server and interface it with vMix

This already exists : it's called a browser

WebRTC is a web-app technology based on HTML5 to allow peer-to-peer communication between BROWSERS.

https://en.wikipedia.org/wiki/WebRTC

Sorry if I offended someone but as we say in French "Let's call a cat a cat". It helps understanding things...

The "WebRTC through Web Browser Input" method is challenging, I agree, but did you try to use WebRTC in your regular web browser with desktop capture (as you would do for skype) on the same PC or a second one?

I can add a couple of possibly useful things based upon personal experience.

Firstly, my use of vMix is centered around a weekly podcast about IP communications. We're coming to episode #628 this week. We've been actively covering WebRTC since its inception. We've had the various movers and shakers in the space as guests, including the project lead from Google. We've helped smaller players get exposure, helping them to be purchased by bigger players.

Martin says, "It's early days for WebRTC."

That's just no longer true. Things have largely settled down. The codec wars have subsided and people have moved on to creating products.

That said, I have a hard time seeing how vMix could "integrate webrtc" in a way that didn't completely subsume the product. Further, I don't see the need.

When we interviewed the Jitsi Video Bridge team we used JVB instead of a Hangout. We connected two computers such that we could host the conversation on JVB, and stream one of the clients to YouTube Live. See also part 2.

It took some head scratching to get it all worked out, but it worked fine in the end. The big issue is the audio requirement for multiple mix-minus outputs. I used VoiceMeeter Banana to handle the audio routing outside of vMix.

I did that interview long before NDI was available. NDI makes it a lot easier than before.

My biggest problem at the time was that my vMix host is older and was CPU bound. I think that's the defining thing about such integrations. You probably don't want everything in one PC, presenting a single point of failure.

Tom Sinclair recently did a video showing how to bring someone into vMix using a second PC. This is a turnaround for him. I think that it's is a smarter move, especially when small, inexpensive PCs like the Intel NUCs can be leveraged.

To truly have vMix integrated with WebRTC I think that Martin would need to be running a back-end service, perhaps based upon Jitsi Video Bridge. But that wouldn't satisfy everyone as some would not want the SFU functionality. They might want the Brady Bunch presentation of a traditional MCU instead.

It'd be hard to deliver satisfactory solution within vMix alone. On that basis I say, if it's important to you, it has to be a DIY solution so that you can be in control.

Incidentally, JVB is open source. I have access to a private instance. That lets me do a variety of nice things, like add a watermark logo in the corner, or specify maximum resolution.

Since it's Select Forwarding Unit (SFU) it doesn't actually process the media streams. It merely routes them. That makes it a lightweight app. Our private instance runs on a modest AWS vm.

The alternative is a traditional Multi-point Control Unit (MCU.) This is the classic way to do video conferencing (think Cisco, Polycom, Tandberg) where a server receives all the media streams, decoding them, rendering a presentation layout that gets encoded and sent to everyone.

An MCU requires massive server infrastructure to achieve scale. It adds latency and degrades video quality.

Since JVB created an open source SFU, the Freeswitch team, a leading open source voip + video platform, implemented an MCU.

It appears Newteks Talkshow comes at considerable expense with additional hardware?

http://newtek.com/talkshow

No problems here. I prefer people speak frankly.

- Tom

Sorry to belabor the point, but something just occured to me that won't be obvious. A WebRTC service can be unpredictable in how it loads a host computer. In some cases it may be a modest load, while at other times it can be a serious burden.

This is especially true when the service being used is a peer-to-peer service or an SFU. In both of those cases the load on the host increases with every participant that joins the conference.

I had an instance where everything worked fine with 3-4 participants in testing, but fell over in a heap with 7+ participants.