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 (tt)

BỘ GIÁO DỤC VÀ ĐÀO TẠO
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

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

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

HÀ NỘI - 2019


Công trình này được hoàn thành tại:
Trường Đại học Bách khoa Hà Nội

Người hướng dẫn khoa học: PGS.TS Phạm Ngọc Nam

Phản biện 1:
Phản biện 2:
Phản biện 3:
Luận án được bảo vệ trước Hội đồng đánh giá luận án tiến sĩ cấp trường
họp tại Trường Đại học Bách khoa Hà Nội

vào hồi . . . giờ, ngày . . . tháng . . . năm . . .

Có thể tìm hiểu luận án tại:

1. Thư viện Tạ Quang Bửu, Trường ĐHBK Hà Nội
2. Thư viện Quốc gia Việt Nam


MỞ ĐẦU

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
Internet 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ệu suất cao. Thách thức chính của streaming video qua Internet
là sự biến động của thông lượng gây ra bởi các mạng không đồng nhất,
dẫn đến không thể phát video với tốc độ bit cố định trong suốt một phiên
streaming. Do đó, các chuẩn streaming video được phát triển từ năm 2008
đã dựa trên công nghệ streaming thích ứng để cho phép máy chủ/máy
khách thích ứng chất lượng video với sự biến động của mạng.
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 (HTTP Adaptive Streaming) [7, 39]. Kỹ thuật này 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áy chủ 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.
• 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 áp
dụng bao gồm Netflix, Youtube, Hulu và Amazon Instant Video.
Năm 2012, chuẩn toàn cầu đầu tiên của HAS có tên là MPEG-DASH ra

đời cho phép máy khách thay vì máy chủ là thành phần đưa ra quyết định
về việc thích ứng chất lượng video. Cụ thể, nhà cung cấp dịch vụ sẽ tạo ra
nhiều mức chất lượng (phiên bản video) từ một video gốc. Mỗi mức chất
lượng video được chia nhỏ thành các phân đoạn. Trong phiên streaming,
1


một phương pháp thích ứng chất lượng video đặt tại máy khách có nhiệm
vụ quyết định mức chất lượng nên được truy vấn cho mỗi phân đoạn dựa
vào tình trạng của mạng và mức sử dụng bộ đệm của máy khách. 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
đa hướng.
Cho đến nay, chưa có chuẩn nào chỉ ra việc thích ứng chất lượng trong
HAS 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). Vì vậy, việc nghiên cứu, đề xuất các giải pháp cải thiện QoE 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 đến QoE
trong HAS [19, 32, 36, 50]. 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
video qua 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 để đối phó hiệu quả với sự biến động của thông lượng
mạng, từ đó nâng cao QoE của người dùng.
2. Những vấn đề còn tồn tại
Cho đến này, các phương pháp thích ứng chất lượng hầu hết tập trung vào
video được mã hóa với tốc độ bit không đổi (CBR) [4, 24, 27, 41]. Các
nghiên cứu về streaming thích ứng qua HTTP đố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à các phân đoạn video trong cùng một mức chất lượng có tốc độ bit
cố định, dẫn đến việc thích ứng chất lượng tương đối đơn giản. Tuy nhiên,
video được hiển thị trên màn hình người dùng có chất lượng không ổn định.
So với video dạng CBR, video dạng VBR mang lại chất lượng hình ảnh ổn
định hơn. Tuy nhiên, sự biến động mạnh của tốc độ bit video VBR trong
cùng một mức chất lượng cùng với sự biến động mạnh của thông lượng
mạng là thách thức lớn trong HAS. Chính vì vậy, việc nghiên cứu các giải
pháp để cải thiện QoE trong streaming một video VBR và streaming đồng
thời nhiều video VBR qua HAS đang thu hút sự quan tâm nghiên cứu.
Năm 2015, 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 [8]. HTTP/2
giới thiệu một số tính năng mới trong đó có tính năng Server Push. Tính
năng này cho phép máy chủ đẩy nhiều tài nguyên tới máy khách hơn yêu
cầu trong truy vấn của máy khách. Nhờ vào tính năng này, máy khách sẽ
2


không phải gửi quá nhiều truy vấn và máy chủ cũng không cần đợi truy vấn
từ máy khách mới được gửi dữ liệu. Khi áp dụng tính năng Server Push của
HTTP/2 vào streaming thích ứng, nó cho 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ất lượng cho mỗi truy vấn của
máy khách, từ đó giảm được overhead liên quan đến số lượng truy vấn của
máy khách. Do những lợi ích mà tính năng Server Push của HTTP/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 của các nhà khoa học.
3. Mục tiêu nghiên cứu
Đề xuất các giải pháp cải thiện QoE trong streaming video theo yêu cầu
(VoD) đối với ba ngữ cảnh cụ thể, đó là: streaming một video VBR qua
HTTP, streaming đồng thời nhiều video VBR qua HTTP và streaming một

video VBR/CBR qua HTTP/2.
4. Những đóng góp của luận án
• Đề xuất và thực hiện giải pháp cải thiện QoE dựa trên lập trình động
ngẫu nhiên (SDP) trong streaming video dạng VBR qua HTTP. Ngoài
ra, các mô hình toán học được triển khai để dự đoán các thông số
ảnh hưởng đến QoE. Thực nghiệm cho thấy (i) phương pháp đề xuất
mang lại QoE tốt hơn so với một số phương pháp streaming thích
ứng video dạng VBR hiện tại, (ii) kết quả dự đoán các thông số ảnh
hưởng đến QoE bằng mô hình toán khá gần với các thông số được đo
đạc từ mô phỏng thực nghiệm.
• Đề xuất và thực hiện giải pháp phân bổ băng thông và cải thiện QoE
khi streaming đồng thời nhiều video VBR qua một đường truyền có
băng thông hạn chế trên nền giao thức HTTP. Thực nghiệm được
thực hiện trong thời gian thực cho thấy phương pháp đề xuất có
phân bổ băng thông hợp lý và cải thiện đáng kể QoE, trong điều kiện
ràng buộc về tổng lượng băng thông của đường truyền và giới hạn
của độ trễ.
• Đề xuất và thực hiện các thuật toán cải thiện QoE khi streaming
video VBR/CBR qua HTTP/2 đồng thời làm giảm overhead liên
quan đến số lượng truy vấn của máy khách. Thực nghiêm cho thấy
các giả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ể số lượng truy
vấn của máy khách.
3


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

