Truyền video dùng giao thức điều khiển tắc nghẽn đa đường (tt)

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG
---------------------------------------

VŨ DUY KHÁNH

TRUYỀN VIDEO DÙNG GIAO THỨC
ĐIỀU KHIỂN TẮC NGHẼN ĐA ĐƯỜNG
CHUYÊN NGÀNH :

HỆ THỐNG THÔNG TIN

MÃ SỐ:

60.48.01.04

0

LUẬN VĂN THẠC SĨ KỸ THUẬT

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. VÕ THỊ LƯU PHƯƠNG

TP.HỒ CHÍ MINH – 2016


Luận văn được hoàn thành tại:
HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

Người hướng dẫn khoa học: TS. Võ Thị Lưu Phương

Phản biện 1: ………………………………………………
Phản biện 2: ………………………………………………

Luận văn sẽ được bảo vệ trước Hội đồng chấm luận văn thạc sĩ tại Học
viện Công nghệ Bưu chính Viễn thông
Vào lúc: ... giờ .... ngày ..... tháng .... năm ….....
Có thể tìm hiểu luận văn tại:
- Thư viện của Học viện Công nghệ Bưu chính Viễn thông


1

MỞ ĐẦU
Hiện nay, nhu cầu sử dụng thiết bị di động đã trở nên rất phổ biến không chỉ ở Việt
Nam mà trên toàn thế giới. Trong những năm gần đây, những thiết bị di động như điện thoại
thông minh (smartphone), máy tính bảng (tablet), máy tính xách tay (laptop) đều hỗ trợ kết
nối băng thông rộng như : ADSL, WiFi, 3G/4G, LTE. Các ứng dụng ngày nay cũng đòi hỏi
nhiều dung lượng, cho nên nhu cầu băng thông cần được tăng lên. Theo các nghiên cứu gần
đây [1], lưu lượng dữ liệu di động sẽ tăng trưởng một cách mạnh mẽ từ năm 2010 đến năm
2015, gần như tăng gấp đôi mỗi năm. Trong đó, video chiếm 65% tổng số lưu lượng dữ liệu
di động vào năm 2015.
Video trực tuyến trên mạng Internet đã trở nên phổ biến trong những năm qua. Tuy
nhiên, các giải pháp video trực tuyến luôn bị hạn chế bởi việc họ sử dụng một đường mạng
duy nhất. Dynamic Adaptive Streaming over HTTP (DASH) [23] là một giao thức thích ứng
dòng, nó cho phép dòng video chuyển đổi giữa các tốc độ bit dựa trên hiệu suất mạng, để điều
tiết việc thay đổi băng thông và sử dụng băng thông hiện có hiệu quả hơn.
Đa số các thiết bị đầu cuối hiện nay được trang bị nhiều công cụ kết nối bằng nhiều
đường, nhưng thông tin liên lạc thường được giới hạn bởi một con đường duy nhất cho mỗi
lần kết nối. Sử dụng tài nguyên trong hệ thống sẽ hiệu quả hơn nếu được sử dụng đa đường
kết nối đồng thời. Giao thức Multipath TCP của tổ chức IETF [2], nhằm phát triển và mở
rộng thêm các đặc điểm từ giao thức TCP, cho phép một kết nối TCP phân chia thành nhiều
luồng con và phân bổ lưu lượng thông qua những luồng con riêng biệt. Mục tiêu của giao

thức này là sử dụng nhiều đường đồng thời giữa hai thiết bị đầu cuối nhằm cải thiện đáng kể
hiệu suất cho nhu cầu truyền tải hiện nay.
Chính vì những yêu cầu cấp thiết trên, tôi xin chọn đề tài nghiên cứu : “ Truyền video
dùng giao thức điều khiển tắc nghẽn đa đường ”.
 Mục tiêu nghiên cứu của luận văn:
-

Xây dựng mô hình kiểm thử video streaming dùng giao thức MPTCP.

-

Viết hoặc chỉnh sửa chương trình MPEG-DASH player để có thể giám sát các thông
số về chất lượng khi truyền video.

-

Đo đạt và phân tích chất lượng khi truyền video trên MPTCP.

-

Đề xuất các phương án khắc phục những nhược điểm khi truyền video trên MPTCP.


2
Với mục tiêu nghiên cứu trên, đối tượng nghiên cứu của luận văn là như sau: tìm hiểu
giao thức truyền tải đa đường MPTCP, tìm hiểu video streaming dùng HTTP, MPEG-DASH,
chỉnh sửa player để đánh giá và cải tiến chất lượng video khi truyền trên giao thức MPTCP.
 Phạm vi nghiên cứu :
-

Nghiên cứu giao thức điều khiển tắc nghẽn đa đường MPTCP: nguyên lý điều khiển
và kiến trúc của MPTCP.

-

Tìm hiểu và nghiên cứu video streaming dùng HTTP, MPEG-DASH: bộ thích ứng
(adaptation set), trình diễn (representation), phân đoạn video (segment), mô tả tập tin
MPD (media presentation description)

-

Xây dựng hệ thống kiểm thử video streaming MPEG-DASH trên MPTCP.

-

Phân tích và đánh giá kết quả đo lường khi truyền video trên MPTCP.

-

Đề xuất phương pháp cải tiến player trên giao thức MPTCP.
Luận văn gồm 3 chương tập trung nghiên cứu những vấn đề sau:
Chương 1: Tổng quan về giao thức MPTCP
Chương 2 : Tồng quan video streaming dùng HTTP
Chương 3 : Thực nghiệm và đánh giá


3

Chương 1 - TỔNG QUAN VỀ GIAO THỨC MPTCP
1.1 Tổng quan về giao thức MPTCP

Multipath TCP là sự cải thiện từ TCP cho phép tận dụng triệt để nguồn tài nguyên
nhằm đảm bảo máy tính kết nối mạng trên nhiều đường mà không cần phải thay đổi giao diện.
MPTCP cải thiện băng thông, điều khiển tắc nghẽn tốt hơn so với TCP thông thường bằng
cách cho phép nhiều luồng con gửi gói tin trên đường truyền. Về khía cạnh ứng dụng,
multipath TCP cải thiện chất lượng băng thông bằng việc sử dụng nhiều đường, một kết nối
multipath TCP có băng thông tốt hơn so với kết nối TCP ở trạng thái tốt nhất. Ngoài ra, một
cơ chế cho giao thức điều khiển tắc nghẽn đa đường là khả năng phục hồi (độ sẵn sàng cao):
khi một luồng con mất kết nối thì nó sẽ chuyển dữ liệu sang luồng con khác. Thêm vào đó,
multipath TCP có chức năng hợp nhất tài nguyên nhằm giải quyết vấn đề tắc nghẽn bằng cách
chuyển dữ liệu qua các con đường ít tắc nghẽn hơn [2].

