Luận án tiến sĩ một số giải pháp nâng cao chất lượng streaming thích ứng video trên nền giao thức HTTP

Đặc điểm chính của công nghệ này là khả năng thayđổi tốc độ bit video theo sự biến động của thông lượng mạng và theo khả năngcủa máy khách độ phân giải màn hình, lượng video còn lại tron

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

NGUYỄN THỊ KIM THOA

MỘT SỐ GIẢI PHÁP NÂNG CAO CHẤT LƯỢNG STREAMING THÍCH ỨNG VIDEO

TRÊN NỀN GIAO THỨC HTTP

LUẬN ÁN TIẾN SĨ KỸ THUẬT VIỄN THÔNG

HÀ NỘI - 2019

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

NGUYỄN THỊ KIM THOA

MỘT SỐ GIẢI PHÁP NÂNG CAO CHẤT LƯỢNG STREAMING THÍCH ỨNG VIDEO

TRÊN NỀN GIAO THỨC HTTP

LUẬN ÁN TIẾN SĨ KỸ THUẬT VIỄN THÔNG

Ngành: KỸ THUẬT VIỄN THÔNG

Mã số: 9520208

NGƯỜI HƯỚNG DẪN KHOA HỌC:

PGS.TS PHẠM NGỌC NAM

HÀ NỘI - 2019

Tôi xin cam đoan rằng các kết quả khoa học được trình bày trong quyểnluận án này là kết quả nghiên cứu của bản thân tôi trong suốt thời gian làmnghiên cứu sinh và chưa từng xuất hiện trong công bố của các tác giả khác.Các tài liệu tham khảo đều được trích dẫn đầy đủ, rõ ràng và trung thực.

Hà Nội, ngày tháng năm 2019

Trước hết, tôi xin bày tỏ lời cảm ơn sâu sắc tới PGS.TS Phạm Ngọc Nam,người không chỉ hướng dẫn trực tiếp về mặt khoa học mà còn hỗ trợ về mọi mặt

để tôi có thể hoàn thành luận án này Tôi cũng xin gửi lời cảm ơn chân thành đếnPGS.TS Trương Công Thắng và TS Lê Thái Hưng ở đại học Aizu, Fukushima,Nhật Bản, những người luôn cho tôi sự hỗ trợ kịp thời về mặt chuyên môn trongsuốt thời gian nghiên cứu vừa qua Cảm ơn các thành viên nhóm HTTP củaLab ESRC đã hỗ trợ và cùng tôi thực hiện một số thí nghiệm trong luận án.Qua đây, tôi cũng xin cảm ơn Viện Điện tử Viễn thông, Phòng Đào tạo,Trường Đại học Bách Khoa Hà Nội đã tạo mọi điều kiện thuận lợi cho tôi trongquá trình học tập nghiên cứu

Cuối cùng, tôi xin dành những lời yêu thương nhất đến gia đình tôi Sự độngviên, giúp đỡ và hi sinh của họ là động lực mạnh mẽ giúp tôi hoàn thành luận

án này

Tôi xin chân thành cảm ơn!

Hà Nội, ngày tháng năm 2019

MỤC LỤC

DANH MỤC CÁC TỪ VIẾT TẮT iv

DANH MỤC HÌNH VẼ vi

DANH MỤC BẢNG viii

MỞ ĐẦU 1

Chương 1 TỔNG QUAN VỀ CÔNG NGHỆ HAS VÀ KHẢO SÁT CÁC NGHIÊN CỨU LIÊN QUAN 9

1.1 Giới thiệu chương 9

1.2 Tổng quan về công nghệ HAS 9

1.2.1 Giải thích thuật ngữ 9

1.2.2 Công nghệ streaming video 9

1.2.3 Công nghệ HAS 15

1.2.4 Các yếu tố ảnh hưởng đến QoE trong HAS 19

1.2.5 Tối đa hóa QoE trong HAS 21

1.3 Khảo sát các giải pháp cải thiện QoE trong HAS 22

1.3.1 Các giải pháp thích ứng cho streaming một video 22

1.3.2 Các giải pháp thích ứng cho streaming đồng thời nhiều video 24

1.3.3 Các giải pháp thích ứng cho streaming qua HTTP/2 25

1.4 Kết luận chương 27

Chương 2 CẢI THIỆN QoE TRONG STREAMING THÍCH ỨNG VIDEO DẠNG VBR QUA HAS SỬ DỤNG SDP 28

2.1 Giới thiệu chương 28

2.2 Ý tưởng sử dụng SDP trong streaming thích ứng 28

2.3 Mô hình hóa hệ thống để áp dụng SDP 30

2.3.1 Rời rạc hóa băng thông 30

2.3.2 Rời rạc hóa bộ đệm 31

i

2.4 Mô tả vấn đề và giải pháp 31

2.4.1 Trạng thái hệ thống 31

2.4.2 Xác suất chuyển trạng thái 32

2.4.3 Hàm chi phí 34

2.4.4 Giải pháp tìm tập chính sách tối ưu 35

2.5 Dự đoán các thông số ảnh hưởng đến QoE 36

2.5.1 Dự đoán mức chất lượng video 37

2.5.2 Dự đoán sự nhảy mức chất lượng 37

2.5.3 Dự đoán mức sử dụng bộ đệm 37

2.6 Thực nghiệm và đánh giá 38

2.6.1 Cài đặt thực nghiệm 38

2.6.2 Đánh giá thực nghiệm 39

2.7 Kết luận chương 45

Chương 3 GIẢI PHÁP PHÂN BỔ BĂNG THÔNG VÀ CẢI THIỆN QoE TRONG STREAMING ĐỒNG THỜI NHIỀU VIDEO VBR QUA HAS 46

3.1 Giới thiệu chương 46

3.2 Mô hình thỏa hiệp giữa chất lượng cảm nhận và độ trễ 46

3.3 Giải pháp cải thiện QoE trong streaming đồng thời nhiều video VBR qua HAS 50

3.3.1 Mô tả vấn đề 50

3.3.2 Giải pháp phân bổ băng thông và thích ứng chất lượng 52

3.3.3 Kết quả thực nghiệm và đánh giá 56

3.4 Kết luận chương 61

Chương 4 ỨNG DỤNG TÍNH NĂNG SERVER PUSH CỦA HTTP/2 ĐỂ CẢI THIỆN QoE TRONG STREAMING VIDEO VBR/CBR QUA HAS 62

4.1 Giới thiệu chương 62

4.2 Giải pháp cải thiện QoE trong streaming video VBR qua HTTP/2 63 4.2.1 Giải pháp thích ứng chất lượng 63

4.2.2 Kết quả thực nghiệm và đánh giá 67

4.3 Một cách sử dụng hiệu quả tính năng Server Push 73

4.3.1 Mô tả chung 73

4.3.2 Thuật toán thích ứng chất lượng 75

4.3.3 Thực nghiệm và đánh giá kết quả 77

4.4 Kết luận chương 87

KẾT LUẬN 88 DANH MỤC CÁC CÔNG TRÌNH ĐÃ CÔNG BỐ CỦA LUẬN ÁN 90

Viết tắt Tên tiếng Anh Tên tiếng Việt

CDN Content Delivery Networks Mạng phân phối nội dung

CDF Cumulative Distribution Function Hàm phân phối tích lũy

CPU Central Procession Unit Đơn vị xử lý trung tâm

CSM Conventional Streaming Method Phương pháp streaming thông thườngDASH Dynamic Adaptive Streaming Streaming thích ứng động

HAS HyperText Transimission Streaming thích ứng qua

Protocol Adaptive Streaming giao thức HTTP

HDS HTTP Dynamic Streaming Streaming động qua HTTP được

developed by Adobe Systems phát triển bởi hệ thống Adobe

HLS HTTP Live Streaming developed Streaming trực tiếp qua HTTP

HTTP HyperText Transfer Protocol Giao thức truyền siêu văn bản

IETF Internet Engineer Task Force Lực lượng quản lý kỹ thuật

IPTV Internet Protocol Television Truyền hình giao thức Internet

ITU International Telecommunication Liên hiệp viễn thông quốc tế

Union

MPD Media Presentation Description Mô tả trình diễn phương tiện

MPEG Moving Picture Expert Group Nhóm chuyên gia hình ảnh động

MSS Microsoft Siverlight Smooth Streaming mượt trên ứng dụng

iv

Siverlight được phát triểnbởi Microsoft

NAT Network Address Translation Dịch địa chỉ mạng

NP Non-deterministic Polynomial-time Bất định trong thời gian đa thức

PSNR Peak Signal-to-Noise Ratio Tỉ số tín hiệu trên nhiễu

RTCP Real-Time Control Protocol Giao thức điều khiển thời gian thựcRTP Real-time Transport Protocol Giao thức truyền tải thời gian thựcRTSP Real-Time Streaming Protocol Giao thức streaming thời gian thực

SAND Server and Network Assisted DASH Máy chủ và mạng hỗ trợ DASHSDP Stochastic Dynamic Programming Lập trình động ngẫu nhiên

TCP Transmission Control Protocol Giao thức điều khiển truyền vậnUDP User Datagram Protocol Giao thức gói dữ liệu người dùng

XML Extensible Markup Language Ngôn ngữ đánh dấu mở rộng

1.1 Tốc độ bit của video dạng VBR 12

1.2 Hệ thống HAS 16

1.3 Sơ đồ khối của máy khách HAS 17

1.4 Bộ đệm của máy khách HAS 19

1.5 Các yếu tố ảnh hưởng đến QoE trong HAS 20

2.1 Tốc độ bit của các mức chất lượng khác nhau của video Tokyo Olympic [103] 29

2.2 Băng thông trước và sau khi rời rạc hóa với W = 10 30

2.3 Mô hình băng thông Markov-Chain gồm W trạng thái 31

2.4 Rời rạc hóa bộ đệm 31

2.5 Minh họa sự chuyển trạng thái hệ thống 32

2.6 Test-bed dùng cho thực nghiệm 38

2.7 Băng thông dùng cho đánh giá sự thích ứng 40

2.8 Kết quả thích ứng của các giải pháp 41

