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

LỜI CẢM ƠN Qua quá trình học tập và nghiên cứu, được sự giúp đỡ nhiệt tình của các thầy cô giáo trường Đại học Công nghệ thông tin và truyền thông Thái Nguyên, Phòng Quản lý đào tạo sau

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

PHẠM VĂN TRƯỜNG

NGHIÊN CỨU VÀ ĐÁNH GIÁ MỘT SỐ YẾU TỐ ẢNH HƯỞNG TỚI CHẤT LƯỢNGTRUYỀN PHÁT VIDEO

SỬ DỤNG CÔNG NGHỆ WEBRTC

LUẬN VĂN THẠC SĨ NGÀNH KỸ THUẬT VIỄN THÔNG

Thái Nguyên, tháng 06 năm 2022

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

PHẠM VĂN TRƯỜNG

NGHIÊN CỨU VÀ ĐÁNH GIÁ MỘT SỐ YẾU TỐ ẢNH HƯỞNG TỚI CHẤT LƯỢNGTRUYỀN PHÁT VIDEO

SỬ DỤNG CÔNG NGHỆ WEBRTC

Ngành kỹ thuật viễn thông Mã số: 8520208

LUẬN VĂN THẠC SĨ NGÀNH KỸ THUẬT VIỄN THÔNG

Người hướng dẫn khoa học: TS Đinh Xuân Lâm

Thái Nguyên, tháng 06 năm 2022

LỜI CẢM ƠN

Qua quá trình học tập và nghiên cứu, được sự giúp đỡ nhiệt tình của các thầy cô giáo trường Đại học Công nghệ thông tin và truyền thông Thái Nguyên, Phòng Quản lý đào tạo sau đại học, tôi đã hoàn thành chương trình học tập và nghiên cứu luận văn

với đề tài “Nghiên cứu và đánh giá một số yếu tố ảnh hưởng tới chất lượngtruyền

phát video sử dụng công nghệ WEBRTC”

Tôi xin chân thành cảm ơn các thầy cô giáo trường Đại học Công nghệ thông tin

và truyền thông Đại học Thái Nguyên đã tạo điều kiện thuận lợi cho tôi trong quá trình học tập, nghiên cứu và hoàn thành luận văn

Xin cảm ơn sự quan tâm, giúp đỡ chu đáo của Hội đồng khoa học, Ban Chủ nhiệm Khoa và các thầy cô giáo Phòng quản lý sau đại học trường Đại học Công nghệ thông tin và truyền thông Đại học Thái Nguyên đã tạo mọi điều kiện thuận lợi và góp nhiều ý kiến quý báu cho luận văn

Tôi xin trân trọng bày tỏ lòng biết ơn sâu sắc tới: TS Đinh Xuân Lâm - người Thầy đã tận tình hướng dẫn, chỉ bảo, động viên tôi trong suốt quá trình thực hiện luận án, bổ sung cho tôi nhiều kiến thức chuyên môn và những kinh nghiệm quý báu trong nghiên cứu

Cuối cùng, tôi xin bày tỏ lòng biết ơn và chia sẻ thành quả nhỏ bé này với tất cả những người thân trong gia đình tôi, bè bạn đã luôn động viên, giúp đỡ, tạo những điều kiện tốt nhất để tôi hoàn thành tốt chương trình học tập và thực hiện thành công luận án này

Thái Nguyên, ngày tháng năm 2022

Phạm Văn Trường

LỜI CAM ĐOAN

Tôi tên là: Phạm Văn Trường

Lớp: Cao học viễn thông K18

Tôi xin cam đoan đề tài luận văn thạc sỹ: “Nghiên cứu và đánh giá một số yếu

tố ảnh hưởng tới chất lượngtruyền phát video sử dụng công nghệ WEBRTC” là do

tôi thực hiện với sự hướng dẫn của TS Đinh Xuân Lâm Đây không phải là bản sao chép của bất kỳ một cá nhân, tổ chức nào Các số liệu, nguồn thông tin trong Luận văn là do tôi điều tra, trích dẫn và tham khảo

Tôi xin hoàn toàn chịu trách nhiệm về những nội dung mà tôi đã trình bày trong Luận văn này

Thái Nguyên, ngày tháng năm 2022 Người viết cam đoan

Phạm Văn Trường

2 Đối tượng và phạm vi nghiên cứu 10

3 Đối tượng và phạm vi nghiên cứu 10

4 Phương pháp nghiên cứu 10

CHƯƠNG 1 TỔNG QUAN VỀ WEBRTC 11

1.1 Khái niệm và các ứng dụng của WebRTC 11

1.2 Mô hình kiến trúc của WebRTC 12

1.2.1 Khởi tạo Session 13

1.2.2 Truy cập dữ liệu của phiên 15

1.3 Tổng quan về chất lượng dịch vụ video trực tuyến 15

1.3.1 Hệ thống mã hóa/giải mã 15

1.3.2 Giới hạn về băng thông 16

1.3.3 Mất gói tin 17

1.4 Tổng quan về chất lượng trải nghiệm – Quality of Experience 17

1.4.1 Khái niệm Quality of Experience (QoE) 17

1.4.2 Video QoE 17

1.4.3 Đo lường QoE 18

1.4.4 Những thách thức đối với WebRTC QoE 19

CHƯƠNG 2 CÁC YẾU TỐ QUYẾT ĐỊNH CHẤT LƯỢNG DỊCH VỤ CỦA

2.2.3 Đồng bộ hóa Audio – Video 25

2.3 Tính ổn định (Stability) 27

2.3.1 Sự ổn định về độ phân giải (Resolution Stability) 27

2.3.2 Sự ổn định về tốc độ khung hình (Frame Rate Stability) 28

2.4 Chất lượng (Quality) 29

2.4.1 Chất lượng âm thanh(Audio Quality) 30

2.4.2 Chất lượng video (Video Quality) 30

CHƯƠNG 3 KẾT QUẢ ĐO LƯỜNG VÀ ĐÁNH GIÁ 33

3.1 Phương pháp nghiên cứu 33

3.2 Thiết lập hệ thống thí nghiệm trực tuyến 33

3.3 Phương pháp thực hiện thí nghiệm và phân tích kết quả 34

3.3.1 Phương pháp thực hiện thí nghiệm 34

3.3.2 Phân tích kết quả 34

3.4 Truyền phát video và âm thanh giữa hai người dùng 35

3.4.1 Chi tiết kỹ thuật của phiên 35

3.8.2 Chất lượng video 71 KẾT LUẬN VÀ KHUYẾN NGHỊ 75 TÀI LIỆU THAM KHẢO 78

DANH MỤC HÌNH ẢNH

Hình 1.1 Tổng quan về webrtc 11

Hình 1.2 Sơ đồ kiến trúc WebRTC 12

Hình 1.3 Sơ đồ quy trình ICE trong WebRTC 14

Hình 2.1 Các tham số được đánh giá 21

Hình 2.2 KPIaudiosync phụ thuộc vào hệ số R 24

Hình 2.3 KPIvideosync phụ thuộc vào độ trễ video 25

Hình 2.4 KPIavsync phụ thuộc vào độ trễ video 27

Hình 2.5 KPIresolution phụ thuộc vào thời gian dành cho chất lượng video cao nhất 28 Hình 2.6 Sự phụ thuộc của KPIfps vào tốc độ khung hình(fps) 29

Hình 2.7 KPIQvideo phụ thuộc vào tốc độ bit của video và chiều cao hình ảnh 31