1.2 Nền tảng kiến trúc MPTCP
Phần này trình bày kiến trúc tầng vận chuyển, là một cơ sở để xây dựng một MPTCP
hiệu quả và các thành phần chức năng được sử dụng trong thiết kế MPTCP. Kiến trúc được
sử dụng là Tng (Transport next-generation, “ tầng vận chuyển thế hệ mới ”). Tng không phải
là kiến trúc duy nhất hỗ trợ MPTCP, nó là sự kết hợp từ việc nghiên cứu và phát triển nhiều
kiến trúc có hỗ trợ MPTCP [2]. Các chức năng chính của Tng được thể hiện trong hình 1.1
bên dưới.

Hình 1.1: Mô hình phân chia chức năng của Tng

Tng chia tầng vận chuyển thành 2 phần: hướng ứng dụng và hướng mạng. Hướng ứng
dụng (lớp ngữ nghĩa): chức năng chính là hỗ trợ và bảo vệ các thông tin liên lạc tại đầu cuối.
Trong khi tầng hướng mạng thực hiện các chức năng như nhận dạng thiết bị đầu cuối (trên cơ


4
sở xác định số cổng) và điều khiển tắc nghẽn. Các chức năng này cũng đã được chứng minh
trong thực tế để có thể kết nối chặt chẽ với các nhà khai thác mạng và các thiết bị trung gian
như trong hình 1.2 bên dưới [2].

Hình 1.2: Các thiết bị trung gian trong mô hình mạng Internet thế hệ mới

Dựa trên nền tảng là mô hình Tng đã được chúng tôi phân tích ở phần trước, chúng tôi
chia MPTCP thành 2 tầng con để kết nối với nhau thông qua một giao diện được xác định.
Kiến trúc của MPTCP được thiết kế theo mô hình phân chia Tng như hình 1.3.
Tầng con MPTCP có vai trò như một lớp ngữ nghĩa hướng ứng dụng, nó có khả năng
tương thích với lớp ứng dụng. Thành phần của luồng con TCP cung cấp khả năng tương thích
mạng và đóng vai trò như một luồ ng TCP thông thường trong mạng, cũng như tầng
Flow/Endpoint là thành phần hướng mạng [2].

Hình 1.3: Mối quan hệ giữa Tng(bên trái) và MPTCP(bên phải)

MPTCP hoạt động ở tầng vận chuyển và sự tồn tại của nó trở nên trong suốt đối với
các lớp cao hơn hoặc thấp hơn. MPTCP là giao thức được mở rộng từ TCP. Nó nằm dưới lớp
ứng dụng nhưng trong phần mở rộng thì MPTCP sẽ quản lý nhiều luồng con TCP dưới nó.
Để làm được điều này, nó phải thực hiện các chức năng sau:


5
 Quản lý đường dẫn
 Lập lịch cho các phân đoạn
 Giao diện luồng con
 Điều khiển tắc nghẽn
1.3 Nguyên lý điều khiển

Cân bằng tải trên giao thức MPTCP
Cải thiện băng thông
Công bằng và truyền đơn đường
1.4 Hoạt động của MPTCP

Tất cả các hoạt động MPTCP được báo hiệu khi sử dụng các tùy chọn của trường
header TCP. Một số tùy chọn TCP đã được công nhận bởi IANA cho MPTCP được thể hiện
trong bảng 1.1 dưới đây.
Bảng 1.1: Bảng thông tin của giao thức MPTCP

Tên bản tin

Ký hiệu bản tin

Giá trị

Giải thích ý nghĩa

MP_CAPABLE

Multipath Capable

0x0

Tuyên bố có hỗ trợ MPTCP khi
thiết lập kết nối.

MP_JOIN

Join Connection

0x1

Yêu cầu gia nhập kết nối MPTCP
hiện tại, có thể yêu cầu thao tác

bắt tay hợp lệ để chứng thực.

DSS

Data Sequence

0x2

Ánh xạ thứ tự dữ liệu khi truyền
đa đường MPTCP, kiểm tra

Signal

checksum, báo nhận ACK.
ADD_ADDR

Add Address

0x3

Thông báo các host khác về địa
chỉ mới có sẵn.

REMOVE_ADDR

Remove Address

Yêu cầu điều khiển và xóa bớt
một luồng con cụ thể.

6

Thiết lập kết nối MPTCP
Khởi tạo luồng con
Ánh xạ số thứ tự dữ liệu
Đóng một kết nối MPTCP
1.5 Các vấn đề nghiên cứu liên quan đến MPTCP
1.6 Kết luận chương 1
Chương này giới thiệu tổng quan về nền tảng kiến trúc của giao thức truyền tải đa
đường MPTCP, tìm hiểu các nguyên lý điều khiển và hoạt động của giao thức MPTCP. Từ
đó, đưa ra các ứng dụng truyền video trên giao thức truyền tải đa đường MPTCP.

Chương 2 - TỔNG QUAN VIDEO STREAMING DÙNG HTTP
2.1 Giới thiệu video streaming
Adaptive bitrate (ABR) là một kỹ thuật truyền dữ liệu đa phương tiện thông qua mạng
máy tính. Kỹ thuật này thực hiện bằng nguyên lý dựa trên sự dò tìm chất lượng đường truyền
của người dùng và thời gian thực sử dụng CPU, sau đó sẽ cân chỉnh chất lượng video cho phù
hợp trước khi truyền tải (đến) cho người dùng nhằm đảm bảo truyền tải video với chất lượng
tốt nhất. Kỹ thuật ABR đòi hỏi một bộ mã hóa có thể mã hóa được chất lượng bitrate đầu vào
thành nhiều bitrate chất lượng từ thấp đến cao. Người dùng có thể chuyển đổi giữa các tỉ lệ
bitrate khác nhau.
Năm 2010, MPEG nghiên cứu và phát triển một công nghệ mới dựa trên kỹ thuật
truyền tải Adaptive bitrate. Năm 2011 nó trở thành một tiêu chuẩn quốc tế. Công nghệ này
được đặt tên là Dynamic Adaptive Streaming over HTTP (DASH) - công nghệ truyền tải đa
phương tiện thông qua HTTP bằng kỹ thuật tương thích.

