FIOS isn't exactly normal "consumer Internet." It is not available to most people (and its rollouts were essentially halted a decade or more ago), and it offers far better upload speeds than cable. And it's weird that the audio is BEHIND the video, and by a lot. And the SRT has LESS video delay in the comparison here, not more. He stated the opposite a couple of times, but it's wrong. Pause the video when his hand is in motion, and you'll see that the SRT is ahead of webRTC.
In the side by side camera comparison, SRT looks slightly better but not enough of a difference to be complaining about. With the gaming aspect, both were choppy and laggy.
Thanks for the demo. I notice audio sync is out in both locations. I struggle with this often too with remote guests, especially when compositing like the 2 box, etc. Do you find this a lot with vmix?
Thanks for the video guys. Quick question, how would you handle sending a return feed to a contributor using SRT? I am currently using Vmix call and as you mentioned the advantage is that it sends a return back to the contributor. How would you recreate this using SRT? Thanks
Hello interesting, want to learn here! So I want to deliver a NBA live or Madden game via vmix...I’m in a remote location (control room) 3 contributors (quests?) 2 guests opponents playing and 1 commentary...More than likely I will use webRTC (cost effective!) Now I would like to Livestream this to FB, UA-cam or RTMP(S)? Can you help? Thx so much!!!
Thanks for the demo! Why was Aubrey's audio out of sync? And Phil's was slightly out in the beginning, then when Phil's audio source was switched from webRTC to SRT, his lip sync was perfect, but the webSRT window lip sync and Aubrey's got worse... Also, although you mentioned SRT having slightly more latency than webSRT, it appeared just the opposite to me, that the SRT was slightly ahead of the webRTC?
Hey Ari - so this was shot live in a real world use case - we did not edit or post. In this demo the WebRTC is 6Mb - Unknown at the time we stepped down the SRT to 4Mb - SRT can be as fast as WebRTC but you trade off latency for reliability. In this case the lower bandwidth allowed the SRT feed to be slightly less than latent in this example. That is not typical that we have found but each case and ISP etc is different. Aubrey's audio is running through a ClearCom headset (we use this because our show is about Live Shows so it's more about BTS) - We believe thats why it seems to sound out of synch. It could also be we were running SRT, WebRTC and multiple processes in vMix on one Production Bot which could have caused the drift you see.
So based on my research, it seems like SRT is the better of the two if you have the bandwidth, but SRT also require hardware encoders / decoders on either end to transmit / receive? Or can this be accomplished by software means?
"WebRTC is 2-mbps .SRT is set up with 4-mbps" -- Do you realize that this means your little comparison is utterly worthless? Higher video quality and latency are exactly what you would expect with higher bitrate.
@@LivexTv1 -- but you do realize that giving SRT twice the bitrate that of course the video quality looks better. If you gave WebRTC twice the bitrate, it would have looked better. In a proper comparison you give them both the same bandwidth.
@@reuvenwachtfogel7012 Yes of course - it was a live demo. We had anticipated setting the test up that way but by the time we were live it came to my attention it was not. Its still a valuable test and to say its utterly worthless lacks a fundamental understanding of live vs vod and actual real world testing.
@@LivexTv1 -- What advantage have you shown for one over the other? People are comparing the quality which is wrong to do because of the different bitrates as you already agreed. It is also wrong to compare the latency because increased bitrate usually brings increased latency. So what conclusions are left to draw from your comparison? Not sure what VOD has to do with anything. I certainly understand the difference between ABR and low-latency, As for real-world testing, a proper real-world test would need to compare the 2 approaches under a variety of real-world network conditions, varying jitter, varying packet loss, WIFI connected devices, etc. and see how the two protocols handle each situation. I have no complaint that you didn't do a thorough professional comparison - only that the comparison that you did do is flawed and misleading based on the conclusions people took away in the comments.
Your Web RTC was more delayed, the SRT looked great.
FIOS isn't exactly normal "consumer Internet." It is not available to most people (and its rollouts were essentially halted a decade or more ago), and it offers far better upload speeds than cable.
And it's weird that the audio is BEHIND the video, and by a lot.
And the SRT has LESS video delay in the comparison here, not more. He stated the opposite a couple of times, but it's wrong. Pause the video when his hand is in motion, and you'll see that the SRT is ahead of webRTC.
In the side by side camera comparison, SRT looks slightly better but not enough of a difference to be complaining about. With the gaming aspect, both were choppy and laggy.
We use SRT between the vMix computer and a broadcasting transmitter for one client and we use SRT from the transmitter in Detroit to Israel
This is a great explanation between the two.
Is there a video that explains the set up on the camera end of your example? Specifically the SRT option
Thanks for the demo. I notice audio sync is out in both locations. I struggle with this often too with remote guests, especially when compositing like the 2 box, etc. Do you find this a lot with vmix?
Thanks for the video guys. Quick question, how would you handle sending a return feed to a contributor using SRT? I am currently using Vmix call and as you mentioned the advantage is that it sends a return back to the contributor. How would you recreate this using SRT? Thanks
Hi Daniel - you could send an SRT return feed using our App Rivet
Were the WebRTC links in this demo vMix-to-vMix or browser-to-vMix?
Hello interesting, want to learn here! So I want to deliver a NBA live or Madden game via vmix...I’m in a remote location (control room) 3 contributors (quests?) 2 guests opponents playing and 1 commentary...More than likely I will use webRTC (cost effective!)
Now I would like to Livestream this to FB, UA-cam or RTMP(S)?
Can you help? Thx so much!!!
Thanks for the demo! Why was Aubrey's audio out of sync? And Phil's was slightly out in the beginning, then when Phil's audio source was switched from webRTC to SRT, his lip sync was perfect, but the webSRT window lip sync and Aubrey's got worse... Also, although you mentioned SRT having slightly more latency than webSRT, it appeared just the opposite to me, that the SRT was slightly ahead of the webRTC?
Hey Ari - so this was shot live in a real world use case - we did not edit or post. In this demo the WebRTC is 6Mb - Unknown at the time we stepped down the SRT to 4Mb - SRT can be as fast as WebRTC but you trade off latency for reliability. In this case the lower bandwidth allowed the SRT feed to be slightly less than latent in this example. That is not typical that we have found but each case and ISP etc is different. Aubrey's audio is running through a ClearCom headset (we use this because our show is about Live Shows so it's more about BTS) - We believe thats why it seems to sound out of synch. It could also be we were running SRT, WebRTC and multiple processes in vMix on one Production Bot which could have caused the drift you see.
The audio sync was terrible the whole time. But you're right that SRT is ahead of webRTC. Pausing during his arm motion easily shows this.
Which WebRTC Program did you use, or was it something you developed for yourselves?
+1
We used vMix Call as the WebRTC side in this video. We also have a Ultra Low Latency product called LiveX Director : director.livex.tv/
So based on my research, it seems like SRT is the better of the two if you have the bandwidth, but SRT also require hardware encoders / decoders on either end to transmit / receive? Or can this be accomplished by software means?
Mostly Hardware but you can check out rivet.stream for our Software encoder solution
What coders are you using to use up to 8 cameras with SRT?
Hi Phil, you can use 2 makitos x4: www.haivision.com/products/makito-series/makito-x4-video-encoder/
Or take a look on Kiloview... The Makitos are REALLY expensive for what their doing...
@@Keksstar Do you have any experience with Klioview? The specs look great, but i haven't had the chance to test it.
@@johannesgasthuber3366 well, then give it a try? they´re doing it´s job... nothing less, nothing more...
@@johannesgasthuber3366 i just got a Kiloview e2. So far, it works as expected. Did you already try this brand? What is your experience?
"WebRTC is 2-mbps .SRT is set up with 4-mbps" -- Do you realize that this means your little comparison is utterly worthless? Higher video quality and latency are exactly what you would expect with higher bitrate.
I dont think the comparison is worthless. Its a real world example on an actual live show.
@@LivexTv1 -- but you do realize that giving SRT twice the bitrate that of course the video quality looks better. If you gave WebRTC twice the bitrate, it would have looked better. In a proper comparison you give them both the same bandwidth.
@@reuvenwachtfogel7012 Yes of course - it was a live demo. We had anticipated setting the test up that way but by the time we were live it came to my attention it was not. Its still a valuable test and to say its utterly worthless lacks a fundamental understanding of live vs vod and actual real world testing.
@@LivexTv1 -- What advantage have you shown for one over the other? People are comparing the quality which is wrong to do because of the different bitrates as you already agreed. It is also wrong to compare the latency because increased bitrate usually brings increased latency. So what conclusions are left to draw from your comparison?
Not sure what VOD has to do with anything. I certainly understand the difference between ABR and low-latency,
As for real-world testing, a proper real-world test would need to compare the 2 approaches under a variety of real-world network conditions, varying jitter, varying packet loss, WIFI connected devices, etc. and see how the two protocols handle each situation. I have no complaint that you didn't do a thorough professional comparison - only that the comparison that you did do is flawed and misleading based on the conclusions people took away in the comments.
@@reuvenwachtfogel7012 Its one of many - to say its worthless is counterproductive
hello
Hello!
@@LivexTv1 Hello
@@philgreen5906 Hello!