A Hybrid Approach for WebRTC Video Streaming on Resource-Constrained Devices

Abstract

This paper introduces thorough comparative and interoperability analyses involving a browser-based P2P video streaming approach utilizing WebRTC (web real-time communication), along with WebRTC hybrid solutions developed using the React Native framework (for mobile) and the electron framework (for desktop and Raspberry Pi). The assessment is carried out based on various metrics, including CPU (central processing unit) load, RAM (random access memory) utilization, and network data consumption. The obtained findings highlight the potential of integrating WebRTC P2P video streaming into hybrid applications as a promising alternative for real-time video streaming applications in embedded systems; given that, compared to the current mainstreams, e.g., Chrome or Firefox, the proposed approach has superiority performance in terms of CPU load, RAM usage, and network occupancy. The results also demonstrated that interoperability is ensured between the two types of applications (web-based and hybrid-based one).

1. Introduction

Optimizing WebRTC’s performance is crucial due to the rising demand for real-time video communication, especially on devices with limited resources. WebRTC, an open-source framework, eliminates the necessity for plugins and incorporates powerful tools for audio and video encoding/decoding. These tools include codecs like Opus, iSAC, and iLBC for audio, and VP8 and VP9 for video. Additionally, WebRTC consists of features such as acoustic echo cancellation for suppressing real-time echoes, noise reduction to mitigate common background noise in VoIP (Voice over Internet Protocol) calls, a dynamic jitter buffer that addresses packet loss effects, and image enhancement for reducing noise in webcam-based videos.

WebRTC integrates a secure media layer management using protocols like SRTC (secure real-time transport protocol), ICE (interactive connectivity establishment), STUN (session traversal utilities for NAT), and TURN (traversal using relays around NAT). The main purpose is to aid in developing real-time communication (RTC) applications on web browsers, mobile devices, and IoT (internet of things) devices. These applications can communicate using a common protocol set [1]. Compatibility covers contemporary web browsers and native/hybrid clients on major desktop and mobile platforms. The technologies behind WebRTC are implemented as a standard web feature and can be accessed through standard JavaScript APIs (application programming interfaces) on major browsers. Equivalent functionality is available for native/hybrid clients, such as Android and iOS, through a dedicated library. The WebRTC initiative was initiated by Google in 2011 and received support from W3C (World Wide Web Consortium) and IETF (Internet Engineering Task Force).

WebRTC primarily targets web browsers and native/hybrid clients across various devices. Nonetheless, there is limited research available concerning its application outside of browsers and on devices with constrained resources.

Boni et al. [2] investigated various full-reference (FR) models’ performance in WebRTC applications for video and audio. They established an open-source benchmark to simulate changing network conditions—packet loss (15%, 30%, and 45%) and jitter (25 ms, 50 ms, and 75 ms). Different existing FR metrics for video (VMAF, VIFp, SSIM, MS-SSIM, PSNR, PSNR-HVS, and PSNR-HVS-M) and audio (PESQ, ViSQOL, and POLQA) were used, along with respective references. They also conducted a subjective assessment through mean opinion scores (MOS), where users rated audio and video quality. Objective-subjective correlations were calculated to find models that best aligned with subjective results. VMAF, VIFp, and POLQA showed significant correlation with subjective outcomes during packet loss scenarios.

The authors in Reference [3] carried out real-world experiments on mobile nodes using the MONROE platform to investigate WebRTC performance. They studied WebRTC performance in different wireless settings, considering both static and mobile cellular users. The study analyzed application and network data, addressing the impact of mobility on WebRTC due to limited quality from mobile broadband providers. The primary emphasis was on Google Chrome, with an investigation into metrics such as video frame rate, bit rate, packet delay, and jitter delay.

Asif et al. [4] conducted a study comparing WebRTC video conferencing to a Skype-based solution with the goal of evaluating the potential advantages of an integrated approach. The integration involved adding WebRTC to an existing groupware web application called PowerMeeting. The study compared this with PowerMeeting’s existing Skype-based system. The results revealed that although users recognized WebRTC’s potential with minor drawbacks, Skype exhibited better stability and quality for groupware tasks. Notably, WebRTC technology has advanced considerably since their study. Their solution was based on the SimpleWebRTC library, which was developed prior to WebRTC’s initial stable release [5]. Therefore, a WebRTC hybrid application could potentially offer an enhanced solution.

Bacco et al. [6] investigated real-time video streaming via the WebRTC platform, specifically on power-constrained devices such as Raspberry Pi. They determined that the default WebRTC settings prioritize video quality over energy efficiency. However, they demonstrated the possibility of maintaining comparable video quality while reducing energy consumption by about 30%, as opposed to default configurations. This was accomplished through actions like decreasing the CPU frequency (from 1200 MHz to 600 MHz), reducing the source bit rate, and modifying the “cpu_used” parameter within the VP8 video codec of WebRTC. Their primary objective was to enhance the energy efficiency of WebRTC video streaming, which is vital for systems with limited resources.