2.9 Mức sử dụng bộ đệm của các giải pháp 42

2.10 Hàm phân phối tích lũy (CDF) của hai băng thông bw1 và bw2 43

3.1 Minh họa tốc độ bit R với độ trễ ban đầu d0 47

3.2 Hệ thống streaming nhiều video 51

3.3 Đường cong lồi L0[i] của L[i]. 54

3.4 Minh họa một số lần cải thiện chất lượng cho hai video dựa vào tỉ số α . 55

3.5 So sánh giá trị lợi ích trung bình của phương pháp đề xuất và phương pháp CSM 58

3.6 So sánh tổng băng thông sử dụng của phương pháp đề xuất và phương pháp CSM 59

3.7 Thời gian chạy của thuật toán đề xuất so với thuật toán vét cạn 60

3.8 Thời gian chạy của thuật toán đề xuất 60

vi

4.1 Test-bed dùng cho thực nghiệm 67

4.2 Tốc độ bit của các mức chất lượng video 68

4.3 Băng thông sử dụng trong thực nghiệm 68

4.4 Kết quả thích ứng của giải pháp Push-1, Push-2 và Push-3 70

4.5 Kết quả thích ứng của giải pháp Push-4, AGG và giải pháp đề xuất 71 4.6 Mức sử dụng bộ đệm của giải pháp đề xuất so với Push-N và AGG 72 4.7 Cơ chế hoạt động của tính năng Server Push trong giải pháp đề xuất 73 4.8 Test-bed dùng cho thực nghiệm 78

4.9 Băng thông dùng trong thí nghiệm [67] 79

4.10 Kết quả thích ứng của tất cả các phương pháp 80

4.11 Mức sử dụng bộ đệm của tất cả các phương pháp 81

4.12 Đánh giá ảnh hưởng của RTT đối với chất lượng hình ảnh video và số lượng truy vấn 84

4.13 Đánh giá ảnh hưởng của RTT đối với bộ đệm 85

1.1 Các loại streaming video 10

1.2 Video CBR 12

2.1 Thống kê kết quả thích ứng 42

2.2 Ngữ cảnh sử dụng một băng thông có sẵn 43

2.3 Ngữ cảnh dùng các lưu lượng lịch sử 43

2.4 Ngữ cảnh tái tính toán trên mỗi phiên với V max = 9 44

2.5 Ngữ cảnh tái tính toán trên mỗi phiên với V max = 8 45

2.6 Ngữ cảnh tái tính toán trên mỗi phiên với V max = 7 45

3.1 Ký hiệu và định nghĩa 54

3.2 Các thông tin được lưu tại máy chủ của video Silence of the Lambs 57 3.3 Phân bổ băng thông và lựa chọn mức chất lượng cho từng video trong phương pháp đề xuất 58

3.4 Tổng băng thông sử dụng và lợi ích trung bình của người dùng trong thuật toán đề xuất và thuật toán vét cạn 59

4.1 Ký hiệu và định nghĩa 64

4.2 Thống kê kết quả thích ứng của giải pháp đề xuất so với Push-N và AGG 69

4.3 Thống kê kết quả thích ứng khi thực nghiệm trên một băng thông và một giá trị RTT 82

4.4 Kết quả thích ứng trung bình khi thực nghiệm trên 20 băng thông khác nhau 86

viii

1 Tính cấp thiết của luận án

Hiện nay, streaming video đang trở thành một dịch vụ chính trên mạng net nhờ có các kết nối không dây băng thông rộng và các thiết bị di động hiệusuất cao Theo dự báo gần đây [95], đến năm 2021, lưu lượng video sẽ chiếm 82%tổng lưu lượng được sử dụng trên mạng Internet Kênh Youtube tạo ra hàng tỉlượt xem cho hơn một tỉ người dùng trên toàn cầu mỗi ngày [119] Nhiều sự kiệnthể thao lớn như thế vận hội Olympic và cúp bóng đá thế giới được truyền trựctiếp trên mạng Internet với độ trễ chỉ một vài giây [47]

Inter-Mặc dù vậy, Internet không được thiết kế để dành riêng cho streaming video.Thách thức chính của streaming video qua Internet là sự biến động của thônglượng gây ra bởi các mạng không đồng nhất Sự biến động này dẫn đến khôngthể phát video với tốc độ bit cố định trong suốt một phiên streaming Do đó, cácchuẩn streaming video được phát triển từ năm 2008 được dựa trên công nghệstreaming thích ứng [89] Đặc điểm chính của công nghệ này là khả năng thayđổi tốc độ bit video theo sự biến động của thông lượng mạng và theo khả năngcủa máy khách (độ phân giải màn hình, lượng video còn lại trong bộ đệm (cònđược gọi là mức sử dụng bộ đệm))

Những năm qua, kỹ thuật phổ biến cho streaming video qua mạng Internet làstreaming thích ứng qua giao thức truyền siêu văn bản, viết tắt là HAS [11, 100]

So sánh với các cách tiếp cận khác sử dụng giao thức truyền tải thời gian thực(RTP)/giao thức điều khiển thời gian thực (RTCP)/giao thức streaming thờigian thực (RTSP) [87, 88], việc sử dụng giao thức truyền siêu văn bản (HTTP)[12, 28] mang lại một số thuận lợi như sau:

• Lợi ích quan trọng của HAS là hiệu quả về chi phí Do sử dụng HTTP, nhàcung cấp dịch vụ streaming có thể giảm chi phí bằng việc duy trì các máychủ Web chuẩn thay vì các máy chủ chuyên biệt đắt tiền

• Sử dụng HTTP, HAS tận dụng cơ sở hạ tầng mạng phân phối rộng lớn banđầu được tạo ra cho lưu lượng truy cập Web

1

• Khi dùng HAS, các gói tin media có thể truyền qua tường lửa và bộ dịchđịa chỉ mạng (NAT) dễ dàng.

Do những lợi thế này, HAS được các ứng dụng streaming lớn hiện nay ápdụng bao gồm Netflix, Youtube, Hulu và Amazon Instant Video

Năm 2012, chuẩn toàn cầu có tên là MPEG-DASH ra đời cho phép máy kháchthay vì máy chủ sẽ là thành phần đưa ra quyết định trong việc thích ứng chấtlượng video Cụ thể, nhà cung cấp dịch vụ sẽ tạo ra nhiều mức chất lượng (phiênbản video) từ một video gốc Mỗi mức chất lượng video được chia nhỏ thànhcác phân đoạn Độ dài mỗi phân đoạn thường trong khoảng từ 2 đến 10 giây[72, 100] Trong phiên streaming, một giải pháp thích ứng chất lượng video đặttại máy khách có nhiệm vụ quyết định mức chất lượng nên được truy vấn chomỗi phân đoạn dựa vào khả năng của máy khách và tình trạng của mạng.Năm 2014, phiên bản thứ hai của chuẩn MPEG-DASH ra đời và hiện tại,các chuyên gia MPEG đang hướng tới phiên bản thứ ba cho streaming video đahướng Hiện tại, chưa có chuẩn nào chỉ ra việc thích ứng chất lượng video trongHAS nên được thực hiện như thế nào nhằm nâng cao chất lượng trải nghiệm(QoE) của người dùng Vì vậy, việc nghiên cứu và đề xuất các giải pháp cải thiệnQoE trong HAS đang thu hút sự quan tâm nghiên cứu của cộng động khoa học.Tại thời điểm bắt đầu luận án này, đã có một số nghiên cứu liên quan đếnQoE trong HAS [43, 78, 92, 121] Tuy nhiên, các nghiên cứu này vẫn chưa thực

sự hiệu quả trong việc cải thiện QoE, đặc biệt là trong bối cảnh streaming videoqua mạng di động với thông lượng mạng thường biến động mạnh theo thời gian.Được thúc đẩy bởi tiềm năng chưa được khai thác hết của công nghệ HAS vànhu cầu mạnh mẽ của streaming video qua mạng di động những năm gần đây,luận án đề xuất các giải pháp thích ứng chất lượng video trên nền HTTP để đốiphó hiệu quả với sự biến động của thông lượng mạng, từ đó nâng cao QoE củangười dùng

2 Những vấn đề còn tồn tại

Cho đến nay, các giải pháp nâng cao QoE trong streaming thích ứng videotrên nền HTTP đều tập trung vào hai ngữ cảnh chính: streaming một video[14, 27, 65, 67, 94, 116, 122, 125] và streaming đồng thời nhiều video [3, 6, 16,

18, 75, 77, 106, 120] Hầu hết các giải pháp trên chỉ tập trung vào video được

mã hóa với tốc độ bit không đổi (CBR) Các nghiên cứu về streaming thích ứng

đối với video được mã hóa với tốc độ bit biến đổi (VBR) còn rất hạn chế Đặcđiểm của video dạng CBR là tốc độ bit của các phân đoạn video trong cùngmột mức chất lượng là cố định, dẫn đến việc thích ứng chất lượng tương đối đơngiản Tuy nhiên, video được hiển thị trên màn hình người dùng có chất lượnghình ảnh không ổn định So với video dạng CBR, video dạng VBR mang lạichất lượng hình ảnh ổn định hơn Tuy nhiên, sự biến động mạnh của tốc độ bitvideo VBR trong một mức chất lượng cùng với sự biến động mạnh của thônglượng mạng là thách thức lớn trong HAS Chính vì vậy, streaming một videodạng VBR và streaming đồng thời nhiều video dạng VBR qua HAS là xu hướngnghiên cứu mới thu hút sự quan tâm của các nhà khoa học.

Hiện tại, HTTP/1.1 là giao thức phổ biến trong HAS với cơ chế hoạt độngchính là truy vấn-phản hồi Cụ thể, sau khi tải xong từng phân đoạn video, máykhách gửi một truy vấn tới máy chủ để yêu cầu một mức chất lượng phù hợpcho phân đoạn video tiếp theo Sau đó, máy chủ phản hồi bằng cách gửi phânđoạn video với mức chất lượng tương ứng cho máy khách Thông thường, cácphân đoạn video có độ dài bằng nhau và nằm trong khoảng từ 2 giây đến 10giây [72, 100]

