Resolution / Bitrate / Framerate concerns

Prepping / testing for a call today to be on Wirecast in the Wild, I'm confirming my camera feed since this is the first time I'll be using Rendezvous since it was recommended against launch back in the beta version of it and I'm seeing a significant quality drop in the output of the video between computers even on the same network. I know I'm sending 720 and 1080, I know my network can handle that traffic as it can do 1080p60 NDI, but the quality and frame degradation happening seems abysmal. Is this what it always has been?

cc: Jens Jarke and Greg Kuhnert

23replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Currently, Rendezvous doesn't support 1080. It can support 720 but it'll drop depending on conditions and number of people on call.




  • CraigS Well that is disappointing.

  • Matthew Potter I think WebRTC technology is advancing quickly though. 

  • CraigS interestingly, the code shows that screen capture supports 1080 but video doesn't you say.

  • Matthew, I suggested to Greg to use NDI over WAN as we both are infront of a greenscreen. He is on MAC and the software is Windows only. If you like we can do some testing if you are on windows. 

    If we send our feeds as NDI into a central system with enough power and bandwidth we should be able to do these kind of remote guests in good quality.

  • Matthew Potter said:
    the code shows that screen capture supports 1080

     If WebRTC backend can support 1080 it would be immediately available. 

    Jens Jarke said:
    If we send our feeds as NDI into a central system

    NDI over the internet is also an interesting area to consider of course, as the tools are being presented.

  • Jens, so far the best for this I've found is Skype. It allows for each participant to be a distinct NDI feed of ONLY their video meaning that if they send a message in and it shows in the interface, the video feed is not impacted. Great for backchannel communication without impacting the source. The quality so far has been pretty good so long as the source is fine and the persons have enough bandwidth.

    My biggest issue with it so far is 2 things: all audio from a conference call is combined for each feed so you need to disable audio for all but 1 and Skype no longer allows for their icon to be removed from the signal.

  • CraigS said:
     If WebRTC backend can support 1080 it would be immediately available. 

     I'm sorry, can you be more specific here? WebRTC backend? WebRTC does support 1080p.


    WebRTC uses a backend to perform the introduction handshake but it is a peer to peer technology.

  • The server doesn't support it as implemented. If you think we can make the changes on our end please do request it but there are "challenges" to that.

  • CraigS Would those "challenges" be anything to do with the engineers not being able to get a smooth video output from the WebRTC client side into Wirecast even at the current 720p resolution and they don't want to effectively create a worse experience for professionals who want to use Rendezvous with higher resolutions when they can't provide a solid experience in the current iteration?

    I would think a better idea would be focusing on creating a solid way to be able to add audio channels available for the system to which you could use other tools and independent partnerships so it would take the stress off them. Reach out to Skype devs, reach out to Zoom, work with them on creating a method to communicate to these softwares (whom are already thinking of creating solid local NDI feeds) and have them be able to integrate with Wirecast instead of building your own tool which depends on browser technologies that update and are not consistent on a per platform basis. Heck, not consistent on a per device basis. Partner With Microsoft and piggyback on their NDI output but have it even labelled as a "Skype" input. Then have it where you can send back ONLY the audio that is not from that input. Instant mix minus ability or better yet, you don't even have to worry about it since they already handle that. Work with Zoom on what I can only assume is currently being built since they focus on quality of the feeds. A perfect pairing for ensuring quality of inputs.

    Rendezvous was a nice experiment. It launched before it was ready, it's always been a pain for you and the engineers (Based on what I always see in the forum) and with the restrictions that are still there for quality and bitrates, it doesn't seem like a solution that I would recommend anybody use in what amounts to a professional environment.

  • Matthew Potter Rendezvous works for guests who don't have the capacity to deal with third party programs like Skype. I often deal with guests who have limited computer knowledge and, for them, a webcam in Chrome or Firefox is far easier than having them sign up for Skype and figure out how to use it with short notice. 

  • Matthew Potter 


  • CraigS yup. Testing shows that my cameras are capable of doing 1920x1080... 

    Check resolution 320x240

    Check resolution 640x480

    Check resolution 1280x720

    Check supported resolutions

    [ OK ] Supported: 160x120

    [ OK ] Supported: 160x120

    [ OK ] Supported: 320x180

    [ OK ] Supported: 320x240

    [ OK ] Supported: 640x360

    [ OK ] Supported: 640x480

    [ OK ] Supported: 768x576

    [ OK ] Supported: 1024x576

    [ OK ] Supported: 1280x720

    [ OK ] Supported: 1280x768

    [ OK ] Supported: 1280x800

    [ OK ] Supported: 1920x1080

    [ OK ] Supported: 1920x1200

    [ INFO ] 3840x2160 not supported

    [ INFO ] 4096x2160 not supported

  • Matthew Potter I'm testing with a Logitech C920 and it's only supported to 720 even though it supports 1080. What are you testing with?

  • Matthew Potter OK now I'm getting the same results as you. Using Chrome 72.
    Perhaps on at least a one on one call 1080 could be viable.

  • CraigS Indeed, here's a video I just made of it to ensure I'm not BSing you. 

  • CraigS figures... you reply just as I am pushing send. Sorry, I hope that last post doesn't come off as a "told you so" it was intended as a proof and being sure I'm not flappin' my gums.

  • Just so you know, this week's show was cancelled due to internet issues. At least my provider acknowledged the problem. Back next week.

    Like 1
  • A solid WebRTC solution is kinda expensive. In an ideal world WebRTC uses a P2P communication managed by a central signalling server. A and B talking to the signalling server providing their IPs and then start communicating P2P. This is the cheap way.The signalling server is just there to introduce the partners and hand off the traffic to them.

    In reality it's not always possible. Then there is a TURN server to be used. The TURN server sits then in the middle as a star point. Taking all data streams in and sending them out to the participants. This is expensive for the WebRTC vendor as he has to pay the bill for the traffic. To limit the costs you can reduce quality.

    Just to set expactations correct on both ends.

  • Jens Jarke We do use a TURN server.

  • CraigS It looks like there has been some minor updates to the rendezvous server side code however I just wanted to point out that the current settings that are used max out the resolution to 720 for camera feeds but allow for max 1080 for screen sharing:

  • Matthew Potter More to come (we expect).

    Like 1
  • CraigS said:
    More to come (we expect).

    My hope is that this would be configurable. Yes, we all want perfect high resolution video... BUT, some people might have bandwidth constraints. Making this stuff configurable will give you an advantage over your competition.

    At an extreme end, even let us turn off video feeds to remote guests. The important factor is getting their data in and broadcast out. Sometimes, them seeing a studio shot can be secondary to the other objectives.


    Like 1
Like Follow
  • 1 yr agoLast active
  • 23Replies
  • 262Views
  • 6 Following