Hình 3.1 Tương tác của các thành phần được cài đặt trên cloud 34

Hình 3.2 Các thông số cho luồng video ở môi trường băng thông thấp 37

Hình 3.3 Các thông số cho luồng video ở môi trường băng thông cao 40

Hình 3.4 Các thông số cho luồng âm thanh trong cấu hình băng thông thấp 43

Hình 3.5 Các thông số cho luồng âm thanh trong cấu hình băng thông cao 44

Hình 3.6 Thông số luồng video trong cấu hình băng thông thấp của ba người dùng 47

Hình 3.7 Các thông số cho luồng video trong cấu hình băng thông cao của ba người dùng 48

Hình 3.8 Thông số luồng âm thanh trong cấu hình băng thông thấp của ba khách hàng 50

Hình 3.9 Các thông số cho luồng âm thanh trong cấu hình băng thông thấp của ba khách hàng 51

Hình 3.10 KPIaudiosync với hai khách hàng 53

Hình 3.11 Các thông số ảnh hưởng đến sự đồng bộ âm thanh với hai khách hàng 54 Hình 3.12 KPIaudiosync với hai khách hàng 55

Hình 3.13 Các thông số ảnh hưởng đến sự đồng bộ âm thanh với hai khách hàng 55 Hình 3.14 KPIvideosync với hai giai đoạn P2P và RELAY 57

Hình 3.15 Các thông số ảnh hưởng đến KPIvideosync 57

Hình 3.16 KPIvideosync trong quá trình đo với ba khách hàng 58

Hình 3.17 Các thông số ảnh hưởng đến KPIvideosync với ba khách hàng 59

Hình 3.18 KPIavsync trong giai đoạn P2P và RELAY 60

Hình 3.20 KPIavsync trong quá trình đo với ba khách hàng 62

Hình 3.21 Các thông số ảnh hưởng đên KPIavsync với ba máy khách 63

Hình 3.22 KPIresolution trong phép đo với hai khách hàng 64

Hình 3.23 Tỷ lệ phần trăm đạt độ phân giải cao nhất 64

Hình 3.24 KPIresolution trong phép đo với ba khách hàng 65

Hình 3.25 Tỷ lệ phần trăm đạt độ phân giải cao nhất trong phép đo với ba khách hàng 65

Hình 3.26 KPIfps trong giai đoạn P2P và RELAY 66

Hình 3.27 Tốc độ khung hình đầu ra trung bình 67

Hình 3.28 KPIfps trong phép đo với ba máy khách 68

Hình 3.29 Tốc độ khung hình đầu ra trung bình với ba khách hàng 68

Hình 3.30 KPIQaudio trong giai đoạn RELAY và P2P 69

Hình 3.31 Tốc độ bit (Kbit/s) 70

Hình 3.32 KPIQaudio trong phép đo với ba máy khách 70

Hình 3.33 Tốc độ bit (Kbit/s) 71

Hình 3.34 KPIQvideo trong giai đoạn RELAY và P2P 72

Hình 3.35 Các thông số ảnh hưởng đến chất lượng video 73

Hình 3.36 KPIQvideo trong phép đo với ba máy khách 73

Hình 3.37 Các thông số ảnh hưởng đến chất lượng video với ba máy khách 74

DANH MỤC THUẬT NGỮ VÀ TỪ VIẾT TẮT

Session Instantiation Khởi tạo phiên

Influencing Factors Những nhân tố ảnh hưởng

Frames per Second/FPS Tốc độ khung hình trong môt giây

KPI

KPI là chữ cái viết tắt của cụm từ Key Performance Indicator KPI được hiểu là chỉ số đánh giá hiệu quả

KPIaudiosync KPI đồng bộ hóa Audio KPIvideosync KPI đồng bộ hóa Video

KPIavsync KPI đồng bộ hóa Audio – Video KPIresolution KPI sự ổn định về độ phân giải

KPIQaudio KPI về chất lượng âm thanh

Video Frame Rate Tốc độ khung hình của video

Sent Frame Khung hình gửi đi

Sent Frame Per Secnd Tốc độ khung hình(fps) đã gửi đi Sent Frame Height Độ cao khung hình gửi đi

Bitrate Sent Video Tốc độ bit gửi video

Recv Frame Height Độ cao khung hình nhận được Recv Frame Width Độ rộng khung hình nhận được Bitrate Recv Video Tốc độ bit nhận video

Bitrate Sent Audio Tốc độ bit gửi đi của audio Bitrate Recv Audio Tốc độ bit nhận của audio Recv Jitter Buffer Audio Jitter Buffer nhận được của audio

Preferred Recv Jitter Buffer Audio Jitter Buffer ưu tiên nhận được của audio

MỞ ĐẦU 1 Đặt vấn đề

Công nghệ truyền video qua công nghệ WebRTC cho phép người dùng giao tiếp và tương tác trực tiếp với nhau trong thời gian thực Công nghệ WebRTC cho phép dễ dàng triển khai lên web hay ứng dụng di động

Do đó công nghệ WebRTC ngày càng được phổ biến Khi mức độ phổ biến và sử dụng tăng lên, nhu cầu đánh giá và đo lường hiệu suất cũng tăng theo để tăng chất lượng của dịch vụ

2 Đối tượng và phạm vi nghiên cứu

Đối tượng nghiên cứu của luận văn là đánh giá một số 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

Phạm vi nghiên cứu là mô phỏng 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.Hướng nghiên cứu của đề tài

3 Đối tượng và phạm vi nghiên cứu

Luận văn này cung cấp một cái nhìn tổng quan về các yếu tố ảnh hưởng đến QoE của WebRTC Để đánh giá các yếu tố này các phân tích và thí nghiệm liên quan đã được tiến hành Bằng cách này, một loạt các tham số đóng góp vào QoE của người dùng đã được xác định

4 Phương pháp nghiên cứu

Để có được dữ liệu sử dụng cho việc đánh giá các thí nghiệm đo lường WebRTC được triển khai Các kịch bản đo cho phép tiến hành các phép đo lặp lại và thự hiện một cách tự động Nó hỗ trợ phát lại video được xác định trước, sửa đổi thời lượng đo cũng như số lần lặp lại Các phép đo có thể được tiến hành với số lượng khách hàng tham gia khác nhau vì kịch bản đo cho phép dễ dàng bổ sung và loại bỏ người tham gia khỏi các phép đo Trong quá trình đo, các thông số phiên được ghi lại tự động, sau đó được thu thập và tổ chức lại để tính toán các giá trị KPI Các phép được thực hiện bằng cách sử dụng các phiên bản máy tính được ảo hóa tại Google Cloud

CHƯƠNG 1 TỔNG QUAN VỀ WEBRTC 1.1 Khái niệm và các ứng dụng của WebRTC

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 1 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

Hình 1.1 Tổng quan về webrtc

Dựa trên API này, các nhà phát triển sau đó có thể xây dựng dịch vụ của họ bằng cách sử dụng các chức năng được cung cấp Ưu điểm của WebRTC là việc sử dụng các công nghệ hiện có như giao tiếp dựa trên HTTP và TCP/IP và tích hợp liền mạch trong các trình duyệt mà không cần phần mềm của bên thứ ba [2] Một trong những tính năng cốt lõi của WebRTC là giao tiếp peer to peer giữa các clients Bằng cách này WebRTC giới thiệu khả năng giao tiếp trực tiếp giữa các máy khách trong một session Tuy nhiên để khởi tạo một sesion thì trình sửa lỗi trung tâm vẫn cần thiết [3]