1.1. Giới thiệu chương
Chương này trình bày cơ sở lý thuyết của công nghệ HAS, các yếu tố ảnh
hưở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. Đó 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 là 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 là 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 đó. Thời gian trọn vòng
(RTT) là Khoảng thời gian từ lúc máy khách gửi truy vấn cho đế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à lượng video còn lại trong bộ đệm.

1.2.2. Công nghệ streaming video
Trước đây, để 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ư vậy,
người dùng phải chờ đợi lâu và máy tính tốn tài nguyên bộ nhớ. Kỹ thuật
streaming video ra đời đã khắc phục những vấn đề trên. Trong streaming
video, máy khách bắt đầu hiển thị video chỉ vài giây sau khi nó bắt đầu
4


nhận dữ liệu từ máy chủ. Sau đó, máy khách vẫn tiếp tục hiển thị video
trong khi đang tải nốt những phần sau của video. Các kỹ thuật streaming
video thường được phân loại theo 5 yếu tố: yêu cầu về độ trễ, chế độ mã
hóa video, giao thức tầng giao vận, tính thích ứng và vị trí khối thích ứng
[21]

1.2.3. Công nghệ HAS
Kiến trúc của một hệ thống HAS gồm máy chủ, mạng phân phối và máy
khách (Hình 1.2). Một video gốc được mã hóa thành nhiều mức chất lượng
(phiên bản). Mỗi mức chất lượng được chia thành nhiều phân đoạn nhỏ
có độ dài bằng nhau. Nội dung video được gửi từ máy chủ tới máy khách
thông qua một chuỗi truy vấn/phản hồi. Đối với mỗi truy vấn của máy
khách, thuật toán thích ứng chất lượng đặt tại máy khách 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 tình trạng của mạng và mức sử dụng bộ đệm của máy khách.
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ều phâ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ạn
video nhận được vào bộ đệm, sau đó giải mã và hiển thị trên thiết bị của
người dùng.
Nội dung video

Mã hóa video

Bộ phận thích
ứng chất lượng

Phân đoạn
video
Truy vấn

Phiên bản 3
Phiên bản 2
Phiên bản 1

Bộ đệm

Internet
Máy
chủ

Phản hồi

Hiển thị
Giải mã
video

Máy
khách

Hình 1.2: Hệ thống HAS

Trong HAS, việc dự đoán thông lượng được dựa vào lịch sử của nó.
Cách đơn giản nhất là sử dụng thông lượng (Ti ) đo được ngay sau khi một
e ) cho phân
phân đoạn i vừa được tải xong làm thông lượng dự đoán (Ti+1
e = (1 − µ) × T với µ là hệ số an toàn nằm
đoạn kế tiếp [34, 40], cụ thể Ti+1
i
trong khoảng [0;1]. Ngoài ra, thông lượng trung bình Tis của một số phân
đoạn video đã được tải về cũng được sử dụng để dự đoán thông lượng cho

5


phân đoạn kế tiếp [4, 39]:

e
Ti+1
= Tis =

s + γ × T , i > 1,
(1 − γ) × Ti−1
i
Ti , i = 1,

(1.2)

với γ là trọng số nằm trong khoảng [0;1].

1.2.4. Các yếu tố ảnh hưởng đến QoE trong HAS
Trong HAS, TCP - lớp dưới của HTTP có cơ chế kiểm soát tắc nghẽn và
cơ chế truyền lại khi mất gói. Độ trễ do mất gói và jitter đã được chuyển
thành sự biến động thông lượng của TCP. Vì vậy, các yếu tố chính ảnh
hưởng đến QoE được điều khiển bởi máy khách bao gồm: độ trễ nạp bộ
đệm ban đầu, sự gián đoạn video, chất lượng cảm nhận, độ trễ trực tiếp
(trong streaming trực tuyến) [20] (Hình 1.5).
Các yếu tố tác độ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

Độ trễ
trực �ếp

Chất lượng
video

Khoảng
thời gian
gián đoạn

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

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

1.2.5. Tối đa hóa QoE trong HAS
Các yếu tố ảnh hưởng đến QoE được trình bày trong Phần 1.2.4 không thể
được xem xét một cách riêng lẻ. Ví dụ, để tránh gián đoạn video và giảm
thiểu số lần chuyển đổi mức chất lượng, máy khách luôn chọn mức chất
lượng thấp nhất. Việc này làm giảm chất lượng tổng thể nếu dung lượng
mạng cho phép tốc độ bit video cao hơ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 nhất 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ảm mức chất lượng có
6


tác động rất lớn đến QoE trong HAS [22, 48]. Nghiên cứu [13] 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àng chấ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 hoặc khoảng thời gian gián đoạn [16, 35].
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, (ii) tăng tốc độ bit trung bình của video,
(iii) giảm số lần giảm mức chất lượng, (iv) giảm biên độ giảm mức chất
lượng.

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
chia thành hai nhóm chính: nhóm giải pháp heuristic [4, 9, 15, 18, 26, 27,
37, 51] và nhóm giải pháp dựa vào mô hình toán học [6, 10, 17, 23, 25, 47,
52, 53].
Các giải pháp thích ứng chất lượng thuộc các nhóm trên hầu hết tập
trung vào video CBR. Các nghiên cứu về streaming thích ứng qua HTTP

đối với video 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ạng còn phải ứng phó với sự biến động mạnh của tốc độ bit video.
Hơn nữa, phần lớ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ác thông số ảnh hưởng đến QoE chỉ được biết sau khi kết
thúc phiên streaming.

1.3.2. Các giải pháp thích ứng cho streaming đồng thời nhiều
video
Trong HAS, việc thích ứng 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ẳng hạn IPTV) cách tiếp cận hướng
máy khách sẽ dẫn đến sự tranh chấp bă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, có ba nhóm giải pháp: Nhóm giải pháp đặt tại
7