2.2 Tổng quan adaptive streaming dựa trên nền tảng HTTP
Tổng quan
Công nghệ MPEG - DASH sử dụng HTTP/1.1 (giao thức phi trạng thái) để cung cấp

dịch vụ truyền tải nội dung đa phương tiện từ máy chủ đến người dùng. Công nghệ này tận
dụng cực kỳ tốt lợi thế của cơ sở hạ tầng internet hiện nay được thể hiện trong hình 2.2 bên
dưới [10].


7
 Triển khai sử dụng rộng rãi tiêu chuẩn HTTP servers và tiêu chuẩn HTTP để
phân phối nội dung đa phương tiện.
 Truyền tải đơn giản qua tường lửa và NAT.
 Cung cấp cho người dùng chức năng thay đổi chất lượng các nội dung truyền
thông đa phương tiện một cách tự động tương ứng với thay đổi băng thông hợp
lệ mà ko cần thương lượng với nhà cung cấp máy chủ.
 HTTP dựa trên CDNs sử dụng trên nền tảng phân phối thông dụng để cung cấp
công nghệ truyền dữ liệu đa phương tiện tốt hơn trên các thiết bị di động.

Hình 2.2: Kiến trúc phân phối nội dung dựa trên HTTP Streaming

Mô tả hệ thống MPEG - DASH
Hình 2.3 bên dưới mô tả một cách chi tiết mô hình của hệ thống MPEG-DASH:
 Bảng mô tả trình diễn media (MPD) là một tập tin xml, được mô tả bằng cấu
trúc thu thập chuỗi phân đoạn được tiếp cận thông qua DASH client nhằm cung
cấp thông tin truyền tải media đến cho người dùng. MPD bao gồm phân đoạn
cơ sở HTTP - URL, là một thu thập các phiên bản khác nhau của nội dung media
được mã hóa.
 Định dạng của phân đoạn xác định các tập đính kèm trong HTTP và yêu cầu
phản hồi đến client một HTTP GET. Các phân đoạn bao gồm dữ liệu media
được mã hóa với các phiên bản khác nhau được định nghĩa trong bảng mô tả
trình diễn media.
 Giao thức phân phối HTTP/1.1
 Mô tả cơ bản chỉ ra cách thức DASH client xử lý các thông tin và nguồn dữ liệu

để truyền tải nội dung media.


8

Hình 2.3: Thành phần của tiêu chuẩn DASH [11]

Mô tả tập tin MPD
Một bộ thu thập các phiên bản nội dung media mã hóa khác nhau được tiếp cận thông
qua DASH client và mô tả chi tiết của các định dạng trình diễn media. Hình 2.4 bên dưới chỉ
ra các mô hình dữ liệu của MPD [11]:
 Một chương trình trình diễn media chứa một chuỗi liên tục các Period theo thời
gian.
 Mỗi Period bao gồm một bộ Adaptation.
 Mỗi Adaptation bao gồm một chuỗi trình diễn nội dung media.
 Mỗi trình diễn bao gồm một chuỗi các phân đoạn media đại diện cho một
khoảng thời gian thu phát cụ thể.
 Mỗi HTTP-URL cơ bản của phân đoạn và định dạng được chứa đựng trong
thông tin của phân đoạn.

Hình 2.4: Mô hình phân cấp MPD [11]

Đối với DASH, mỗi phiên bản có chất lượng media khác nhau sẽ có dòng thời gian
trình diễn như nhau và được sơ đồ theo dòng thời gian phổ biến toàn cầu. Dòng thời gian này


9
được gọi là một màn trình diễn theo dòng thời gian, mỗi phân đoạn chiếm một phần cụ thể
trong dòng thời gian trình diễn được thể hiện như hình 2.5 dưới đây [11].

Hình 2.5: Mô hình làm việc Adaptive Dynamic Streaming

DASH cũng hỗ trợ dịch vụ truyền tải trực tuyến. Trong trường hơp này, trình diễn
media sẽ được mô tả bằng MPD gốc và MPD cập nhật. Phân đoạn trở nên sẵn sàng với khoảng
thời gian như nội dung đã sản xuất, và MPD cập nhật mô tả thông tin của các phân đoạn sẵn
sàng cho Dash client để tiếp nhận thông qua HTTP/1.1. Bằng phương pháp cập nhật và theo
dõi MPD nhằm đảm bảo tương thích với các MPD trước.
Mỗi trình diễn bao gồm một phân đoạn khởi tạo và một chuỗi các phân đoạn media.
Tuy nhiên, trong trường hợp phân đoạn khởi tạo không xuất hiện, thì mỗi phân đoạn media
sẽ tự khởi tạo. Có 4 loại phân đoạn.
 Phân đoạn khởi tạo cung cấp thông tin đầy đủ về nội dung media và xác định
các định dạng tập tin media có thể được nhận dạng bằng DASH client.
 Phân đoạn media bao gồm các thành phần media được mô tả thông qua phân
đoạn media và phân đoạn khởi tạo.
 Danh mục phân đoạn bao gồm danh mục thông tin của phân đoạn media.
 Phân đoạn chuyển đổi bitstream bao gồm dữ liệu cần thiết cho việc chuyển đổi
trình diễn trong quá trình khởi chạy.

2.3 Giới thiệu tổng quan phương pháp adaptation
Adaptation được chúng tôi thảo luận và phân loại thành 2 phương pháp. Đầu tiên,
phương pháp thông lượng quyết định bitrate dựa trên việc ước tính thông lượng. Thứ hai,
phương pháp bộ đệm quyết định việc duy trì bitrate dựa trên các kích thước của bộ đệm.


10

Phương pháp thông lượng
Phương pháp thông lượng quyết định bitrate của phân đoạn tiếp theo dựa trên ước tính
thông lượng. Sự khác biệt chính của những phương pháp này là 1) phương pháp ước lượng
và 2) cách sử dụng thông lượng ước tính. Trong phần tiếp theo, thông lượng phân đoạn được