Như trong hầu hết trường hợp, các clients truy cập Internet qua tường lửa và sử dụng kỹ thuật Network Address Translation (NAT), do đó không thể trực tiếp trao đổi dữ liệu giữa các clients Interactive Connectivity Establishment (ICE) là một khuân mẫu cho phép trình duyệt của các clients vượt qua tường lửa để kết nối với các trình duyệt của client khác Sau đó các clients có thể trao đổi dữ liệu trực tiếp [4] Thông tin thêm về hoạt động của ICE được cung cấp trong phần sau

1.2 Mô hình kiến trúc của WebRTC

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 Hình dưới mô tả sự liên kết sơ đồ của các thành phần WebRTC Tại tầng trên cùng có nhiều ứng dụng truy cập API Javascript API Web sau đó được kết nối với API trình duyệt WebRTC thông qua việc triển khai trình duyệt

Hình 1.2 Sơ đồ kiến trúc 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 session Công cụ quản lý session (Session Management) chịu trách nhiệm quản

lí theo dõi trạng thái của session Công xử lý âm thanh (voice engine) 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ý xử lý video (video engine) xử lý việc 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 (transport) nó 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 client qua mạng

1.2.1 Khởi tạo Session

Session Instantiation: Khởi tạo phiên là một phần quan trọng trong quá trình thiết lập phiên cho cuộc gọi WebRTC Như đã đề cập ở trên, 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 client 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 client 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 Để 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 client 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ộ [4] Để 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 cho dữ liệu

Hình 1.3 Sơ đồ quy trình ICE trong WebRTC

Sơ đồ trên mô tả chuỗi các thông điệp được trao đổi trong quá trình thiết lập một phiên Để bắt đầu một phiên client-1 tạo một Offer Mỗi Offer chứa thông tin về máy khách này cũng như các máy khách khác sẽ tham gia phiên do ICE thu thập Như vậy, bước đầu tiên sẽ là thu thập thông tin của các máy khách tham gia phiên truyền ICE của một máy khách là sự kết hợp của địa chỉ IP và một cổng có thể được sử dụng để giao tiếp với máy khách khác Các địa chỉ này được thu thập bằng cách sử dụng tiện ích truyền tải phiên cho NAT (STUN), qua đó máy khách gửi một yêu cầu đến máy chủ STUN cùng với với IP và cổng của nó[21] Ngoài ra máy khách có thể yêu cầu máy chủ TURN do nhà điều hành dịch vụ WebRTC chỉ định Máy chủ TURN hoạt động như một thiết bị chuyển tiếp cho luồng video trong trường hợp không thể sử dụng bất kỳ máy khách nào được thu thập thông qua máy chủ STUN Sau khi tập hợp thông tin của các máy khách, Offer được tạo và gửi đến máy chủ Sau đó, máy chủ chuyển tiếp Offer tới client-2, máy này đồng thời cũng thu thập cùng một thông tin để tạo ra một Offer và được truyền trở lại máy client-1 Cả hai máy client sau đó đều có danh sách các máy khách để kết nối với các máy máy khách khác và bắt đầu

kiểm tra đường truyền có thể sử dụng 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

1 Giao tiếp trực tiếp giữa máy client-1 và máy cient-2 bằng cách sử dụng một trong các máy khách được cung cấp bởi máy chủ STUN

2 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

1.2.2 Truy cập dữ liệu của phiên

Để tiến hành đánh giá thí nghiệm này, việc đầu tiên là cần phải thu thập dữ liệu về việc chạy các phiên WebRTC Google Chrome cung cấp khả năng truy cập nhiều loại dữ liệu liên quan đến WebRTC thông qua webrtc-internals1 được tích hợp trong Chrome Mô-đun này cung cấp thông tin thời gian thực về các phiên và luồng dữ liệu hiện đang chạy và có thể được sử dụng trong quá trình phát triển ứng dụng dựa trên WebRTC Ngoài ra khả năng xuất dữ liệu đã thu thập dưới dạng file JSON cũng được webrtc-internals cung cấp Sau đó, file này có thể được phân tích để lấy các trường dữ liệu như cấu hình máy chủ, thông tin các máy khách, các hàm API đã được gọi, và khối thông tin về luồng video được truyền qua người dùng đầu cuối

1.3 Tổng quan về chất lượng dịch vụ video trực tuyến

Có rất nhiều yếu tố ảnh hưởng đến chất lượng dịch vụ video trực tuyến từ bước mã hóa/giải mã, nén/giải nén, và các yếu tố liên quan đến việc truyền dẫn như giới hạn băng thông đường truyền, mất gói tin, suy hao đường truyền, lỗi bit,… Phần sau sẽ trình bày một số yếu tố chính ảnh hưởng tới chất lượng của dịch vụ video trực tuyến

1.3.1 Hệ thống mã hóa/giải mã

Mã hóa và giải mã video là một trong những khâu quan trọng trong việc truyền tải một nội dung đa phương tiện Hiện tại có hai hệ thống mã hóa tiêu chuẩn được sử

1chrome://webrtc-internals

dụng rộng rãi đó là ITU (International Telecommunications Union) và MPEG (Motion Picture Experts Group) [1] Trong những năm qua cả hai hệ thống tiêu chuẩn này đều đưa ra các tiêu chuẩn cho việc mã hóa và giải mã video

Các phương pháp mã hóa video nói chung thường kết hợp cả kiểu mã hóa intra-frame và inter-intra-frame Trong kiểu mã hóa intra-intra-frame, một intra-frame ảnh được chia thành các khối, mỗi khối này được biến đổi thành tập các hệ số thông qua biến đổi Cosin rời rạc Một nhóm các khối được kết hợp lại thành một thực thể duy nhất (slice) và đôi khi được đóng gói vào một gói Nếu có lỗi trên đường truyền xảy ra thì có thể cả một nhóm các khối sẽ bị mất tạo nên “sọc” trong các ảnh giải mã Điều này xảy ra bởi vì các hệ số của biển đổi Cosin rời rạc trong mỗi khối được tính toán dựa trên khối đầu tiên trong slice nếu lỗi làm mất thông tin của khối đầu tiên thì tất cả các khối còn lại trong slice là không xác định Một vài lỗi có thể làm hỏng cấu trúc của frame do đó không có khả năng tái tạo lại frame Với kiểu mã hóa inter-frame (motion based coding) các vector chuyển động được xác định và mã hóa cho mỗi khối Trong các hệ thống mã hóa kiểu inter-frame việc mất một frame có thể làm cho các frame theo sau nó trở nên không sử dụng được cho đến khi I-frame tiếp theo được nhận kết quả là có thể thu được hình ảnh video trắng hay hình ảnh bị đông cứng chất lượng video bị suy giảm đáng kể

Trong hầu hết các trường hợp các tiêu chuẩn mã hóa video đều cung cấp khả năng linh động ở cả bộ mã hóa và giải mã cho việc cân bằng giữa chất lượng và tốc độ Việc hiểu biết rõ ràng về ảnh hưởng của các bộ mã hóa và giải mã video là yếu tố quan trọng góp phần vào việc đánh giá chính xác các ảnh hưởng của mạng đến chất lượng truyền video trên mạng

1.3.2 Giới hạn về băng thông