máy khách [1, 43], nhóm giải pháp đặt tại máy chủ [2, 12, 49] và nhóm giải
pháp đặt tại một thành phần của mạng (cache, proxy) [5, 11, 14, 30, 31].
Tuy nhiên, tất cả các giải pháp trên đều tập trung cho video CBR.

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. Giao thức này cung cấp một số tính
năng mới, trong đó, tính năng Server Push được sử dụng hiệu quả trong
streaming video. Tính năng này cho phép máy chủ đẩy nhiều phân đoạn
video cho một truy vấn của máy khách.
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 [45]. Họ triển khai chiến lược PushN, nghĩa là máy khách truy vấn một mức chất lượng cụ thể cho mỗi N
phân đoạn. Ngoài ra, chiến lược Push-N được nghiên cứu để giảm overhead
liên quan đến truy vấn của máy khách [44] và tiết kiệm năng lượng trong
streaming trên thiết bị di động [46]. Tuy nhiên, do số lượng phân đoạn cho
mỗi truy vấn là cố định trong toàn bộ phiên streaming dẫn tớ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, một số giải pháp được
đề xuất nhằm quyết định số lượng phân đoạn được đẩy cho mỗi truy vấn
của máy khách [21, 28]. Tuy nhiên, máy khách phả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 ứng chậ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 đến khi 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áy khá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
Chương này đã trình bày cơ sở lý thuyết nền tảng của công nghệ HAS và
các yếu tố tác động đến QoE trong HAS. Từ đó luận án đi đến kết luận
rằng để tối đa hóa QoE cần loại bỏ sự gián đoạn video, tăng tốc độ bit
trung 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ên quan 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ện trong Chương 2, Chương 3 và Chương 4.
8


Chương 2

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
Chương này đề xuất giải pháp cải thiện QoE trong streaming thích ứng
video dạng VBR dùng SDP. Cách tiếp cận của tác giả 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 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ất mạ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, ta cần xây dựng các trạng thái của hệ thống. Trạng thái
của hệ thống được đặc trư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 video tại thời điểm quan sát trạng thái đó. Tổ hợp
các giá trị sau khi được rời rạc hóa băng thông, bộ đệm và các mức chất
lượng video tạo nên tất cả các trạng thái của hệ thống. Khi hệ thống chuyển
từ trạng thái này sang trạng thái khác sẽ sinh ra hàm chi phí. Một vấn đề
phạm vi vô hạn được đề xuất để 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. Vai trò 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ất lượng video cho phân đoạn kế tiếp) với tất
cả các trạng thái của hệ thống. Dựa trên tập chính sách tìm được và mô
hình hệ thống được xây dựng, các mô hình toán học được phát triển để dự
đoán các thông số ảnh hưởng đến QoE trước mỗi phiên bao gồm mức chất
9


lượng trung bình, mức sử dụng bộ đệm trung bình, biên độ nhảy mức chất

lượng trung bình và xác suất bộ đệm bị rỗng.

2.3. Mô hình hóa hệ thống để áp dụng SDP
2.3.1. Rời rạc hóa băng thông
Băng thông được rời rạc hóa thành W mức. Sau đó, W trạng thái băng
thông khác nhau BWw (1 ≤ w ≤ W ) được tạo ra từ W mức này. Do băng
thông mạng thường biến động mạnh và ngẫu nhiên, luận án sử dụng mô hình
chuỗi Markov được minh họa trong Hình 2.3. Mỗi trạng thái được đặc trưng
bởi một giá trị băng thông BWw (1 ≤ w ≤ W ). Có một xác suất pij khi băng
thông chuyển từ trạng thái này sang trạng thái khác sau mỗi bước thời gian.
Tổng các xác suất trong mô hình (

pij ) bằng 1.

i,j

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

2.3.2. Rời rạc hóa bộ đệm
Tương tự như băng thông, bộ đệm được rời rạc hóa thành B mức từ 1 đến
Bs tương ứng với số phân đoạn video có trong bộ đệm. Bs là kích thước
bộ đệm.

2.4. Mô tả vấn đề và giải pháp
2.4.1. Trạng thái hệ thống
Hệ thống được đặc trưng bởi biến trạng thái sk (bk , bwk , vk ) khi một phân
đoạn video được tải xong tại giai đoạn k. Tại mỗi trạng thái sk , hệ thống
lựa chọn một hành động a tương ứng với mức chất lượng cho phân đoạn
tiếp theo. Hệ thống sau đó ngẫu nhiên nhảy sang trạng thái mới sk+1 tại
giai đoạn tiếp theo, khi đó sinh ra một chi phí C(sk , a).

10