Rõ ràng, phân đoạn video càng dài thì cần ít truy vấn hơn dẫn đến giảmoverhead, cho nên thông lượng tổng thể sẽ cao hơn so với phân đoạn video ngắn[68] Tuy nhiên, nhược điểm của phân đoạn video dài là làm tăng độ trễ nạp bộđệm ban đầu Hơn nữa, máy khách chỉ có thể thích ứng với sự biến động củamạng khi nó nhận được hết một phân đoạn Khi đó, phân đoạn dài sẽ làm máykhách thích ứng chậm với sự biến động của mạng, dẫn đến bộ đệm không ổnđịnh [51, 68]

Giải pháp đơn giản để máy khách thích ứng nhanh hơn với tình trạng mạng

là sử dụng phân đoạn video ngắn Khi đó, số lượng truy vấn của máy kháchgửi đến máy chủ sẽ tăng Overhead liên quan đến truy vấn, đặc biệt khi phânđoạn video ngắn đã được quan tâm trong một số nghiên cứu gần đây [109, 110]

Cụ thể, máy khách gửi càng nhiều truy vấn thì năng lượng tiêu thụ của thiết

bị di động càng nhiều Hơn nữa, đối với mỗi truy vấn, máy khách cần đợi mộtkhoảng thời gian trễ trọn vòng (RTT) trước khi bắt đầu nhận phân đoạn video.Bên cạnh đó, mặc dù có kích thước nhỏ, mỗi truy vấn đều phải được xử lý bởicác nút mạng (chẳng hạn proxy, cache, máy chủ) Do vậy, với một số lượng truyvấn lớn sẽ tiêu tốn nhiều năng lượng của thiết bị, giảm thông lượng tổng thể và

tăng độ phức tạp xử lý tại các nút mạng [109].

Gần đây, một phiên bản mới của giao thức HTTP được đề xuất, gọi làHTTP/2, mang nhiều tính ưu việt hơn so với HTTP/1.1 [13] HTTP/2 giớithiệu một số tính năng mới trong đó có tính năng Server Push Tính năng nàycho phép máy chủ đẩy nhiều phân đoạn video liên tiếp với cùng một mức chấtlượng cho mỗi truy vấn của khách Do đó, phân đoạn video ngắn được dùng màkhông cần quá nhiều truy vấn Do những lợi ích mà tính năng Server Push củaHTTP/2 mang lại cho streaming video, các giải pháp thích ứng chất lượng sửdụng tính năng này đang thu hút sự quan tâm và đầu tư nghiên cứu

3 Mục tiêu nghiên cứu

Xuất phát từ những phân tích ở trên, luận án tập trung thực hiện các mục tiêuchính sau đây:

• Đề xuất và thực hiện thuật toán thích ứng chất lượng, đề xuất các môhình toán học để dự đoán các thông số ảnh hưởng đến QoE trong ngữ cảnhstreaming video VBR trên nền giao thức HTTP nhằm cải thiện QoE

• Đề xuất và thực hiện thuật toán thích ứng chất lượng khi streaming đồngthời nhiều video VBR qua một đường truyền có băng thông hạn chế (nút

cổ chai) trên nền giao thức HTTP nhằm cải thiện QoE, trong sự ràng buộc

về giới hạn băng thông và độ trễ

• Đề xuất và thực hiện các thuật toán thích ứng chất lượng khi streamingvideo VBR/CBR qua HTTP/2 nhằm cải thiện QoE và giảm overhead liênquan đến số lượng truy vấn của máy khách

4 Phạm vi nghiên cứu

Các nghiên cứu của luận án được giới hạn trong phạm vi dưới đây:

• Streaming video chia thành 2 nhóm chính là streaming tương tác và ing không tương tác Luận án chỉ tập trung vào streaming không tương táctrong đó máy khách một chiều nhận video từ máy chủ

stream-• Tập trung vào streaming video theo yêu cầu (VoD), không quan tâm đếnstreaming trực tiếp

• Thực hiện các giải pháp tại lớp ứng dụng, không can thiệp vào các lớp dướicủa lớp ứng dụng.

• Thực hiện các thuật toán thích ứng chất lượng trong streaming video, khôngquan tâm đến quá trình mã hóa và giải mã dữ liệu video

• Tập trung vào giai đoạn streaming thực sự (máy khách nhận và hiển thị dữliệu một cách đồng thời), không tập trung vào giai đoạn nạp bộ đệm banđầu

• Tỉ lệ mất gói được thiết lập là 0%, giả sử rằng băng thông được dùng trongthực nghiệm đã bao gồm sự biến động gây ra bởi sự mất gói, trễ gói dữ liệu

5 Những đóng góp của luận án

Luận án đã đạt được các kết quả nghiên cứu và đóng góp chính như sau:

• Trong đóng góp đầu tiên, luận án đề xuất một giải pháp thích ứng chấtlượng khi streaming video dạng VBR qua giao thức HTTP dựa vào lậptrình động ngẫu nhiên (SDP) Giải pháp đề xuất có thể ứng phó tốt với sựbiến động mạnh của thông lượng mạng cũng như sự biến động mạnh củatốc độ video dạng VBR Ngoài ra, luận án phát triển các mô hình toán học

để dự đoán các thông số ảnh hưởng đến QoE trước mỗi phiên Thực nghiệmcho thấy (i) giải pháp đề xuất mang lại QoE tốt hơn so với một số giải phápstreaming video dạng VBR hiện tại, (ii) kết quả dự đoán các thông số ảnhhưởng đến QoE bằng mô hình toán gần với các thông số được đo đạc từ môphỏng thực nghiệm

Kết quả được công bố trên các công trình [C1][J1]

• Trong đóng góp thứ hai, luận án đề xuất một giải pháp thích ứng chấtlượng khi streaming đồng thời nhiều video VBR qua một đường truyền cóbăng thông hạn chế Trong đề xuất này, một thành phần trong mạng (nhưproxy, cache) có nhiệm vụ phân bổ băng thông và lựa chọn mức chất lượngvideo phù hợp cho từng máy khách Thực nghiệm được thực hiện trong thờigian thực cho thấy giải pháp đề xuất cung cấp cho từng máy khách mứcchất lượng video sao cho tối đa hóa QoE, trong điều kiện ràng buộc về tổnglượng băng thông của đường truyền và giới hạn của độ trễ

Kết quả được công bố trên công trình [C2],[J4]

• Trong đóng góp thứ ba, luận án lần đầu tiên đề xuất giải pháp thích ứngchất lượng cho streaming video dạng VBR qua HTTP/2 Ngoài ra, luận

án cũng đề xuất một cách tiếp cận mới sử dụng tính năng Server Pushcủa HTTP/2 cho streaming video dạng CBR Trong cách tiếp cận này, máykhách gửi truy vấn đến máy chủ để quyết định mức chất lượng cho các phânđoạn sắp tải về, không quyết định số lượng phân đoạn video cho mỗi truyvấn Sau khi nhận được truy vấn của máy khách, máy chủ đẩy liên tiếp cácphân đoạn video về máy khách cho đến khi nó nhận được truy vấn mới yêucầu một mức chất lượng khác của máy khách Kết quả mô phỏng cho thấygiải pháp đề xuất cung cấp tốc độ bit video cao, ít sự biến động chất lượng,

bộ đệm ổn định, đồng thời giảm đáng kể overhead liên quan đến lượng truyvấn của máy khách

Kết quả được công bố trên các công trình [J2][J3]

6 Bố cục luận án

Trong Chương 1, luận án trình bày các kiến thức tổng quan về công nghệHAS, bao gồm kiến trúc và nguyên lý hoạt động của một hệ thống HAS Chươngnày cũng phân tích chi tiết các yếu tố tác động đến QoE trong HAS Từ đó,luận án chỉ ra các yếu tố quyết định đóng vai trò tối đa hóa QoE Các yếu tốnày được sử dụng để đánh giá các giải pháp đề xuất và so sánh chúng với cácgiải pháp đối sánh trong luận án Ngoài ra, các nghiên cứu liên quan cũng đượckhảo sát kỹ lưỡng, tạo tiền đề cho việc đề xuất các giải pháp cải thiện QoE đượcthể hiện trong Chương 2, Chương 3 và Chương 4

Trong Chương 2, luận án đề xuất một giải pháp thích ứng chất lượng dựatrên SDP khi streaming video VBR trên nền giao thức HTTP Chương này cũng

đề xuất các mô hình toán học để dự đoán trước các thông số ảnh hưởng đếnQoE, bao gồm các yếu tố như mức chất lượng trung bình, mức sử dụng bộ đệmtrung bình, sự biến động mức chất lượng và xác suất video bị gián đoạn Thựcnghiệm được triển khai để đánh giá giải pháp thích ứng chất lượng được đề xuấtđồng thời đánh giá độ chính xác của các thông số ảnh hưởng đến QoE được dựđoán bằng mô hình toán so với các thông số được đo đạc từ thực nghiệm Đónggóp của chương này được công bố trong hội nghị và tạp chí quốc tế sau:

[J1] Thoa Nguyen, Thang Vu, Nam Pham Ngoc, Truong Cong Thang,

"SDP-based Quality Adaptation and Performance Prediction in Adaptive Streaming

of VBR Videos", Journal of Advances in Multimedia (Scopus), Volume 2017, pp.1-12.

[C1] "SDP-based Adaptation for Quality Control in Adaptive Streaming",International Conference on Communications, Management and Telecommuni-cations (ComManTel), Danang, Vietnam, pp 194-199, 2015

Trong Chương 3, luận án đề xuất giải pháp thích ứng chất lượng khi streamingđồng thời nhiều video VBR qua một đường truyền có băng thông hạn chế Giảipháp giúp phân bổ băng thông hợp lý và lựa chọn mức chất lượng phù hợp chotừng luồng video nhằm tối đa hóa lợi ích của người dùng, trong giới hạn về băngthông và độ trễ Một thuật toán heuristic được trình bày cho phép giải pháp đềxuất khả thi trong thời gian thực khi số lượng luồng video rất lớn Đóng gópcủa chương này được công bố trong hội nghị quốc tế sau:

[C2] Thoa Nguyen, Thang Vu, Nam Pham Ngoc, Truong Cong Thang "QoE

Optimization for Adaptive Streaming with Multiple VBR Videos", in tional Conference on Communications, Management and Telecommunications(ComManTel), Danang, Vietnam, pp 189-193, 2015

Interna-[J4] Nguyen Thi Kim Thoa, Pham Hong Thinh, Pham Ngoc Nam, 2018,

"QoE Optimization Based on Quality-delay Trade-off Model for Adaptive

Stream-ing with Multiple VBR Videos", The Journal of Science & Technology, 2018,

được chấp nhận đăng

Trong Chương 4, luận án trình bày hai giải pháp thích ứng chất lượng dùngtính năng Server Push của HTTP/2, trong đó một giải pháp được áp dụng chostreaming video dạng CBR và một giải pháp được áp dụng cho streaming videodạng VBR Thực nghiệm được thực hiện để đánh giá các giải pháp đề xuất và

so sánh với một số giải pháp streaming thích ứng qua HTTP/2 đã triển khai.Kết quả thực nghiệm cho thấy các giải pháp đề xuất không những cải thiện QoE

mà còn giảm đáng kể overhead liên quan đến số lượng truy vấn của máy khách.Đóng góp của chương này được công bố trong các tạp chí trong nước và quốc

tế sau:

[J2] Nguyen Thi Kim Thoa, Nguyen Minh, Nguyen Hai Dang, Pham Hong

Thinh, Pham Ngoc Nam, "Adaptation method for streaming of VBR video overHTTP2", Journal of Science and Technology, vol 120, Jun 2017

[J3] Thoa Nguyen, Nguyen Hai Dang, Nguyen Minh, Pham Ngoc Nam,

Hung T Le, Truong Cong Thang, "An Efficient Server Push Approach for

Video Streaming Over HTTP2", IEICE Transaction on Communication (SCI),Vol.E101-B, No.11, 2018.

Cuối cùng là phần kết luận chung, sẽ tóm tắt lại những đóng góp, kết quảcủa nghiên cứu sinh trong luận án này cũng như hướng phát triển trong tươnglai

TỔNG QUAN VỀ CÔNG NGHỆ HAS VÀ KHẢO SÁT CÁC

NGHIÊN CỨU LIÊN QUAN

1.1 Giới thiệu chương

Chương này trình bày ngắn gọn cơ sở lý thuyết nền tảng của công nghệ HAS,các yếu tố tác động đến QoE trong HAS và khảo sát các nghiên cứu liên quanđến cải thiện QoE trong ba ngữ cảnh: streaming một video, streaming đồng thờinhiều video và streaming video qua HTTP/2 Đó là cơ sở, động lực cho những

đề xuất ở các chương tiếp theo của luận án

1.2 Tổng quan về công nghệ HAS

1.2.1 Giải thích thuật ngữ

Phần này giải thích ý nghĩa của một số thuật ngữ được sử dụng trong luận án.Băng thông (bandwidth): Dung lượng lý thuyết của kết nối tại một thời điểm,được tính bằng số bit trên một giây

Thông lượng (throughput): Được đo sau khi nhận được một phân đoạn video.Thông lượng được tính bằng tỉ số giữa kích thước dữ liệu của phân đoạn vàkhoảng thời gian tải phân đoạn đó Khoảng thời gian tải phân đoạn được tính

từ thời điểm máy khách gửi truy vấn cho đến khi nó nhận được byte cuối cùngcủa phân đoạn được truy vấn

Thời gian trọn vòng (RTT): Khoảng thời gian từ lúc máy khách gửi truy vấncho đến khi nó nhận được byte đầu tiên của phân đoạn được truy vấn

Mức sử dụng bộ đệm: Lượng video còn lại trong bộ đệm, thường được tínhbằng đơn vị thời gian

1.2.2 Công nghệ streaming video

Đặc điểm và phân loại

Vào đầu những năm 1990, công nghệ đa phương tiện bắt đầu hình thành và

9

phát triển khi có sự ra đời của các chuẩn quốc tế đầu tiên về nén video nhưH261, MPEG-1 Khi đó, các video được số hóa, mã hóa và lưu trữ dưới dạng cáctệp đặt tại máy chủ Để xem một video, người dùng phải tải tệp đó về máy tính

cá nhân, sau đó video được giải mã và hiển thị trên màn hình Nhược điểm củaphương pháp này là người dùng phải đợi đến khi tải xong video mới xem được,

có khi mất một khoảng thời gian rất dài Hơn nữa, người dùng phải lưu tệpvideo vào máy tính, dẫn đến vấn đề về tài nguyên bộ nhớ Kỹ thuật streamingvideo ra đời đã khắc phục những vấn đề trên Trong streaming video, máy kháchbắt đầu hiển thị video chỉ vài giây sau khi nó bắt đầu nhận dữ liệu từ máy chủ.Nói một cách khác, máy khách vẫn tiếp tục hiển thị video trong khi đang tải nốtnhững phần sau của video Các kỹ thuật streaming video rất đa dạng, thườngđược phân loại theo 5 yếu tố, đó là: yêu cầu về độ trễ, chế độ mã hóa video, giaothức tầng giao vận, tính thích ứng và vị trí khối thích ứng [51] Bảng 1.1 liệt kêchi tiết sự phân loại này

Bảng 1.1: Các loại streaming video

Yêu cầu về độ trễ Tương tác (nhỏ hơn 150ms), trực tiếp (nhỏ hơn 10s), VoD

(không quy định) Dạng mã hóa video Video dạng CBR, video dạng VBR

Giao thức tầng giao vận UDP, TCP

Sự thích ứng Thích ứng, không thích ứng

Vị trí điều khiển thích

ứng Máy chủ, máy khách, thành phần trong mạng, phối hợp

• Phân loại theo yêu cầu về độ trễ Dựa vào yêu cầu về độ trễ, kỹ thuậtstreaming được chia thành ba loại: streaming tương tác, streaming trực tiếp

và streaming theo yêu cầu (VoD) Đặc trưng của phương pháp streamingtương tác và streaming trực tiếp là nội dung video đang được truyền trongkhi sự kiện đang được ghi bởi máy quay, do đó độ trễ thấp là một yêu cầurất quan trọng [46] Một ví dụ điển hình của streaming tương tác là hộithảo truyền hình giữa hai hay nhiều người ở các vị trí địa lý khác nhau,tương tác với nhau Để sự chuyển đổi không làm ảnh hưởng tới người dùng,

độ trễ từ khi một người nói đến khi những người khác nghe thấy nên ít

hơn vài trăm mili giây (ms) Cụ thể, với độ trễ nhỏ hơn 150ms, người dùng

không cảm nhận được [48] Với streaming trực tiếp, chẳng hạn truyền tảimột trận đấu bóng đá đang diễn ra, thì độ trễ từ khi hình ảnh được ghi bởi

máy quay đến khi hiển thị trên màn hình của người dùng nên nhỏ hơn 10giây [49] Ngược lại, với VoD, video được ghi trước và được lưu tại máy chủnên nó không có bất kỳ yêu cầu nào về độ trễ Trừ trường hợp đặc biệt làkhi người dùng thường xuyên chuyển kênh, độ trễ khởi động mỗi kênh cầnphải nhỏ [45].

• Phân loại theo dạng video được mã hóa Hầu hết các bộ mã hóa ngày nayđều kết hợp nén ảnh không gian và bù chuyển động Bù chuyển động là một

kỹ thuật dùng để dự đoán khung hình trước và/hoặc những khung hình

kế tiếp bằng các tính toán chuyển động của máy quay và các chuyển độngtrong video Một dữ liệu đầu vào quan trọng của bộ mã hóa là tham sốlượng tử (QP) định nghĩa lượng thông tin cần loại bỏ từ một khối pixelnhất định (marcoblock) Khi QP rất nhỏ, hầu hết các thông tin đều đượcgiữ lại Khi QP tăng lên, một số thông tin được loại bỏ để giảm tốc độ bit

Vì vậy, QP được coi là tham số đặc trưng cho mức chất lượng của video,

có giá trị nằm trong khoảng từ 0 đến 51 [31] QP càng tăng thì mức chấtlượng của video càng giảm [99]

Với cách mã hóa tốc độ bit biến đổi, còn gọi là VBR, với mỗi mức chấtlượng, QP được giữ cố định còn các khung hình được mã hóa với kích thướckhác nhau tùy thuộc vào nội dung video, làm cho chất lượng video đầu rakhông thay đổi trong khi tốc độ bit video thay đổi một cách tự nhiên Do

đó, việc dự đoán tốc độ bit cho một video dạng VBR là không dễ dàng vàviệc streaming video dạng VBR là một thách thức Hình 1.1 minh họa tốc

độ bit của video Tokyo Olympic [97] với 5 mức chất lượng tương ứng với 5giá trị của tham số lượng tử QP: 24, 28, 34, 38, 42

Một dạng mã hóa video khác được gọi là mã hóa tốc độ bit cố định (CBR).Trong mã hóa CBR, tốc độ bit được giữ cố định trong mỗi mức chất lượngcủa video Bảng 1.2 là một ví dụ về các mức tốc độ bit của một video đượclưu trữ tại Youtube [118] Mã hóa CBR rất hữu ích trong streaming cácnội dung đa phương tiện trên kênh truyền có dung lượng hạn chế vì nó chobiết tốc độ bit chính xác thay vì chỉ biết tốc độ bit trung bình Loại mãhóa này có nhược điểm là phân bổ dữ liệu dư thừa cho những cảnh đơngiản trong video, chẳng hạn như cảnh tĩnh về phong cảnh, đồng thời khôngphân đủ dữ liệu cho những cảnh có nhiều chuyển động nhanh và liên tục,

Hình 1.1: Tốc độ bit của video dạng VBR

cho nên chất lượng video đầu ra không ổn định Tuy nhiên, việc thích ứngchất lượng cho video CBR đơn giản hơn so với video VBR

• Phân loại theo đặc tính thích ứng Với streaming thích ứng, tốc độ bit củavideo được lựa chọn phù hợp với điều kiện mạng, khả năng của máy khách