tính bằng tỉ lệ của kích thước phân đoạn chia cho thời gian tải về của phân đoạn đó. Thời gian
tải về của phân đoạn được tính từ lúc HTTP gửi yêu cầu đến server cho tới lúc byte cuối cùng
của phân đoạn được chuyển về client.
Phương pháp thông lượng sử dụng các thông số đo lường như bảng 2.1 dưới đây:
Bảng 2.1: Bảng các tham số đo lường

Ký hiệu

Giải thích

𝑇𝑒

throughtput ước lượng

i

Chỉ số của phân đoạn

𝑇 𝑒 (𝑖 + 1)

Thông lượng ước lượng của phân đoạn tiếp theo i+1

𝐵𝑒 (𝑖 + 1)

bitrate ước lượng của phân đoạn i+1 tiếp theo

t

Thời gian tải về của phân đoạn

𝜏

Độ dài của phân đoạn

𝛼

Là hệ số an toàn

𝑋̅

Thông lượng trung bình

Một trong những phương pháp thông lượng đơn giản nhất là phương pháp thông lượng
tức thời của phân đoạn, trong phương pháp này thông lượng ước lượng của phân đoạn tiếp
theo 𝑇 𝑒 (𝑖 + 1) được tính bằng thông lượng của phân đoạn trước đó T(i) [12].
𝑇 𝑒 (𝑖 + 1) = T(i).

(2.1)

Một phương pháp tiếp theo là phương pháp thông lượng trung bình. Tương tự như
(2.1) thì thông lượng ước lượng của phân đoạn tiếp theo 𝑇 𝑒 (𝑖 + 1) được tính bằng giá trị
trung bình của những thông lượng phân đoạn trước đó. Trong luận văn này, chúng tôi lấy giá
trị trung bình của n mẫu phân đoạn hợp lệ gần nhất để tính toán. Khi đó, thông lượng trung
bình được tính bằng tổng số phân đoạn trước đó chia cho số mẫu được chọn là n.
𝑛

∑
𝑋
𝑋 + 𝑋 +𝑋 +⋯+ 𝑋𝑛
̅

𝑋= 1 2 3
= 𝑖=1 𝑖
𝑛

𝑛

(2.2)

Để yêu cầu bitrate ước lượng tiếp theo thì 𝐵 𝑒 (𝑖 + 1) được tính bằng thông lượng ước
lượng tiếp theo 𝑇 𝑒 (𝑖 + 1) nhân với một hệ số an toàn 𝛼 [12][13].


11
𝐵𝑒 (𝑖 + 1) = (1 − 𝛼) × 𝑇 𝑒 (𝑖 + 1)

(2.3)

Trong đó, 𝛼 là hệ số an toàn và 𝛼 nằm trong khoảng [0, 0.5]. Công thức trên đảm bảo
cho phiên bản bitrate yêu cầu từ server có giá trị nhỏ hơn phân đoạn thông lượng ước lượng.
Nếu thời gian tải về của phân đoạn t mà nhỏ hơn độ dài phân đoạn 𝜏 thì chất lượng video ngày
càng tốt. Nếu thời gian tải về của phân đoạn t mà bằng với độ dài phân đoạn 𝜏 thì nó sẽ giữ
nguyên mức bitrate. Nếu thời gian tải về của phân đoạn t mà lớn hơn độ dài của phân đoạn 𝜏
thì client trở nên không an toàn lúc này xảy ra lỗi tràn bộ đệm và ngưng không trình chiếu
nữa và chờ cho đến khi bộ đệm giảm xuống thì client tiếp tục trình chiếu tiếp.

Phương pháp bộ đệm
Phương pháp bộ đệm quyết định việc duy trì một bitrate dựa trên các kích thước của
bộ đệm. Phương pháp bộ đệm cũng sử dụng thông lượng của các phân đoạn. Trong
[14][15][16], một bộ đệm được chia thành nhiều khoảng và nó có những hành vi khác nhau
được áp dụng khi một mức bộ đệm nằm trong các khoảng khác nhau.

Trong đó 𝐵1 , 𝐵2 , 𝐵3 , 𝐵𝑚𝑎𝑥 (0 < 𝐵1 < 𝐵2 < 𝐵3 < 𝐵𝑚𝑎𝑥 ) được gọi là ngưỡng của bộ đệm.
Lưu ý rằng các giá trị cụ thể của các ngưỡng bộ đệm còn phụ thuộc vào phương pháp thích
ứng. Phương pháp của [14] thì bộ đệm có 4 mức ngưỡng như sau : 𝐵3 𝐵𝑚𝑎𝑥 , 𝐵2 𝐵3 ,
𝐵1 𝐵2 , 0𝐵1 . Giả sử, nếu mức bộ đệm nằm trong khoảng 𝐵3 𝐵𝑚𝑎𝑥 thì bitrate sẽ được
chuyển lên một mức cao hơn so với phiên bản hiện tại với điều kiện các bitrate chuyển lên
tiếp theo phải nhỏ hơn thông lượng phân đoạn trước đó. Tiếp theo, nếu mức bộ đệm nằm
trong khoảng 𝐵2 𝐵3 thì mức bộ đệm tại mức này sẽ giữ nguyên phiên bản bitrate hiện tại.
Nếu mức bộ đệm nằm trong khoảng 𝐵1 𝐵2 thì bitrate sẽ giảm xuống mức thấp hơn so với
phiên bản hiện tại với điều kiện bitrate hiện tại phải cao hơn thông lượng phân đoạn trước
đó. Cuối cùng, nếu mức bộ đệm nằm trong khoảng 0𝐵1 thì nó sẽ chuyển sang phiên bản
bitrate thấp nhất.
Phương pháp [14] và [15] tương tự nhau và có thề duy trì một bitrate mượt dựa trên
yêu cầu của streaming. Phương pháp của [14] có vẻ ổn định hơn bởi các tiêu chí để duy trì
một bitrate dựa trên giới hạn của một mức độ bitrate (được xác định bởi các ngưỡng 𝐵2 và
𝐵3 ), hơn là phương pháp tính toán độ mượt thông lượng của [15]. Với phương pháp [16] nếu
mức bộ đệm nằm trong khoảng 35% ~ 50% của mức cao nhất, ước tính của thông lượng sẽ
tương tự như thông lượng trước đó. Nếu mức bộ đệm giảm xuống thấp, ước tính thông lượng
sẽ bằng với thông lượng trước đó nhân với một hệ số tỉ lệ giảm (hệ số có giá trị <1) .