2.4.2. Xác suất chuyển trạng thái
Do hệ thống là ngẫu nhiên, có nghĩa là đầu ra của hệ thống ứng với mỗi
hành động a là bất định, cho nên xác suất chuyển trạng thái phụ thuộc lựa
chọn a cần được xây dựng. Xác suất mà trạng thái sk chuyển đến trạng
thái sk+1 , với một lựa chọn a được định nghĩa như sau:
P r {sk+1 |sk , a} =

P r {bwk+1 |bwk } , bk+1 = ba , vk+1 = a,
0, bk+1 = ba ||vk+1 = a.

(2.7)

2.4.3. Hàm chi phí
Hàm chi phí được định nghĩa để phạt những yếu tố gây ra sự giảm QoE,
đó là: tốc độ bit, sự gián đoạn video và sự biến động mức chất lượng, cụ
thể như sau:
C(sk , a) = α × ∆rk + β × ∆bk + γ × ∆qk

(2.11)

với ∆rk là sự sai khác giữa băng thông hiện tại và tốc độ bit của phân
đoạn tiếp theo được lựa chọn bởi hành động a (∆rk = |bwk − ra |), ∆bk là
sự chênh lệch của mức sử dụng bộ đệm hiện tại với mức sử dụng bộ đệm
tối ưu (∆bk = |bk − bopt |) và ∆qk là sự sai khác giữa mức chất lượng được
lựa chọn với mức chất lượng trước đó (∆qk = (vk − a)2 ).

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

Đối với mỗi trạng thái sk , hành động a hợp lý nhất, được gọi là chính sách
cho trạng thái sk . Tập π chứa các chính sách cho từng trạng thái sk , là sự
ánh xạ giữa tập trạng thái và tập hành động π : s −→ a. Luận án sử dụng
thuật toán PI (Policy Iteration) của SDP [42] để tìm ra tập chính sách tối
ưu π ∗ sao cho tối tiểu hóa hàm giá trị của mỗi trạng thái:
π ∗ (sk ) = argmina C(sk , a) +

P (sr |sk , a) × V (sr ) , ∀a ∈ a.

(2.13)

sr ∈s

Các tập chính sách tìm được giống như một bảng tìm kiếm để ánh xạ mỗi
trạng thái với một mức chất lượng tối ưu cho phân đoạn tiếp theo.

2.5. Dự đoán các thông số ảnh hưởng đến QoE
Để dự đoán các thông số ảnh hưởng đến QoE, điểm mấu chốt là cần xác
định vectơ xác suất p = [p1 , p2 , ..., pN ] với pn (1 ≤ n ≤ N ) là xác suất mà
11


hệ thống ở trạng thái sn trong suốt phiên streaming. Trong phần này, xác
suất trạng thái p được tính như sau:
L
ti
i=1 p

p=

L

(2.16)

với L là độ dài video và pti = pt1i , pt2i , ..., ptNi (1 ≤ i ≤ L), trong đó ptni
(1 ≤ n ≤ N ) là xác suất mà hệ thống ở trạng thái sn tại thời điểm ti .

2.5.1. Dự đoán chất lượng video
Mức chất lượng trung bình Av của video được dự đoán bởi:
N

vn × pn .

Av =

(2.17)

n=1

2.5.2. Dự đoán sự nhảy mức chất lượng
Biên độ nhảy mức chất lượng trung bình trong một phiên streaming:
N

Asw =

(vn − an ) × pn , an ∈ π ∗ .

(2.19)

n=1

2.5.3. Dự đoán mức sử dụng bộ đệm
Mức sử dụng bộ đệm trung bình Ab và xác suất video bị gián đoạn Pund
được thể hiện qua 2.7 và 2.8 dưới đây:
N

bn × pn ,

Ab =

(2.20)

n=1
N

bn × pn |bn =1 .

Pund =

(2.21)

n=1

2.6. Thực nghiệm và đánh giá
2.6.1. Cài đặt thực nghiệm
Test-bed gồm một máy khách chạy Java 8.0 trên máy tính Window 7 để
thực thi thuật toán thích ứng và một máy chủ Apache2 chạy trên Ubuntu
12

12.04LTS để lưu các phân đoạn video. Băng thông kênh được giả lập bằng
Dummynet [33]. RTT được đặt bằng 40ms. Video VBR được sử dụng là
Tokyo Olympic [38] có Vmax = 9. Đoạn video được đánh giá gồm 300 phân
đoạn. Độ dài mỗi phân đoạn video bằng 2 giây. Băng thông được chia thành
10 mức (W = 10). Xác suất ban đầu po là vectơ 1 × N với các giá trị được
đặt là 1/N . Kích thước bộ đệm được đặt là 5 phân đoạn. Mức sử dụng bộ
đệm tối ưu được đặt là 4 phân đoạn.

2.6.2. Đánh giá thực nghiệm
1. Đánh giá sự thích ứng. Các giải pháp được đánh giá trên băng thông
được lấy từ một mạng di động thực tế [27]. Video Tokyo Olympic
gồm 9 phiên bản có độ dài L bằng 300 phân đoạn. Sự thích ứng chất
lượng của giải pháp đề xuất, giải pháp SDP và giải pháp BE lần lượt
được thể hiện trong Bảng 2.1 Có thể thấy rằng giải pháp BE ít hiệu
quả hơn so với giải pháp đề xuất về việc cải thiện QoE. Cụ thể, Aq
và Asw của giải pháp BE lần lượt là 7.85 và 0.43 trong khi Aq và
Asw của giải pháp đề xuất lần lượt là 7.88 và 0.18. Đối với giải pháp
thích ứng dựa trên SDP, rõ ràng thông số ảnh hưởng đến QoE của
giải pháp này là xấu nhất với chất lượng trung bình thấp nhất (7.40)
và biên độ nhảy mức chất lượng trung bình cao nhất(0.76).
Bảng 2.1: Thống kê kết quả thích ứng của các giải pháp
Tham số SDP BE Đề xuất
Ab (s)
8.62 8.85 8.52
Aq
7.40 7.85 7.88
Asw
0.76 0.43 0.18
P rund
0.00 0.00 0.00