In Reference [7], the authors presented a test environment designed to perform experiments on real-time multimedia sessions using the WebRTC method over LTE (long-term evolution) infrastructure. This setup utilizes the NS-3 simulator and evaluates performance metrics like throughput, jitter, and packet loss within various simulated mobile network scenarios. The study also has connections to web browsing.

Kundan et al. [8] presented seven unique cross-platform applications created using Chrome App and Apache Cordova frameworks. These applications employed WebRTC for live audio-video streaming and interacted with cloud servers using HTTPS. The study discussed obstacles such as media management and network problems. Yet, it lacked a comparison between browser-based WebRTC solutions and hybrid alternatives concerning hardware-related performance. This factor, involving CPU load and RAM utilization, significantly impacts video conferencing user experience.

In Reference [9], a WebRTC solution was developed to enable video conferencing with bidirectional communication across diverse networks, including wired and Wi-Fi connections in both LAN (local area network) and WAN (wide area network) setups. The evaluation encompassed CPU performance, bandwidth utilization, and quality of experience (QoE). The findings demonstrated that WebRTC audio communication consumed around (53–54 kBit/s) on LAN and (48–50 kBit/s) on WAN. Additionally, CPU usage averaged between 13% and 17% in their testing environment. It is worth noting that the study focused exclusively on the Google Chrome browser and did not cover mobile devices or hybrid applications.

In the process of creating a P2P video conferencing platform with WebRTC, Khalid et al. [10] analyzed CPU and memory consumption in relation to the number of users participating in the conference. Although their emphasis was primarily on web browsers, their study provides a strong foundation for evaluating the technical efficiency (CPU utilization and RAM consumption) of a P2P video conferencing system built on WebRTC technology.

Van et al. [11] introduced a novel method for developing an advanced 360-degree vision telepresence wheelchair for healthcare use. They utilized the WebRTC protocol for effective video and data streaming. Experimental results confirmed seamless real-time 360-degree video streaming, averaging 25.83 frames per second, with an average peak signal-to-noise ratio (PSNR) of 29.06 dB. The simulation results for the proposed QoE estimation scheme exhibited 94% prediction accuracy. This solution operates through a web browser interface.

In Reference [12], a video conferencing system was presented, using Mozilla Firefox and the ScaleDrone service for multi-participant communication. This method prioritizes rapid data transmission via WebRTC. Additionally, they investigated the incorporation of a thermal camera into the system for detecting body temperature in relation to COVID-19. It is worth highlighting that their approach is entirely reliant on web browsers.

In Reference [13], Agnieszka and colleagues studied the interaction between IEEE 802.11 network’s QoS mechanism and WebRTC’s congestion control. The research found that WebRTC adjusts video stream transmission to align with wireless link throughput, ensuring smooth real-time streaming and minimizing errors in scenarios of multiple video streams surpassing available throughput. The investigation primarily focused on the Google Chrome browser.

The work mentioned in Reference [14] presents a lab-based framework for interactive hands-on assignments applicable to a range of STEM disciplines. Through the integration of WebRTC technology, the framework allows for an instantaneous interaction between educators and learners during practical tasks. Furthermore, this framework is constructed using web browser capabilities.

In Reference [15], a new approach is presented for a multi-party WebRTC service model designed for upcoming 5G networks. In this configuration, a video service provider (VSP) collaborates with network service providers (NSPs) to offer an NSP-managed service that can stream adaptive video layers. The approach relies on software-defined networking (SDN) to facilitate internet protocol (IP) multicasting among peers, using the NSP infrastructure. The authors demonstrate the advantages of the SDN-backed IP multicast service architecture compared to the traditional SFU (central selective forwarding unit) model. These benefits include improved network resource utilization, lower end-to-end service latency, and addressing concerns about uneven traffic distribution and peer upload bandwidth limitations.

The authors in Reference [16] presented a simple approach for performing QoE-driven non-functional tests on WebRTC services. This approach utilizes the ElasTest open-source platform to perform thorough end-to-end testing on complex systems. The initial validation of this approach included a study that compared the effort required to evaluate the QoE of WebRTC services, both with and without the ElasTest platform. The results suggest that ElasTest improves the ease of setting up the test environment, coordinating the execution of SUT modules, and capturing and comparing metrics/logs during the execution of test cases.

The study mentioned in Reference [17] involved analyzing the distinctions between native and cross-platform frameworks intended for mobile apps. The investigation encompassed both basic and intricate applications, developed through the two methodologies, with a focus on parameters like CPU and RAM utilization, application size, and startup performance. The research was predominantly centered around the iOS and Android platforms. The three primary cross-platform frameworks evaluated were Xamarin, Flutter, and React Native. Additionally, the researchers evaluated the relative complexity of implementation for each of these frameworks. It is important to note that their examination excluded web applications and apps built on WebRTC technology.

Moreover, several recent studies have been conducted on audio and video quality assessment (A/V-QA) in a video streaming application.