12

2.4

Tổng quan adaptation của Dash.js
Sau đây, chúng tôi sẽ đi vào tìm hiểu cách hoạt động của client dash.js dựa theo mô

hình logic dash.js như hình 2.6 bên dưới :

Hình 2.6: Mô hình adaptation logic của Dash.js

Khi client khởi tạo kết nối đến server CDN thì quá trình khởi chạy ban đầu sẽ kiểm tra
xem đó có phải là giá trị GET lần đầu tiên hay không. Nếu nó là giá trị GET đầu tiên thì nó
sẽ cho một chất lượng bằng với giá trị mặc định, ngược lại không phải là giá trị đầu tiên thì
nó sẽ kiểm tra xem client đã sẵn sàng để trình chiếu chưa. Nếu client chưa sẳn sàng thì sẽ
quay trở lại và bắt đầu quá trình trình chiếu lại từ đầu, ngược lại nó sẽ thực hiện xử lý các
rule. Theo quan sát của chúng tôi, client mặc định hoạt động hỗn hợp trên bốn rule :
ThroughtputRule, BufferOccupancyRule, InsufficientBufferRule, AbandonRequestRule
trong quá trình trình chiếu. Chúng tôi sữa đổi Throughtput rule để kiểm chứng chất lượng
video trên môi trường truyền đa đường. Tiếp theo, throughtput rule chọn ra một chất lượng
video trước khi gửi yêu cầu đến server CDN, nếu server chấp nhận một kết nối thì nó sẽ phản
hồi cho client để tiến hành trình chiếu.
Trong phần tiếp theo, chúng tôi tìm hiểu và giới thiệu chi tiết về 4 rule hoạt động trên
mô hình adaptation logic của dash.js [22].


13

Phương pháp thông lượng của Dash
2.4.1.1 Throughtput rule

Hình 2.7: Mô hình hoạt động của Throughtput Rule

Phương pháp Throughput Rule như trong hình 2.7 giúp client quyết định số bitrate
cần thiết dựa trên ước tính thông lượng. Trong client Dash.js, thông lượng hoạt động và thực
thi theo những nguyên tắc sau : Đầu tiên lưu trữ những thông lượng của phân đoạn trước đó,
tiếp theo tính toán giá trị trung bình của thông lượng cho phân đoạn X (mặc định mẫu thử
bằng 3). Chúng tôi tiến hành lấy giá trị trung bình của 3 mẫu phân đoạn hợp lệ gần nhất để
tính toán. Khi đó, thông lượng trung bình được tính bằng tổng số phân đoạn trước đó chia cho
số mẫu được chọn (mặc định số mẫu của client đang chọn là 3) như trong hình 2.7 [22].

3

∑
𝑋
𝑋̅ = 𝑖=1 𝑖
3

(2.4)

Tiếp theo, chúng tôi đề xuất lấy giá trị trung bình của n mẫu phân đoạn hợp lệ gần nhất
để tính toán. Khi đó, thông lượng trung bình được tính bằng tổng số phân đoạn trước đó chia
cho số mẫu được chọn là n.
𝑛

∑
𝑋
𝑋̅ = 𝑖=1 𝑖
𝑛

(2.5)

Để yêu cầu bitrate ước lượng tiếp theo thì 𝐵 𝑒 (𝑖 + 1) được tính bằng thông lượng ước
lượng của phân đoạn tiếp theo 𝑇 𝑒 (𝑖 + 1) nhân với một hệ số an toàn 𝛼.
𝐵𝑒 (𝑖 + 1) = (1 − 𝛼) × 𝑇 𝑒 (𝑖 + 1)

(2.6)

Trong đó, 𝛼 là hệ số an toàn và 𝛼 = 0.9. Công thức trên đảm bảo cho phiên bản bitrate
yêu cầu từ server có giá trị sẽ nhỏ hơn phân đoạn thông lượng ước lượng. Như vậy thời gian
tải về của phân đoạn t sẽ luôn luôn nhỏ hơn độ dài của phân đoạn 𝜏.

14

2.4.1.2 Abandon request rule
Nguyên tắc Abandon yêu cầu theo dõi thông lượng thời gian thực của mỗi phân đoạn
tải xuống. Nếu thời gian tải xuống (ước tính) cao hơn nhiều lần (mặc định là 1.5 nhân với độ
dài phân đoạn) so với độ dài phân đoạn thì nó sẽ ngưng tải xuống ngay lập tức. Sau đó nó sẽ
tải lại phân đoạn đó ở mức chất lượng thấp hơn để tránh hiện tượng tràn bộ đệm. Mức chất
lượng mới được xem là phù hợp nhất dựa trên sự tính toán thông lượng của thời gian thực
trước đó (nó không dựa trên việc tính toán trung bình). Nguyên tắc này rất quan trọng trong
trường hợp băng thông tức thời bị giảm xuống. Nguyên tắc này đa số sử dụng để giảm mức
chuyển đổi [22].

Phương Pháp bộ đệm của Dash
Buffer Occupancy Rule : được phân loại như là một phương pháp dựa trên bộ đệm, nó
duy trì hoạt động trong client nhằm chuyển đổi phiên bản video lên phiên bản bitrate cao nhất
và dùy trì ở trạng thái này. Tuy nhiên, khi bộ đệm của hệ thống lớn hơn các ngưỡng
RICH_BUFFER_THRESHOLD (mặc định là 20s) thì nguyên tắc này sẽ được kích hoạt và
ghi đè lên throughtput rule [22].
Insufficient Buffer Rule : được phân loại như là một phương pháp bộ đệm. Nó trái
ngược hoàn toàn với Buffer Occupancy Rule. Trong client dash.js, chức năng đầu tiên của
nguyên tắc này là chuyển đổi phiên bản video xuống phiên bản bitrate thấp hơn trong điều
kiện bộ đệm hệ thống trong trạng thái trống rỗng. Nguyên tắc này là một giải pháp giúp client
yêu cầu một phiên bản video thích hợp nhất để tiếp tục streaming [22].

2.5 Các vấn đề nghiên cứu liên quan đến giải pháp Dash
2.6 Kết luận chương 2
Chương này tìm hiểu tổng quan về chuẩn MPEG-DASH như : mô tả hệ thống, mô hình
dữ liệu DASH và một số các mô tả phương tiện trình diễn. DASH là một tiêu chuẩn dành cho

