logo

Live Production Software Forums


Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
TBacker  
#1 Posted : Saturday, January 11, 2020 2:00:12 AM(UTC)
TBacker

Rank: Advanced Member

Groups: Registered
Joined: 10/29/2019(UTC)
Posts: 51
United States
Location: Syracuse

Thanks: 4 times
I know this is the way that vMix call functions at present, but is it good?

We have two vMix call inputs that we use for multiple guests on multiple shows, but it's unnerving to have what happened today happen - the guest for the next hour connected early and kicked a live guest off.

Yes, managing talent is one solution, but in our case they are not TV nor technical people, so they will always be prone to error.

I would much rather callers get a "Channel is busy, try again later" message when they attempt to connect with an already active login so we can protect our on-air product. Or better yet, have it say "Connection busy, waiting for previous call to conclude" then retry every 15-30 seconds.
mjgraves  
#2 Posted : Saturday, January 11, 2020 6:50:12 AM(UTC)
mjgraves

Rank: Advanced Member

Groups: Registered
Joined: 7/1/2015(UTC)
Posts: 972
Man
United States
Location: Houston TX

Thanks: 283 times
Was thanked: 228 time(s) in 201 post(s)
vMix Call is a WebRTC application. Much of its functionality a constrained by WebRTC as a platform. There is no way to implement what you suggest without a major amount of work to abandon the mechanics of WebRTC in the browser, and re-engineer the web service itself.

You're better off to upgrade your vMix license to support more vMix Call instances. My 4K license supports 2, pro supports 4. That way you can give separate access details to each of your guests.

I suppose you might have separate vMix Call instances for each of them preset in your project. Perhaps only the # allowed by your license would be allowed to connect.
TBacker  
#3 Posted : Saturday, January 11, 2020 8:30:48 AM(UTC)
TBacker

Rank: Advanced Member

Groups: Registered
Joined: 10/29/2019(UTC)
Posts: 51
United States
Location: Syracuse

Thanks: 4 times
I will have to read into the WebRTC protocol, but I have to say I have my doubts that there is no way to block subsequent calls using the same ID/password as an established call. The server in the middle (at vMixCall.com) is responsible for looking at the ID, mapping it to a listening vMix session input, and negotiating the WebRTC handshake / protocols that the ends will use. I'm pretty sure there are multiple steps during this process handled outside of the API (in StudioCoast code) during the call progress - read multiple places to block the call progress.

Again, I could be wrong. I will read up more on WebRTC.

mjgraves  
#4 Posted : Tuesday, January 14, 2020 4:27:45 AM(UTC)
mjgraves

Rank: Advanced Member

Groups: Registered
Joined: 7/1/2015(UTC)
Posts: 972
Man
United States
Location: Houston TX

Thanks: 283 times
Was thanked: 228 time(s) in 201 post(s)
Martin & the team stood up the service quickly, and for free, buy leveraging a reference implementation of a webRTC video chat service.
That reference implementation does not have the capability you describe.

It could be implemented, but it would require significant effort for little advantage, and for zero additional revenue.
TBacker  
#5 Posted : Tuesday, January 14, 2020 4:45:24 AM(UTC)
TBacker

Rank: Advanced Member

Groups: Registered
Joined: 10/29/2019(UTC)
Posts: 51
United States
Location: Syracuse

Thanks: 4 times
Originally Posted by: mjgraves Go to Quoted Post
Martin & the team stood up the service quickly, and for free, buy leveraging a reference implementation of a webRTC video chat service.
That reference implementation does not have the capability you describe.

It could be implemented, but it would require significant effort for little advantage, and for zero additional revenue.


That's fine. I guess if we want guest hits that can't be interrupted while on the air we'll have to do them via other stream/input types or assign new passwords every use. Having a live guest suddenly replaced by someone connecting a minute or two early is horrendous.

I'll add - be careful with the "it won't make money, so we won't do it" litmus test. I fully understand that coding time and resources are limited, and a company exists to make money. And in this case the benefit may not be in my favor, but if something saves headaches and adds to the overall utility and feeling of being a "well thought out, my bases are covered, no surprises" product, that it should at least be in the bottom of the priority list.
Barney Box Lane  
#6 Posted : Monday, January 20, 2020 2:10:45 AM(UTC)
Barney Box Lane

Rank: Advanced Member

Groups: Registered
Joined: 8/21/2017(UTC)
Posts: 309
Location: Uk

Thanks: 24 times
Was thanked: 33 time(s) in 29 post(s)
If its important and worth it then they do offer more callers in the 4k/pro version where you can add up to 8 with their own passwords
thanks 2 users thanked Barney Box Lane for this useful post.
sinc747 on 1/21/2020(UTC), mjgraves on 1/21/2020(UTC)
Bunkerboss  
#7 Posted : Friday, February 14, 2020 8:31:44 PM(UTC)
Bunkerboss

Rank: Newbie

Groups: Registered
Joined: 2/14/2020(UTC)
Posts: 7
Netherlands
Location: Leiden

My idea for a liveshow would be: throw a few links in the comments and let the viewers get into the show. But when they can kick each other out, that will be a problem for sure.

I would love to see the possibility to 'lock' someone, after a login. Or would there be another solution for this?
grantcoll  
#8 Posted : Sunday, March 22, 2020 6:48:17 AM(UTC)
grantcoll

Rank: Advanced Member

Groups: Registered
Joined: 10/7/2017(UTC)
Posts: 32
Location: Hamilton

Thanks: 6 times
Was thanked: 1 time(s) in 1 post(s)
My experience with this shows the following:
One guest connected and talking.
A second guest joins in, typing his own name, but mistyping the password, I typed the same password as the first guest. This freezes both, and at vmix, both call inputs become named the second name, and both are frozen. This is no way to recover, as the calls can't be reset at that end. Even closing the offending ( 2nd call ), the first is still frozen.

This is a risk, as someone could type in a different password by mistake, and take out another clients show.
admin  
#9 Posted : Sunday, March 22, 2020 12:45:07 PM(UTC)
admin

Rank: Administration

Groups: Administrators
Joined: 1/13/2010(UTC)
Posts: 4,401
Man
Location: Gold Coast, Australia

Was thanked: 2530 time(s) in 1096 post(s)
Closing all browser windows that are using that password, and logging in again from a new browser window will recover the call.
This is actually by design, as browsers and internet connections can fail, and maybe the guest wants to move over to a mobile phone to connect at a moment's notice, for just one example.

Finally, it is not possible practically speaking to randomly type in a password and knock some person off a call, the chances are extremely low for that to occur.
(There are billions of potential call passwords, all randomly generated)
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.