The authors in Reference [18] proposed four families of objective audio video (A/V) quality prediction models that combine single-mode quality predictors or quality-aware features. To do this, they created a substantial and distinctive dataset called the LIVE-SJTU A/V-QA Database, which includes 336 A/V sequences distorted in ways typical of streaming situations. For this purpose, they conducted a subjective A/V-QA study to collect real quality ratings for all the distorted A/V sequences in the database. These ratings were then used to compare and enhance the A/V objective models. The findings revealed that all four categories of suggested A/V-QA models showed promising results when assessed on the LIVE-SJTU A/V-QA database.

In contrast to traditional image quality assessment (IQA) metrics, which assess the difference between distorted and perfect images, Xiongkuo et al. [19] introduced a new concept: the pseudo reference image (PRI). This image is generated from the distorted image and undergoes the most severe distortion. They developed a blind IQA framework using the PRI, quantifying the gap between the distorted image and the PRI. The study revealed that the proposed model demonstrates improved or comparable quality prediction performance compared to existing metrics. Additionally, the authors highlighted the efficacy of the proposed metrics for both natural scene and screen content images.

Numerous surveys on the current models for audio and video quality assessment have also been carried out.

The authors in Reference [20] undertook a thorough and up-to-date examination of perceptual image quality assessment. They delved into databases for subjective quality assessment, covering established as well as emerging datasets. Afterward, they appraised conventional metrics for full-reference, reduced-reference, and no-reference image quality. Moreover, they categorized and appraised diverse measures for objective image quality assessment, considering their applications and methodologies.

In Reference [21], the authors present a comprehensive overview of the background, historical context, recent advancements, and future prospects in emerging research on screen content quality assessment. The study concentrates on highlighting distinctions and similarities between screen content and conventional natural scene content.

In a previous study (available at reference [22]), we compared a browser-based WebRTC videoconferencing solution with a hybrid alternative for mobile devices. This encompassed various networks such as Wi-Fi and LTE. Furthermore, we juxtaposed a hybrid mobile app using WebRTC with the video call function of two well-known multimedia apps: Meta Messenger and Meta WhatsApp Messenger. Our findings revealed that a WebRTC videoconferencing hybrid app, developed using React Native, yielded similar results to the two major apps in terms of CPU usage and RAM usage. This emphasizes both the effectiveness of WebRTC technology and the successful integration of WebRTC video streaming into a mobile hybrid app.

This paper provides a detailed comparative and interoperability analysis of a WebRTC browser-based videoconferencing solution and hybrid-based solutions for mobile and Raspberry Pi. CPU load, RAM usage, and network occupancy are used to evaluate the performance of the proposed model. For the experiments, a real-time WebRTC video streaming solution was created and executed, comprising a signaling server and three distinct client applications. All three clients utilize the same core JavaScript algorithm. The initial client is a responsive web app suitable for both mobile and desktop platforms. The second client is an electron framework-based WebRTC hybrid desktop app [23], compatible with Windows and Raspberry Pi. The third client is a WebRTC hybrid mobile app developed using the React Native framework [24].

The suggested approach could be applied in various ways within home automation and IoT systems, including:

•

In an elevator setting, a Raspberry Pi board could be utilized along with a physical button to connect and notify a security agent of any elevator problems through a Wi-Fi network. This would allow the security agent to access a live video feed from the Raspberry Pi on their smartphone.

•

In a video door entry unit.

•

Develop an emergency communication system for patients and nurses in a hospital setting.

•

In a surveillance drone, a Raspberry Pi board could be embedded to film and transmit a real-time video stream to a smartphone on the ground using a Wi-Fi or LTE connection.

The remaining content of this article is structured as follows: in Section 2, we introduce the suggested approach. In Section 3, we outline the experimental setup and assessed variables. Section 4 is dedicated to appraising the suggested approach’s performance on a mobile device. We perform an assessment on Raspberry Pi in Section 5. The Section 6 offers an analysis of the achieved outcomes. Finally, a conclusion and prospects for future endeavors are provided in Section 7.

2. Proposed Approach

A WebRTC-based solution comprises of two fundamental constituents: a client element and a server element. The client component is versatile, functioning across web, mobile, or desktop platforms. It can be developed using diverse programming languages including JavaScript, HTML (HyperText Markup Language), and CSS (Cascading Style Sheets), or other native languages such as Java, C++, or Objective-C. The HTML and CSS components are responsible for crafting the human–machine interface (HMI), while the JavaScript facet manages interactions with servers, encompassing signaling, STUN, and TURN servers. Additionally, it facilitates the integration of WebRTC functionalities, enabling tasks like connection establishment and data exchange.

The envisaged prototype for WebRTC video streaming entails the incorporation of a signaling server coupled with three distinct client applications.

2.1. Signaling Server

WebRTC uses three principal APIs:

• MediaStream: This API is responsible for creating and managing a WebRTC MediaStream object. This object contains audio/video tracks acquired through the mediaDevices.getUserMedia() method. This method grants access to the user’s multimedia resources, such as the camera and microphone. It can also incorporate tracks from existing multimedia files like .mp3 and .mp4 stored on the user’s device.
• RTCPeerConnection: The RTCPeerConnection API facilitates the establishment of direct connections (P2P) between two users. It operates using the ICE (Interactive Connectivity Establishment) protocol, enabling the exchange of audio/video streams between the connected users.
• RTCDataChannel: This API establishes a data channel between two users. It allows the transfer of non-media data, facilitating real-time communication of messages or other forms of data between the connected peers.

