Design and implement a new mechanism for audio, video and screen recording based on WebRTC technology

Received Mar 27, 2019 Revised Nov 27, 2019 Accepted Dec 12, 2019 Many years ago, Flash was essential in browsers to interact with the user media devices, such as a microphone and camera. Today, Web Real-Time Communication (WebRTC) technology has come to substitute the flash, so browsers do not need the flash to access media devices or establish their communication. However, WebRTC standards do not express precisely how browsers can record audios, videos or screen instead of describing getUserMedia API that enables a browser to access microphone and camera. The prime objective of this research is to create a new WebRTC recording mechanism to record audios, videos, and screen using Google Chrome, Firefox, and Opera. This experiment applied through Ethernet and Wireless of the Internet and 4G networks. Also, the recording mechanism of this research was obtained based on JavaScript Library for audio, video, screen (2D and 3D animation) recording. Besides, different audio and video codecs in Chrome, Firefox and Opera were utilised, such as VP8, VP9, and H264 for video, and Opus codec for audio. Not only but also, various bitrates (100 bytes bps, 1 Kbps, 100 Kbps, 1 MB bps, and 1 GB bps), different resolutions (1080p, 720p, 480p, and HD (3840* 2160)), and various frame-rates (fps) 5, 15, 24, 30 and 60 were considered and tested. Besides, an evaluation of recording mechanism, Quality of Experience (QoE) through actual users, resources, such as CPU performance was also done. In this paper, a novel implementation was accomplished over different networks, different browsers, various audio and video codecs, many peers, opening one or multi browsers at the same time, keep the streaming active as much as the user needs, save the record, using only audio and/or video recording as conferencing with full screen, etc.


INTRODUCTION
Web Real-Time Communication (WebRTC) was developed by The Internet Engineering Task Force (IETF) and World Wide Web Consortium (W3C) [1][2][3][4][5]. WebRTC is a new standard and a collection of libraries [6] that supports interactive communications of video and data [7][8][9][10]. Additionally, it provides many benefits such as no fees, no license, no plug-ins, no installation, and so on [11][12][13]. In [14], emphasised that recording has changed the education route for delivering and consuming, Besides, many Application Programming Interface (APIs) have provided by WebRTC to be used in the screen capture and the media recording, also as clarified in the corresponding W3C drafts that have implemented in new browsers [15]. On the other hand, WebRTC lacks high-end videoconferencing types like a recording of a session [16]. Furthermore, [14] The essential objectives of this research are to design and test  a WebRTC recording mechanism for audios, videos, and screen, (b) apply the created mechanism via  Ethernet and Wireless of the Internet and 4G networks, (c) utilised various audio and video codecs, such as  VP8, VP9, H264 and Opus audio codec, (d) different bitrates, such as (1 Kbps, 100 Kbps, 1 Mbps, and 1 GB) were used, (e) assortment of resolutions such as (1080p, 720p, 480p, and HD (3840* 2160)) were considered, (f) various frame-rates such as (5, 15, 24, 30 and 60) were tested, and (g) an evaluation of recording mechanism, Quality of Experience (QoE) through actual users and CPU performance was also done. Consequently, a novel implementation was accomplished over different networks, different browsers, various audio and video codecs, different peers, opening one or multi browsers at the same time, keep the streaming eactive as much as the user needs, save the record, and using only audio and/or video recording as conferencing with full screen. The organization of this project is as describes; Section 2 talks about the survey and WebRTC recording related work. In section 3, a preview of the methodology of the paper is explained with implementation and analysis. Section 4 relates to the evaluation. Finally, Section 5 is the conclusion and future work.