Nếu băng thông có sẵn không đủ để truyền một video stream thì sẽ xảy ra mất gói tại các bộ đệm của bộ định tuyến dẫn đến việc suy giảm chất lượng video Trong trường hợp này sự thay đổi hình ảnh hay sự thay đổi các frame là đáng kể sẽ làm tăng yêu cầu về băng thông trong một khoảng thời gian ngắn, điều này có thể gây lên hiện tượng mất gói và do đó làm suy giảm chất lượng hình ảnh

1.3.3 Mất gói tin

Việc mất gói tin khi truyền tải có thể gây ra bởi nhiều nguyên nhân: do nghẽn mạng, mất kết nối, không đủ băng thông hay lỗi trên đường truyền, v.v… Sự cố mất gói tin thường xảy ra đột ngột, mức độ tắc nghẽn mạng cao gây nên độ mất gói cao Sự suy giảm chất lượng video gây ra bởi hiện tượng mất gói tùy thuộc vào giao thức được sử dụng để truyền tải video:

- Với giao thức UDP khi xảy ra hiện tượng mất gói thì hiện tượng mất gói có thể làm hỏng một phần hay thậm chí hoàn toàn các frame một của video stream

- Khi giao thức TCP được dùng để truyền tải dữ liệu video, khi một gói bị mất thì sẽ có yêu cầu truyền lại gói đã bị mất, điều này làm thiếu hụt bộ đệm gây nên hiện tượng dừng hình

1.4 Tổng quan về chất lượng trải nghiệm – Quality of Experience

1.4.1 Khái niệm Quality of Experience (QoE)

Theo tiêu chuẩn ITU P.10/G100[1] QoE được định nghĩa là “Mức độ hài lòng hoặc khó chịu của người dùng với ứng dụng hoặc dịch vụ” Các tác giả của [37] đã thực hiện một cách tiếp cận hướng tới khái niệm khung QoE Các tác giả tạo ra một mô hình kết nối các yếu tố QoS khác nhau để xác định các thành phần đặc biệt của QoE Trong [14], việc chuyển đổi từ các thỏa thuận cung cấp dịch vụ dựa trên QoS sang QoE được thảo luận Các tác giả cho rằng sự xuất hiện của các loại nội dung đa phương tiện mới trên internet khiến cho việc đo lường mức độ hài lòng của người dùng là cần thiết Họ đề xuất việc đánh giá sự hài lòng bằng cách sử dụng QoE trong khi thảo luận về những thách thức so với các phương pháp tiếp cận cổ điển

1.4.2 Video QoE

Sự phát triển mạnh mẽ của tất cả các loại dịch vụ trực tuyến liên quan đến video trong những năm qua đã tạo ra sự quan tâm mạnh mẽ đến việc đánh giá QoE cho video Một lĩnh vực được quan tâm đặc biệt là lĩnh vực phát video trực tuyến Trong bối cảnh này, QoE là sự kết hợp của nhiều yếu tố Một là chất lượng không gian đề cập đến chất lượng của một hình ảnh duy nhất Nó được tạo ra bởi một loạt các tham số bao gồm

codec, tốc độ bit video và độ phân giải Một yếu tố cấu thành khác trong QoE là chất lượng tạm thời Nó liên quan đến khả năng của các khung hình video theo đúng thứ tự kịp thời và có mặt tại máy client vào thời điểm cần thiết [28]

Tùy thuộc vào giao thức được sử dụng để phát trực tuyến video, các yếu tố khác nhau có thể được xem xét để đánh giá QoE Phát trực tuyến dựa trên UDP dễ bị mất gói và mạng bị chập chờn gây ra hiện tượng biến dạng hình ảnh hoặc thiếu khung hình, có khả năng ảnh hưởng đến QoE của người dùng [29] Trong trường hợp phát video dựa trên giao thức TCP, yếu tố ảnh hưởng chính tới QoE là một thành phần khác Vì giao thức TCP hướng đến truyền tin tin cậy, đảm bảo việc phân phối video không bị thay đổi, không có các hình ảnh bị biến dạng [30] Thay vào đó, phương pháp đánh giá QoE phải dựa vào lượng video có trong bộ nhớ đệm của máy khách, bộ nhớ này sẽ giảm đi khi video được phát và tăng lên mỗi khi một phân đoạn video mới được tải về thành công Trong trường hợp tải xuống các phân đoạn như vậy bị trì hoãn, bộ đệm có thể bị trống Khi đó, video sẽ bị dừng, hiện được này được gọi là

video stalling Số lượng lần video bị dừng và độ dài của nó là yếu tố chính trong việc

đánh giá QoE đối với phương pháp truyền video dựa trên TCP [31]

1.4.3 Đo lường QoE

QoE, với các thuộc tính ít liên quan tới mạng máy tính hơn so với QoS, nó đòi hỏi các phương tiện đo lường mới để nắm bắt chính xác QoE Trong [15], Schatz và cộng sự đã cung cấp một cái nhìn tổng quan về lĩnh vực đo lường QoE Các tác giả trên đã nêu bật sự khác biệt giữa các phương pháp đánh giá chủ quan và khách quan Các tác giả lập luận rằng trong khi các đánh giá khách quan rất dễ thực hiện, chúng chỉ có thể đưa ra một giá trị gần đúng hạn chế Do đó, để đo lường QoE một cách chính xác, cần phải bao gồm các chỉ số đo lường chủ quan Đối với trường hợp phát trực tuyến video, các tác giả của [38] trình bày một loạt các chỉ số QoE khách quan và mối quan hệ của chúng với nhau Lưu ý rằng ước tính QoE chính xác bằng cách sử dụng các số liệu mục tiêu là một nhiệm vụ đầy thách thức vì cần phải xác định mối quan hệ giữa các số liệu mục tiêu Trong [27], các tác giả trình bày khung đo lường QoE cho việc truyền thoại và video qua IP Khung có khả năng ước tính QoE trực

tuyến dựa trên các thông số mạng đo được Nó được xây dựng dựa trên các phép đo chủ quan cung cấp dữ liệu cho mô hình hoạt động.

Cách tiếp cận thứ hai là ước tính QoE trực tuyến dựa trên các tham số hệ thống khách quan Trong trường hợp này, dữ liệu của một hệ thống đang chạy bình thường được đánh giá bằng cách sử dụng các kỹ thuật khách quan được biết là gần đúng chính xác QoE của người dùng sử dụng hệ thống được đề cập Cách tiếp cận này cho phép đưa ra được các hành động phòng ngừa nếu ước tính QoE cho thấy rằng QoE của người dùng cuối đang xấu đi Ngược lại phản ứng đối với sự suy giảm QoE thực tế chỉ có thể xảy ra sau khi sự giảm sút thực tế đã diễn ra [27]

1.4.4 Những thách thức đối với WebRTC QoE

Kiến trúc truyền thông

Kiến trúc của phiên WebRTC khác biệt đáng kể so với phiên phát trực tuyến video thông thường Trong quá trình phát trực tuyến video truyền thống, ứng dụng yêu cầu video từ máy chủ Sau đó máy chủ sẽ gửi video được yêu cầu đến máy khách Máy chủ có thể xử lý nhiều máy khách cùng một lúc Đối lập với điều này trong WebRTC tồn tại hai kiến trúc khác nhau Thứ nhất các máy khách có thể giao tiếp bằng cách sử dụng giao tiếp ngang hàng được kích hoạt bởi máy chủ STUN Nếu không thể giao tiếp ngang hàng, máy chủ TURN có thể được sử dụng làm phương án dự phòng Đặc điểm của hai kiểu giao tiếp này là khác nhau Khi sử dụng máy chủ TURN, mỗi gói được gửi hai lần, xảy ra khả năng mất gói hoặc suy giảm mạng ảnh hưởng đến quá trình truyền Ngoài ra giống như máy chủ phát trực tuyến video, máy chủ TURN có thể phải xử lý nhiều luồng đồng thời Điều này dẫn tới việc truyền tải có khả năng gây ra độ trễ từ đầu đến cuối và giảm QoE