Given that WebRTC technology lacks a standardized signaling protocol between clients and the signaling server, developers have the flexibility to create their own signaling mechanisms. In this project, a signaling server was developed and implemented using the Node.js framework [25], along with the JavaScript Session Establishment Protocol (JSEP) [26] and the WebSocket API [27]. The signaling protocol comprises five control messages: “connexion”, “offer”, “answer”, “candidate”, and “fin”. The “connexion” message refers to the initial message sent by each client to connect to the signaling server. The “offer” message, representing a WebRTC RTCSessionDescription object of type “offer”, is generated and sent by a client to initiate a call. The “answer” message, representing a WebRTC RTCSessionDescription object of type “answer”, is generated and sent by a client to answer an incoming call. The “candidate” message, representing a WebRTC RTCIceCandidate object, is exchanged between two clients to configure a connection. Finally, the “fin” message is sent by a client to hang up a call. All messages are sent in JSON (JavaScript Object Notation) format via the send() method of the WebSocket API. For example, the instruction ‘conn.send(JSON.stringify(type: “offer”, offer: offer, name: “6000”))’ is used to send an “offer” message to the client with the identifier “6000.” The “type” field represents the type of the control message, which is “offer” in this case. The “offer” field represents an offer object containing information about the local client configuration. “conn” is a JavaScript variable representing a WebSocket connection. Figure 1 depicts a situation where Client 1 triggers a call by transmitting an “offer” message to Client 2 through the signaling server. Client 2 responds by transmitting an “answer” message back to Client 1. Subsequently, the clients exchange “candidate” messages via the signaling server until they successfully establish a peer-to-peer connection (RTCPeerConnection).

2.2. Client Applications

A trio of WebRTC client applications were developed, all sharing a common core algorithm coded in JavaScript.

• The initial application, displayed in Figure 2, is a responsive web app designed for both desktop and mobile use.
• The second variant, depicted in Figure 2, serves as a hybrid desktop app constructed using the Electron framework. This version is compatible with Windows and Raspberry Pi platforms.
• The third iteration, featured in Figure 2, takes the form of a hybrid mobile app crafted using the React Native framework.

2.2.1. Web Client Overview

WebRTC serves as a JavaScript API within web browsers. It enjoys compatibility with a wide array of modern browsers, notably Google Chrome, Mozilla Firefox, Safari, and Opera. The user interface is crafted using HTML5 and CSS3, incorporating local and remote videos through HTML5 ‘<video>’ tags. The GUI’s responsiveness, achieved through CSS3’s “Responsive design”, allows adaptation to diverse screen dimensions like desktop and mobile. Communication with the signaling server transpires through JavaScript utilizing the WebSocket API found in the web browser. This scripting also manages real-time audio and video stream acquisition and transmission via the WebRTC API. Refer to Figure 2 for visual representations of the application’s interface.

2.2.2. Hybrid Desktop Client

The Electron Framework is based on Node.js and the Chromium tool (the open-source part of Google Chrome). It is installed and used as a Node.js module and runs in a lightweight customizable web browser that can be extracted and distributed as a desktop application. Once a fully functioning web application was obtained, it was modified to a hybrid desktop application using the Electron framework for the Windows and Raspbian Buster operating systems (a Debian version for Raspberry Pi). The graphical user interface of this application was set to a default size of $340\times 620$ pixels, which can be enlarged to full screen. Several screenshots of this application are shown in Figure 2.

2.2.3. Hybrid Mobile Client

Contrary to an Electron application, the structure of a React Native app significantly differs from that of a website. React Native merges native development advantages with React, a JavaScript library for crafting user interfaces [28]. The graphical interface is built using JSX, a distinct markup language that blends HTML into JavaScript. React Native introduces its own tags (referred to as components) like <Text> for rendering text, <TextInput> for text input, and <RTCView> for real-time video streaming. Unlike interpreting React Native code in a web browser, it is rendered as platform-native code. This process involves transforming graphical elements into their native counterparts. The app’s backend can be managed using both JavaScript and Java (for Android) or JavaScript and Objective-C (for iOS). Notably, the React Native framework does not directly incorporate the WebRTC API. Instead, it adopts a specific Node.js module named react-native-WebRTC for WebRTC functionality [29]. While some JavaScript functions needed adjustments, their fundamental algorithms remained reusable. Figure 2 displays select screenshots of this application.

3. Experimental Environment and Evaluated Parameters

3.1. Experimental Environments

The experiments were conducted using the network topology shown in Figure 3. This network constitutes a WLAN (wireless local area network) and includes the following components:

• TP-LINK TD-W8901N wireless modem-router, operating at 150 Mbps.
• TCHNO CF7 smartphone (Smartphone 1) equipped with a 1.5 GHz ARMv7 Quad Core CPU and 3 GB RAM, and running Android 8.1.0 (Oreo).
• LG-M700A Smartphone (Smartphone 2) featuring an Octa Core 1.09 GHz Qualcomm Technologies, Inc MSM8940 CPU, and 3GB RAM, and Android 8.1.0 (Oreo).
• HP 600B Microtower desktop computer containing an Intel Pentium G645T 2.50 GHz CPU and 4 GB RAM, and running Windows 7 Professional 64-bit OS.
• Raspberry Pi 2 Model B v1.1 board, comprising a 900 MHz quad-core ARM Cortex-A7 CPU and 1 GB RAM, and running Raspbian Buster OS (a Debian variant for Raspberry Pi).
• NOVATECH $640\times 480$ pixel USB 2.0 webcam with an integrated microphone, connected to the Raspberry Pi 2.
• Mozilla Firefox Mobile version 67.0.3 and Google Chrome Mobile version 84.0.4147.89 installed on both smartphones.
• Firefox ESR 60.9.0 web browser installed on the Raspberry Pi 2.
• The Google Chromium browser, which is pre-installed with the Raspbian Buster Operating System.

3.2. Evaluated Parameters

This work assesses four main parameters:

• CPU usage.
• RAM utilization.
• Outgoing bytes per second.
• Incoming bytes per second.

These parameters significantly impact the user’s quality of experience in video streaming. To conduct the study, 21 video calls (6 comparative study + 3 interoperability study + 12 evaluation on Raspberry Pi) were executed via WLAN, each lasting 5 min. A total of 61 measurements were recorded, spaced 5 s apart. Measurements encompassed CPU usage, RAM utilization, and outgoing and incoming bytes per second. Data collection employed the “Simple System Monitor” app on Android and the “nmon” tool on Raspberry Pi.

The goal of the video calls was to compare CPU usage, RAM, and bandwidth occupancy and evaluate interoperability between WebRTC web and hybrid clients (on mobile and Raspberry Pi).

All video calls maintained a resolution of $320\times 240$ pixels and a frame rate of 25 fps.

4. Evaluation on the Mobile

4.1. Comparative Analysis on Mobile Devices

In this comparative study, six video calls were conducted between the two smartphones using WLAN. The study considered two scenarios:

• Scenario 1: Three video calls were made between the smartphones using the Google Chrome Mobile browser, the Mozilla Firefox Mobile browser, and the WebRTC hybrid mobile application.
• Scenario 2: The same calls were made by switching the roles of the calling and called parties.

The evaluation yielded 61 measurements for four parameters on Smartphone 1 in Scenario 1, as depicted in Figure 4, Figure 5, Figure 6 and Figure 7.

Figure 4 illustrates that the mobile browsers Google Chrome (orange) and Mozilla Firefox (green) utilize 100% of the CPU, while the hybrid mobile app (brown) consumes significantly less. The RAM usage, shown in Figure 5, is comparable across the three applications. From Figure 6 and Figure 7, it is evident that the Google Chrome Mobile browser (orange) consumes more data compared to Mozilla Firefox (green) and the hybrid mobile app (brown).

Table 1. Average measurements of CPU load, RAM usage, outgoing bytes/s, and incoming bytes/s on Smartphone 1 (in Chrome Mobile, Firefox Mobile, and React Native app) in both Scenario 1 and Scenario 2.

Measurement	Call Scheme
	Phone Default Setup	Chrome to Chrome		Firefox to Firefox		Hybrid App to Hybrid App
	Before Calls	Scenario 1	Scenario 2	Scenario 1	Scenario 2	Scenario 1	Scenario 2
CPU Load (%)	50.21	100.00	100.00	100.00	100.00	85.29	84.17
RAM Usage (%)	43.49	55.59	53.24	55.52	53.75	56.23	57.35
Outgoing Bytes/s (kB/s)	1.28	54.14	60.84	11.00	23.16	17.38	14.75
Incoming Bytes/s (kB/s)	0.07	67.92	81.97	13.17	23.76	16.55	11.58

presents the average values for CPU usage, RAM usage, bytes sent per second, and bytes received per second over the 61 measurements for Smartphone 1 in both Scenario 1 and Scenario 2. Similar results for Smartphone 2 are provided in

Table 2. Average measurements of CPU load, RAM usage, outgoing bytes/s, and incoming bytes/s on Smartphone 2 (in Chrome Mobile, Firefox Mobile, and React Native app) in both Scenario 1 and Scenario 2.

Measurement	Call Scheme
	Phone Default Setup	Chrome to Chrome		Firefox to Firefox		Hybrid App to Hybrid App
	Before Calls	Scenario 1	Scenario 2	Scenario 1	Scenario 2	Scenario 1	Scenario 2
CPU Load (%)	36.43	43.24	48.31	46.48	41.74	38.35	33.82
RAM Usage (%)	51.03	63.13	59.72	58.66	58.38	59.94	58.40
Outgoing Bytes/s (kB/s)	1.12	54.98	38.89	16.45	19.82	16.51	13.59
Incoming Bytes/s (kB/s)	0.10	48.48	59.94	4.19	6.74	13.57	13.82