2. Đánh giá các mô hình dự đoán các tham số ảnh hưởng đến QoE.
Ngữ cảnh dùng một băng thông có sẵn
Lưu lượng được lấy từ mạng di động [27] được dùng làm băng thông
cho mô hình toán trong việc thống kê băng thông đồng thời được
dùng trong mô phỏng. Bảng 2.2 thống kê chi tiết các kết quả thực
nghiệm trong ba trường hợp lựa chọn giá trị cho phiên bản lớn nhất:
Vmax = 7, Vmax = 8 hoặc Vmax = 9. Dễ dàng nhận thấy rằng không
có sự khác nhau nhiều giữa thông số chất lượng được dự đoán và
thông số chất lượng được đo đạc. Đặc biệt, khi phiên bản lớn nhất
(Vmax ) càng nhỏ thì hệ thống dự đoán gần như chính xác các thông
số ảnh hưởng đến QoE.
13


Bảng 2.2: Ngữ cảnh dùng một băng thông có sẵn
Tham số Vmax = 9
Vmax = 8
Vmax = 7
Dự Mô Dự Mô Dự Mô
đoán phỏng đoán phỏng đoán phỏng
Ab (s)
9.48 8.52 9.59 8.77 9.8 9.68
Aq
7.64 7.88 7.45 7.73 6.48 6.87
Asw
0.30 0.18 0.14 0.09 0.03 0.02
P rund
0.01 0.00 0.006 0.00 0.00 0.00
Ngữ cảnh dùng các lưu lượng lịch sử
Ngữ cảnh này sử dụng hai băng thông lịch sử được ghi lại từ hai phiên

streaming của máy khách, trong đó một băng thông được dùng cho
mô hình toán và một băng thông dùng cho mô phỏng. Bảng 2.3 thống
kê chi tiết các kết quả thực nghiệm trong ba trường hợp lựa chọn giá
trị cho phiên bản lớn nhất: Vmax = 7, Vmax = 8 hoặc Vmax = 9. Có
thể thấy mô hình toán dự đoán khá chính xác các thông số chất lượng
video so với mô phỏng.
Bảng 2.3: Ngữ cảnh dùng các lưu lượng lịch sử
Tham số Vmax = 9
Vmax = 8
Vmax = 7
Dự Mô Dự Mô Dự Mô
đoán phỏng đoán phỏng đoán phỏng
Ab (s) 9.52 8.44 9.61 8.85 9.69 9.65
Aq
7.48 7.92 7.27 7.71 6.80 6.98
Asw
0.31 0.19 0.18 0.11 0.08 0.05
P rund 0.00 0.00 0.00 0.00 0.00 0.00

2.7. Kết luận chương
Trong chương này, luận án đã đề xuất một giải pháp thích ứng chất lượng
cho streaming video dạng VBR qua HTTP sử dụng lập trình động ngẫu
nhiên (SDP) đồng thời đề xuất các mô hình toán học để dự đoán trước
các thông số ảnh hưởng đến QoE. Thực nghiệm trong hai ngữ cảnh offline
và trực tuyến cho thấy: (i) giải pháp đề xuất thích ứng tốt với với biến
động mạnh của thông lượng mạng và sự biến động của tốc độ bit video,
(ii) thông số ảnh hưởng đến QoE được dự đoán bằng mô hình toán tương
đối khớp với thông số được đo đạc từ mô phỏng.

14

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

3.1. Giới thiệu chương
Trong chương này, một mô hình thỏa hiệp giữa chất lượng cảm nhận và độ
trễ ban đầu [29] được sử dụng để tìm ra mức chất lượng thích ứng tốt nhất
cho một video ứng với một mức băng thông được cấp cho video đó. Sau đó,
một thành phần trong mạng đóng vai trò phân bổ băng thông và lựa chọn
mức chất lượng video phù hợp cho từng máy khách nhằm cải thiện QoE.

3.2. Mô hình thỏa hiệp giữa chất lượng video và độ
trễ
Mô hình thỏa hiệp giữa chất lượng cảm nhận và độ trễ đề xuất trong [29]
được thực hiện bằng cách thay thế một số phân đoạn có tốc độ bit cao của
một mức chất lượng bằng các phân đoạn tương ứng ở mức chất lượng thấp
hơn. Mục đích của mô hình là hạ tốc độ bit đại diện và/hoặc giảm độ trễ
ban đầu trong khi chất lượng video tổng thể không bị ảnh hưởng nhiều.
Giả sử video C gồm M mức chất lượng {Vi , 1 ≤ i ≤ M }. Mỗi mức
chất lượng Vi có chất lượng QPi và gồm N phân đoạn với tốc độ bit
{Bij , 1 ≤ j ≤ N }. Các tác giả trong [29] đã định nghĩa một hàm p( ) như
sau. Đặt V ∗ là mức chất lượng thích ứng tương ứng với một hàm p( ). Tại
mỗi phân đoạn, nếu tốc độ bit của nó lớn hơn thì phân đoạn đó được thay
thế bởi một phân đoạn tương ứng ở mức chất lượng thấp hơn gần nhất mà
có tốc độ bit nhỏ hơn .
15