và ngữ cảnh người dùng nhằm nâng cao QoE Với streaming không thíchứng, người dùng có thể phải trải nghiệm dịch vụ kém chất lượng gây ra bởinhững lần gián đoạn video khi thông lượng mạng biến động mạnh, đặc biệttrong mạng di động

• Phân loại theo vị trí điều khiển thích ứng Trong streaming thích ứng, khốichức năng đóng vai trò thích ứng chất lượng có thể được đặt tại máy chủ,máy khách hoặc một thành phần trong mạng Theo kỹ thuật streamingtruyền thống, khối này được đặt ở máy chủ Tuy nhiên điều này dẫn đến

sự phức tạp tính toán tại máy chủ trong trường hợp có quá nhiều máykhách kết nối tại một thời điểm cũng như hạn chế sự mở rộng quy mô của

hệ thống streaming Do đó, hầu hết các dịch vụ streaming (trừ dịch vụstreaming tương tác) đặt khối thích ứng ở máy khách Ngoài ra, một sốnhóm nghiên cứu đang rất nỗ lực để tạo ra một framework hiệu quả chodịch vụ streaming hướng máy khách được hỗ trợ bởi cả máy chủ và mạng

Ví dụ điển hình là SAND, một mở rộng gần đây của MPEG-DASH [62]

Lịch sử phát triển của công nghệ streaming video

Sự phát triển của công nghệ streaming video trải qua các giai đoạn sau:

• Streaming gói dữ liệu Từ những năm 1990 đến đầu những năm 2000, cáchthông thường để streaming video trên mạng Internet là sử dụng bộ giaothức RTP/RTCP/RTSP RTP được phát triển bởi IETF, là một giao thứcchuẩn Internet cho truyền dữ liệu thời gian thực Chuẩn RTP thực sự địnhnghĩa một cặp giao thức RTP và RTCP RTP được sử dụng để trao đổi dữliệu đa phương tiện trong khi RTCP là phần điều khiển được sử dụng đểnhận phản hồi từ máy khách về sự kết nối mạng và trạng thái của trìnhphát video Giao thức RTP/RTCP chạy trên nền UDP UDP là giao thứcphi kết nối cung cấp phương tiện truyền dữ liệu với tối thiểu các cơ chếgiao thức Do đó, độ trễ truyền dữ liệu rất thấp, phù hợp với việc truyền

dữ liệu đa phương tiện nhạy cảm với thời gian, chẳng hạn như streamingtương tác Tuy nhiên, việc truyền dữ liệu qua UDP thiếu sự tin cậy do nókhông có các cơ chế điểu khiển nghẽn, điều khiển lỗi, điều khiển luồng Hơnnữa, các dịch vụ dựa trên UDP không thân thiện với bộ dịch địa chỉ mạng

NAT và có thể bị chặn bởi tường lửa [57, 76].

• Streaming tải lũy tiến Do những nhược điểm của streaming qua RTP trênnền UDP, kỹ thuật streaming tải lũy tiến ra đời sử dụng giao thức HTTPtrên nền TCP Trong kỹ thuật này, tệp video được tải lên máy chủ webthông thường, tương tự các đối tượng web khác như tệp ảnh, tệp văn bản.Máy khách chỉ đơn giản truy cập vào máy chủ web để tải một phần videovào bộ đệm, sau đó hiển thị dữ liệu video được lưu trong bộ đệm trong khivẫn tiếp tục tải về phần tiếp theo của video Có một số lợi ích trong kỹthuật này, đó là:

– Việc triển khai và mở rộng hệ thống dễ dàng do sử dụng các máy chủ

web thay vì các máy chủ chuyên biệt đắt tiền

– Hỗ trợ CDN nhờ sự phổ biến rộng rãi của HTTP.

– Thân thiện với tường lửa, vì các gói tin TCP đi qua được hầu hết tường

lửa và bộ dịch địa chỉ mạng NAT

Tuy nhiên, nhược điểm chính của streaming tải lũy tiến đó là chất lượngcủa video phải được lựa chọn thủ công bởi người dùng và chỉ được lựa chọnmột lần ngay khi bắt đầu một phiên truyền tải [62] Điều này có thể dẫnđến những gián đoạn video do thông lượng TCP thay đổi suốt phiên truyềntải Một giải pháp cho vấn đề này là sử dụng bộ đệm lớn nhưng nó khôngphù hợp với các dịch vụ streaming thời gian thực Trong [108], các tác giảchỉ ra rằng truyền tải dựa trên TCP cung cấp hiệu suất tốt khi thông lượngTCP có thể đạt được bằng hai lần tốc độ bit video Trên thực tế, điều nàykhó đạt được do tỉ lệ lỗi bit cao [7] Có thể thấy rằng, những hạn chế củaviệc triển khai các kỹ thuật streaming qua HTTP truyền thống là chúngkhông hỗ trợ sự thích ứng tốc độ bit một cách hiệu quả, mang lại chất lượngvideo thấp khi thông lượng mạng biến động theo thời gian Vấn đề này dẫnđến sự phát triển của công nghệ HAS - công nghệ streaming phổ biến trongnhững năm qua

• Công nghệ HAS và chuẩn MPEG-DASH Công nghệ HAS lần đầu tiên đượcgiới thiệu bởi Move Networks vào năm 2007 [55] Trong HAS, máy chủ lưunhiều mức chất lượng khác nhau của một video gốc Mỗi mức chất lượngđược chia nhỏ thành các phân đoạn ngắn, thường có độ dài bằng nhau

Chuẩn MPEG-DASH ra đời cho phép máy khách thay vì máy chủ sẽ đưa

ra quyết định về mức chất lượng nên được lựa chọn cho từng phân đoạnvideo Trong phiên streaming, một thuật toán đặt tại máy khách có nhiệm

vụ thích ứng chất lượng video với điều kiện mạng Bằng cách này, HASgiảm được sự gián đoạn trải nghiệm và do đó làm tăng QoE so với phươngpháp streaming tải lũy tiến

Sau khi tung ra thị trường lần đầu tiên vào năm 2007, HAS đã được cáccông ty thương mại chấp nhận bao gồm tập đoàn Microsoft (MSS) [23],Apple (HLS) [39], Adobe (HDS) [38] Chuẩn đầu tiên của HAS được công

bố cho hệ thống viễn thông toàn cầu-giải pháp dài hạn (UTMS-LTE) bởi3GPP năm 2009 Sau đó, chuẩn này được cải tiến hơn trong sự hợp tác vớiMPEG và cuối cùng là chuẩn quốc tế MPEG-DASH ra đời vào năm 2012[93] Phiên bản thứ hai của MPEG-DASH ra đời năm 2014 [98] Hiện tại,các chuyên gia về MPEG đang tiến tới phiên bản thứ ba của chuẩn này chophép triển khai công nghệ thực tế ảo và video 360 độ trên HAS

1.2.3 Công nghệ HAS

Giao thức HTTP

HTTP là một giao thức thuộc tầng ứng dụng trong mô hình TCP/IP Phiênbản đầu tiên của giao thức này là HTTP/1.0, ra đời từ năm 1996 Một năm sau,phiên bản HTTP/1.1 ra đời Năm 2009, SPDY – một giao thức thực nghiệmđược công bố bởi Google với mục đích giảm thời gian trễ để hiển thị trang webbằng cách khắc phục một số hạn chế trong hiệu năng của HTTP/1.1 Khônglâu sau đó, vào năm 2015, giao thức HTTP/2.0 chính thức ra đời và công bốtrong RFC 7540 [12] HTTP/2.0 kế thừa, xây dựng, phát triển và chuẩn hóamột số tính năng xuất hiện trong SPDY Giao thức HTTP được thiết kế đểtruyền thông giữa các trình duyệt và máy chủ web Nó được coi là nền tảng củacác ứng dụng web hiện tại HTTP hoạt động trên nền giao thức TCP theo môhình máy khách-máy chủ, máy khách gửi truy vấn tới máy chủ và đợi dữ liệutrả về từ máy chủ Quá trình này tiếp diễn trong suốt phiên kết nối giữa máykhách và máy chủ HTTP mang lại một số thuận lợi cho các dịch vụ streamingnhư sau: (i) dễ dàng triển khai và mở rộng do sử dụng các máy chủ Web thay vìcác máy chủ chuyên biệt đắt tiền, (ii) hỗ trợ SDN do sự phổ biến rộng rãi củaHTTP, (iii) thân thiện với tường lửa

Nguyên lý của HAS

Kiến trúc điển hình của một hệ thống HAS gồm máy chủ, mạng phân phối

và máy khách, được trình bày trên Hình 1.2

Nội dung video

Mã hóa video Phân đoạn video

Bộ đệm

Giải mã video Internet

sẽ quyết định mức chất lượng và số lượng phân đoạn (đối với HTTP/2.0) nênđược tải về dựa trên giá trị thông lượng được dự đoán trước và mức sử dụng

bộ đệm Dựa vào truy vấn của máy khách, máy chủ sẽ phản hồi một hay nhiềuphân đoạn video với cùng một mức chất lượng Máy khách lưu những phân đoạnvideo nhận được vào bộ đệm, sau đó giải mã theo thứ tự các phân đoạn và hiểnthị trên thiết bị của người dùng Sau đây, luận án trình bày chi tiết một số thànhphần quan trọng trong hệ thống HAS

• Tệp MPD Trong thuật ngữ của MPEG-DASH, tệp siêu dữ liệu được gọi

là MPD [98] Đó là một file XML, chứa các thông tin như thông tin siêu

dữ liệu truyền tải chung (chẳng hạn tên tệp, thông tin mật mã, truyền tảitheo yêu cầu hay trực tiếp), loại luồng (chẳng hạn âm thanh, hình ảnh, phụđề), các mức chất lượng (bao gồm các thông tin về dạng mã hóa, tốc độ bittrung bình), chỉ số của phân đoạn, đường dẫn tới từng phân đoạn riêng lẻ.Nếu video được mã hóa dạng VBR, thông tin về tốc độ bit đỉnh của từngmức chất lượng cũng được lưu trong tệp MPD Hiện tại, thông tin về kíchthước của từng phân đoạn video VBR không được chứa trong tệp MPD dolượng dữ liệu cần thiết để chuyển tải thông tin này rất lớn Chi tiết về tệpMPD thể hiện trong [40, 86].