.

The average values in Table 1 indicate that the Google Chrome and Mozilla Firefox Mobile browsers consume around 100% of CPU, while the React Native hybrid mobile application consumes around 85% on Smartphone 1. RAM usage differs insignificantly at around 55%. Moreover, the Google Chrome Mobile browser consumes more data (approximately 65 kB/s) compared to Mozilla Firefox Mobile (approximately 17 kB/s) and the hybrid mobile application (approximately 15 kB/s). Results from Smartphone 2 in Table 2 mirror those from Smartphone 1, with Google Chrome and Mozilla Firefox Mobile browsers exhibiting an average CPU load of approximately 45%, while the hybrid mobile app’s average CPU load is about 36%. RAM usage remains close to 58%. Furthermore, the Google Chrome Mobile browser uses more binary data during video calls, with approximately 50 kB/s compared to approximately 15 kB/s. Both scenarios yield similar average values on both smartphones.

4.2. Interoperability Study on Mobile

The interoperability investigation comprised three WLAN video calls between two smartphones, designated as Scenario 3. These calls transpired as follows:

• A video call occurred between Google Chrome Mobile browser (Smartphone 1) and Mozilla Firefox Mobile (Smartphone 2).
• A video call took place between Google Chrome Mobile (Smartphone 1) and a hybrid mobile application (Smartphone 2).
• A video call transpired between Mozilla Firefox Mobile (Smartphone 1) and a WebRTC hybrid mobile application (Smartphone 2).

All mixed video calls were successfully executed, as detailed in

Table 3. Average measurements of CPU load, RAM usage, outgoing bytes/s, and incoming bytes/s on Smartphone 1 (Phone 1) and Smartphone 2 (Phone 2) (in Chrome Mobile, Firefox Mobile, and React Native app) in Scenario 3.

Measurement	Call Scheme
	Chrome to Hybrid		Firefox to Hybrid		Chrome to Firefox
	Chrome (Smartphone 1)	Hybrid (Smartphone 2)	Firefox (Smartphone 1)	Hybrid (Smartphone 2)	Chrome (Smartphone 1)	Firefox (Smartphone 2)
CPU Load (%)	99.51	34.19	100.00	34.11	100.00	40.17
RAM Usage (%)	58.66	59.02	56.75	59.09	55.86	59.97
Outgoing Bytes/s (kB/s)	4.70	14.11	2.32	1.75	6.42	11.35
Incoming Bytes/s (kB/s)	20.58	2.69	2.49	2.35	13.41	5.02

. The average metrics exhibited by the mobile web browsers closely resemble those derived from the comparative analysis (Table 1 and Table 2). This same observation extends to the hybrid application.

Consequently, this study indicates that the latest WebRTC release (WebRTC 1.0) guarantees compatibility between the mobile web browsers Google Chrome and Mozilla Firefox, as well as between these browsers and a WebRTC hybrid mobile application created using the React Native framework on the Android OS.

5. Evaluation on Raspberry Pi

The evaluation of the WebRTC Desktop hybrid client on the Raspberry Pi involved conducting 12 video calls (6 comparative study + 6 interoperability study) between a Raspberry Pi 2 and Smartphone 1 over a WLAN network. The assessment consisted of two sets of six video calls each. The initial six calls aimed to compare the performance of the WebRTC Electron hybrid app and the browser-based version. These were executed on RPi-Chromium (a lightweight version of Google Chrome for Raspberry Pi) and RPi-Firefox-ESR (Mozilla Firefox for Raspberry Pi). Four key parameters were analyzed. The subsequent six video calls were designed to assess compatibility between the Electron hybrid app on the Raspberry Pi and the WebRTC React Native hybrid app on the mobile device.

For every video call, a total of 61 measurements were captured at 5-s intervals. These measurements included CPU load, RAM usage, bytes sent per second, and bytes received per second. The “nmon” tool available on the Raspberry Pi was utilized, and the command “$ nmon -f -s 5 -c 65” was executed to gather the data. Notably, the CPU usage measurement on the Raspberry Pi focused solely on user-related CPU consumption, in contrast to the smartphones where overall CPU usage was recorded.

5.1. Comparative Analysis of Raspberry Pi

The initial six video calls for the comparative analysis were segregated into two distinct scenarios:

• Scenario 1: Within this setup, video calls were executed between the Google Chrome Mobile browser and RPi-Chromium, Mozilla Firefox Mobile, and RPi-Firefox-ESR, along with the React Native hybrid app and the Electron hybrid app.
• Scenario 2: The identical calls were reiterated, but with the direction of the call reversed (the initiating client takes on the role of the recipient).

The mean statistics for CPU utilization, RAM occupancy, data transmitted per second, and data received per second across the 61 performed measurements are displayed in

Table 4. Average measurements of CPU load, RAM usage, outgoing bytes/s, and incoming bytes/s on Raspberry Pi 2 (in RPi-chromium, RPi-firefox-ESR, and Raspberry Pi Electron Hybrid app) in Scenario 1 and Scenario 2.