Thành phần phiên không đồng nhất

Thực tế là một phiên có thể bao gồm nhiều hơn hai client làm tăng độ phức tạp Trong quá trình phát trực tuyến video máy chủ dễ dàng quyết định chất lượng video để gửi cho máy khách Quyết định được đưa ra dựa trên độ phân giải hiển thị của máy khách và băng thông khả dụng Đối với phiên WebRTC có ba client trở lên, mỗi video được gửi cho ít nhất hai client Trong trường hợp này, có thể có các độ phân giải màn

hình và điều kiện mạng khác nhau Mỗi máy client phải quyết định độ phân giải video nào sẽ được gửi cho các client khác Tất cả các client đều nhận được cùng một độ phân giải hoặc mọi máy khách đều gửi video tốt nhất có thể dựa trên điều kiện mạng của họ Một khả năng khác là tạo video cho từng người nhận dựa trên điều kiện mạng của họ Việc tạo ra nhiều mức chất lượng video làm tăng tải ở người gửi, điều này cũng có khả năng ảnh hưởng đến QoE Hơn nữa việc nhận các mức chất lượng khác nhau có thể ảnh hưởng đến QoE của bộ thu

Truyền âm thanh - Video riêng biệt

Một video thông thường bao gồm định dạng vùng chứa một luồng video và một hoặc nhiều luồng âm thanh Trong quá trình phát trực tuyến video dựa trên TCP, các phần nhỏ của video như vậy được tải xuống theo trình tự Mỗi phân đoạn video chứa một thời lượng video cụ thể và âm thanh tương ứng Trong trường hợp của WebRTC, việc truyền các luồng âm thanh và video diễn ra riêng biệt Định tuyến khác nhau của các gói có thể dẫn đến độ trễ khác nhau cho hai luồng dữ liệu trên Dựa trên chiến lược phát tại máy thu, sự chênh lệch về độ trễ này có thể đáng chú ý bởi máy thu và có thể ảnh hưởng xấu đến QoE [34] Một giải pháp được đưa ra là sử dụng bộ đệm jitter (jitter buffer) để đảm bảo phát đồng thời hai luồng Tuy nhiên giải pháp này có thể làm tăng độ trễ giữa các client

Tương tác

Sự khác biệt quan trọng nhất giữa phát trực tuyến video theo yêu cầu và một cuộc gọi trực tuyến là bản chất thời gian thực của một cuộc gọi Khi người dùng xem video việc máy chủ bị chậm trễ sẽ không liên quan đến họ, miễn là phân đoạn video tiếp theo đến đúng giờ Nhưng công nghệ WebRTC là một hệ thống, nhằm mục đích cho phép tương tác và giao tiếp thời gian thực giữa những người tham gia, độ trễ giữa các client là một yếu tố quan trọng [35]

CHƯƠNG 2 CÁC YẾU TỐ QUYẾT ĐỊNH CHẤT LƯỢNG DỊCH VỤ CỦA WEBRTC

2.1 Kỹ thuật truyền dữ liệu trong WebRTC

Dựa trên các nghiên cứu [34], [10] và [17], 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 như sau:

a) Đồng bộ hóa (Synchronization) b) Tính ổn định (Stability)

c) Chất lượng (Quality)

Hình 2.1 Các tham số được đánh giá

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

2.2 Đồ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 Trong bối cảnh một cuộc gọi video với hành động nghe và nhìn thì sự đồng bộ đạt được khi mà trải nghiệm của người dùng trong một cuộc giao tiếp có thể so sánh với một cuộc trò chuyện trực tiếp bất kể khoảng cách địa lý giữa các bên tham gia[18] 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 Ví dụ: trong khi luồng âm thanh có thể được đồng bộ theo cách có thể chấp nhận được thì luồng video có thể bị trễ Bất kể loại luồng nào, chỉ cần một luồng bị trễ sẽ ảnh hưởng tới QoE được cảm nhận bởi người dùng [19] Do việc truyền âm thanh và video riêng biệt, đánh giá liên quan đến đồng bộ hóa sẽ được đánh giá theo hai luồng riêng biệt Các điểm số khác nhau này sau đó được kết hợp để có thể hiểu sâu hơn về trạng thái của sự đồng bộ hóa trong một phiên truyền

2.2.1 Đồng bộ hóa Audio

Đảm bảo đồng bộ hóa âm thanh là một vấn đề không chỉ đối với một cuộc hội thoại trực tuyến Bất kỳ đường truyền âm thanh hai chiều nào được thiết kế để hỗ trợ tương tác của người dùng phải đảm bảo sự đồng bộ của tất cả những người tham gia Luồng âm thanh của cuộc gọi trực tuyến có thể so sánh với điện thoại, đối với mạng điện thoại, Liên minh viễn thông quốc tế (ITU) đã phát triển mô hình E-model và được mô tả trong tài liệu ITU-T Rec G.107 [20]

Tài liệu [22] đưa ra mô hình ước tính mức độ hài lòng của người dùng khi sử dụng các hệ thống truyền khác nhau với danh sách đầy đủ các thông số đầu vào liên quan đến điều kiện phần cứng và môi trường mạng Kết quả của phép tính mô hình E là Hệ số xếp hạng (R-factor) nằm trong khoảng từ 0 đến 100 Nó cũng có thể được ánh xạ tới giá trị MOS Trong phần sau, chúng ta sử dụng giá trị MOS được tính bởi mô hình E-Model và được sử dụng cho giá trị KPIaudiosync

Một giải pháp thay thế được đề xuất bởi các tác giả trong [23] Các tác giả cung cấp một phiên bản đơn giản của mô hình E-Model Mô hình đã được đơn giản hóa

bằng cách sử dụng các giá trị mặc định theo đề xuất của các tác giả của E-model gốc

Sử dụng giá trị mặc định, phương trình cơ sở để tính hệ số R theo công thức

Trong đó Id là thành phần trễ, được đặc trưng bởi:

Id = 0.024d + 0.11(d ‒ 177.3) * H(d ‒ 177.3) (2.2)

Với d là độ trễ một chiều và H là hàm bước có giá trị bằng 0 đối với các giá trị

nhỏ hơn hoặc bằng 0, bằng 1 với các giá trị khác Trong đề tài này, thành phần trễ là tổng hợp của độ trễ một chiều thực tế và jitter ở máy thu

Hệ số suy giảm thiết bị Ief được tính theo công thức:

Ief = 30 ‒ ln(1 + 15 * e) (2.3)

Trong đó e là xác suất mất gói tin Lưu ý rằng phương trình Ief sử dụng ba tham

số “fitting” phù hợp là các mã (codec) cụ thể Các giá trị được sử dụng được các tác

giả đề xuất là codec G729a, khác với codec Opus được WebRTC sử dụng trong các

kịch bản đo trong đề tài này Đối với codec Opus, không có giá trị phù hợp (fitting)

nào được đưa ra Tuy nhiên, trong các kịch bản thực nghiệm, thành phần chính ảnh