Ngưỡng tốc độ bit có thể nhận một số giá trị rời rạc. Với mỗi hàm
p( ), ta tìm được một mức chất lượng thích ứng V ∗ có chất lượng Q∗ và độ
trễ ban đầu d0∗ , với một tốc độ bit đại diện R bằng mức băng thông được
cấp. Tìm p( ) sao cho lợi ích U của người dùng là lớn nhất, với giới hạn độ
trễ là DT . Lợi ích U được định nghĩa là hàm bù trừ giữa chất lượng video
và độ trễ ban đầu:
U = f (Q∗ , d0∗ ).

(3.2)

Mô hình này tìm ra một phiên bản video thích ứng mang lại giá trị lợi
ích cao nhất cho người dùng, ứng với một mức băng thông được cấp cho
video. Luận án sử dụng mô hình này bối cảnh streaming đồng thời nhiều
video qua đường truyền có băng thông giới hạn.

3.3. Streaming đồng thời nhiều video VBR qua HAS
3.3.1. Mô tả vấn đề
Kiến trúc hệ thống đề xuất được trình bày trong Hình 3.2 với nhiều video
VBR được lưu tại máy chủ. Thông tin về từng video (phiên bản thích ứng,
độ trễ ban đầu, lợi ích của người dùng tương ứng với từng mức băng thông
có thể được cấp cho từng video) được lưu trong tệp MPD. Một thuật toán
tối ưu được đặt tại khối điều khiển với mục đích xác định phiên bản thích
ứng cho từng video sao cho tối đa hóa lợi ích trung bình của người dùng.
Khối điều
khiển

Backbone

Bo�leneck

Các máy khách
Các máy chủ
Tòa nhà, trường học

Hình 3.2: Hệ thống streaming nhiều video

Giả sử hệ thống streaming đồng thời H video tới các máy khách. Mỗi
video Vi có thể được cấp Ki mức băng thông khác nhau. Băng thông tại
mỗi mức ki được ký hiệu bởi ri (ki ),(ki ∈ [1; Ki ]). Tại mỗi mức băng thông
được cấp ri (ki ), ta có phiên bản thích ứng tốt nhất Vi∗ (ki ) mang lại giá trị
lợi ích u∗i (ki ) cao nhất, ứng với ngưỡng tốc độ bit ∗i (ki ).
Tìm {Vi∗ (ki )} cho tất cả các video Vi (ki ∈ [1; Ki ] , i ∈ [1; H]) sao cho
tối đa hóa lợi ích trung bình U , cụ thể:
16


H

wi × u∗i (ki )), i ∈ [1; H] , ki ∈ [1; Ki ],