Measurement	Call Scheme
	RPi 1 Default Setup	Chrome Mobile RPi-Chromium		Firefox Mobile to Firefox-ESR		Mobile Hybrid to RPi Hybrid
	Before Calls	Scenario 1	Scenario 2	Scenario 1	Scenario 2	Scenario 1	Scenario 2
CPU Load (%)	0.79	72.21	71.99	59.55	64.20	57.12	55.97
RAM Usage (%)	23.03	41.63	42.45	49.69	51.88	37.35	38.59
Outgoing Bytes/s (kB/s)	0,00	63.76	64.30	10.71	17.22	25.46	53.06
Incoming Bytes/s (kB/s)	0,00	49.22	40.73	47.33	44.94	85.995	84.11

¹ Raspberry Pi.

. From these average values, it can be observed that the WebRTC Electron hybrid app exhibits better CPU performance (around 56%) than the two mini browsers RPi-Chromium and RPi-Firefox-ESR, which consume at least 60% of the CPU. In terms of RAM occupancy, the Electron hybrid app has an average value of 38%, while the two mini browsers show an average value greater than 41%. The Electron app appears to use less data than RPi-Chromium. More detailed information can be observed in Figure 8, Figure 9, Figure 10 and Figure 11, which, respectively, show the CPU time, RAM usage, outgoing bytes per second, and incoming bytes per second on Raspberry Pi 2.

5.2. Interoperability Study on Raspberry Pi

Six additional video calls took place between Raspberry Pi 2 and Smartphone 1, focusing on scenario 3. These calls aimed to test interoperability among web browsers such as Google Chrome and Mozilla Firefox, alongside WebRTC hybrid applications for both mobile and desktop platforms. The division of the six video calls is outlined below:

• A video call between RPi-Chromium and Mozilla Firefox Mobile.
• A video call between RPi-Chromium and the WebRTC React Native hybrid app.
• A video call between RPi-Firefox-ESR and Google Chrome Mobile.
• A video call between RPi-Firefox-ESR and the WebRTC React Native hybrid app.
• A video call between the WebRTC Electron hybrid app and Google Chrome Mobile.
• Finally, a video call between the WebRTC Electron hybrid app and Firefox Mobile.

• A video call using RPi-Chromium and Mozilla Firefox Mobile.
• Video communication via RPi-Chromium with the WebRTC React Native hybrid app.
• Video call involving RPi-Firefox-ESR and Google Chrome Mobile.
• Video communication between RPi-Firefox-ESR and the WebRTC React Native hybrid app.
• Connecting the WebRTC Electron hybrid app with Google Chrome Mobile for a video call.
• Lastly, initiating a video call between the WebRTC Electron hybrid app and Firefox Mobile.

The six video calls were successfully completed, demonstrating interoperability among various web browsers and hybrid apps on Raspberry Pi and mobile devices, including RPi-Chromium, RPi-Firefox-ESR, WebRTC Electron hybrid app for Raspberry Pi, Google Chrome and Mozilla Firefox on mobile browsers, and the WebRTC React Native hybrid mobile app. Averaged results from 61 measurements across four key parameters are shown in tables (

Table 5. Average measurements of CPU load, RAM usage, outgoing bytes/s, and incoming bytes/s on Raspberry Pi 2 (in RPi-Chromium) in Scenario 3.

Measurement	Call Scheme
	Chromium to Firefox Mobile	RPi-Chromium to React Native Hybrid App
CPU Load (%)	70.14	68.20
RAM Usage (%)	41.53	46.47
Outgoing Bytes/s (kB/s)	67.76	95.82
Incoming Bytes/s (kB/s)	25.89	103.69

,

Table 6. Average measurements of CPU load, RAM usage, outgoing bytes/s, and incoming bytes/s on Raspberry Pi 2 (in RPi-Firefox-ESR) in Scenario 3.

Measurement	Call Scheme
	RPi-Firefox-ESR to Chrome Mobile	RPi-Firefox-ESR to React Native App
CPU Load (%)	57.21	66.53
RAM Usage (%)	46.78	42.19
Outgoing Bytes/s (kB/s)	11.2	13.66
Incoming Bytes/s (kB/s)	55.93	51.12

and

Table 7. Average measurements of CPU load, RAM usage, outgoing bytes/s, and incoming bytes/s on Raspberry Pi 2 (in RPi-Electron-App) in Scenario 3.

Measurement	Call Scheme
	RPi-Firefox-ESR to Chrome Mobile	RPi-Firefox-ESR to React Native App
CPU Load (%)	48.83	52.34
RAM Usage (%)	43.01	33.57
Outgoing Bytes/s (kB/s)	13.47	14.57
Incoming Bytes/s (kB/s)	73.53	66.12

). These outcomes align with prior findings from the comparative study on Raspberry Pi. Specifically, the Electron hybrid app maintains an average CPU usage below 56% and RAM occupancy around 38%. Conversely, the two mini web browsers exhibit higher average CPU load exceeding 60% and approximately 45% RAM usage.

6. Discussion