RELATED WORK
In [14,[16][17][18][19], explained that media capture, media screen, and media stream recording have considered as main WebRTC issues; especially recording API has not implemented yet. Additionally, recording in the browser may be unauthorized as long the server is in the media path. However, in [20] claimed that an application of screen recording with WebRTC on android was designed using getUserMedia API, but practically the author has not proved or presented the work. What is more, in [21] expected that using MediaRecorder API can support recording in WebRTC. On the other hand, in [22] illustrated that session recording is a significant challenge while stream mechanism has not provided by WebRTC standard to gather the information and store them. Accordingly, in [18,23] expounded that WebRTC needs some solutions such as recording functionality to allow involvement of devices in limited network environments, and offer a WebRTC conferencing prototype that assists recording of conversations. Besides, in [11] confirmed that during the test, a screen recorder is necessary to record the data, such as video and audio, obtain user feedback and evaluate the quality.

METHODOLOGY, IMPLEMENTATION, AND ANALYSIS 3.1. Methodology
Methodology for designing and testing this application, different Libraries for audio, video, screen, canvas (2 nd and 3 rd animation) was used for the implementation and recording to designing and test this application. Also, JavaScript language, a task manager to evaluate a CPU performance, access Point-NetCommWireless to provide 4G, and Cameras and Microphones were used. Furthermore, Google Chrome, Opera, and Firefox were utilised as a client-side. Additionally, one computer connected through (Ethernet and Wireless) of the Internet and 4G networks.

Implementation
In this research, a new mechanism for video, audio, and screen recording has been designed and implemented based on RecordRTC library, MediaRecorder API and WebRTC JavaScript code for audios, videos, screen and canvas (2 nd +3 rd animation) recording. This application has divided into the following parts:  Setup the main browser (Index HTML).  Utilised RecordRTC API.  Utilised node.js server for localhost server.

Setting up a browser web page
The first step will need to grant using the getUserMedia API in order to access the camera and microphone. So, RecordRTC will be able to start the video recording. RecordRTC and adapter scripts were needed to provide cross-browser for supporting getUserMedia and other browsers APIs. Moreover, different JavaScript methods were written in order to build this application as showing: It sets a video width to offer more clearance as width = 640 and high 480, as shown in Figure 1. When an initiator opened the browser, it will present audio and video "MediaStream," which can be obtained via "navigator.getUserMedia" method to capture screen. Once access to the camera and microphone; a media will start streaming the video and/or audio and display, and then saving them on disk. Figure 2 shows the pseudocode of this experiment. To leave the room or change the setup like resolution, bitrates, and codec, a user needs to close or reopen the web page. Also, can control the streaming of the camera or microphone, maximize the screen or pause anytime.

The created mechanism
This mechanism has been created and used based on RecordRTC API and JavaScript Methods. The RecordRTC library has been used to initialize and set up a new session for audios, videos, and screen using Google Chrome, Firefox, and Opera. Also, it has added many different JavaScript functions and methods for local and remote media streams.

Analysis 3.3.1. Signalling mechanism for saving media stream
This mechanism has been analyzed separately for ten users based to test the delay to get ready. This was implemented based on the network analysis inspecting element of Google Chrome, Firefox, and Opera, at the actual communication. The mean time was calculated, so it expands 132 milliseconds (ms) to be ready and consumes 475 (ms) to establish media streaming. This mechanism can set up, establish and send audios, videos, and screen simultaneously. The variation of delay between using Chrome, Firefox, and Opera was slightly different. In contrast, the quality of audios, videos and screen did not affect by the CPU load or the bandwidth consumption; especially the media streaming was between the internal devices, such as camera and microphone with the disk in the computer.

Quality of video conferencing
The quality of audios, videos and screen were done by individual test between ten users over the Internet and 4G networks. Therefore, the quality of audios, videos and screen were excellent. As a result, using the created mechanism for recording sounds, videos, and screens is efficient, as shown in Table 1.

Quality of experience (QoE)
In [24] mentioned that QoE is necessary and has been considered as a subjective matrix in media communication, as well as it has been adopted by ITU-T group [23,25,26]. Through the use of a questionnaire, users have taken part in this test to give their individual perspectives on the realized user experience as presented in Table 2. This application confirmed an excellent quality of audio, video and screen recording, in specific between ten peers via the Internet and 4G networks.