Study and assessment of several factors influencing video transmission quality using webrtc

Nội dung text: Study and assessment of several factors influencing video transmission quality using webrtc

1. TNU Journal of Science and Technology 226(16): 188 - 195 STUDY AND ASSESSMENT OF SEVERAL FACTORS INFLUENCING VIDEO TRANSMISSION QUALITY USING WEBRTC * Dinh Xuan Lam , Ha My Trinh, Ta Thi Thao, Do Thi Phuong, Nguyen Toan Thang TNU - University of Information and Communication Technology ARTICLE INFO ABSTRACT Received: 18/9/2021 Web Real-Time Communications (WebRTC) is an open-source standard that aims to provide rich and high-quality real-time Revised: 11/11/2021 communication over the Internet. This work focuses on the study, Published: 15/11/2021 analysis, and evaluation of three factors that influence the quality of video and audio transmission using WebRTC. These influencing KEYWORDS factors include synchronization, stability, and quality of the video. The author uses an experimental method with a WebRTC server that Webrtc provides a free online video conferencing service, and the clients are P2P video simulated on the Google cloud environment, the network in between Video conferencing is emulated to evaluate the influence of network QoS on the video transmission quality. The results show that the synchronization of Quality of experience audio and video is directly affected by changing the network quality Quality of service of service in the peer-to-peer video media version. However, the stability and the quality of the video are less affected. The study can be used as a reference for other researchers to perform WebRTC optimization before actual implementation. NGHIÊN CỨU VÀ ĐÁNH GIÁ MỘT SỐ YẾU TỐ ẢNH HƯỞNG TỚI CHẤT LƯỢNG TRUYỀN PHÁT VIDEO SỬ DỤNG CÔNG NGHỆ WEBRTC * Đinh Xuân Lâm , Hà Mỹ Trinh, Tạ Thị Thảo, Đỗ Thị Phượng, Nguyễn Toàn Thắng Trường Đại học Công nghệ thông tin và Truyền thông – ĐH Thái Nguyên THÔNG TIN BÀI BÁO TÓM TẮT Ngày nhận bài: 18/9/2021 Web Real-Time Communications (WebRTC) là một tiêu chuẩn mã nguồn mở nhằm mục đích cung cấp giao tiếp thời gian thực chất Ngày hoàn thiện: 11/11/2021 lượng cao và phong phú qua Internet. Bài báo tập trung nghiên cứu, Ngày đăng: 15/11/2021 phân tích và đánh giá ba yếu tố ảnh hưởng tới chất lượng truyền phát video và audio sử dụng công nghệ WebRTC là sự đồng bộ hóa TỪ KHÓA (Synchronization), tính ổn định (Stability) và chất lượng (Quality). Tác giả sử dụng phương pháp thực nghiệm với một máy chủ Webrtc WebRTC miễn phí và các máy khách được mô phỏng và giả lập chất Video ngang hàng lượng mạng trên môi trường điện toán đám mây Google cloud. Kết quả thực nghiệm cho thấy yếu tố đồng bộ hóa và chất lượng truyền Video trực tuyến phát video bị ảnh hưởng trực tiếp bởi thay đổi chất lượng dịch vụ Chất lượng trải nghiệm mạng ở phiên truyền video ngang hàng. Tuy nhiên, tính ổn định của Chất lượng dịch vụ các phiên truyền tương đối tốt và ít bị ảnh hưởng hơn. Nghiên cứu có thể được sử dụng để tham khảo cho các nhà nghiên cứu thực hiện tối ưu công nghệ WebRTC trước khi triển khai trong thực tế. DOI: * Corresponding author. Email: dxlam@ictu.edu.vn 188 Email: jst@tnu.edu.vn
2. TNU Journal of Science and Technology 226(16): 188 - 195 1. Giới thiệu Việc truyền video trực tiếp qua Internet là một chủ đề nổi lên vào những năm 1990 [1]. Vào đầu những năm 2000 trở lại đây dưới sự bùng nổ về khoa học công nghệ và các thiết bị như laptop, smartphone ngày càng phổ cập tới mọi người. Do đó, việc trò chuyện video trực tiếp qua internet ngày càng phổ biến. Năm 2011, WebRTC nổi lên như một giải pháp mã nguồn mở thay thế cho các ứng dụng trò chuyện video độc quyền. Một năm sau vào năm 2012, bản thảo làm việc đầu tiên của tiêu chuẩn WebRTC 1.0 đã được phát hành bởi Nhóm Công tác truyền thông Thời gian thực trên Web của W3C. Kể từ năm 2019, tất cả các trình duyệt phổ biến trên máy tính để bàn và hệ điều hành di động đều hỗ trợ WebRTC [2], [3]. Về mặt kỹ thuật, các ứng dụng sử dụng WebRTC được triển khai dựa trên API Javascript do các trình duyệt hỗ trợ WebRTC cung cấp. API Javascript được triển khai bởi các nhà phát triển trình duyệt. Nó tương tác với các chức năng của WebRTC thông qua API WebRTC. WebRTC có bốn thành phần chính, mỗi thành phần chịu trách nhiệm riêng cho một phiên. Công cụ quản lý phiên chịu trách nhiệm quản lí theo dõi trạng thái của phiên truyền. Công cụ xử lý âm thanh chịu trách nhiệm xử lý phương tiện nhận sau đó mã hóa và áp dụng các bộ lọc, ví dụ như giảm tiếng ồn. Tương tự như âm thanh, công cụ xử lý video thực hiện ghi hình và mã hóa rồi phát lại nội dung đã ghi nhận. Cuối cùng là thành phần truyền tải cung cấp các tính năng để bắt đầu và duy trì một phiên. Các dữ liệu được đóng gói và được gửi đến máy khách qua mạng Internet [4]. WebRTC cung cấp khả năng giao tiếp trực tiếp giữa các máy khách. Do đó, các máy khách có thể trao đổi các gói trực tiếp với nhau mà không cần thông qua máy chủ để truyền tải dữ liệu. Những lợi thế của giao tiếp ngang hàng rất đa dạng. Thứ nhất, lưu lượng truy cập trên máy chủ trung tâm được giảm tải vì nó chỉ chịu trách nhiệm thiết lập phiên. Vì vậy, một máy chủ duy nhất có thể xử lý nhiều phiên đồng thời hơn. Thứ hai, giao tiếp trực tiếp giữa các máy khách có khả năng giảm độ trễ từ người gửi đến người nhận. Vấn đề nằm ở bản chất của các mạng thực tế có chứa NAT (Network Address Translation) và tường lửa [5]. Để gửi một gói đến một máy khách khác, máy khách cần địa chỉ IP công cộng của máy khách cần giao tiếp. Tuy nhiên, đa số các máy khách nằm sau một bộ định tuyến và NAT được sử dụng để kết nối với các dịch vụ trên Internet. Ngoài ra, tường lửa ngăn cản sự truy cập từ bên ngoài vào mạng cục bộ [6]. Để khắc phục điều này, WebRTC sử dụng ICE để tạo ra các lỗ hổng trên tường lửa, sau đó có thể được sử dụng để gửi dữ liệu trực tiếp đến các máy khách khác. Trong trường hợp ICE không thể thiết lập giao tiếp ngang hàng, máy chủ TURN được sử dụng như một thiết bị chuyển tiếp (RELAY) cho dữ liệu. Khi một đường truyền được thiết lập thành công từ một trong các máy khách, phiên truyền bắt đầu. Trong suốt phiên truyền, video có thể được truyền bằng một trong hai cách: a) Giao tiếp trực tiếp giữa hai máy tính, b) Chuyển tiếp dữ liệu qua máy chủ TURN. Cách giao tiếp đầu tiên được đặt tên là P2P, cách thứ hai được gọi là RELAY. Trên thực tế, dữ liệu của các phép đo thực tế cho thấy, các phiên có hai hay nhiều người tham gia được chia thành hai trạng thái. Ở trạng thái đầu tiên, ngay sau khi tham gia phiên, các máy khách được kết nối thông qua máy chủ RELAY của nhà cung cấp dịch vụ. Sau một khoảng thời gian nhất định, luồng dữ liệu trong phiên sẽ chuyển từ giao tiếp RELAY sang giao tiếp P2P. Dữ liệu được gửi trong giai đoạn RELAY có thể được điều chỉnh bởi máy chủ chuyển tiếp. Tác giả của các nghiên cứu [7], [8] và [9] cho rằng, có ba yếu tố chính ảnh hưởng tới chất lượng của các phiên truyền video sử dụng công nghệ WebRTC là a) Đồng bộ hóa, b) Tính ổn định và c) Chất lượng. Mỗi tham số là tổng hợp của nhiều chỉ số hiệu suất chính (KPI) là các chức năng xếp hạng cụ thể cho một khía cạnh riêng biệt của phiên WebRTC. Dựa vào kết quả của các nghiên cứu này, tác giả đã thực hiện một số thí nghiệm thực tế để đánh giá chất lượng truyền phát video trong cả hai giai đoạn truyền. Trong đó, chất lượng dịch vụ mạng (Quality of Service - QoS) được giả lập để so sánh mức độ ảnh hưởng của băng thông khả dụng đến sự thay đổi của độ phân giải khung hình, tốc độ bit và tốc độ khung hình truyền nhận sử dụng công nghệ WebRTC. 189 Email: jst@tnu.edu.vn
3. TNU Journal of Science and Technology 226(16): 188 - 195 2. Các yếu tố quyết định chất lượng dịch vụ WebRTC Phần này trình bày chi tiết ba yếu tố ảnh hưởng chính tới chất lượng truyền phát video sử dụng công nghệ WebRTC, trong đó giá trị KPI được tính toán dựa trên các phân tích từ các công trình tham khảo trên. 2.1. Đồng bộ hóa (Synchronization) Tính đồng bộ hóa đề cập đến khả năng đảm bảo sự liên kết kịp thời của các sự kiện. Các thành phần điển hình của một cuộc hội thoại như vậy là một luồng âm thanh và một luồng video. Các luồng khác nhau được truyền riêng biệt, do đó việc đồng bộ chúng cũng khác nhau. Do vậy, việc đánh giá tính đồng bộ hóa trong truyền dữ liệu đa phương tiện sử dụng WebRTC là cần thiết và quan trọng. 2.1.1. Đồng bộ video Sự đồng bộ của luồng video giữa các máy khách tham gia vào một phiên là yếu tố quan trọng thứ hai khi xem xét đồng bộ hóa phiên tổng thể. Các thí nghiệm được tiến hành trong tài liệu [10] chỉ ra độ trễ (delay) 350 ms được coi là chấp nhận được và khoảng từ 100 ms đến 150 ms được coi là tối ưu khi truyền video. Theo khuyến nghị ITU G.114, quy định độ trễ 150 ms là đủ để đảm bảo tương tác ổn định cho người dùng [11]. Các tác giả trong nghiên cứu [12] đã kết luận với tổng độ trễ 250 ms, đồng bộ khẩu hình miệng trong truyền video tương tác có thể đạt được. Dựa trên các nghiên cứu trên, phương trình ước tính KPI được trình bày bao gồm ba thành phần như sau: 5 푛ế 푒푙 400 2.1.2. Đồng bộ hóa Audio-Video Tham số quan trọng hơn là tính đồng bộ cả âm thanh và video ở phía máy thu. Để đạt được ấn tượng tự nhiên về một phiên nghe - nhìn, điều cần thiết là việc phát âm thanh và luồng video phải đồng bộ với nhau. Sự khác biệt giữa độ trễ âm thanh và độ trễ video được coi là lỗi đồng bộ hóa. Các nghiên cứu cho thấy, thời gian trễ tối đa giữa âm thanh và video nên dưới 100 ms để đảm bảo cảm nhận của người dùng về sự đồng bộ hóa âm thanh với khẩu hình miệng [12]. Theo ITU, không thể phát hiện được phương tiện không đồng bộ trong khoảng từ 45 ms đến -125 ms (dấu âm “-” thể hiện dữ liệu video đến sau âm thanh so với nguồn). Trong khi đối với các giá trị khác trong khoảng từ 90 ms đến -185 ms, sự không đồng bộ có thể được phát hiện, tuy nhiên, nó được coi là chấp nhận được [13]. Để tính toán các giá trị KPIavsync phụ thuộc vào độ trễ âm thanh/video, công thức sau được sử dụng. ((delay + 125)/60) × 4 + 5 nếu -185 < delay < -125 5 nếu -125 ≤ delay ≤ 45 퐾푃 푣푠 푛 = (2) 5 - ((delay - 45)/50) × 4 nếu 45 < delay < 90 { 1 nếu delay ≥90 2.2. Tính ổn định (Stability) Ngược lại với đồng bộ hóa, tính ổn định đề cập đến thách thức trong việc duy trì cuộc trò chuyện ở mức độ chấp nhận được. Trong các ứng dụng thông thường, tải xuống HTTP có thể không bị ảnh hưởng nhiều bởi giá trị round trip time (RTT) tăng lên, nhưng các ứng dụng thời gian thực nhạy cảm hơn. Để bù đắp các độ trễ khác nhau, các ứng dụng sử dụng bộ đệm ở phía người nhận, tuy nhiên nếu độ trễ quá lớn có thể khiến bộ đệm mất đi tác dụng. 2.2.1. Sự ổn định về độ phân giải (Resolution Stability) 190 Email: jst@tnu.edu.vn
4. TNU Journal of Science and Technology 226(16): 188 - 195 Chất lượng mạng thay đổi có thể gây ra mất ổn định về thông lượng cho phiên WebRTC dẫn đến video có thể được phát từ bộ đệm nhanh hơn tốc độ nhận được, khi đó bộ đệm sẽ hết dữ liệu và video bị dừng (hiện tượng stalling). Tình trạng ngừng phát video này cũng có thể xảy ra trong WebRTC, nó chủ yếu được giảm thiểu bằng cách điều chỉnh chất lượng phát video ở máy khách. Trong hệ thống truyền phát video thích ứng, độ phân giải của video tự động giảm xuống khi băng thông bị giảm, kỹ thuật này giúp giảm thiểu được hiện tượng video ngừng phát. Một trong số đó là tần suất thay đổi độ phân giải [14] và khoảng thời gian video được phát ở độ phân giải cao nhất [15]. KPIresolution cho hiện tượng này được tính như sau: 0.064×푡 퐾푃 resolution = 0.003 × 푒 + 2.498 (3) Trong đó, t là số phần trăm ([0,100]) thời gian video được phát ở độ phân giải cao nhất. 2.2.2. Sự ổn định về tốc độ khung hình (Frame Rate Stability) Bên cạnh chất lượng phát video ở máy khách, tham số thứ hai áp dụng cho video thích ứng chính là tốc độ khung hình. Trong [16], các tác giả tiến hành thử nghiệm trong khi thay đổi ba tham số: tốc độ khung hình, độ phân giải và tốc độ bit. Họ kết luận rằng người dùng nhạy cảm hơn với việc giảm tốc độ khung hình video hơn là giảm độ phân giải video. Sử dụng các kết quả đã trình bày ở nghiên cứu trên, ta có thể tính toán KPIfps dưới dạng một hàm phụ thuộc vào tốc độ khung hình bằng cách sử dụng công thức sau: 1 nếu fps 30 Trong đó, fps là tốc độ khung hình đầu ra hiện tại của luồng video đã nhận. 2.3. Chất lượng video (video quality) Thông số kỹ thuật của WebRTC có hai codec video bắt buộc là H.264 và VP8 [17]. Trong các thí nghiệm thuộc phạm vi bài báo này, tác giả sử dụng video codec VP8. Dựa trên kết quả từ các nghiên cứu [18] và [19], tác giả xây dựng KPI cho chất lượng video KPIQvideo. Giả sử rằng, VP8 và H.264 có thể so sánh được với các tập hợp tốc độ bit và độ phân giải giống nhau, chúng ta sử dụng các giá trị được trình bày bởi [20] để tra cứu giá trị KPIQvideo cho một tổ hợp độ phân giải và tốc độ bit nhất định. Đối với mỗi độ phân giải, hai tập hợp giá trị KPIQvideo tương ứng được đưa ra và chúng đại diện cho các bộ mã hóa khác nhau. Về độ phân giải, dữ liệu được phân bổ cho các kích thước hình ảnh khác nhau, từ 360px đến 1080px. Giá trị tốc độ bit mà các điểm dữ liệu tồn tại nằm trong khoảng từ 130 kbit/s đến 5.0 Mbit/s. 3. Phương pháp nghiên cứu và thí nghiệm Phương pháp nghiên cứu chủ yếu dựa trên thực nghiệm, trong đó tác giả xây dựng các kịch bản thí nghiệm để đánh giá các tham số KPI với băng thông thay đổi từ 250 Kbit/s đến 50 Mbit/s. Trong đó băng thông thấp thể hiện các điều kiện mạng suy giảm như đang đi trên đường hoặc tín hiệu không giây bị suy hao do vật cản. Băng thông cao từ 10 Mbit/s đến 50 Mbit/s đang được cung cấp khá phổ biến bởi các nhà cung cấp dịch vụ mạng như VNPT hay FPT tại Việt Nam. Đối với các kịch bản được thực hiện trong thí nghiệm này, quá trình đo được điều khiển bằng một chương trình Python, bộ kiểm thử tự động Selenium1, trình duyệt, nguồn video và lưu trữ nhật ký. Chương trình sử dụng thư viện Selenium để tương tác với trình duyệt web Chromium. Với bộ công cụ này, một phiên truyền video trực tuyến thời gian thực WebRTC được bắt đầu và kết nối người dùng tham gia vào một cách tự động. Trong quá trình đo, băng thông gửi khả dụng của các máy khách bị giới hạn bằng cách sử dụng các lệnh của ứng dụng Network Emulator trong Linux [21]. Việc giả lập chất lượng mạng 1 191 Email: jst@tnu.edu.vn
5. TNU Journal of Science and Technology 226(16): 188 - 195 sẽ cho thấy sự ảnh hưởng của băng thông lên hiệu năng hoạt động của hệ thống và chất lượng video truyền trong phiên. Trong thí nghiệm ở bài báo này, mỗi phép đo bao gồm hai máy khách tham gia có cấu hình giả lập mạng giống hệt nhau. Các phép đo sẽ được lặp đi lặp lại từ 10 đến 20 lần và độc lập với nhau để đảm bảo ý nghĩa về mặt thống kê, một tệp video định dạng .y4m sẽ được đưa vào thay thế cho webcam của máy tính. Nó có độ phân giải 1280px 720px và tốc độ khung hình 60fps. Tuy nhiên, định dạng file này không hỗ trợ âm thanh mà thay vào đó một chuỗi tiếng bíp được tạo ra tự động. Các phép đo ở phía client bao gồm 4 bước: 1. Mở URL cụ thể để tham gia phòng WebRTC. 2. Tham gia vào phiên WebRTC bằng cách phát video từ file .y4m và ghi lại các thông số từ phiên với webrtc-internals 3. Bắt đầu tải xuống nhật ký webrtc-internals. 4. Chấm dứt cuộc gọi. 4. Kết quả nghiên cứu Trong phần này tác giả trình bày một số kết quả thí nghiệm dựa trên các phân tích trình bày ở phần trước. Trong khuôn khổ của bài báo, tác giả chỉ trình bày kết quả đánh giá các tham số chính là KPIavsync, KPIfps, KPIQvideo và một số yếu tố ảnh hưởng tới các giá trị này. 4.1. Sự đồng bộ audio - video Hình 1 trình bày kết quả tính toán giá trị KPIavsync ở hai giai đoạn truyền phát video RELAY (Hình 1a) và P2P (Hình 1b). Trong đó, trục y là các giá trị KPI từ 0 đến 5, trục x thể hiện các mức băng thông được giả lập trong quá trình thí nghiệm. Giá trị KPI được tính tại mỗi mức băng thông này là giá trị trung bình qua các lần đo độc lập cùng cấu hình, errorbar tại mỗi điểm này thể hiện giá trị trung bình có khoảng tin cậy 95%. a) RELAY b) P2P Hình 1. KPIavsync với hai giai đoạn P2P và RELAY Kết quả trong Hình 1 cho thấy, giá trị KPIavsync ở cả hai giai đoạn truyền tăng lên khi băng thông khả dụng tăng lên. KPI gần đạt giá trị tối đa khi băng thông khả dụng đạt từ 1 Mbit/s trở lên. Điều này cho thấy mức độ đồng bộ hóa cao của cả hai pha truyền tại máy thu. Kết quả này cũng phù hợp với thực tế người dùng có thể xem được video rõ nét ở mức băng thông này. So với giai đoạn RELAY, KPIavsync tính ở giai đoạn P2P có sự khác biệt. Dễ dàng nhìn thấy giá trị KPI ở giai đoạn RELAY tăng đều khi băng thông tăng lên, ở mức băng thông 500 Kbit/s KPI của giai đoạn RELAY đạt 3,2; trong khi giai đoạn P2P chỉ có 2,7 nhỏ hơn cho thấy sự đồng bộ hóa ở giai đoạn RELAY tốt hơn so với P2P. Điều này cũng dễ hiểu do video truyền trong giai đoạn RELAY được chuyển tiếp qua một máy chủ trung gian giống như các công nghệ truyền video khác. Hình 2 biểu diễn một số yếu tố trễ về thời gian lên sự đồng bộ audio-video. Trục x thể hiện các mức băng thông được giả lập trong quá trình thí nghiệm; trong khi trục y bên phải hiển thị độ trễ của âm thanh hoặc video, trục y bên trái biểu thị độ trễ của video so với luồng âm thanh. Độ 192 Email: jst@tnu.edu.vn
6. TNU Journal of Science and Technology 226(16): 188 - 195 trễ được tính tại mỗi mức băng thông này là giá trị trung bình qua các lần đo độc lập cùng cấu hình, errorbar tại mỗi điểm này thể hiện giá trị trung bình có khoảng tin cậy 95%. a) RELAY b) P2P Hình 2. Các yếu tố độ trễ ảnh hưởng tới sự đồng bộ audio-video Hình 2 cho thấy độ trễ âm thanh, hình ảnh và giữa chúng với nhau đạt mức ổn định khi băng thông duy trì từ 1 Mbit/s trở lên, tương ứng với độ ổn định của KPIavsync đã phân tích ở trên. Khi đề cập tới độ trễ giữa âm thanh và hình ảnh, so sánh hai giai đoạn truyền RELAY và P2P, ta nhận thấy rõ ràng đỗ trễ giai đoạn P2P là cao hơn hẳn so với giai đoạn RELAY. Kết quả này cho thấy sự thiếu đồng bộ về thời gian khi người dùng truyền video ngang hàng trong WebRTC. Điều này có thể ảnh hưởng tiêu cực tới chất lượng trải nghiệm của người dùng. 4.2. Tính ổn định về tốc độ khung hình (Stability) Giống như độ phân giải, tốc độ khung hình được WebRTC tự động điều chỉnh tùy thuộc vào các điều kiện mạng. Hình 3 biểu diễn giá trị KPIfps ở hai giai đoạn truyền của thí nghiệm. Trong Hình 3, trục y biểu diễn các giá trị KPI từ 0 đến 5, trục x thể hiện các mức băng thông được giả lập trong quá trình thí nghiệm. KPI trung bình với khoảng tin cậy 95% của hai giai đoạn truyền được thể hiện bằng hai đường khác nhau. Hình 3. KPIfps trong giai đoạn P2P và RELAY Kết quả cho thấy, trong giai đoạn RELAY, KPIfps có giá trị gần như bằng 5 trong toàn bộ quá trình thay đổi của băng thông. Lý do cho sự khác biệt nằm ở đầu phiên, dữ liệu đo được cho thấy đôi khi phải mất vài giây để video bắt đầu. Đường dữ liệu bên dưới mô tả KPIfps trong giai đoạn P2P. Dữ liệu cho thấy, KPIfps bắt đầu với giá trị trung bình là 2,8 ở 250 Kbit/s. Trong khoảng từ 250 Kbit/s đến 400 Kbit/s KPI được tăng lên giá trị gần 5, đối với băng thông lớn hơn 400 Kbit/s KPI vẫn gần với giá trị đó. 4.3. Chất lượng video (Quality) Hình 4 biểu diễn sự thay đổi giá trị KPIQvideo trong giai đoạn RELAY và P2P. Trong đó, trục y là các giá trị KPI từ 0 đến 5, trục x thể hiện các mức băng thông được giả lập trong quá trình thí nghiệm. Giá trị KPI được tính tại mỗi mức băng thông này là giá trị trung bình qua các lần đo độc 193 Email: jst@tnu.edu.vn
7. TNU Journal of Science and Technology 226(16): 188 - 195 lập cùng cấu hình, errorbar tại mỗi điểm này thể hiện giá trị trung bình có khoảng tin cậy 95%. Kết quả cho thấy giá trị KPIQvideo trong cả hai giai đoạn RELAY và P2P bắt đầu ở mức 1,5 với băng thông khả dụng 250 Kbit/s. Giá trị này tăng cho đến khi đạt tối đa tại 2,0 Mbit/s gần như không đổi với các mức băng thông còn lại. Ta có thể kết luận rằng, tương tự như với các tham số khác, chất lượng video bị ảnh hưởng trực tiếp bởi băng thông đường truyền thấp, nhưng tham số này lại không có nhiều khác biệt ở hai giai đoạn RELAY và P2P. Điều này cho thấy sự ổn định về chất lượng của video trong quá trình truyền sử dụng công nghệ WebRTC. a) RELAY b) P2P Hình 4. KPIQvideo trong giai đoạn RELAY và P2P 5. Kết luận WebRTC hỗ trợ giao tiếp trực tiếp giữa các máy khách (P2P), cũng như việc sử dụng máy chủ chuyển tiếp (RELAY). Thực nghiệm cho thấy, đối với tất cả các phép đo, giai đoạn RELAY xuất hiện ở đầu phiên, sau đó phiên giao tiếp sẽ chuyển sang P2P sau một thời gian nhất định. Theo kết quả thí nghiệm thì chất lượng truyền phát video ở cả hai phiên này đều bị ảnh hưởng bởi chất lượng dịch vụ mạng. Cụ thể, đánh giá của tham số đồng bộ hóa (Synchronization) cho thấy sự đồng bộ hóa tổng thể là chưa tốt trong cả hai giai đoạn nếu băng thông thấp hơn 0,5 Mbit/s. Ở mức băng thông này giá trị của tất cả các KPI đóng góp vào sự đồng bộ hóa đều dưới 4. Về tính ổn định (Stability) và chất lượng video (Quality), kết quả thí nghiệm cho thấy sự ổn định tương đối cao dù băng thông thấp trong cả hai giai đoạn RELAY và P2P. Lý do cho điều này nằm ở cơ chế thích ứng chất lượng video với chất lượng mạng Internet. Nhìn chung, các kết quả thí nghiệm của nghiên cứu này mới chỉ phản ánh được một số yếu tố ảnh hưởng tới chất lượng truyền nhận video trong điều kiện băng thông khả dụng thay đổi, những tham số này còn có thể bị ảnh hưởng bởi các yếu tố khác nữa, tác giả sẽ tiếp tục nghiên cứu và công bố ở những công trình sau. Kết quả này hoàn toàn có thể được sử dụng như một tài liệu tham khảo cho các nghiên cứu sinh, các nhà nghiên cứu cùng lĩnh vực để cải tiến chất lượng dịch vụ của công nghệ WebRTC. Lời cảm ơn Nghiên cứu này được hỗ trợ bởi đề tài nghiên cứu khoa học cấp cơ sở Trường Đại học Công nghệ thông tin và Truyền thông – Đại học Thái Nguyên (Mã số: T2021-07-17). TÀI LIỆU THAM KHẢO/ REFERENCES [1] R. J. Vetter, “Videoconferencing on the Internet,” Computer, vol. 28, no. 1, pp. 77-79, 1995, doi: 10.1109/2.362625. [2] H. W. Barz and G. A. Bassett, “WebRTC,” In Multimedia Networks: Protocols, Design and Applications, Publisher: Wiley, pp. 213-222, ch. 8, 2016, doi: 10.1002/9781119090151. [3] S. Loreto and S. P. Romano, Real-time communication with WebRTC: peer-to-peer in the browser, Publisher: O'Reilly Media, Inc. ISBN: 9781449371876, chapter 1, 2014. 194 Email: jst@tnu.edu.vn
8. TNU Journal of Science and Technology 226(16): 188 - 195 [4] B. Sredojev, D. Samardzija, and D. Posarac, "WebRTC technology overview and signaling solution design and implementation," In 38th International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), 2015, pp. 1006-1009. [5] J. F. Kurose, Computer networking: A top-down approach featuring the Internet, Third edition, Publisher: Pearson Education India, 2005. [6] J. Rosenberg, Interactive connectivity establishment (ICE): A protocol for network address translator (nat) traversal for offer/answer protocols, Technical Report, 2010. [7] Y. Lu, Y. Zhao, F. Kuipers, and P. Van Mieghem, "Measurement study of multi-party video conferencing," In International Conference on Research in Networking. Springer, 2010, pp. 96-108. [8] X. Zhang, Y. Xu, H. Hu, Y. Liu, Z. Guo, and Y. Wang, "Profiling skype video calls: Rate control and video quality," 2012 Proceedings IEEE INFOCOM. IEEE, 2012, pp. 621-629. [9] S. Jana, A. Pande, A. Chan, and P. Mohapatra, “Mobile video chat: issues and challenges," In IEEE Communications Magazine, vol. 51, no. 6, pp. 144-151, 2013. [10] J. Jansen, P. Cesar, D. C. Bulterman, T. Stevens, I. Kegel, and J. Issing, "Enabling composition-based video-conferencing for the home," In IEEE Transactions on Multimedia, vol. 13, no. 5, pp. 869-881, 2011. [11] I. ITU-T Recommendation G.114, One-Way Transmission Time, Standard G, vol. 114, 2003. [12] Y. Chen, T. Farley, and N. Ye, "QoS requirements of network applications on the internet," Information Knowledge Systems Management, vol. 4, no. 1, pp. 55-76, 2004. [13] I. ITU-T Recommendation 1359, Relative timing of sound and vision for broadcasting, International Telecommunication Union, Geneva, Switzerland, 1998. [14] T. Hossfeld, M. Seufert, C. Sieber, and T. Zinner, "Assessing effect sizes of influence factors towards a QoE model for HTTP adaptive streaming," In 2014 sixth international workshop on quality of multimedia experience (qomex). IEEE, 2014, pp. 111-116. [15] P. Ni, R. Eg, A. Eichhorn, C. Griwodz, and P. Halvorsen, "Flicker effects in adaptive video streaming to handheld devices," In Proceedings of the 19th ACM international conference on Multimedia. ACM, 2011, pp. 463-472. [16] T. Zinner, O. Hohlfeld, O. Abboud, and T. Hossfeld, "Impact of frame rate and resolution on objective qoe metrics," In 2010 second international workshop on quality of multimedia experience (QoMEX). IEEE, 2010, pp. 29-34. [17] R. Adam, WebRTC video processing and codec requirements, Internet Engineering Task Force 238, 2016. [18] O. Nawaz, T. N. Minhas, and M. Fiedler, "QoE based comparison of H. 264/avc and webm/vp8 in an error-prone wireless network," In Integrated Network and Service Management (IM), IFIP/IEEE Symposium on. IEEE, 2017, pp. 1005-1010. [19] R. K. Addu and V. K. Potuvardanam, “Effect of Codec Performance on Video QoE for videos encoded with Xvid, H.264 and WebM/VP8,” Dissertation, Blekinge Institute of Technology, 2014. [20] G. Berndtsson, M. Folkesson, and V. Kulyk, "Subjective quality assessment of video conferences and telemeetings," In Packet Video Workshop (PV), 2012 19th International. IEEE, 2012, pp. 25-30. [21] S. Hemminger, “Network emulation with netem,” In Australia’s National Linux conference, Canberra, Australia, April, 2005. 195 Email: jst@tnu.edu.vn