hưởng đến việc truyền âm thanh là độ trễ Có thể thấy, Id thành phần độ trễ được xác định bằng độ trễ từ đầu đến cuối Không có thông số ghi rõ codec nào được áp dụng Do đó, mặc dù các giá trị được sử dụng để đánh giá, nhưng thông thường nên sử dụng các giá trị chính xác cho một tham số Dựa trên hệ số R được tính toán, giá trị KPIaudiosync được tính như sau:

Hình 2.2 KPIaudiosync phụ thuộc vào hệ số R

Hình 2.2 mô tả giá trị KPIaudiosync được tính toán phụ thuộc vào hệ số R được tính

bằng các phương trình mô tả ở trên Hệ số R được ghi nhận trên trục x, và trục y mô tả

các giá trị KPI được tính toán Về tính toán hệ số R, có thể thấy rằng giá trị lớn nhất có thể đạt được là 94,2 Do đó, điểm MOS tối đa có thể đạt được là khoảng 4.3

2.2.2 Đồng bộ hóa 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 [25] chỉ ra độ trễ 350ms đượ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 Một ước tính khác về thời gian trễ có thể chấp nhận được trong phiên video thời gian thực được cung cấp bởi các tác giả trong [24] 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 [26] Cho rằng độ trễ này là có thể chấp nhận được đối với luồng âm thanh, các tác giả trong nghiên cứu trên lập luận rằng đối với đồng bộ hóa khẩu hình miệng, độ trễ giữa âm thanh và video không được lớn

hơn 100 ms Các tác giả đã kết luận với tổng độ trễ 250 ms, việc truyền video tương tác, đồng bộ khẩu hình miệng có thể đạt được [24] Dựa trên các nghiên cứu trên, phương trình ước tính KPI được xây dựng bao gồm thành ba phần như sau:

Hình 2.3 KPIvideosync phụ thuộc vào độ trễ video

Hình 2.3 mô tả KPIvideosync là một hàm của tổng độ trễ video Trục x mô tả độ trễ của video, trong khi trục y mô tả các giá trị KPI Chúng ta có thể dễ dàng nhìn thấy giá

trị biên là từ 100 đến 400ms và KPI giảm tuyến tính theo đà tăng của độ trễ

2.2.3 Đồng bộ hóa Audio – Video

Trái ngược với các cách truyền trực tiếp khác như truyền trực tuyến thích ứng HTTP, hai luồng âm thanh và video được truyền riêng biệt khi sử dụng WebRTC Do vậy, dữ liệu âm thanh và video có thể không được đồng bộ hóa

Tham số quan trọng thứ ba là tính đồng bộ ở 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 lại âm thanh và luồng video phải đồng bộ Nhiều yếu tố dẫn đến sự đồng bộ hóa của hai luồng Chúng bao gồm: mã hóa ở cả phía người gửi và người nhận, thời gian truyền, độ trễ

hiển thị Vì đánh giá dựa trên dữ liệu do thành phần WebRTC-internals cung cấp

nên không thể xem xét tất cả các thông số này Do đó, độ trễ của một luồng từ người gửi cho đến khi người nhận nhận ra nó được coi là tổng của độ trễ một chiều và thời gian phát tương ứng 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 khoảng cách trễ tối đa giữa âm thanh và video nên là 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 [24]

Theo đánh giá chủ quan, người dùng nhạy cảm hơn trong trường hợp âm thanh được phát ra sớm hơn dữ liệu video liên quan 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 [27] Dựa trên khuyến nghị của ITU, một mô hình ước tính được xây dựng Đối với sự khác biệt về độ trễ, trong đó độ trễ được coi là không thể phát hiện được, giá trị KPI có giá trị bằng 5 Đối với các giá trị trễ được coi là có thể chấp nhận được, KPI được tính bằng cách sử dụng một hàm tuyến tính được xác định trong khoảng thời gian có liên quan Tất cả các giá trị nằm ngoài phạm vi chấp nhận được được coi là giá trị KPI bằng 1 Để tính toán các giá trị KPI phụ thuộc vào độ trễ âm thanh/video, công thức sau được sử dụng

Kết quả ước tính KPI được mô tả trong dưới Trong biểu đồ hình 2.4, trục x mô tả video phát ra so với âm thanh trong khi trục y hiển thị các giá trị KPI Các giá trị dương trên trục x đại diện cho video được phát trước so với âm thanh, trong khi các giá trị âm

tượng trưng cho việc phát video bị trễ so với luồng âm thanh

Hình 2.4 KPIavsync phụ thuộc vào độ trễ video

2.3 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 Quá trình truyền gói tin có thể bị ngắt do thời gian truyền khác nhau hoặc mất gói Lý do cho điều này là việc định tuyến qua các đường dẫn khác nhau và độ dài hàng đợi trong bộ định tuyến dẫn đến tăng thời gian chuyển mạch [28] 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ị 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, độ trễ quá lớn có thể khiến bộ đệm mất đi tác dụng

2.3.1 Sự ổn định về độ phân giải (Resolution Stability)

Điều kiện 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 (stalling) Tần suất và thời gian ngừng phát video là yếu tố chính trong việc đánh giá chất lượng QoE cho video trực tuyến

[11] 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 đáp ứ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 Tuy nhiên, QoE vẫn có thể bị ảnh hưởng bởi một số yếu tố khác Một trong số đó là tần suất thay đổi độ phân giải [29] và khoảng thời gian video được phát ở độ phân giải cao nhất [16] KPI cho hiện tượng này được tính như sau:

KPIresolution = 0:003 * e0.064*t + 2.498 (2.7)

Trong đó t là số phần trăm ([0,100]) thời gian video được phát ở độ phân giải cao

nhất Hình 2.5 cho thấy sự phụ thuộc của KPIresolutionvào khoảng thời gian video được

phát ở độ phân giải cao nhất Trục x mô tả giá trị t trong khi trục y hiển thị giá trị KPI

Thời gian đạt độ phân giải cao nhất(%)

Hình 2.5 KPIresolution phụ thuộc vào thời gian dành cho chất lượng video cao nhất

2.3.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 [30], 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 Các tác giả trình bày kết quả từ các kịch bản đo ước tính QoE cho các video khác nhau với tốc độ khung hình khác nhau bằng cách sử dụng mô hình VQM Sử dụng các kết quả đã trình bày, chúng ta nội suy các giá trị còn thiếu bằng hàm logarit Do đó, ta có thể tính toán KPI để ước lượng QoE 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:

Trong đó fps là tốc độ khung hình đầu ra hiện tại của luồng video đã nhận Hình 2.6 mô tả sự phụ thuộc của KPI vào tốc độ khung hình Trục x hiển thị fps và trục y

hiển thị giá trị KPI

Hình 2.6 Sự phụ thuộc của KPIfps vào tốc độ khung hình(fps)

2.4 Chất lượng (Quality)

Một trong những mục tiêu chính của dự án WebRTC là cung cấp dịch vụ giao tiếp thời gian thực chất lượng cao Chất lượng dịch vụ có thể được kiểm nghiệm bằng cách sử dụng các thông số khác nhau

2.4.1 Chất lượng âm thanh(Audio Quality)

Trong các kịch bản thực nghiệm đã tiến hành, codec Opus được sử dụng để mã hóa âm thanh Trong [31], các tác giả đánh giá hiệu suất của codec EVS so sánh với Opus Các codec được so sánh trong các tình huống khác nhau bằng cách sử dụng tốc độ bit từ 5.9 kbit/s đến 128 kbit/s Dựa trên kết quả được đưa ra từ các kịch bản đo giọng nói rõ ràng, KPI cho chất lượng âm thanh KPIQaudio được xây dựng như sau:

Tốc độ bit (kbit/s) KPI

Bảng 2.1: KPIQaudio dựa trên tốc độ bit của âm thanh

Cần lưu ý rằng KPI này rất đơn giản, vì nó chỉ sử dụng tốc độ bit của âm thanh Các yếu tố khác chẳng hạn như tỷ lệ mất gói được bỏ qua vì ảnh hưởng không lớn

2.4.2 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 [32] Các tác giả đã so sánh sự khác nhau của H.264 và VP8 Trong [33], các tác giả so sánh MOS của các luồng video qua mạng không dây Họ kết luận rằng trong hầu hết các trường hợp, H.264 có lợi thế hơn VP8, trong khi VP8 tạo ra kết quả ổn định hơn trong các mạng dễ bị lỗi Sự khác biệt MOS đo được nằm trong khoảng [0; 0.5] Trong đề tài này, tác giả sử dụng video codec VP8 trong các kịch bản thực nghiệm

Các tác giả của [34] so sánh H.264, VP8 và Xvid trong tình huống đường truyền có sự mất gói tin hoặc trễ Tương tự như [33], họ tuyên bố rằng chất lượng dịch vụ mạng QoS có ít ảnh hưởng hơn, H.264 hoạt động tốt hơn các codec khác Tuy nhiên, trong trường hợp nhiễu cao hơn, VP8 tạo hoạt động tốt hơn Sự khác biệt MOS đo được nằm trong khoảng [0; 0.5] Giá trị MOS trong trường hợp hội thảo trực tuyến

cũng được nghiên cứu trong [35] Các nhà nghiên cứu đã sử dụng một đoạn video tương tự như đoạn video trong các kịch bản đo trong thí nghiệm của báo cáo này để mô phỏng một cuộc trò chuyện Video được mã hóa ở các độ phân giải và tốc độ bit khác nhau bằng codec H.264 Do đó, các giá trị MOS có sẵn tùy thuộc vào tốc độ bit và độ phân giải của video Dựa trên kết quả từ [33] và [34], chúng ta 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 [35] để tra cứu giá trị KPI 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ị KPI tương ứng được đưa ra 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

Đối với các giá trị tốc độ bit, nếu chúng không nằm giữa các điểm dữ liệu có sẵn thì không có giá trị KPI nào được tính Thay vào đó, các điểm dữ liệu sẽ bị loại bỏ Nếu không có dữ liệu nào cho độ phân giải khung hình đã nhận, thì hàm cho dữ liệu tốt nhất sẽ được lựa chọn

Tốc độ bit (Mbit/s)

Hình 2.7 KPIQvideo phụ thuộc vào tốc độ bit của video và chiều cao hình ảnh

CHƯƠNG 3 KẾT QUẢ ĐO LƯỜNG VÀ ĐÁNH GIÁ 3.1 Phương pháp nghiên cứu

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ố QoE Mục tiêu của các kịch bản này là cung cấp cái nhìn về mức độ cũng như khả năng sử dụng thực tế của dữ liệu do hệ thống cung cấp Ngoài ra, dữ liệu đo lường được đánh giá theo phạm vi giả định, cũng như sự tồn tại của các giá trị đơn lẻ trên tổng QoE Thiết lập đo lường bao gồm các kịch bản thử và các kịch bản này được sử dụng để chạy các kịch bản đo độc lập và có thể lặp lại

3.2 Thiết lập hệ thống thí nghiệm trực tuyến

Đố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 Selenium, 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 Selenium là bộ kiểm thử tự động miễn phí (mã nguồn mở) dành cho các ứng dụng web trên các trình duyệt và nền tảng khác nhau Với bộ công cụ này một phiên họp WEBRTC được bắt đầu tự động và đưa người dùng tham gia vào cuộc gọi

Các phép đo sẽ được táo tạo và độc lập với nhau, một tệp video định dạng y4m

sẽ được đưa vào thay thế cho webcam2 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 sẽ được tạo ra tự động định kì

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

2 https://media.xiph.org/video/derf/y4m

Hình 3.1 Tương tác của các thành phần được cài đặt trên cloud

Nhật ký webrtc-internals là một luồng dữ liệu ghi lại quá trình tham gia cuộc gọi được cung cấp bởi trình duyệt Các tệp được tải xuống bằng webrtc-internals lưu trữ dữ liệu phiên bằng định dạng JSON với các trường được mô tả tại website testrtc3 Ngoài ra phần mềm Network Emulator (NetEm) tích hợp trong hệ điều hành Linux được sử dụng để giả lập các điều kiện mạng internet khác nhau

3.3 Phương pháp thực hiện thí nghiệm và phân tích kết quả

3.3.1 Phương pháp thực hiện thí nghiệm

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 NetEm trong linux Qua đó, các điều kiện mạng khác nhau được giả lập Việc giả lập mạng sẽ cho thấy sự ảnh hưởng của băng thông nê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, mỗi phép đo bao gồm 2 hoặc 3 client có cấu hình giả lập mạng giống hệt nhau và mỗi kịch bản được đo ít nhất 10 lần

3.3.2 Phân tích kết quả

Bộ phân tích cú pháp dữ liệu chịu trách nhiệm xử lý dữ liệu đo lường Nó được bắt đầu sau khi thí nghiệm hoàn tất Đối với mỗi tệp dữ liệu, trình phân tích cú pháp sẽ kiểm tra xem quá trình ICE có thành công hay không Nếu không thành công, toàn

3 https://testrtc.com/webrtc-internals-parameters/

bộ phép đo sẽ bị loại bỏ Đối với các phép đo hợp lệ, dữ liệu của tất cả những người tham gia được tổng hợp và tính toán Sau đó, dữ liệu được phân tích cú pháp và các

giá trị KPI được tính toán được lưu vào tệp csv

3.4 Truyền phát video và âm thanh giữa hai người dùng

Phần này trình bày các quan sát chung từ dữ liệu thu thập được trong quá trình đo với hai client Bằng cách này, chúng ta chỉ ra tiến trình thời gian của một quá trình đo lường để đề xuất các kế hoạch điều chỉnh chất lượng, trong đó điều chỉnh chất lượng âm thanh và video dựa trên băng thông có sẵn

Trong thí nghiệm đầu tiên, băng thông gửi được giới hạn ở 250kbit/s Đối với cuộc hội thoại, nó đại diện cho băng thông thấp Phép đo thứ hai được thực hiện với băng thông khả dụng là 50Mbit/s Nó đại diện cho băng thông cao Việc đánh giá hiệu năng của mỗi cấu hình trình sẽ được tách ra các phiên truyền video và audio riêng

3.4.1 Chi tiết kỹ thuật của phiên

Dữ liệu của các phép đo cho thấy, các phiên có hai người tham gia có thể đượ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 do Jitsi Meet cung cấp

Do đó, cả hai máy khách đều sử dụng máy chủ chuyển tiếp để trao đổi dữ liệu âm thanh và video 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 Đôi khi kết nối không bao giờ chuyển từ giai đoạn RELAY sang giai đoạn P2P Điều này có thể xảy ra khi tường lửa chặn các kết nối trực tiếp giữa hai máy khách này

3.4.2 Video

