Well… this week we had a bit of a rough start, but we’re here. We just updated our production version of testRTC with some really cool capabilities. The time was selected to fit with the vacation schedule of everyone in this hectic summer and also because of some nagging Node.js security patch.
As always, our new release comes with too many features to enumerate, but I do want to highlight something we’ve added recently because of a couple of customers that really really really wanted it.
Screen sharing.
Yap. You can now use testRTC to validate the screen sharing feature of your WebRTC application. And like everything else with testRTC, you can do it at scale.
This time, we’ve decided to take appear.in for a spin (without even hinting anything to Philipp Hancke, so we’ll see how this thing goes).
First, a demo. Here’s a screencast of how this works, if you’re into such a thing:
Testing WebRTC Screen Sharing
There are two things to do when you want to test WebRTC screen sharing using testRTC:
- “Install” your WebRTC Chrome extension
- Show something interesting
#1 – “Install” your WebRTC Chrome extension
There are a couple of things you’ll need to do in the run options of the test script if you want to use screen sharing.
This is all quite arcane, so just follow the instructions and you’ll be good to go in no time.
Here’s what we’ve placed in the run options for appear.in:
#chrome-cli:auto-select-desktop-capture-source=Entire screen,use-fake-ui-for-media-stream,enable-usermedia-screen-capturing #extension:https://s3-us-west-2.amazonaws.com/testrtc-extensions/appearin.tar.gz
The #chrome-cli thingy stands for parameters that get passed to Chrome during execution. We need these to get screen sharing to work and to make sure Chrome doesn’t pop up any nagging selection windows when the user wants to screen share (these kills any possibility of automation here). Which is why we set the following parameters:
- auto-select-desktop-capture-source=Entire screen – just to make sure the entire screen is automatically selected
- use-fake-ui-for-media-stream – just add it if you want this thing to work
- enable-usermedia-screen-capturing – just add it if you want this thing to work
The #extension bit is a new thing we just added in this release. It will tell testRTC to pre-install any Chrome extensions you wish on the browser prior to running your test script. And since screen sharing in Chrome requires an extension – this will allow you to do just that.
What we pass to #extension is the location of a .tar.gz file that holds the extension’s code.
Need to know how to obtain a .tar.gz file of your Chrome extension? Check out our Chrome extension extraction guide.
Now that we’ve got everything enabled, we can focus on the part of running a test that uses screen sharing.
#2 – Show something interesting
Screen sharing requires something interesting on the screen, preferably not an infinite video recursion of the screen being shared in one of the rectangles. Here’s what you want to avoid:
And this is what we really want to see instead:
The above is a screenshot that got captured by testRTC in a test scenario.
You can see here 4 participants where the top right one is screen sharing coming from one of the other participants.
How did we achieve this in the code?
Here are the code snippets we used in the script to get there:
var videoURL = "https://www.youtube.com/tv#/watch?v=INLzqh7rZ-U";
client
.click('.VideoToolbar-item--screenshare.jstest-screenshare-button')
.pause(300)
.rtcEvent('Screen Share ' + agentSession, 'global')
.rtcScreenshot('screen share ')
.execute("window.open('" + videoURL + "', '_blank')")
.pause(5000)
// Switch to the YouTube
.windowHandles(function (result) {
var newWindow;
newWindow = result.value[2];
this.switchWindow(newWindow);
})
.pause(60000);
.windowHandles(function (result) {
var newWindow;
newWindow = result.value[1];
this.switchWindow(newWindow);
});
We start by selecting the URL that will show some movement on the screen. In our case, an arbitrary YouTube video link.
Once we activate screen sharing in appear.in, we call rtcEvent which we’ve seen last time (and is also a new trick in this new release). This will add a vertical line on the resulting graphs so we know when we activated screen sharing (more on this one later).
We call execute to open up a new tab with our YouTube link. I decided to use the youtube.com/tv# URL to get the video to work close to full screen.
Then we switch to the YouTube in the first windowHandles call.
We pause for a minute, and then go back to the appear.in tab in the browser.
Let’s analyze the results – shall we?
Reading WebRTC screen sharing stats
Screen sharing is similar to a regular video channel. But it may vary in resolution, frame rate or bitrate.
Here’s how the appear.in graphs look like on one of the receiving browsers in this test run. Let’s start with the frame rate this time:
Two things you want to watch for here:
- The vertical green line – that’s where we’ve added the rtcEvent call. While it was added to the browser who is sending screen sharing, we can see it on one of the receiving browsers as well. It gets us focused on the things of interest in this test
- The incoming blue line. It starts off nicely, oscillating at 25-30 frames per second, but once screen sharing kicks in – it drops to 2-4 frames per second – which is to be expected in most scenarios
The interesting part? Appear.in made a decision to use the same video channel to send screen sharing. They don’t open an additional video channel or an additional peer connection to send screen sharing, preferring to repurpose an existing one (not all services behave like that).
Now let’s look at the video bitrate and number of packets graphs:
The video bitrate still runs at around 280 kbps, but it oscillates a lot more. BTW – I am using the mesh version of appear.in here with 4 participants, so it is going low on bitrate to accommodate for it.
The number of video packets per second on that incoming blue line goes down from around 40 to around 25. Probably due to the lower number of frames per second.
What else is new in testRTC?
Here’s a partial list of some new things you can do with testRTC
- Manual testing service
- Custom network profiles (more about it here)
- Machine performance collection and visualization
- Min/max bands on high level graphs
- Ignore browser warnings and errors
- Self service API key regeneration
- Show elapsed time on running tests
- More information in test runs on the actual script and run options used
- More information across different tables and data views
Want to check screen sharing at scale?
You can now use testRTC to automate your screen sharing tests. And the best part? If you’re doing broadcast or multiparty, you can now test these scales easily for screen sharing related issues as well.
If you need a hand in setting up screen sharing in our account, then give us a shout and we’ll be there for you.