việc điều phối linh hoạt các dòng video thông qua giao thức HTTP, nó có khả năng thay thế
các công nghệ hiện tại như : Smooth Streaming của Microsoft, HTTP Dynamic Streaming
(HDS) của Adobe, HTTP Live Streaming (HLS) của Apple. Bên cạnh đó, cũng giới thiệu và
mô tả kỹ thuật adaptation dựa trên phương pháp thông lượng và phương pháp bộ đệm. Tiếp
theo, chúng tôi tiến hành chỉnh sửa player Dash.js client, theo quan sát thì client mặc định
hoạt động chạy hỗn hợp trên bốn rule : ThroughtputRule, BufferOccupancyRule,


15
InsufficientBufferRule, AbandonRequestRule trong quá trình trình chiếu. Chúng tôi sữa đổi
Throughtput rule để kiểm chứng chất lượng video trên môi trường truyền đa đường.

Chương 3 - THỰC NGHIỆM VÀ ĐÁNH GIÁ
3.1 Mô tả video mẫu theo chuẩn Dash
Các số liệu được sử dụng trong thực nghiệm của chúng tôi là video “ Big Buck Bunny”
[24]. Đây là một đoạn phim hoạt hình có độ phân giải theo tỉ lệ khung hình khác nhau và thời
gian phát là 596 giây. Thời gian phát đoạn phim tương đối dài cho việc triển khai kiểm thử
chất lượng video. Độ dài của phân đoạn video bao gồm 1s, 2s, 4s, 6s, 10s, 15s, ví dụ phân
đoạn 6s có tốc độ bitrate tối thiểu là 46 Kbps và tốc độ bitrate tối đa là 3,9 Mbps, được thể
hiện chi tiết trong bảng 3-1.
Bảng 3.1: Mô tả tốc độ bitrate và tỉ lệ khung hình của phân đoạn 6s
Bitrate

Tỉ lệ khung hình

46 Kbps

320x240

89 Kbps

320x240

………

……….

1.2 Mpbs

1280x720

1.5 Mpbs

1280x720

………..

…………

3.6 Mpbs

1920x1080

3.9 Mpbs

1920x1080

3.2 Triển khai thực nghiệm
Chúng tôi xây dựng mô hình kiểm thử video streaming hoạt động trên cả MPTCP và
TCP. Mô hình được thể hiện trong hình dưới đây:

Hình 3.1: Mô hình kiểm thử video streaming trên giao thức MPTCP


16
 Ban đầu chúng tôi xây dựng một hệ thống Server cài hệ điều hành Ubuntu 14.04
phiên bản 64 bit có tính năng hỗ trợ truyền đa đường MPTCP. Sau đó, chúng
tôi tiến hành xây dựng hệ thống Web-server Apache trên máy server để xử lý
các truy cập được gửi từ máy khách thông qua giao thức HTTP. Web-server
được cấu hình cho các kết nối mạng khác nhau. Web-Server chứa các bộ dữ liệu
MPD, độ dài phân đoạn video bao gồm 1s, 2s, 4s, 6s, 10s, 15s.
 Tiếp theo, chúng tôi xây dựng một hệ thống Client cài hệ điều hành Ubuntu
14.04 phiên bản 64 bit có tính năng hỗ trợ truyền đa đường MPTCP. Tiếp theo,
chúng tôi sử dụng trình client dash.js phiên bản 2.1.1 chạy trên trình duyệt
chrome phiên bản 51.0 để trình chiếu và ghi lại các thông số biến đổi trong quá
trình đo lường, nhằm đánh giá chất lượng video trong quá trình truyền tải đa
đường.
 Tiếp theo, chúng tôi xây dựng hệ thống tường lửa dummynet được triển khai
dựa trên hệ điều hành FreeBSD 10.0 phiên bản 64bit. Dummynet là một công
cụ dùng để mô phỏng chất lượng mạng nhằm điều chỉnh giới hạn băng thông,
độ trễ và tỉ lệ mất gói tin . Chúng tôi, đưa ra các trường hợp như trong bảng 3.2
để mô phỏng chất lượng video dựa trên tỉ lệ băng thông giữa hai đường khác
nhau.
Bảng 3.2: Mô tả tỉ lệ băng thông giữa hai đường khác nhau

Băng thông

Băng thông

Tỉ lệ mất gói trên

đường 1

đường 2

2 đường

Trường hợp 1

1000Kbps

1000Kbps

1%

Trường hợp 2

1334Kbps

666Kbps

1%

Trường hợp 3

1600Kbps

400Kbps

1%

Trường hợp 4

1500Kbps

500Kbps

1%

Trường hợp 5

1666Kbps

334Kbps

1%

3.3 Tiêu chí đánh giá chất lượng video
Trong phần này, chúng tôi đánh giá chất lượng video dựa trên các phân đoạn 1s, 2s,
6s, 10s với thời gian kiểm thử 420 giây và tỉ lệ băng thông giữa hai đường khác nhau trong
môi trường truyền dẫn đa đường. Chúng tôi, tiến hành lấy giá trị của 3 mẫu thử trung bình để


17
kiểm thử, sau đó tăng số mẫu lên để so sánh chất lượng video. Việc đánh giá chất lượng video
của chúng tôi dựa trên bốn tiêu chí như sau :
 Thời gian video ở chất lượng tốt nhất
 Tổng số lần switch ảnh hưởng lớn đến chất lượng video
 Dựa trên số lần switch
 Dựa trên bitrate trung bình

Chúng tôi tiến hành đánh giá chất lượng video dựa trên các tiêu chí trên trong phần
tiếp theo của luận văn.

Thời gian video ở chất lượng tốt nhất
N=3

Thời gian video ở chất lượng tốt nhất

100%
90%
80%
70%
60%

TH 1
TH 2
TH 3
TH 4
TH 5

50%
40%
30%
20%
10%
0%
1

2

6

10

Phân đoạn

Hình 3.2(a): Sự thay đổi chất lượng video dựa trên độ dài phân đoạn
của 3 mẫu trung bình