• Máy khách HAS Sơ đồ khối của máy khách HAS được thể hiện trong Hình1.3 Dựa trên truy vấn của máy khách và phiên bản của giao thức HTTP(HTTP/1.1 hoặc HTTP/2.0), máy chủ sẽ phản hồi một hay nhiều phânđoạn video với cùng một mức chất lượng Các phân đoạn đó được máykhách lưu trong bộ đệm trước khi chuyển sang trình phát video Một thànhphần quan trọng của máy khách là bộ phận thích ứng có nhiệm vụ quyếtđịnh khi nào/phân đoạn nào được truy vấn Quyết định được đưa ra thườngdựa trên mức sử dụng bộ đệm (được quan sát từ bộ đệm), thông lượng dựđoán (được cung cấp bởi bộ phận dự đoán thông lượng) và tệp MPD Máykhách nhận tệp MPD tại đầu phiên streaming, còn việc dự đoán thông lượng

và đo mức sử dụng bộ đệm được thực hiện trong suốt phiên streaming

Hình 1.3: Sơ đồ khối của máy khách HAS

• Dự đoán thông lượng Thông thường, cách thức dự đoán thông lượng đượcdựa vào lịch sử của nó và mỗi phương pháp dự đoán thông lượng đều có

ưu và nhược điểm riêng Dự đoán thông lượng là một phần của giải pháp

thích ứng và tùy vào từng ngữ cảnh cụ thể sẽ lựa chọn một phương pháp

dự đoán thông lượng phù hợp

Trong HAS, cách đơn giản nhất là sử dụng thông lượng (T i) đo được ngay

sau khi một phân đoạn i vừa được tải xong làm thông lượng dự đoán (T e

i+1)cho phân đoạn kế tiếp [85, 101], cụ thể như sau:

với µ là hệ số an toàn nằm trong khoảng [0;1].

Cách dự đoán thông lượng trên có ưu điểm là giúp cho máy khách phản ứngrất nhanh với sự biến động của thông lượng Tuy nhiên, những lúc thônglượng giảm đột ngột, việc dự đoán sai thông lượng sẽ làm cho mức sử dụng

bộ đệm bị giảm mạnh

Một phương pháp khác để dự đoán thông lượng đó là sử dụng thông lượng

trung bình T i s của một số phân đoạn video đã được tải về làm thông lượng

dự đoán cho phân đoạn kế tiếp [4, 100], cụ thể như sau:

với γ là trọng số nằm trong khoảng [0;1] Ưu điểm của phương pháp này là

giúp máy khách tránh được việc ứng xử một cách vội vàng khi có sự thayđổi đột ngột của thông lượng

• Bộ đệm máy khách Bộ đệm của máy khách đóng vai trò quan trọng trongviệc đối phó với sự biến động của thông lượng mạng Kích thước bộ đệmcàng lớn thì tần suất và khoảng thời gian xảy ra gián đoạn càng nhỏ vàngược lại Hình 1.4 minh họa kích thước bộ đệm và mức sử dụng bộ đệm.Kích thước bộ đệm và mức sử dụng bộ đệm được tính bằng đơn vị thờigian, không phải là kích thước dữ liệu trong bộ đệm

Khi bắt đầu một phiên streaming trong HAS, máy khách sẽ nạp vào bộđệm một lượng dữ liệu nhất định trước khi giải mã và hiển thị dữ liệu ramàn hình Đây là giai đoạn nạp bộ đệm ban đầu Sau đó, máy khách chuyểnsang giai đoạn streaming ổn định (nhận và hiển thị dữ liệu video đồng thời).Trong giai đoạn này, nếu mức sử dụng bộ đệm đủ lớn, người dùng có thể

Kích thước bộ đệm

Mức sử dụng bộ đệmĐầu vào Đầu ra

Hình 1.4: Bộ đệm của máy khách HAS

trải nghiệm video với chất lượng mượt mà bất chấp thông lượng mạng biếnđộng mạnh Nếu mức sử dụng bộ đệm nhỏ, khả năng gián đoạn video dễxảy ra

Đối với streaming trực tiếp, do yêu cầu khắt khe về độ trễ nên mức sử dụng

bộ đệm được giới hạn, thường dưới 10 giây [49] Đối với streaming videotheo yêu cầu, mức sử dụng bộ đệm không bị giới hạn Tuy nhiên, trongmột phiên streaming, người dùng có thể dừng xem video bất cứ lúc nào vàmột lượng lớn dữ liệu trong bộ đệm không được sử dụng sẽ gây lãng phítài nguyên mạng Do vậy, trong thực tế, kích thước bộ đệm cho streamingtheo yêu cầu thường được thiết lập từ 10 đến 50 giây [63]

1.2.4 Các yếu tố ảnh hưởng đến QoE trong HAS

Cải thiện QoE trong HAS hiện đang thu hút mạnh mẽ sự đầu tư nghiên cứu[8, 81, 89, 92] Hai khía cạnh thiết kế chính có tác động đến QoE đó là (i) lựachọn TCP làm giao thức tầng giao vận và (ii) điều khiển lưu lượng dữ liệu đượcthực hiện bởi máy khách Việc lựa chọn giao thức TCP loại bỏ sự suy giảmchất lượng do mất gói tin Thay vào đó, độ trễ do mất gói và jitter đã đượcchuyển thành sự biến động thông lượng của TCP Vì vậy, các yếu tố chính ảnhhưởng đến QoE được điều khiển bởi máy khách bao gồm: độ trễ nạp bộ đệmban đầu, sự gián đoạn video, chất lượng video, độ trễ trực tiếp (trong streamingtrực tuyến) [49, 65] (Hình 1.5)

Độ trễ nạp bộ đệm ban đầu

Độ trễ nạp bộ đệm ban đầu luôn tồn tại trong streaming video do một sốlượng dữ liệu nhất định phải được nạp vào bộ đệm trước khi được giải mã và hiểnthị trên màn hình Nghiên cứu [89] đã chỉ ra rằng có một mối quan hệ logarit

Các yếu tố ảnh hưởng đến QoE trong HAS

Độ trễ

nạp bộ đệm

ban đầu

Sự gián đoạn video

Tần suất gián đoạn thời gianKhoảng

gián đoạn

Chất lượng video

Biên độ chất lượng

Sự biến động chất lượng

Tần suất biến động chất lượng

Biên độ biến động chất lượng

Độ trễ trực �ếp

Hình 1.5: Các yếu tố ảnh hưởng đến QoE trong HAS.

giữa độ trễ này và QoE Nếu máy khách nạp vào bộ đệm một số lượng lớn dữliệu sẽ dẫn đến độ trễ lớn Tuy nhiên, mức sử dụng bộ đệm ban đầu lớn sẽ giúpcho máy khách tránh gặp sự gián đoạn video gây ra bởi sự sụt giảm thông lượngmạnh Do đó, số lượng dữ liệu ban đầu được nạp vào bộ đệm cần thỏa mãn sựthỏa hiệp giữa độ trễ và sự gián đoạn video Nghiên cứu [35] cho biết độ trễ nạp

bộ đệm ban đầu được chấp nhận hơn so với sự gián đoạn video bởi khoảng 90%người dùng Độ trễ này bằng 16 giây có thể làm giảm nhẹ chất lượng video nếungười dùng dự định xem video đó [35, 89] Nghiên cứu [24] khẳng định rằng, đốivới người dùng di động, độ trễ này ít quan trọng hơn so với các yếu tố khác

đó là khoảng thời gian chờ đợi trước khi video được hiển thị trên màn hình, sựgián đoạn xảy ra bất ngờ trong lúc người dùng đang xem video được coi là tồi

tệ hơn nhiều [80] Nghiên cứu [36, 79] cho thấy khoảng thời gian gián đoạn dài

cũng như tần suất gián đoạn lớn làm giảm nghiêm trọng QoE.

Chất lượng cảm nhận

Trong HAS, chất lượng cảm nhận được đánh giá thông qua độ nét của hìnhảnh mà người dùng nhận được, được thể biện bởi tốc độ bit (đối với video CBR)hoặc tham số lượng tử (QP) (mức chất lượng đối với video VBR), còn được gọi

là biên độ chất lượng Tốc độ bit càng cao, QP càng thấp thường cung cấp chấtlượng cảm nhận càng tốt Ngoài ra, sự thay đổi tốc độ bit hay thay đổi mứcchất lượng trong một phiên streaming cũng tác động đến QoE [5, 71] Sự thayđổi này được xác định bằng biên độ và tần suất thay đổi Một số nghiên cứucho thấy tăng/giảm mức chất lượng sẽ tương ứng làm tăng/giảm QoE [53, 117].Một phân tích về sự thay đổi mức chất lượng trong [66] cho thấy việc dần dầnchuyển xuống một số mức trung gian cung cấp QoE tốt hơn so với việc đột ngộtgiảm xuống một mức thấp Tuy nhiên, khi cần tăng mức chất lượng, sự tăngđột ngột lên mức chất lượng cao có thể cải thiện QoE [32] Bên cạnh đó, tầnsuất giảm mức chất lượng cần được giảm thiểu để cải thiện QoE [126]

Độ trễ trực tiếp

Trong streaming trực tiếp, yếu tố đóng vai trò quan trọng ảnh hưởng đếnQoE là độ trễ trực tiếp (độ trễ từ lúc hình ảnh được chụp bởi camera tới lúchiển thị trên màn hình) Các thành phần chậm trễ chính bao gồm việc chuẩn bịnội dung, trễ phân đoạn, thời gian tải phân đoạn, thời gian nạp vào bộ đệm vàthời gian giải mã [59] Hiện tại, streaming thích ứng trực tiếp qua HTTP cho

