I would really love to build a general WebRTC tester. Spinning up lots of Chromium instances is super expensive. Even if you do the mock webcam you are doing way more then needed.
I created[0] which spins up many PeerConnections to load test a server. I think this would be a great alternative to the testing that exists today. * You can send pre-encoded video or RTP packets directly. * You can receive RTP and not pay the costs of processing * You get direct access to Receiver Reports, Transport Wide Congestion Control and Receiver Estimated Max Bandwidth. * Way easier to deploy. We can build a small static binary. If anyone is interested would love to help them kick off a project. We can make it general enough to test Galene, Janus, Jitsi, Ion etc... If it gets acceptance from the greater WebRTC community it could really grow! [0] https://github.com/pion/rtsp-bench/blob/master/client/main.go On Tue, Mar 02, 2021 at 05:01:42PM +0100, Luca Muscariello wrote: > Dave, > > we have done extensive WebRTC (and several other online meeting > apps) testing lately and this paper > https://ieeexplore.ieee.org/document/9153228 reports a > methodology for WebRTC based on Chromium and Selenium Grid and > as test orchestrator Jitsi Torture. > > I would avoid feeding clients with BBB as video as it is not > representative of a meeting as encoders are optimized for > different kinds of video. There are several video samples > out there. > > We have scaled up clients to hundreds with this methodology. > The paper is short so many details have been omitted but there > are not many other options to do this kind of test at scale. > > Luca > > > > > > > > describes the methodology > > > > On Tue, Mar 2, 2021 at 2:15 AM Dave Taht <[email protected]> wrote: > > > Given that we have a worldwide network of flent servers... > > > > Given how easy galene is to hack on... and a 10 minute install... > > > > given some webrtc scripting... a few more stats... some javascript... > > skull sweat... funding... > > > > It seems plausible to be able to construct a suite of tests that could > > indeed track jitter > > delay and loss across the internet over webrtc. Perpetually uploading > > bigbuckbunny or some > > other suitable movie might be an option, but I have a fondness for > > extracting a sub 30 second segment from "Max Headroom", which if > > those here have not seen it, predicted much of the fine mess we're all > > in now. > > > > I guess my question is mostly, is a "headless" test feasible? In the > > context of samknow's lack of webrtc test... lowpowered hw.... > > > > -- > > "For a successful technology, reality must take precedence over public > > relations, for Mother Nature cannot be fooled" - Richard Feynman > > > > [email protected] <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729 > > _______________________________________________ > > Bloat mailing list > > [email protected] > > https://lists.bufferbloat.net/listinfo/bloat > > > _______________________________________________ > Galene mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