Kết quả thể hiện trong hình 3.2(a) sự thay đổi chất lượng video của độ dài phân đoạn
video so với tỉ lệ băng thông giữa 2 đường khác nhau đều cho kết quả giảm dần đều. Chúng
tôi nhận thấy trường hợp phân đoạn 1s cho kết quả tệ nhất trong các phân đoạn của thực
nghiệm. Các phân đoạn còn lại cho chất lượng giảm dần nhưng không thực sự đáng kể.
Tiếp theo, Chúng tôi tiến hành chỉnh sửa và tăng mẫu thử lên 6 để so sánh xem chất
lượng của 6 mẫu thử có tốt hơn chất lượng của 3 mẫu thử hay không


18

N=6

Thời gian video ở chất lượng tốt nhất

100%
90%
80%
70%
60%

TH 1

50%

TH 2
TH 3

40%

TH 4

30%

TH 5

20%
10%
0%
1

2

Phân Đoạn

6

10

Hình 3.3(a): Sự thay đổi chất lượng video dựa trên độ dài phân đoạn
của 6 mẫu trung bình

Kết quả thể hiện trong hình 3.3(a) cho thấy ở trường hợp phân đoạn 1s luôn cho kết
quả giảm dần so với tỉ lệ băng thông giữa 2 đường khác nhau. Các độ dài phân đoạn còn lại
không có sự thay đổi rõ rệt (chất lượng luôn được giữ ở mức tương đương 100%). Điều này
cho thấy việc tăng số mẫu thử có hiệu quả trong việc cải thiện chất lượng video.
Nhận xét :
-

Đây là tiêu chí đầu tiên được đưa ra để đánh giá khi chất lượng của DASH ở
các điều kiện băng thông khác nhau trong môi trường truyền đa đường MPTCP.

-

Tỉ lệ phần trăm trong hình biểu thị phần trăm thời gian video ở chất lượng tốt
nhất so với tổng thời gian.

-

Chất lương video được đánh giá tốt nhất khi video luôn trình chiếu ở độ phân
giải 1280x720.

-

Trong khi đó, các phân đoạn 2s, 6s, 10s luôn cho video trình chiếu hoàn toàn ở
độ phân giải 1280x720 với tỉ lệ đạt được 100% trong quá trình thực nghiệm.

Tổng số lần switch ảnh hưởng đến chất lượng video
Tương tự tiêu chí 1, hình 3.4(a) cho thấy tổng số lần switch ảnh hưởng đến chất lượng
video dựa trên độ dài phân đoạn video so với tỉ lệ băng thông giữa 2 đường khác nhau. Chúng
tôi thấy rằng tỉ lệ băng thông giữa 2 đường khác nhau tại trường hợp 1 luôn cho chất lượng
khá tốt ở tất cả các phân đoạn. Ngược lại chất lượng tệ dần khi tỉ lệ băng thông giữa 2 đường

khác nhau tăng lên.


19
Chúng tôi khảo sát thì thấy rằng độ dài phân đoạn 1s luôn cho chất lượng video tệ nhất.
Ngược lại chất lượng của phân đoạn 6s luôn cho chất lượng video tốt nhất trong tất cả các
phân đoạn. Bên cạnh đó, độ dài phân đoạn 2s và 10s so với tỉ lệ băng thông giữa 2 đường

Tổng số lần switch ảnh hưởng đến chất lượng
video

khác nhau tại trường hợp 5 thì cho chất lượng tương đương nhau.

N=3
50.00%
45.00%
40.00%
35.00%
30.00%

TH 1

25.00%

TH 2

20.00%

TH 3

15.00%

TH 4

10.00%

TH 5

5.00%
0.00%
1

2

6

10

Phân Đoạn

Hình 3.4(a): Tổng số lần switch ảnh hưởng đến chất lượng video
dựa trên độ dài phân đoạn của 3 mẫu trung bình

Tiếp theo, Chúng tôi tiến hành chỉnh sửa và tăng mẫu thử lên 6 để so sánh xem chất
lượng của 6 mẫu thử có tốt hơn chất lượng của 3 mẫu thử hay không

Tổng số lần switch ảnh hưởng đến chất lượng
video

N=6

50.00%
45.00%
40.00%
35.00%
30.00%

TH 1

25.00%

TH 2

20.00%

TH 3

15.00%

TH 4
TH 5

10.00%
5.00%
0.00%
1

2

6

10

Phân Đoạn

Hình 3.5(b): Tổng số lần switch ảnh hưởng đến chất lượng video dựa trên
tỉ lệ băng thông giữa hai đường khác nhau của 6 mẫu trung bình


20
Tương tự tiêu chí 1, Hình 3.5(a) cho thấy tổng số lần switch ảnh hưởng đến chất lượng
video dựa trên độ dài phân đoạn video so với tỉ lệ băng thông giữa 2 đường khác nhau.Việc
tăng mẫu thử cho kết quả rất tốt khi đa số các trường hợp đều cho kết quả tốt (trừ độ dài phân
đoạn 1s), độ dài phân đoạn 1s không có sự cải thiện đáng kể so với việc sử dụng 3 mẫu thử
thông lượng trung bình được khảo sát trước đó.
Trong khi đó, tỉ lệ băng thông giữa 2 đường khác nhau tại trường hợp 4 thậm chí còn
cho chất lượng tệ hơn ở phân đoạn 1s của 3 mẫu thông lượng trung bình trước đó.
Nhận xét:
-

Tổng số lần switch được chia làm 2 loại : Tổng số lần switch ảnh hưởng lớn
và tổng số lần switch không ảnh hưởng lớn đến chất lượng video.

-

Tổng số lần switch ảnh hưởng lớn có nghĩa là tỉ lệ băng thông giữa 2 đường
khác nhau tăng lên làm chất lượng video tệ dần (thí dụ switch biến đổi qua
lại giữa độ phân giải 1280x720 và rớt xuống độ phân giải thấp là 480x360).

-

Tổng số lần switch ảnh hưởng không lớn có nghĩa là độ dài phân đoạn tăng
dần làm chất lượng video tăng lên (thí dụ switch biến đổi qua lại giữa độ
phân giải 1280x720 đến 854x480 hay từ 854x480 đến 480x360)

Dựa trên số lần switch
Kết quả thể hiện trong hình 3.6 cho thấy tại phân đoạn 6s và 10s luôn cho số lần switch
luôn thấp. Ngược lại, tại phân đoạn 1s luôn cho số lần switch cao. Xét thêm các trường hợp
tương đương của phân đoạn 2s và 10s tại tiêu chí 2 để đánh giá chất lượng video dựa trên số
lần switch. Kết quả số lần switch của phân đoạn 10s có số lần switch thấp hơn so với phân
đoạn 2s.