độ trễ trong vài giây [62, 102] Các thí nghiệm được triển khai trong [105] chothấy kích thước bộ đệm tối thiểu là 10 giây đối với streaming trên thiết bị diđộng dựa trên HTTP/1.1 để có QoE chấp nhận được với tần suất và khoảngthời gian gián đoạn video tương đối thấp Đối với các dịch vụ streaming trựctiếp như giám sát qua video, hội nghị truyền hình, phát trực tiếp sự kiện thểthao, độ trễ phải được giảm tối đa

1.2.5 Tối đa hóa QoE trong HAS

Lưu ý rằng các yếu tố được mô tả ở trên không thể được xem xét một cáchriêng lẻ Ví dụ, để tránh bị gián đoạn video và giảm thiểu số lần chuyển đổimức chất lượng, máy khách luôn chọn mức chất lượng video thấp Việc này làmgiảm chất lượng tổng thể nếu dung lượng mạng cho phép tốc độ bit video caohơn Mặt khác, tối đa hóa QoE bằng cách luôn chọn mức chất lượng cao thường

dẫn đến số lần gián đoạn rất lớn Các yếu tố khác như biên độ và tần suất giảmmức chất lượng có tác động rất lớn đến QoE trong HAS [53, 117] Người dùngthường cảm thấy khó chịu khi video đang ở mức chất lượng rất cao nhưng độtnhiên sau đó lại bị giảm đi rất thấp Thay vào đó, việc giảm chất lượng mộtcách từ từ sẽ ít tác động tiêu cực đến người dùng Nghiên cứu [22] cho thấy sốlần và khoảng thời gian mỗi lần gián đoạn video ảnh hưởng nghiêm trọng nhấtđến QoE, đặc biệt trong trường hợp streaming trực tiếp Người dùng sẵn sàngchấp nhận độ trễ ban đầu và sự biến động chất lượng video cao hơn, nếu nógiúp giảm thiểu số lần và khoảng thời gian gián đoạn [35, 91] Gần đây, một sốnhóm nghiên cứu đã đề xuất mô hình QoE cho HAS [33, 34, 84, 90, 107] Tuynhiên các mô hình này chỉ tập trung vào video CBR và không quan tâm đến

sự gián đoạn video - yếu tố quan trọng nhất để đánh giá QoE Do đó việc xâydựng mô hình QoE cho HAS đang là một câu hỏi mở được nhiều nhà khoa họcquan tâm

Qua những phân tích ở trên có thể kết luận rằng, để tối đa hóa QoE cần: (i)loại bỏ sự gián đoạn video đồng nghĩa với việc giữ cho bộ đệm luôn ở mức ổnđịnh, (ii) tăng tốc độ bit trung bình của video, (iii) giảm số lần giảm mức chấtlượng, (iv) giảm biên độ giảm mức chất lượng Do đó, các yếu tố bao gồm mức

sử dụng bộ đệm trung bình, tần suất rỗng bộ đệm, tốc độ bit trung bình haymức chất lượng trung bình, số lần giảm mức chất lượng, biên độ giảm mức chất

lượng được coi là các thông số ảnh hưởng đến QoE Chúng được sử dụng

để đánh giá các giải pháp đề xuất và các giải pháp đối sánh trong luận án

1.3 Khảo sát các giải pháp cải thiện QoE trong HAS

1.3.1 Các giải pháp thích ứng cho streaming một video

Cho đến nay, các giải pháp thích ứng cho streaming một video có thể được chiathành hai nhóm chính: nhóm giải pháp heuristic và nhóm giải pháp dựa vào môhình toán học Nhóm giải pháp heuristic được chia thành hai nhóm nhỏ: nhómgiải pháp thích ứng dựa vào thông lượng và nhóm giải pháp thích ứng dựa vàomức sử dụng bộ đệm [102] Sự phân chia này có tính chất tương đối do mức sửdụng bộ đệm bị ảnh hưởng mạnh mẽ bởi thông lượng

Nhóm giải pháp thích ứng dựa vào thông lượng quyết định mức chất lượngdựa trên giá trị thông lượng tương lai được dự đoán trước Chúng khác nhau ở

cách dự đoán và sử dụng thông lượng [27, 42, 94] Các giải pháp này thường lựachọn tốc độ bit theo thông lượng cho nên chúng có thể thích ứng nhanh với sựbiến động của mạng nhưng biên độ chất lượng của video đầu ra không ổn định.Nhóm giải pháp thích ứng dựa vào mức sử dụng bộ đệm tận dụng bộ đệm củamáy khách để cố gắng duy trì mức chất lượng video ổn định [4, 14, 65, 67, 122].Nhóm giải pháp này cũng sử dụng thông lượng được dự đoán trong việc ra quyếtđịnh thích ứng Tuy nhiên, do mức sử dụng bộ đệm luôn biến động cùng với sựbiến động của thông lượng, việc quyết định thích ứng để tránh sự biến động mứcchất lượng video đầu ra là không dễ dàng Nếu thông lượng biến động mạnh,các giải pháp đòi hỏi kích thước bộ đệm lớn để tránh gián đoạn video.

Nhóm giải pháp thích ứng dựa vào mô hình toán học quyết định mức chấtlượng cho các truy vấn của máy khách dựa vào lý thuyết điều khiển [64, 116,

123, 125], tiến trình quyết định Markov [15, 41], học máy [19], khai phá dữ liệu[9], lập trình động [54] Đặc trưng của nhóm giải pháp này là có độ phức tạptính toán lớn, khó triển khai trong ngữ cảnh thời gian thực

Hiện tại, các giải pháp thích ứng chất lượng thuộc các nhóm trên hầu hếttập trung vào video được mã hóa với tốc độ bit không đổi (CBR) Các nghiêncứu về streaming thích ứng qua HTTP đối với video được mã hóa với tốc độ bitbiến đổi (VBR) còn rất hạn chế Thách thức đối với streaming video dạng VBR

đó là, ngoài việc phải ứng phó với sự biến động mạnh của thông lượng mạngcòn phải ứng phó với sự biến động mạnh của tốc độ bit video Hơn nữa, phầnlớn các phương pháp thích ứng chất lượng hiện tại là định tính theo nghĩa cácthông số ảnh hưởng đến QoE chỉ được biết sau khi kết thúc phiên streaming.Streaming video dạng VBR lần đầu tiên được đề xuất trong [101] Ý tưởngcủa giải pháp này là thích ứng mức chất lượng dựa trên sự dự đoán tốc độ bitcủa các phân đoạn video và thông lượng tương lai Phương pháp này không có

cơ chế cân bằng giữa các thông số ảnh hưởng đến QoE nên nó giữ được bộ đệm

ở mức cao và ổn định nhưng biên độ chất lượng video bị biến động rất mạnh.Sau đó, có một số công trình nghiên cứu cho streaming video VBR như: giảipháp thích ứng dựa trên việc dự đoán thông lượng và mức sử dụng bộ đệm [25],

dự đoán xu hướng thay đổi của bộ đệm dựa trên mô hình tuyến tính không gian[124], giải pháp thích ứng dựa trên mô hình toán học [3, 44, 56, 58, 115] Tuynhiên, các giải pháp này mới chỉ quan tâm đến sự biến động mạnh của mạng diđộng mà không quan tâm đến đặc trưng biến động của tốc độ bit video VBR,

dẫn đến tần suất bộ đệm bị rỗng lớn hoặc chất lượng video đầu ra không ổnđịnh Hơn nữa, chưa cho giải pháp nào có thể dự đoán trước được các thông

số ảnh hưởng đến QoE (như tốc độ bit trung bình, mức sử dụng bộ đệm trungbình xác suất bộ đệm bị rỗng)

Gần đây, một vài phương pháp thích ứng dựa trên mô hình toán học được

đề xuất để tối ưu hóa việc lựa chọn mức chất lượng video của máy khách trongđiều kiện mạng biến đổi theo thời gian S García và cộng sự [29] là nhóm đầutiên đề xuất một giải thuật thích ứng chất lượng sử dụng lập trình động ngẫunhiên (SDP) để tìm giải pháp tối ưu cho streaming video dạng VBR Việc truyvấn các phân đoạn được điều phối bởi chính sách ánh xạ một tham số điều khiểncho mỗi trạng thái của hệ thống Tuy nhiên, nó được giới hạn với các video cótốc độ bit biến động rất ít, gần như CBR Trong bối cảnh streaming thích ứng,cho đến nay chưa có bất kỳ phương pháp nào có thể 1) hỗ trợ video dạng VBRvới sự biến động tốc độ bit mạnh mẽ và 2) dự đoán các thông số ảnh hưởng đếnQoE trước khi phiên streaming bắt đầu

1.3.2 Các giải pháp thích ứng cho streaming đồng thời nhiều videoTrong HAS, để cải thiện QoE, các giải pháp thích ứng chất lượng thường dựatrên cùng một nguyên lý đó là: (i) máy chủ lưu các mức chất lượng của videogốc cùng với tệp MPD của nó, (ii) dựa trên những thông tin từ tệp MPD, tìnhtrạng của mạng và mức sử dụng bộ đệm, máy khách quyết định những phânđoạn video nào sẽ được tải về tiếp theo Theo cách này, quá trình quyết địnhmức chất lượng được thực hiện hoàn toàn tại máy khách và mỗi máy khách đều

cố gắng tối đa mức chất lượng của riêng mình Trong mạng được quản lý (chẳnghạn IPTV) cách tiếp cận hướng máy khách như trên sẽ dẫn đến sự tranh chấpbăng thông khi chúng cùng chia sẻ một đường truyền có băng thông hạn chế.Hành vi tranh chấp này làm cho việc dự đoán thông lượng thiếu chính xác, dẫnđến chất lượng video trên mỗi máy khách bị biến động mạnh hoặc bộ đệm dễ

bị rỗng [1, 3]

Để khắc phục vấn đề trên, một số đề xuất được thực hiện tại máy khách như:giải pháp ngẫu nhiên hóa khoảng thời gian mà các máy khách truy vấn phânđoạn video mới [106]; một mô hình ON-OFF được sử dụng khi mức sử dụng bộđệm đạt tới một ngưỡng nhất định [1] trong đó máy khách sẽ dừng tải khi bộđệm đầy (giai đoạn OFF) và tiếp tục tải dữ liệu (giai đoạn ON) khi một lượng