This paper conducts a comparison between WebRTC browser-based and hybrid-based video streaming solutions. The focus is on CPU load, RAM usage, and network data on resource-constrained devices. Interoperability is also evaluated.

Results from video calls on a WLAN network indicate that the WebRTC React Native hybrid app consumes around 10% less CPU than the web browser-based counterpart on mobile devices. RAM usage difference was minor. Moreover, the hybrid app and Mozilla Firefox Mobile use less data than Google Chrome Mobile.

On Raspberry Pi 2, the WebRTC Electron hybrid app exhibits lower CPU consumption (around 4%) and RAM usage (about 7%) than the web browser-based app.

These results can be justified based on the following three points:

• Native Capabilities: Since it is possible to use a native programming language (Java and Objective-C for React Native; C++ and Python for Electron) in a hybrid app to interact directly with the native components of the device, a hybrid app can run efficiently and offer more functionalities and a wide range of applications and customization. There is no native API offered by the operating system that an Electron or a React Native app cannot make use of; the React Native module for WebRTC (react-native-WebRTC) is a native module, not a JavaScript based one. In contrast, a web app exists within the confines of the browser that powers it.
• Performance: Since a WebRTC web app is powered by a browser, you have to run the whole browser to access your application. Electron and React Native brings their own rendering engines to run your app, not other unnecessary features included in the web browser.
• Security implementation: A web application operates within a highly controlled browser environment. This confinement effectively limits the capabilities of the web application, thereby mitigating specific security vulnerabilities. Moreover, the browser vendor incorporates security, congestion, and bandwidth management mechanisms while integrating WebRTC functionality into the browser, potentially resulting in increased processing overhead for WebRTC multimedia sessions. Conversely, Electron and React Native applications that retrieve and present remote (online) content need to meticulously address the security dimension.

In addition, when comparing web apps and hybrid apps, the following factors should also be taken into consideration:

• Portability: A WebRTC responsive web app can automatically run on various operating systems (Windows, Linux, Mac OS, Android, and iOS) without the need for specific modifications. Conversely, a hybrid app based on React Native, which utilizes native code for mobile platforms, is limited to functioning on Android and iOS with certain adjustments made to accommodate both systems.
• Installation: A web app can be installed simply by visiting a website, while a hybrid app requires installation on the user’s device. However, in the event that there are clients utilizing varying operating systems like Windows, macOS, Linux, Android, or iOS, not all functionalities of the app may be supported. In such cases, customers may need to be guided to install specific versions of browsers. Requesting customers to install the software is often easier than asking them to install a particular web browser.
• Updating: A WebRTC browser-based app can be updated once for all platforms (desktop and mobile), whereas a hybrid app needs to be updated separately for each platform (desktop and mobile).
• Ergonomics and ease of use: A WebRTC hybrid application provides better ergonomics and user-friendliness in comparison to a browser-based application. For end-users, the distinction between a hybrid app and a native app is virtually indistinguishable.

To enhance efficiency, adaptability, user quality of experience (QoE), and applicability, utilizing a WebRTC hybrid-based approach built with React Native or Electron offers a viable choice. However, for improved portability, decreased development intricacy, and cost benefits tied to updates, a WebRTC browser-based solution could be a more fitting option.

The interoperability research indicates that the first stable version of WebRTC (WebRTC 1.0: Real-Time Communication between Browsers) facilitates smooth communication between a WebRTC hybrid app built using React Native or Electron framework and a browser-based counterpart. This allows developers to provide web and hybrid app variations, customizing them as needed for specific demands.

Further exploration of the comparison between web and hybrid applications can be conducted using audio and video quality assessment models proposed in the References [2,18,19]. The investigations carried out in References [20,21] also examine some models that could be interesting to experiment with.

Furthermore, the energy aspect of the proposed approach can be addressed by employing the techniques suggested in Reference [6].

7. Conclusions and Future Works

This study demonstrated the feasibility of implementing real-time video streaming using WebRTC in both React Native hybrid mobile and Electron hybrid desktop apps, ensuring compatibility with a browser-based client. A WebRTC video streaming solution was established, including a signaling server and three client applications: a browser-based client, a React Native hybrid mobile app, and an Electron hybrid desktop app.

During video calls over a WLAN network, the results indicated that the WebRTC React Native hybrid app exhibited slightly reduced CPU usage (approximately −10%) compared to the web browser-based app, while maintaining similar RAM usage. The Electron hybrid app displayed improved CPU performance (around −4%) and decreased RAM usage (approximately −7%) compared to the browser-based app on Raspberry Pi 2. Both application types were found to achieve interoperability effectively. Thus, employing a hybrid approach is advisable for WebRTC real-time video streaming on devices with limited resources.

For future works, our plans encompass adding support for the iOS operating system and exploring alternative hybrid technologies like the Google Flutter framework, known as a strong competitor to React Native. Furthermore, leveraging the prototype to create real-time embedded video streaming solutions, such as a video door entry unit and a CCTV (Closed-Circuit Television) drone, is intended for development. A thorough analysis of network traffic using Wireshark will also be conducted to gather more information about the additional data added by different browsers to the audio/video streams of WebRTC.