21

Độ dài phân đoạn vs Số lần switch : 3 mẫu
180

TH 1:1

160

TH 1:2

140

TH 1:3

120

TH 1:4

100

TH 1:5

80

Expon. (TH 1:1)

60

Expon. (TH 1:2)

40

Expon. (TH 1:3)

20

Expon. (TH 1:4)

0
0

1

2

3

4

5

6

7

8

9

10

11

Expon. (TH 1:5)

Hình 3.6: Sự thay đổi số lần switch dựa trên độ dài phân đoạn
của 3 mẫu trung bình

Chúng tôi tiến hành chỉnh sửa và tăng mẫu thử lên để so sánh xem chất lượng của 6
mẫu thử có tốt hơn chất lượng của 3 mẫu thử hay không.

Độ dài phân đoạn vs Số lần switch : 6 mẫu
120
TH 1:1
100

TH 1:2

TH 1:3

80

TH 1:4
TH 1:5

60

Expon. (TH 1:1)
40

Expon. (TH 1:2)
Expon. (TH 1:3)

20

Expon. (TH 1:4)
0

Expon. (TH 1:5)
0

1

2

3

4

5

6

7

8

9

10

11

Hình 3.7: Sự thay đổi số lần switch dựa trên độ dài phân đoạn
của 6 mẫu trung bình

Kết quả thể hiện trong hình 3.7 cho thấy khi tăng mẫu thử lên thì số lần switch giảm
xuống cho thấy việc tăng số mẫu thử có hiệu quả trong việc cải thiện chất lượng video, tại
phân đoạn 6s và 10s luôn cho số lần switch luôn thấp hơn so với chất lượng của 3 mẫu thử.
Ngược lại, tại 1s số lần switch luôn cao nhưng giảm đáng kể so với chất lượng video của 3
mẫu thử. Xét thêm các trường hợp tương đương của phân đoạn 2s, 6s và 10s tại tiêu chí 1 để
đánh giá chất lượng video dựa trên số lần switch. Kết quả số lần switch của phân đoạn 10s


22
thấp hơn so với 2 phân đoạn còn lại và số lần switch tại phân đoạn 10s cũng giảm đáng kể so
với trường hợp sử dụng 3 mẫu thử.
Nhận xét :

-

Số lần switch càng tệ khi tỉ lệ băng thông giữa các đường tăng lên, ngược
lại số lần switch càng tốt khi độ dài phân đoạn tăng lên.

-

Số lần switch trong các trường hợp tương đương của phần trước được chúng
tôi kiểm chứng thì phân đoạn 10s luôn cho kết quả rất tốt khi số lần switch
luôn thấp nhất ở cả trường hợp 3 mẫu thử và 6 mẫu thử.

Dựa trên bitrate trung bình
Kết quả thể hiện trong hình 3.8 cho thấy tại phân đoạn 6s và 10s luôn cho số lần bitrate
trung bình cao. Ngược lại, tại 1s luôn cho số lần birate trung bình theo chiều hướng giảm dần
đều. Xét thêm các trường hợp tương đương của phân đoạn 2s và 10s tại tiêu chí 2 để đánh giá
chất lượng video dựa trên bitrate trung bình. Kết quả số lần bitrate trung bình của phân đoạn
10s cao hơn so với phân đoạn 2s.

Độ dài phân đoạn vs Bitrate: 3 mẫu

1500
1400
1300
1200

TH 1:1

1000

TH 1:2

900

TH 1:3

Bitrate (kbps)

1100

TH 1:4

800

TH 1:5

700
600
500
0

1

2

3

4Độ dài5phân 6đoạn (s)
7

8

9

10

11

Hình 3.8: Sự thay đổi bitrate trung bình dựa trên độ dài phân đoạn
của 3 mẫu trung bình

Chúng tôi tiến hành chỉnh sửa và tăng mẫu thử lên để so sánh xem chất lượng của 6
mẫu thử có tốt hơn chất lượng của 3 mẫu thử hay không.


23

Độ dài phân đoạn vs Bitrate : 6 mẫu
1600
1500
1400

Bitrate (kbps)

1300
1200

TH 1:1

1100

TH 1:2

1000

TH 1:3

900
800

TH 1:4

700

TH 1:5

600
500
0

1

2

3

4

5

6

7

8

9

10

11

Độ dài phân đoạn (s)

Hình 3.9: Sự thay đổi bitrate trung bình dựa trên độ dài phân đoạn
của 6 mẫu trung bình

Kết quả thể hiện trong hình 3.9 cho thấy khi tăng mẫu lên thì số bitrate trung bình tăng
lên đáng kể cho thấy việc tăng số mẫu thử có hiệu quả trong việc cải thiện chất lượng video,
tại phân đoạn 6s và 10s luôn cho số lần biến đổi bitrate trung bình luôn cao hơn so với chất
lượng của 3 mẫu thử. Ngược lại, tại 1s luôn cho số bitrate trung bình luôn luôn thấp so với
các phân đoạn khác và tốt hơn so với các trường hợp chất lượng video của 3 mẫu thử. Xét
thêm các trường hợp tương đương của phân đoạn 2s, 6s và 10s tại tiêu chí 1 để đánh giá chất
lượng video dựa trên bitrate trung bình. Kết quả số lần bitrate trung bình của phân đoạn 6s
cao hơn so với hai phân đoạn còn lại và số lần bitrate trung bình tại phân đoạn 6s cũng tăng
hơn so với trường hợp sử dụng 3 mẫu thử.
Nhân xét :
-

Bitrate trung bình càng tốt khi độ dài phân đoạn tăng lên, ngược lại bitrate
trung bình càng xấu khi tỉ lệ băng thông giữa 2 đường khác nhau tăng lên.

-

Dựa trên số lần bitrate trung bình để xem xét các trường hợp tương đương
của tiêu chí 2 thì phân đoạn 10s luôn cho kết quả bitrate trung bình tốt nhất
so với trường hợp của các phân đoạn còn lại.

-

Dựa trên số lần bitrate trung bình để xem xét các trường hợp tương đương
của tiêu chí 1 thì phân đoạn 6s luôn cho kết quả rất tốt so với trường hợp
của các phân đoạn còn lại.