dữ liệu trong bộ đệm được tiêu thụ Rõ ràng, các giải pháp này vẫn thiếu sựphối hợp giữa các máy khách, cho nên vấn đề chia sẻ băng thông vẫn chưa đượcgiải quyết triệt để.

Một số giải pháp triển khai tại máy chủ được đề xuất để giải quyết vấn đềtranh chấp băng thông giữa các máy khách như: giải pháp định hình lưu lượngphía máy chủ [2], thuật toán phân bổ băng thông tại máy chủ có quan tâm đếnQoE [120], thiết kế bộ điều khiển phân bổ động nguồn tài nguyên, điều chỉnh sốlượng máy ảo trong mạng phân phối nội dung (CDN) dựa trên đám mây [18].Mặc dù các giải pháp này đạt được hiệu quả nhất định trong phân bổ nguồntài nguyên và cải thiện QoE, tuy nhiên, rất khó để thực hiện các giải pháp tiếpcận dựa trên máy chủ trong một hệ thống quy mô lớn

Đối với các hệ thống có quy mô lớn, các nghiên cứu gần đây [6, 16, 26, 75, 77]

đã đưa ra các giải pháp dựa trên mạng để cải thiện vấn đề chia sẻ băng thông

và cải thiện QoE Cụ thể, các giải pháp được đặt tại proxy có nhiệm vụ phân bổbăng thông và thích ứng chất lượng cho từng luồng video Các đề xuất này đãcải thiện được sự công bằng trong chia sẻ băng thông, tuy nhiên chúng chỉ tậptrung vào streaming video dạng CBR do ưu điểm dễ thích ứng của dạng videonày

Vấn đề chia sẻ băng thông khi streaming đồng thời nhiều luồng video VBRlần đầu tiên được quan tâm bởi Y Huang và cộng sự [37] Họ cung cấp sự phân

bổ năng lượng cho việc truyền video VBR qua mạng không dây đa tế bào bằngcách tối đa hóa lượng dữ liệu được truyền dưới sự ràng buộc của năng lượngtruyền đỉnh và các yêu cầu về mức sử dụng bộ đệm Mặc dù giải pháp của họcung cấp một sự bù trừ tốt giữa mức độ tiêu thụ năng lượng và sử dụng bộ đệm,

nó chủ yếu tập trung vào việc quản lý năng lượng mà không tối ưu hóa trongviệc sử dụng kênh, dẫn đến hiệu suất sử dụng dung lượng kênh thấp

Như vậy, có thể thấy rằng vấn đề phân bổ băng thông và cải thiện QoEkhi streaming đồng thời nhiều video dạng VBR qua một đường truyền có băngthông hạn chế đang là một thách thức đối với cộng đồng khoa học

1.3.3 Các giải pháp thích ứng cho streaming qua HTTP/2

Năm 2015, giao thức HTTP/2 ra đời, mang nhiều tính ưu việt hơn so vớiHTTP/1.1 [13] HTTP/2 cung cấp một số tính năng mới như ghép luồng (mul-tiplexing), ưu tiên luồng (stream prioritization), chấm dứt luồng (stream termi-

nation) và Server Push Trong đó, tính năng Server Push được sử dụng hiệu quảtrong streaming video.

Tính năng Server Push cho phép máy chủ đẩy nhiều tài nguyên tới máy kháchhơn yêu cầu trong truy vấn của máy khách khi nó biết chắc chắn máy khách sẽphải sử dụng đến những dữ liệu này Ví dụ như khi máy khách gửi yêu cầu mộttập tin HTML từ máy chủ để hiển thị nội dung một trang web, máy chủ thay

vì chỉ gửi duy nhất tập tin HTML này, nó sẽ gửi thêm các tập tin hình ảnh, css

và javascript được nhúng trong tập tin trên vì nó biết chắc chắn máy khách sẽcần đến những nội dung này để hiển thị trang web Khi ứng dụng tính năng nàyvào streaming video, máy khách sẽ không phải gửi quá nhiều truy vấn và máychủ cũng không cần đợi truy vấn từ máy khách mới được gửi dữ liệu

Dùng tính năng Server Push trong streaming thích ứng video được đề xuấtđầu tiên bởi Wei và cộng sự trong [111] Nghiên cứu của họ mang lại độ trễ thấpcho streaming trực tiếp bằng cách giảm độ dài phân đoạn xuống còn 1 giây

Họ triển khai chiến lược Push-N, nghĩa là máy khách truy vấn một mức chấtlượng cụ thể cho mỗi N phân đoạn Sau đó, máy chủ sẽ đẩy liên tiếp N phânđoạn tới máy khách ngay sau khi các phân đoạn đó đã sẵn sàng trên máy chủ.Ngoài ra, tính năng Server Push với chiến lược Push-N được nghiên cứu để giảmoverhead liên quan đến truy vấn của máy khách [109] và tiết kiệm năng lượngtrong streaming trên thiết bị di động [112] Tuy nhiên, do số lượng phân đoạncho mỗi truy vấn là cố định (N phân đoạn) trong toàn bộ phiên streaming dẫntới máy khách không thể phản ứng nhanh với sự biến động của mạng

Để khắc phục vấn đề của chiến lược Push-N, Duc và cộng sự [68] đã địnhnghĩa một hàm chi phí để quyết định số lượng phân đoạn được đẩy cho mỗi truyvấn của máy khách Giải pháp này đạt được một số mục tiêu là giảm overheadliên quan đến số lượng truy vấn và sự ổn định của bộ đệm Tuy nhiên, tốc độbit cho mỗi truy vấn của máy khách được quyết định theo thông lượng mạng,nghĩa là nó biến động theo sự biến động của thông lượng mạng Điều này làmcho biên độ chất lượng của video đầu ra biến động mạnh, ảnh hưởng xấu đếnQoE

Hung và cộng sự [51] cũng đề xuất một giải pháp thích ứng để quyết định sốlượng phân đoạn cho mỗi truy vấn của máy khách, có quan tâm đến việc đảmbảo cho biên độ chất lượng của video được ổn định Tuy nhiên, máy khách vẫnphải tải đủ số lượng phân đoạn video đã được truy vấn trước khi gửi một truy

vấn mới Kết quả là, máy khách vẫn cần nhiều truy vấn cũng như sẽ phản ứngchậm với sự giảm thông lượng đột ngột, dẫn đến bộ đệm có nhiều nguy cơ bịrỗng.

Rõ ràng là, nếu máy chủ có thể đẩy liên tiếp nhiều phân đoạn video cho đếnkhi nhận được truy vấn yêu cầu thay đổi mức chất lượng từ máy khách thì máykhách có thể ứng phó tốt hơn với sự biến động của mạng

1.4 Kết luận chương

Trong chương này, luận án đã trình bày cơ sở lý thuyết nền tảng của kỹ thuậtstreaming video nói chung và công nghệ HAS nói riêng Sau đó, luận án trìnhbày chi tiết các yếu tố tác động đến QoE trong HAS Từ đó luận án đi đến kếtluận rằng để tối đa hóa QoE cần loại bỏ sự gián đoạn video, tăng tốc độ bittrung bình, hạn chế tần suất và biên độ giảm mức chất lượng Đây cũng chính

là các thông số ảnh hưởng đến QoE, được dùng để đánh giá các giải pháp

đề xuất và các giải pháp đối sánh trong luận án Ngoài ra, các nghiên cứu liênquan cũng được khảo sát kỹ lưỡng Từ đó, luận án kế thừa những ưu điểm vànghiên cứu, đề xuất các mô hình, thuật toán nhằm cải thiện QoE được thể hiệntrong Chương 2, Chương 3 và Chương 4

CẢI THIỆN QoE TRONG STREAMING THÍCH ỨNG VIDEO DẠNG VBR QUA HAS SỬ DỤNG SDP

2.1 Giới thiệu chương

Trong chương này, luận án đề xuất giải pháp cải thiện QoE streaming thích ứngvideo dạng VBR dùng SDP Cách tiếp cận của luận án khác so với các giải pháp

đã được nghiên cứu ở một số điểm sau đây Thứ nhất, giải pháp đề xuất đượcđánh giá trên mạng di động có băng thông biến động mạnh theo thời gian Thứhai, nó hỗ trợ hiệu quả cho streaming video VBR có tốc độ bit biến động rấtmạnh Thứ ba, giải pháp đề xuất các mô hình toán để dự đoán một số thông sốQoE trước khi một phiên streaming thực sự bắt đầu

2.2 Ý tưởng sử dụng SDP trong streaming thích ứng

Để áp dụng SDP vào bài toán thích ứng chất lượng, trước hết ta cần xây dựngcác trạng thái của hệ thống Một trạng thái của hệ thống được xác định tại thờiđiểm một phân đoạn video vừa được tải xong Trạng thái của hệ thống được đặctrưng bởi giá trị băng thông, mức sử dụng bộ đệm và mức chất lượng của videotại thời điểm quan sát trạng thái đó Để xây dựng tập hợp tất cả các trạng tháicủa hệ thống, trước hết ta cần rời rạc hóa các yếu tố gồm băng thông và bộđệm, còn mức chất lượng video đã là các giá trị rời rạc Tổ hợp các giá trị saukhi được rời rạc hóa của các yếu tố trên sẽ tạo nên tất cả các trạng thái có thể

có của hệ thống Sau đó, luận án sử dụng thuật toán lặp chính sách (PI) củaSDP để tìm ra tập chính sách tối ưu cho tất cả các trạng thái của hệ thống Vaitrò của tập chính sách này là ánh xạ tham số điều khiển (cụ thể là mức chấtlượng video cho truy vấn tiếp theo) với tất cả các trạng thái của hệ thống.Một tập chính sách là tối ưu nếu nó tối thiểu hóa giá trị chi phí trung bìnhtrên mỗi trạng thái Chi phí là một hàm có liên quan đến các thông số ảnhhưởng đến QoE Dựa trên tập chính sách tìm được và mô hình hệ thống đượcxây dựng, luận án phát triển các mô hình toán học để dự đoán các thông số ảnh

28