Trong phần dưới đây, các phiên đơn lẻ được khảo sát để phân tích chi tiết các thông số và cài đặt được sử dụng bởi các phiên phát trực tuyến WebRTC Chúng ta sẽ phân tích các thông tin liên quan đến quá trình phát video tại phía người dùng đầu cuối về độ phân giải và tốc độ bit Để phân biệt rõ ràng giữa kết nối P2P và RELAY chúng ta sử dụng hai mẫu hiệu năng mạng khác nhau Một là kịch bản băng thông

khả dụng thấp, trong khi kịch bản thứ hai tương ứng với một băng thông cao Tất cả các nhóm đều có bố cục 4 biểu đồ lưới 2x2 giống nhau Đối với mỗi hai biểu đồ trong

nhóm 4 biểu đồ trên, trục x mô tả thời gian tính bằng giây kể từ khi bắt đầu giai đoạn tương ứng của phiên Tổng cộng các trục x cho một hàng ngang biểu thị toàn bộ thời lượng đo là 120 giây Trục y bên trái của các biểu đồ thể hiện các tham số được liệt

kê trong chú giải phí bên dưới biểu đồ Các thông số khác được hiển thị trong chú

giải thứ hai ở góc trên bên phải của các biểu đồ được mô tả bởi trục y bên phải Trong

nhóm 4 biểu đồ theo lưới 2x2 thì hai biểu đồ cùng hàng cho thấy các tham số truyền của máy khách 1 (Client 1) trong hai phiên RELAY và P2P lần lượt từ trái sang phải, còn hai biểu đồ cùng một cột theo chiều dọc cho hiển thị các tham số tại quá trình gửi (biểu đồ trên) và quá trình nhận (biểu đồ dưới)

Cấu hình Băng thông thấp

Hình 3.2 mô tả thống kê cho các luồng video đã gửi trong quá trình giao tiếp RELAY và P2P trong kịch bản với giới hạn băng thông là 250 kbit/s Hàng trên hiển thị dữ liệu cho luồng video đã gửi, trong khi dòng dưới mô tả luồng video từ phía người nhận Hình 3.2a cho thấy trong quá trình giao tiếp RELAY, luồng video được gửi đi có độ phân giải 320 px × 180 px với tốc độ bit thay đổi giữa 0 kbit/s tới 240 kbit/s Tốc độ khung hình thay đổi ở trong khoảng 30 đến 60fps trong toàn bộ thời gian của giai đoạn RELAY

Sau khoảng 17 giây, máy khách chuyển từ sử dụng máy chủ RELAY sang giao tiếp trực tiếp Hình 3.2b cho thấy các thông số video của luồng video đã gửi trong giai đoạn thứ hai của phiên WebRTC Có thể thấy, đối với độ phân giải khung hình, nhiều bước điều chỉnh được tiến hành Khi bắt đầu kết nối, máy khách sẽ gửi một luồng video có kích thước 1280px×720px Tuy nhiên sau đó độ phân giải điều chỉnh được giảm xuống 320px×180px Vào đầu phiên, tốc độ khung hình tối đa là khoảng 25fps Bắt đầu từ điểm giảm độ phân giải thứ hai, tốc độ khung hình tăng lên Sau khi độ phân giải ở mức tối thiểu tốc độ khung hình sau đó đạt đến tối đa là 60fps, khớp với video nguồn Trong khi quá trình điều chỉnh độ phân giải diễn ra, có nhiều

biến thể về tốc độ khung hình Sau đó có vài sự chập chờn về tốc độ khung hình diễn ra khi tốc độ khung hình giảm về 0fps

a Sent video using RELAY b Sent video using P2P

c Received video using RELAY d Received video using P2P

Hình 3.2 Các thông số cho luồng video ở môi trường băng thông thấp

Hình 3.2c mô tả các tham số của khung hình cho luồng nhận được trong giai đoạn RELAY, trong khi hình 3.2d hiển thị dữ liệu từ giai đoạn P2P Tương tự như luồng đã gửi, luồng nhận được của pha RELAY có kích thước khung hình không đổi là 320px×180px So sánh tốc độ khung hình và tốc độ bit, có thể nhận thấy sự khác biệt Mặc dù người gửi gửi tốc độ khung hình không quá 60fps tuy nhiên phía người nhận lại nhận được tốc độ khung hình thay đổi có khi lại vượt trên 60fps

Dữ liệu cho luồng video nhận được sau khi chuyển sang giao tiếp P2P có thể được nhìn thấy trong hình 3.2d Tương tự như luồng đã gửi, video nhận được bắt đầu với độ phân giải 1280px×720px sau đó được xuống độ phân giải 320px×180px Tuy

nhiên, so với luồng đã gửi, mức độ phân giải cao nhất được duy trì trong thời gian dài hơn Tỷ lệ khung hình cũng tồn tại khác nhau Độ phân giải cũng cho thấy sự khác biệt rõ rệt Thời gian đạt số khung hình cao bị giảm đi đáng kể Cũng đáng chú ý là có một hiện tượng tương tự so với pha RELAY đó là có sự đạt độ cao bất thường của tốc độ khung hình tại một số thời điểm Mặc dù tốc độ khung hình gửi đi có giá trị cao nhất chỉ đạt 60fps tuy nhiên tại phía đầu ra có những thời điểm đạt trên 64fps

Cấu hình Băng thông cao

Hình 3.3 hiển thị các thông số khung cho cả hai kết nối của phép đo mẫu với băng thông khả dụng là 50Mbit/s Có thể thấy khi so sánh hình 3.2a và hình 3.3a Đối với cả hai băng thông, luồng video đã gửi có độ phân giải và tốc độ khung hình không đổi Hai phiên cho thấy sự chênh lệch về giá trị tuyệt đối Với băng thông khả dụng là 50Mbit/s, video được gửi có độ phân giải là 960px×540px Trong trường hợp băng thông 250kbit/s độ phân giải liên tục là 320px×180px Sự khác biệt tương tự cũng áp dụng cho tốc độ bit đã gửi

Sau khi chuyển sang giao tiếp P2P, máy khách sẽ bắt đầu bằng cách gửi video có độ phân giải 1280px × 720px Trái ngược với vấn đề băng thông thấp, máy khách duy trì độ phân giải cao này trong gần như toàn bộ phiên nó chỉ chuyển sang độ phân giải thấp hơn 960px × 540px Tốc độ khung hình được gửi gần như không đổi ở mức 60fps chỉ với độ lệch tối thiểu

Hình 6.2b cho thấy mối tương quan giữa độ phân giải đã gửi và tốc độ bit đã gửi Với độ phân giải 1280px × 720px, tốc độ bit vào khoảng 2.5Mbit/s Sau khi giảm độ phân giải, nó được giảm xuống khoảng 2.0Mbit/s So sánh giữa giai đoạn RELAY và giai đoạn P2P, có thể thấy rằng có sự khác biệt trong tốc độ bit được gửi ở các độ phân giải giống hệt nhau Trong giai đoạn RELAY, máy khách gửi khoảng 1.5Mbit/s dữ liệu video với độ phân giải 960px × 540px mất khoảng 20s sau giây thứ 40 Sau khi chuyển sang giao tiếp P2P, tốc độ bit được tăng lên trên 2.0Mbit/s sử dụng cùng độ phân giải Điều này chỉ ra rằng máy khách giảm tốc độ bit dựa trên loại giao tiếp Có thể tốc độ bit được giảm xuống để giảm lượng lưu lượng truy cập được tạo ra tại máy chủ TURN