U = max(

(3.10)

i=1

với điều kiện
H

ri (ki ) ≤ RT , i ∈ [1; H] , ki ∈ [1; Ki ],

(3.11)

i=1

và
d0∗i (ki ) ≤ DT , i ∈ [1; H] , ki ∈ [1; Ki ].

(3.12)

3.3.2. Giải pháp phân bổ băng thông và thích ứng chất lượng
1. Xử lý offline tại máy chủ. Trong khâu này, mô hình thỏa hiệp giữa
chất lượng hình ảnh và độ trễ được áp dụng cho tất cả các mức băng
thông khác nhau có thể được cấp cho từng video. Do đó, ta có thể
tạo ra một cơ sở dữ liệu chứa những thông tin của tất cả các phiên
bản thích ứng tốt nhất tương ứng với tất cả các mức băng thông khác
nhau có thể được cấp cho tất cả các video. Cơ sở dữ liệu này được
lưu tại máy chủ, trong tệp MPD của các video và được cung cấp cho
khối điều khiển.
2. Xử lý trực tuyến tại khối điều khiển. Dựa trên tệp MPD của tất cả
các video, thuật toán tại khối điều khiển tìm phiên bản thích ứng
cùng với băng thông được cấp cho từng video sao cho tối đa hóa lợi
ích U trong biểu thức (3.2) thỏa mãn (3.3) và (3.4).

3.3.3. Kết quả thực nghiệm và đánh giá
Trước hết, tác giả so sánh phương pháp đề xuất với phương pháp CSM về
lợi ích trung bình của người dùng khi streaming 5 video. Kết quả thể hiện
trên hình 3.5.
Tiếp theo, tác giả đánh giá sự tối ưu cũng như thời gian chạy của thuật

toán xử lý trực tuyến được đề xuất so với thuật toán Viterbi (Hình 3.7). Cả
hai thuật toán được triển khai trên C++ và thời gian chạy được đo trên
Window 8.1 notebook với CPU Intel i5-1.7GHz và bộ nhớ 6GB. Số luồng
video (H) thay đổi từ 5 đến 15 và được lựa chọn ngẫu nhiên từ 5 video trên.
Giả sử rằng băng thông được cấp là Rc = 800 ∗ H(kbps).
Hình 3.8 thể hiện thời gian chạy của thuật toán đề xuất với các số lượng
video khác nhau. Có thể thấy, thời gian chạy của thuật toán đề xuất chỉ

17


CSM

Đề xuất

5
4.5
4

Lợi ích (MOS)

3.5
3
2.5
2
1.5
1
2000

3000

4000

5000

6000

7000

8000

9000

10000

Băng thông (kbps)

Hình 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.

Thời gian chạy (ms)

100000
1000
10
0.1
0.001
3

5

7

9

11

13

15

Số lượng video

Hình 3.7: Thời gian chạy của thuật toán đề xuất và thuật toán Viterbi
200

Thời gian chạy (ms)

180
160
140
120
100
80
60
40
20
0
0

5000

10000

15000

20000

25000

30000

35000

Số lượng video

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

tính bằng đơn vị ms ngay cả khi số lượng luồng video lên đến hàng nghìn.
Do đó, thuật toán đề xuất có thể được dùng trong hệ thống streaming lớn.

3.4. Kết luận chương
Trong chương này, một thuật toán offline thực hiện tại máy chủ để tìm ra
các phiên bản thích ứng tốt nhất tương ứng với các mức băng thông được
cấp cho video. Sau đó, một thuật toán online được thực hiện tại khối điều
khiển trong một thành của mạng để phân bổ băng thông và lựa chọn phiên
bản thích ứng phù hợp nhất cho tất cả máy khách nhằm tối đa hóa QoE.

18

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

4.1. Giới thiệu chương
Năm 2015, giao thức HTTP/2 ra đời cung cấp một số tính năng mới trong
đó tính năng Server Push có thể được sử dụng hiệu quả trong streaming
video. Trong chương này, tác giả đề xuất hai phương pháp thích ứng chất
lượng video dùng tính năng Server Push. Thứ nhất, tác giả lần đầu tiên
đề xuất một phương pháp thích ứng chất lượng trong streaming video qua
HTTP/2 với video dạng VBR. Thứ hai, tác giả đề xuất một cách tiếp cận
hiệu quả hơn nữa khi sử dụng tính năng Server Push cho HAS. Phương
pháp này có tên là Full Push, được áp dụng cho video dạng CBR.

4.2. Giải pháp cải thiện QoE trong streaming video
VBR qua HTTP/2
4.2.1. Giải pháp thích ứng chất lượng
Quyết định mức chất lượng
Giả sử rằng, sau khi gửi truy vấn i để yêu cầu Ni phân đoạn video tại
mức chất lượng Ii , máy khách nhận được tất cả N i phân đoạn video, mỗi
phân đoạn có độ dài τ giây. Mức sử dụng bộ đệm hiện tại là Bi , thông
lượng hiện tại là Ti . Khi đó, máy khách sẽ quyết định mức chất lượng Ii+1
và số lượng phân đoạn Ni+1 cho truy vấn tiếp theo i + 1.
Để lựa chọn mức chất lượng cho truy vấn tiếp theo, cần thiết phải dự
đoán thông lượng tương lai. Do tốc độ bit của video VBR biến động mạnh
19

nên cần sử dụng phương pháp dự đoán thông lượng đáp ứng nhanh để kịp
thời ứng phó [40]. Theo đó, thông lượng tại thời điểm nhận xong Ni phân
đoạn video của truy vấn hiện tại i được dùng làm thông lượng dự đoán cho
truy vấn kế tiếp.
Do tốc độ bit của video dạng VBR biến động rất mạnh, máy khách chỉ
biết tốc độ bit của các phân đoạn đã được nhận, và chúng thuộc về các
mức chất lượng video khác nhau. Do đó, sau khi nhận được phân đoạn có
chỉ số j, cần dự đoán (i) tốc độ bit của các phân đoạn thuộc các mức chất
lượng khác nhau tại cùng một chỉ số j và (ii) tốc độ bit tại phân đoạn j + 1
của tất cả các mức chất lượng. Các công việc này được thực hiện lần lượt
bởi phương pháp dự đoán tốc độ bit nội dòng và phương pháp dự đoán tốc
độ bit liên dòng được đề xuất trong [40].
Sau khi dự đoán thông lượng và tốc độ bit video, mức chất lượng video
được quyết định tăng, giữ ổn định hoặc giảm tương ứng với ba khoảng giá
trị với các ngưỡng [0; Blow ], [(Blow ; Bhigh ] và [Bhigh ; Bmax ] với Bmax là kích
thước của bộ đệm.
Quyết định số lượng phân đoạn cho mỗi truy vấn
Số lượng phân đoạn Ni+1 được lựa chọn để tối thiểu hóa hàm chi phí
C. Đây là tổng của chi phí liên quan đến truy vấn Crq và chi phí liên quan
đến bộ đệm Cbf .
C = α × Crq + (1 − α) × Cbf ,

(4.4)

với
1
,
Ni+1

(4.5)

Ni+1 × τ
,
Bi − Blow

(4.6)

Crq =
Cbf =

và α, (1 − α) lần lượt là trọng số của Crq và Cbf .

4.2.2. Kết quả thực nghiệm và đánh giá
Phương pháp đề xuất được đánh giá và so sánh với hai phương pháp đó
là Push-N được trình bày trong [44] và phương pháp AGG được đề xuất
trong [28]. Trong phương pháp Push-N, số lượng phân đoạn cho mỗi truy
vấn được cố định là N phân đoạn. Trong phương pháp AGG, tốc độ bit
được quyết định là tốc độ bit cao nhất mà nhỏ hơn thông lượng mạng dự
đoán.
20


Bảng 4.2: Thống kê kết quả thích ứng
Tham số
Push-N
AGG Đề xuất
N=1 N=2 N=3 N=4
Số lượng truy vấn
500 250 167 125 180
173

Mức chất lượng tb
5.62 5.68 5.68 5.70 5.74
5.8
Số lần giảm mức chất lượng
73
48
35
26
35
18
Mức sử dụng bộ đệm nhỏ nhất 12.9 12.6 9.9 4.0 5.7
11
Thống kê về kết quả thích ứng được trình bày trong Bảng 4.1. Thống
kê cho biết số lượng truy vấn, tốc độ bit trung bình, sự giảm mức chất
lượng và mức sử dụng bộ đệm.
Bảng 4.1 cho thấy phương pháp đề xuất vượt trội hơn các phương pháp
khác trong việc cân bằng giữa sự thích ứng chất lượng và overhead liên
quan đến lượng truy vấn.

4.3. Một cách sử dụng hiệu quả tính năng Server
Push
4.3.1. Mô tả chung
Máy khách

Máy chủ

Máy khách

Máy chủ

τ

…

RTT

…
τ

…

RTT/2

k phân đoạn

…
…

…
Thời gian

Thời gian

Thời gian

Thời gian

Hình 4.7: Cơ chế hoạt động của tính năng Server Push trong giải pháp đề xuất.

Hoạt động của hệ thống đề xuất được thể hiện trong Hình 4.1. Máy

khách gửi truy vấn quyết định mức chất lượng cho các phân đoạn sắp tải
về. Máy chủ đẩy liên tục phân đoạn cho đến khi nhận được truy vấn mới
của máy khách. Cần quyết định bitrate mới tại thời điểm sau khi nhận nốt
21


k phân đoạn của bitrate cũ. Quyết định bitrate dựa vào thông lượng dự
đoán và mức sử dụng bộ đệm.
Giả sử sau khi tải xong phân đoạn Si có chỉ số mức chất lượng là Ii ,
máy khách gửi truy vấn để thay đổi mức chất lượng cho các phân đoạn
tiếp theo. Khi đó, máy khách có thể phải nhận thêm k phân đoạn với tốc
độ bit cũ cho đến khi máy chủ nhận được truy vấn của máy khách. Do đó,
máy khách cần quyết định tốc độ bit mới cho các phân đoạn bắt đầu từ
phân đoạn Si+k+1 , không phải là phân đoạn kế tiếp Si+1 như các phương
pháp khác đã thực hiện.
Do máy chủ đẩy liên tiếp các phân đoạn sau khi nó nhận được truy vấn
của máy khách, hiện tượng tràn bộ đệm có thể xảy ra nếu tốc độ bit của
các phân đoạn được tải về cao hơn tốc độ hiển thị video. Để tránh tràn
bộ đệm, thông báo steady state được máy khách gửi tới máy chủ khi mức
sử dụng bộ đệm hiện tại lớn hơn Bmax − RT2 T giây. Khi đó, máy chủ sẽ
định kỳ gửi từng phân đoạn video tới máy khách sau mỗi khoảng thời gian
là độ dài một phân đoạn. Khi mức sử dụng bộ đệm nhỏ hơn hoặc bằng
Bmax − RT2 T giây, thông báo loading state sẽ được gửi và sau đó máy chủ
đẩy liên tục các phân đoạn video tới máy khách.
e , luận án sử dụng phối hợp cả hai cách dự
Để dự đoán thông lượng Ti+1
đoán thông lượng được trình bày trong 1.2.3, đó là thông lượng của phân
s .
đoạn vừa được tải xong Ti và thông lượng trung bình Ti+1

4.3.2. Thuật toán thích ứng chất lượng
Để quyết định mức chất lượng cho mỗi truy vấn, luận án đề xuất bốn trường
hợp, đó là tăng, giữ ổn định, giảm và trường hợp nguy hiểm tương ứng khi
máy khách tăng, duy trì, giảm hoặc lựa chọn mức chất lượng thấp nhất.
Khi đó, bộ đệm được chia thành bốn khoảng giá trị bởi các ngưỡng Bmin ,
Blow và Bhigh (Bmin < Blow < Bhigh < Bmax ) với Bmax là kích thước bộ
đệm. Khoảng bộ đệm từ Blow đến Bhigh được coi là khoảng an toàn với tốc
độ bit video được duy trì ổn định. Khi mức sử dụng bộ đệm tương lai thấp
hơn hoặc cao hơn khoảng này, tốc độ bit sẽ được giảm hoặc tăng tương
ứng.

4.3.3. Thực nghiệm và đánh giá kết quả
Tất cả các phương pháp được đánh giá khi streaming đoạn video gồm 550
phân đoạn, với RTT bằng 100ms và băng thông được mô tả ở trên. Hình
4.2 thể hiện kết quả thích ứng của các phương pháp. Để rõ ràng, sự so sánh
tốc độ bit của tất cả các phương pháp được thể hiện trong Hình 4.2a, 4.2b,
22


4.2c. Hình 4.2d thể hiện sự thay đổi mức sử dụng bộ đệm của các phương
pháp trong suốt phiên streaming.

3000

Thông lượng

Push 1

Push 8

3000

Đề xuất

Thông lượng

2500

2000

Bitrate (kbps)

Bitrate (kbps)

2500

1500
1000
500

Push 4

Push 12

Đề xuất

2000
1500
1000
500

0

0

0

50

100

150

200

250
300
Thời gian (s)

350

400

450

500

550

0

(a) Push 1, Push 8 and phương
pháp đề xuất.

3000

Throughput

50

100

150

200

250
300
Thời gian (s)

350

400

450

500

550

(b) Push 4, Push 12 and
phương pháp đề xuất.

Adapt-N method

Proposed method

Bitrate (kbps)

2500
2000
1500
1000
500
0
0

50

100

150

200

250
300
350
Time (seconds)

400

450

500

550

(c) Phương pháp Adapt-N and
phương pháp đề xuất.

Hình 4.10: Kết quả thích ứng của tất cả các phương pháp.

4.4. Kết luận chương
Trong chương đã trình bày hai đề xuất sử dụng tính năng Server Push của
HTTP/2 trong streaming thích ứng video. Đề xuất thứ nhất được áp dụng
cho streaming video dạng VBR. Trong đề xuất này, máy khách quyết định
mức chất lượng và số lượng phân đoạn cho mỗi truy vấn. Trong đề xuất
thứ hai, một cách tiếp cận mới của tính năng Server Push áp dụng cho
streaming video dạng CBR có tên là Full Push, được triển khai trong đó
máy khách chỉ quyết định mức chất lượng cho mỗi truy vấn. Một thuật
toán thích ứng dựa trên thông lượng và mức sử dụng bộ đệm tương lai
được đề xuất để quyết định mức chất lượng phù hợp với điều kiện mạng.

23