Tải bản đầy đủ (.pdf) (7 trang)

Tăng cường chất lượng trải nghiệm người dùng trong hệ thống video trực tuyến thích nghi sử dụng mô hình ước lượng băng thông LSTM

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (772.59 KB, 7 trang )

Hội nghị Quốc gia lần thứ 25 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2022)

Tăng cường chất lượng trải nghiệm người dùng trong hệ
thống video trực tuyến thích nghi sử dụng mơ hình ước
lượng băng thơng LSTM
Nguyễn Thị Hương Thảo*, Phạm Văn Sự*, Vũ Hữu Tiến**
* Khoa Kỹ thuật Điện tử I
** Khoa Đa phương tiện
Học viện Cơng nghệ Bưu chính Viễn thơng
Email: {thaonth, supv, tienvh}@ptit.edu.vn
thu được một tập các phân đoạn video bao gồm cả những
video cùng nội dung nhưng có tốc độ bit khác nhau sẵn sàng
cho việc phân phối tới người dùng trong các điều kiện khác
nhau của mạng. Từ tập video này, các thuật tốn ABR sẽ lựa
chọn các phân đoạn video thích hợp dựa trên các yếu tố quan
sát được của hệ thống chẳng hạn như thông lượng của mạng,
độ chiếm dụng bộ nhớ đệm trong tái tạo video, tỷ lệ đóng băng
hình, … nhằm nâng cao QoE của người sử dụng.

Tóm lược — Video trực tuyến là một phương thức truyền
thông đa phương tiện trong thơng tin và giải trí. Cùng với sự
phát triển của Internet, sự tăng nhanh của nhu cầu lưu lượng
video được cho là một nguyên nhân chính dẫn đến tình trạng
nghẽn mạng và làm suy giảm chất lượng trải nghiệm của người
sử dụng (QoE). Do đó, việc cải thiện, nâng cao QoE trong các hệ
thông phân phối video, đặc biệt với các hệ thống phát thích nghi
trên giao thức HTTP, là một trong các nhiệm vụ cấp bách của
các nhà cung cấp nội dung số. Trong nghiên cứu này, chúng tơi
đề xuất một thuật tốn hiệu quả dựa trên mơ hình mạng LSTM
để nâng cao QoE cho các hệ thống Video trực tuyến thích nghi.
Cụ thể, mơ hình mạng LSTM được sử dụng để dự đốn và ước


lượng tình trạng băng thơng hiện tại của mạng. Dựa trên kết
quả dự đốn băng thơng, thuật tốn được đề xuất sẽ xác định và
đưa ra yêu cầu tốc độ bit tối ưu cho phân đoạn video tiếp theo
nhằm đặt được QoE lớn nhất. Các thực nghiệm đã được tiến
hành để kiểm chứng giải pháp đề xuất. Kết quả thực nghiệm cho
thấy giải pháp đề xuất đạt hiệu quả tốt, tăng 10% chất lượng
trung bình và giảm sự thay đổi tốc độ bít 19 lần đối với tốc độ
mạng 1500kbps.

Một công nghệ khác cũng cần phải kể đến trong các cơng
nghệ có vai trị hỗ trợ việc phát triển bùng nổ lưu lượng nội
dung dạng video đó là cơng nghệ phát video trực tuyến dựa
trên giao thức HTTP hay còn được được biết đến là cơng nghệ
video trực tuyến thích nghi động qua HTTP (DASH) [5].
DASH là công nghệ thu hút mạnh mẽ sự quan tâm của các nhà
nghiên cứu cũng như của các hãng cơng nghệ. Nhóm xây dựng
chuẩn 3GPP cũng như MPEG đã thống nhất thành chuẩn
MPEG-DASH [6]. Nhờ có DASH, việc truyền dẫn video có
thể tận dụng các máy chủ HTTP có sẵn cũng nhưng các nền
tảng mạng cung cấp nội dung (CDN). Ngoài ra, tiêu chuẩn
DASH cho phép các chương trình phía người sử dụng có thể
lựa chọn một cách tự do và linh động cơ chế tối ưu để đảm
bảo đạt được yêu cầu về QoE riêng mà không phải là tập quy
tắc được xác định từ trước. Tiêu chuẩn DASH được hỗ trợ
rộng rãi bởi các hãng công nghệ lớn chẳng hạn như công nghệ
phát video trực tuyến MSS của Microsoft [7], phát trực tuyến
trên HTTP của Apple [8], phát trực tuyến động trên HTTP của
Adobe [9]. Đặc biệt, hai hãng cung cấp nội dung video lớn là
Youtube và Netflix xây dựng nền tảng dựa trên DASH trong
đó Youtube sử dụng DASH như là một phương pháp phân

phối mặc định [10] còn Netflix được biết đến là nhà cung cấp
nội dung dựa trên DASH lớn nhất [11].

Từ khóa: Video streaming, Tốc độ bít thích nghi, LSTM, QoE.

I.

GIỚI THIỆU

Trong những năm gần đây, lưu lượng nội dung số chiếm
đa số trong lưu lượng truyền tải trên internet và mạng thông
tin di động là video trong dịch vụ video theo yêu cầu và Video
trực tiếp. Theo Cisco lưu lượng này chiếm khoản 55% tổng
lưu lượng truyền tải và dự báo sẽ chiếm khoảng 75% trong
tương lai gần [1]. Điều này là nhờ sự phát triển và hỗ trợ mạnh
mẽ của Internet, các công nghệ 4G/5G cũng như sự phổ biến
của các thiết bị điện tử cầm tay.
Cùng với sự tăng mạnh của nhu cầu nội dung video, yêu
cầu của người sử dụng cũng trở nên cao hơn và khó tính hơn
về mặt chất lượng và sự sẵn sàng của các dịch vụ cung cấp
video. Với sự dễ dàng tiếp cận nguồn nội dung video phong
phú, người sử dụng sẵn sàng từ bỏ việc xem một video trực
tuyến nếu chất lượng video đó khơng như mong đợi, hoặc việc
xem video bị gián đoạn [2]. Do đó, để thỏa mãn mong đợi của
người dùng, các nhà cung cấp dịch vụ cũng như truyền tải
không ngừng tăng cường và truyền tải video có chất lượng
cao. Tuy nhiên, có một mâu thuẫn giữa việc mong muốn video
chất lượng cao với việc truyền tải video. Video chất lượng cao
đồng nghĩa là lượng dữ liệu cần truyền tải lớn. Điều này dẫn
đến phải mất thời gian lâu hơn để truyền tải và việc truyền tải

thất bại có xác suất cao hơn do điều kiện mạng khơng tốt.

Nhân tố chính mang lại ưu thế cho DASH là ABR. Hầu
hết các thuật toán ABR hiện có đều sử dụng một tập luật điều
kiện được xác định trước để lựa chọn các phân đoạn video.
Các luật này thường được xây dựng dựa trên một số điều kiện
của mạng và điều kiện của chương trình phía người sử dụng.
Chúng có thể chia thành ba nhóm chính. Nhóm thứ nhất là lớp
thuật tốn dựa trên tốc độ. Nhóm này sử dụng thơng tin của
các phân đoạn video tải được để đưa ra dự đốn cho băng
thơng mạng và dựa trên băng thơng mạng dự đốn được
chương trình phía người sử dụng gửi yêu cầu các phân đoạn
video có tốc độ thích hợp [4][12]. Lớp thuật tốn thứ hai là lớp
thuật tốn dựa trên thơng tin của bộ nhớ đệm chương trình tái
tạo video phía người sử dụng, trong đó mức độ chiếm dụng bộ
nhớ đệm của chương trình gồm ba giai đoạn là lưu trữ, đệm
và bão hòa được sử dụng để xây dựng một hàm xác định tốc
độ bit [3]. Lớp thuật toán thứ ba sử dụng lai ghép giữa thông
tin chiếm dụng bộ nhớ đệm và băng thơng của mạng, sau đó
sử dụng q trình tối ưu để xây dựng các luật thay đổi tốc độ
bit [13]. Mặc dầu vậy, các phương pháp trong các lớp vừa kể
có những hạn chế nhất định. Chẳng hạn, các kỹ thuật dựa trên

Các kỹ thuật phát thích nghi tốc độ bit (ABR) được xem là
giải pháp có tính hứa hẹn cho việc truyền tải video qua mạng
có thể thỏa mãn yêu cầu của người dùng [3][4]. Trong kỹ thuật
phát thích nghi tốc độ, các video được phân thành các phân
đoạn ngắn khoảng vài giây. Sau đó, mỗi phân đoạn video được
mã hóa với phương thức và tốc độ mã hóa khác nhau. Kết quả


ISBN 978-604-80-7468-5

152


Hội nghị Quốc gia lần thứ 25 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2022)

bộ nhớ đệm không thể điều chỉnh sự thay đổi đuổi bám kịp
trong điều kiện mạng ln thay đổi, cịn các kỹ thuật dựa trên
tốc độ thì thường có sự thái q và chỉ làm việc tốt khi trạng
thái mạng tương đối ổn định. Mặt khác, các kỹ thuật lai ghép
phải trả giá về mặt chất lượng để đánh đổi việc giảm nhỏ độ
phức tạp tính tốn để phù hợp với u cầu thích nghi đáp ứng
thời gian thực.
Trong các mạng thơng tin di động, rất nhiều yếu tố chẳng
hạn như sự thay đổi đường truyền vô tuyến, can nhiễu đa
đường, nhiễu … luôn khiến cho các kết nối mạng không ổn
định và băng thông sẵn sàng cho truyền tải luôn thay đổi [14].
Điều này khiến cho việc duy trì tốc độ video phát tối ưu, cũng
tức là tối ưu QoE, trở thành một thách thức rất lớn. Nếu phía
người sử dụng yêu cầu các phân đoạn video với tốc độ mã hóa
quá cao thì khả năng cao sẽ gặp phải tình huống bị đứng hình,
bị tải lại khi băng thơng mạng thay đổi. Ngược lại, nếu phía
người sử dụng yêu cầu tốc độ bit giảm thì có thể tránh được
những tình huống vừa nêu nhưng lại gặp phải tình huống mà
chất lượng video thấp thậm chí đến mức khơng thể chấp nhận
được. Do thơng tin về điều kiện mạng rất hữu ích cho việc xây
dựng chính sách thay đổi tốc độ bit, vì thế rất cần thiết việc có
thể dự đốn trong ngắn hạn hoặc/và dài hạn được điều kiện
của mạng. Rất nhiều nghiên cứu đã cố gắng ước lượng/dự

đốn băng thơng mạng [4][15][16] để chuyển đổi tăng lên
hoặc giảm đi tốc độ bit. Các nghiên cứu chỉ ra rằng với sự hỗ
trợ của tri thức về băng thông mạng được dự đoán, việc xử lý
và đưa ra quyết định lựa chọn tốc độ và chất lượng phân đoạn
video có sự vượt trội so với những cách tiếp cận truyền thống
khác [17].

Constructed
video sequence

Video encoder

Video decoder

Video
segmentation

Buffer

Bitrate
adaptation

Quality level 0
Quality level 1

Internet
Client

Quality level N


Server

Hình 1. Kiến trúc video trực tuyến thích nghi trên giao thức
HTTP
II.

CƠ SỞ VÀ CÁC NGHIÊN CỨU LIÊN QUAN

A. Giới thiệu về HAS
Hình 1 minh họa tổng quan về kiến trúc Video trực tuyến
thích nghi trên giao thức HTTP [4][5]. Video được mã hóa với
các mức chất lượng khác nhau. Mỗi mức chất lượng được xác
định bởi tốc độ bít trung bình tương ứng. Thêm nữa, video
được chia thành các phân đoạn (cịn gọi là các chunk) có độ
dài từ một đến khoảng 10 giây. Mỗi phân đoạn có thể được
giải mã một cách độc lập với các phân đoạn khác. Ứng dụng
tại phía máy người sử dụng trong HAS sẽ bắt đầu một phiên
làm việc bằng cách tải một tệp bản kê. Tệp bản kê này cung
cấp một mô tả về các phân đoạn video và các cấp độ chất
lượng của tập các phân đoạn video sẵn sàng cung cấp cho
người sử dụng. Dựa trên điều kiện hiện thời của mạng và mức
chiếm dụng bộ nhớ đệm của trình ứng dụng, thuật tốn thích
nghi chất lượng phía người sử dụng sẽ xác định chất lượng
cho phân đoạn video tiếp theo để thực hiện tải. Mục tiêu của
bộ thích nghi chất lượng là tối ưu hóa QoE trong đó QoE được
xác định là hàm phức hợp của nhiều tham số chẳng hạn như
số lần video dừng hình, mức chất lượng trung bình, tần suất
thay đổi mức chất lượng.

Việc xây dựng quyết định chọn tốc độ bít dựa trên dự đốn

băng thơng tăng cường được Thắng và cộng sự đề xuất trong
[16]. Jang và cộng sự [4], cũng như Tian và cộng sự [15] đã
đề xuất một phương pháp dự đốn an tồn. Tuy nhiên, cả hai
giải pháp không hiệu quả khi áp dụng trong mạng thơng tin di
động. Trình tái tạo video Exoplayer của Google sử dụng kỹ
thuật phần trăm cửa sổ dịch chuyển để ước lượng băng thông
tức thời [18]. Nhằm cải thiện tính chính xác trong dự đốn
băng thơng, phương thức dự đốn băng thơng dựa trên học
máy đã được xem xét trong [19].

Lợi điểm chính của HAS so với các giao thức thời gian
thực truyền thống khác là ở khả năng thay đổi chất lượng video
với băng tần sẵn có của hệ thống để tránh hiện tượng dừng
hình. Do đó, HAS tạo thuận lợi cho việc phát video trực tuyến
trên mạng với cố gắng tốt nhất. Thêm nữa, các luồng video
dựa trên giao thức HTTP có để dễ dàng truyền qua các kiến
trúc tường lửa cũng như có thể tái sử dụng các hạ tầng dựa
trên giao thức HTTP đã được xây dựng sẵn như các hệ thống
máy chủ HTTP, các máy chủ HTTP trung gian, các nút mạng
cung cấp nội dung CDN. Bởi có những lợi thế vừa kể, nhiều
công ty công nghệ lớn như Microsoft, Apple, Adobe, và
Netflix đã chấp nhận một cách rộng rãi mơ hình phát video
trực tuyến thích nghi. Hầu hết các giải pháp HAS sử dụng
cùng kiến trúc, nhóm chuyên gia MPEG đã đề xuất một tiêu
chuẩn phát video trực tuyến thích nghi trên giao thức HTTP
(DASH). Ngoài chuẩn DASH, chuẩn phát trực tuyến thời gian
thực trên HTTP, được biết đến là HLS, cũng là một giao thực
phát nội dung đa phương tiện tốc độ bít thích nghi trên HTTP
được Apple phát triển. HLS được đưa vào sử dụng năm 2009,
giao thức này được sử dụng rộng rãi trong các trình ứng dụng

đa phương tiện, các trình duyệt, các thiết bị di động, và các
máy chủ cung cấp nội dung đa phương tiện. Từ 2019, một
khảo sát thường niên trong lĩnh vực video đã cho thấy HLS là
một định dạng trực tuyến video phổ biến nhất. HLS tương tự
với MPEG-DASH về cách làm việc trong cách chia nhỏ luồng

Trong nghiên cứu này, nhóm nghiên cứu tận dụng khả
năng nhớ ngắn hạn và dài hạn của mạng LSTM để gia tăng
tính chính xác của việc dự đốn băng thơng, sau đó, một chính
sách thay đổi tốc độ bít được đề xuất dựa trên thơng tin dự
đốn có độ chính xác cao của băng thơng mạng nhằm tăng
cường QoE. Ở giải pháp đề xuất, trước hết sử dụng một mạng
LSTM được cá biệt hóa cho việc dự đốn băng thơng với mục
tiêu tăng tính chính xác cho dự đoán ngắn hạn và dài hạn. Cụ
thể, thông tin lịch sử băng thông của mạng được xem xét dưới
hai khía cạnh là vùng thay đổi giá trị và xu thế thay đổi giá trị
cùng được đưa vào mạng LSTM. Sau đó, nghiên cứu đề xuất
giải pháp lựa chọn tốc độ bít để xác định tốc độ bít tốt nhất
dựa trên thơng tin dự đốn băng thơng mạng thu được.
Phần còn lại của bài báo này được cấu trúc như sau. Phần
II giới thiệu cơ sở lý thuyết và những nghiên cứu liên quan về
công nghệ Video trực tuyến thích nghi trên giao thức HTTP
(HAS) và các mơ hình đánh giá QoE. Phần III trình bày đề
xuất phương pháp mới cải thiện QoE cho HAS. Phần IV trình
bày phần thực thi và thực nghiệm để đánh giá giải pháp đề
xuất. Cuối cùng, phần V tổng kết lại nghiên cứu và đưa ra các
thảo luận.

ISBN 978-604-80-7468-5


Video sequence

153


Hội nghị Quốc gia lần thứ 25 về Điện tử, Truyền thơng và Cơng nghệ Thơng tin (REV-ECIT2022)

video chính thành một chuỗi các phần nhỏ hơn cho phép tải
dựa trên giao thức HTTP. Danh sách của các luồng, được mã
hóa với các tốc độ bít khác nhau, được truyền tải tới phía người
sử dụng bằng một danh sách M3U mở rộng. Mặc dù có nhiều
lợi thế, các giao thức sử dụng HAS như DASH hay HLS vẫn
cần phải giải quyết một số điểm khơng hiệu quả để có thể nâng
cao QoE, đặc biệt trong việc phát video trực tuyến thời gian
thực.

III.

PHƯƠNG PHÁP ĐỀ XUẤT

A. Kiến trúc của phương pháp đề xuất
Video Player
10 past data points and
features of bandwidth
Predicted
Bandwidth
LSTM
model
Rendered
video chunks


B. Mô hình đánh giá QoE
Hiện nay, có rất nhiều phương pháp đánh giá QoE đã được
đề xuất và được chuẩn hóa [20][21][22][23]. Như đã đề cập ở
trên, hình ảnh video được truyền tải trong các hệ thống ABR
không bị méo dạng, mà độ phân giải có thể thay đổi (do sự
thay đổi tốc độ bit). Bên cạnh đó, sự đứng hình video có thể
xảy ra do sự nạp lại bộ nhớ đệm. Do đó, phương pháp đánh
giá QoE cho các hệ thống ABR phải xem xét đến các ảnh
hưởng của việc chọn tốc độ bít, sự thay đổi tốc độ bít cũng
như sự nạp lại bộ nhớ đệm.

Playback
Buffer

Video Server

HTTP GET:
Chunk n, Quality q

Video chunk
selector

Video Chunk

Buffer
Occupancy

Hình 2. Kiến trúc của phương pháp đề xuất
Kiến trúc của phương pháp đề xuất được mô tả trong Hình

2. Tại phía máy phát video sử dụng mơ hình LSTM để dự đốn
băng thơng mạng hiện tại. Đầu ra của mạng LSTM cùng với
độ chiếm giữ bộ đệm hiện tại được sử dụng làm đầu vào cho
bộ lựa chọn phân đoạn video. Dựa trên các giá trị đầu vào, bộ
lựa chọn phân đoạn video sẽ chọn tốc độ bit tối ưu cho phân
đoạn video tiếp theo để đạt được giá trị QoE lớn nhất. Sau đó,
yêu cầu bao gồm chỉ số đoạn và tốc độ bit tương ứng của phân
đoạn sẽ được gửi tới máy chủ video (server video).

Có hai nhóm phương pháp chính cho việc đánh giá QoE:
điểm hữu dụng và trung bình điểm số ý kiến (MOS). Điểm
hữu dụng được sử dụng chính trong các thuật toán ABR trong
khi MOS được sử dụng nhiều trong giám sát chất lượng dịch
vụ. Công thức của hai phương pháp này khác nhau nhưng các
tham số đầu vào giống nhau gồm các tốc độ bít của luồng
video và audio, độ phân giải video, tốc độ khung, và các thông
tin liên quan đến sự nạp lại bộ nhớ đệm.

B. Mô hình LSTM đề xuất

Điểm hữu dụng được tính bằng tổng của ba tham số: tốc
độ bít, sự tải lại bộ nhớ đệm, và sự chuyển đổi tốc độ bít. Cơng
thức cụ thể cho tính tốn điểm hữu dụng như sau:
𝑈𝑡𝑖𝑙𝑖𝑡𝑦 =

1
𝑀

∑𝑀
𝑛=1 𝑄(𝑅𝑛 ) −

1

1
𝑀

𝜇𝑇 −

− 𝑀 ∑𝑀−1
𝑛=1 |𝑄(𝑅𝑛+1 ) − 𝑄(𝑅𝑛 )|

(1)

Trong đó, 𝑅𝑛 là tốc độ bít của phân đoạn video thứ n,
𝑄(𝑅) là hàm của tốc độ bít được sử dụng để tính chất lượng
của mỗi phân đoạn video, Δ𝑄(𝑅𝑛 ) = 𝑄(𝑅𝑛+1 ) − 𝑄(𝑅𝑛 ) là
giá trị trả giá sau mỗi lần thay đổi tốc độ, 𝜇 là trọng số của giá
trị trả giả cho việc nạp lại bộ nhớ đệm, T là tổng thời gian nạp
lại bộ nhớ đệm và M là số các phân đoạn của một video. Trong
công thức này, thành phần đầu tiên là tốc độ bít hữu ích, thành
phần thứ hai là giá trị phạt cho việc phải nạp lại bộ nhớ đệm,
và thành phần thứ ba là giá trị phạt cho sự thay đổi tốc độ bít.
Ngồi cơng thức trên, có rất nhiều những biến thể của mơ hình
tính tốn QoE này trong các thuật toán ABR với việc thay đổi
thành phần tốc độ bít hữu ích cũng như các giá trị trọng số của
các giá trị phạt [23][24].

Hình 3. Kiến trúc mơ hình LSTM đề xuất
Mơ hình đề xuất được mơ tả trong Hình 3. Mơ hình nhận
10 điểm dữ liệu trong quá khứ và dự đoán giá trị tốc độ bit tiếp
theo. Mỗi điểm dữ liệu đầu vào có 3 thơng số:


MOS được tính tốn từ mơ hình ước lượng MOS thơng
qua q trình đánh giá chất lượng bởi phương pháp khách
quan. Do MOS phản ánh tốt nhất chất lượng hình ảnh và video
cảm nhận bởi người sử dụng, rất nhiều mơ hình đánh giá MOS
đã được nghiên cứu và đề xuất. Những mơ hình này có sự khác
nhau về các tham số đầu vào, độ chính xác và mức độ tính
tốn. Trong các hệ thống ABR, người dùng khơng thể so sánh
hình ảnh video với phiên bản gốc, do đó mơ hình khơng tham
chiếu thường được sử dụng để ước lượng MOS. Các mơ hình
khơng tham chiếu có thể phân thành nhóm mơ hình dựa trên
siêu dữ liệu [25][26] và nhóm mơ hình dựa trên điểm ảnh
[27][26]. Trong nghiên cứu này, một phương pháp đánh giá
QoE dựa trên điểm hữu dụng được đề xuất để cải thiện QoE
cho hệ thống phát video trực tuyến sử dụng giao thức HLS.
Chi tiết của phương pháp được đề xuất được giới thiệu trong
phần III tiếp theo sau.

ISBN 978-604-80-7468-5

-

Dữ liệu được truyền (Mb): Lượng dữ liệu nhận được
trong một lần truyền.

-

Thời gian truyền (giây): Thời gian từ lúc bắt đầu
truyền cho đến khi kết thúc truyền.


-

Tốc độ bit (Mbps): Dữ liệu được truyền chia cho thời
gian truyền.

Mặc dù có thể tính tốc độ bit từ hai thơng số cịn lại, nhưng
thực nghiệm lại cho thấy ba thông số vẫn giúp cho mơ hình
đạt được kết quả tốt hơn.
Để có được tập dữ liệu huấn luyện, các thông số megabit
được truyền, thời gian truyền và tốc độ bit được thu thập khi
phát trực tuyến 22 video với độ dài từ 1 đến 3 phút mỗi video.
Dữ liệu từ 5 video được sử dụng cho kiểm tra và phần còn lại
cho huấn luyện.
Để lựa chọn được cấu hình tốt nhất cho mơ hình, hai nhóm
thí nghiệm được thực hiện. Trong thí nghiệm thứ nhất, 5 video
được sử dụng cho huấn luyện để tiết kiệm thời gian vì mục
đích chỉ để so sánh các tập đặc trưng khác nhau. Các kêt quả

154


Hội nghị Quốc gia lần thứ 25 về Điện tử, Truyền thơng và Cơng nghệ Thơng tin (REV-ECIT2022)

của thí nghiệm này được tóm tắt trong Bảng 1. Cụ thể, có 4 thí
nghiệm (TN) trong nhóm này và TN 1 gồm cả 3 đặc trưng.
Đối với mỗi một thí nghiệm trong 3 thí nghiệm cịn lại, chúng
tơi loại bỏ một đặc trưng và quan sát các giá trị tổn thất để xem
nó ảnh hưởng như thế nào đến hiệu suất của mơ hình. Tốc độ
bit là đặc trưng quan trọng nhất vì MAE và MSE là cao nhất
khi đặc trưng này bị loại bỏ (TN 4). TN 2 cho thấy rằng dữ

liệu được truyền khơng đóng góp đáng kể bởi vì khi nó bị loại
khỏi tập các đặc trưng, giá trị MAE và MSE tương ứng là thấp
nhất so với 3 thí nghiệm cịn lại có 2 đặc trưng. Tuy nhiên, bộ
ba đặc trưng đầy đủ vẫn cho kết quả tốt nhất.
Bảng 1. Bảng so sánh các kịch bản tập đặc trưng
TN

Tập đặc trưng

MAE

MSE

Hình 5. So sánh dự đốn băng thơng mạng (Mẫu số #2)

thời gian truyền, dữ liệu truyền và tốc
1

độ bit

0,2368

0,1007

2

thời gian truyền, tốc độ bit

0,2452


0,1186

3

dữ liệu truyền, tốc độ bit

0,2849

0,1351

4

thời gian truyền, dữ liệu truyền

0,2875

0,2181

Trong nhóm thứ hai, mơ hình tốt nhất (với 3 đặc trưng)
được huấn luyện trên tất cả dữ liệu trong khi tập dữ liệu thử
nghiệm vẫn không thay đổi. Các kết quả trong thử nghiệm này
được mơ tả trong Bảng 2. Như có thể thấy trong bảng, phương
pháp của chúng tơi có ít tổn thất hơn đáng kể so với phương
pháp truyền thống được gọi là Phân vị trượt – phương pháp
ước tính băng thơng của Google [18].

Hình 6. So sánh dự đốn băng thơng mạng (Mẫu số #3)
Hình 4, 5, 6 mơ tả kết quả của mơ hình đề xuất với đầu vào
3 đặc trưng và phân vị trượt trong trường hợp mạng trên xe
buýt được mô phỏng bởi Mahimahi. Các kết quả thu được cho

thấy giải pháp đề xuất của chúng tôi cung cấp dự đốn băng
thơng với độ chính xác cao. Tóm lại, mơ hình đề xuất là một
lựa chọn phù hợp mang lại hiệu suất có thể chấp nhận được về
MAE và MSE.

Bảng 2. So sánh các phương pháp
TN

Phương pháp

MAE

MSE

Mô hình LSTM đề xuất với 3 đặc trưng
(thời gian truyền, dữ liệu truyền và tốc độ
1

bit)

0,1425

0,0542

2

Phân vị trượt (Phương pháp của
Exoplayer)

0,2181


0,1225

C. Thuật toán lựa chon phân đoạn video đề xuất
Dựa trên băng thơng mạng dự đốn, chúng tơi phát triển
một thuật tốn lựa chọn tốc độ bit thích ứng để tìm ra tốc độ
bit tối ưu cho đoạn video tiếp theo. Đoạn mã giả của thuật toán
đề xuất được cho dưới đây.
Giải thuật lựa chọn đoạn video
Đầu
vào:

Hình 4. So sánh dự đốn băng thơng mạng (Mẫu số #1)

Đầu ra:
1:
2:
3:
4:

ISBN 978-604-80-7468-5

R*: Tốc độ bit của phân đoạn đã tải về trước đó;
Ri: Tốc độ bit của phân đoạn video có chỉ số thứ i;
L: Chiều dài của đoạn video;
Bcurrent: Mức chiếm dụng bộ đệm hiện thời;
Bcurrent-1: Mức chiếm dụng bộ đệm cho phân đoạn
video trước;
C: băng thơng mạng được dự đốn bằng mơ hình
LSTM;

𝜇 = 1: Tải lại bộ đệm và tần suất chuyển đổi mức
chất lượng.
QoEmax = 0;
quality_level = 0;
track_index tối ưu

155

if (𝐵𝑐𝑢𝑟𝑟𝑒𝑛𝑡 > 𝐵𝑐𝑢𝑟𝑟𝑒𝑛𝑡−1 )
𝜇 = 𝜇/2;
else
𝜇 = 𝜇 ∗ 2;


Hội nghị Quốc gia lần thứ 25 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2022)

5:
6:
7:

𝑄𝑜𝐸𝑅𝑖 = 𝑅𝑖 − 𝜇 (

𝑅𝑖 .𝐿
𝐶

− 𝐵𝑐𝑢𝑟𝑟𝑒𝑛𝑡 ) − 𝜇|𝑅𝑖 − 𝑅∗ |;

(2)

if(𝑄𝑜𝐸𝑅𝑖 > 𝑄𝑜𝐸𝑚𝑎𝑥 ) && 𝑅𝑖 ≤ 𝐶) {

𝑄𝑜𝐸𝑚𝑎𝑥 = 𝑄𝑜𝐸𝑅𝑖 ;

8:
9:
10:
11:
12:

Bảng 3. Mức chất lượng của các chuỗi video

for ( i = 0; i<=track_index_max; i++) {

quality_level = i;
}
}
return track_index;

Trong thuật toán trên, hàm QoE dựa trên thuật toán trong
[28]. Mơ hình này được sử dụng rộng rãi trong nhiều cơng
trình nghiên cứu. Trong hàm này, Ri là tốc độ bit được coi là
𝑅 .𝐿
QoE của phân đoạn video, 𝑖 − 𝐵𝑐𝑢𝑟𝑟𝑒𝑛𝑡 và |𝑅𝑖 − 𝑅∗ | là các
𝐶
thuật ngữ được coi là mức phạt tải lại bộ đệm và mức phạt về
độ mượt tương ứng. Vòng lặp trong giải thuật tìm kiếm tốc độ
bit tối ưu Ri trong đó đại lượng QoE đạt được điểm cao nhất.
Tốc độ bit Ri là mức tốc độ bit phù hợp với mức chất lượng
thứ i.

Tốc độ bit

(bps)

Mức chất
lượng

Thứ tự chuỗi

Độ phân giải

Video #1
(MTV),
Video #3

1920 ×1080
1280 × 720
854 × 480

5605600
3405600
2305600

0
1
2

(Trị chơi video),
Video #5
(Hoạt hình 3D)

640 × 360

426 × 240

1152800
1152800

3
4

Video #2
(Phim hành động),
Video #4

1280 × 544
1280 × 720
854 × 480

5605600
3405600
2305600

0
1
2

(Hoạt hình 2D)

640 × 360
426 × 240

1152800

1152800

3
4

Tổng thời gian tải lại bộ đệm là tổng thời gian của các sự
kiện tải lại bộ đệm. Sự kiện tải lại bộ đệm sẽ xuất hiện khi
khơng có dữ liệu trong bộ đệm và vì vậy, quá trình phát lại
video bị đình trệ.
Để đánh giá hiệu quả của phương pháp dựa trên LSTM để
cải thiện QoE, phương pháp đề xuất được tích hợp vào phần
mềm ExoPlayer. Các thử nghiệm được triển khai với dữ liệu
Mahimahi có thơng lượng trung bình 1500 kbps. Có 3 phương
pháp được sử dụng để so sánh gồm: Phương pháp của Google
(GM), phương pháp của Google được tích hợp LSTM để ước
tính băng thơng (GM LSTM) và phương pháp của Google
được tích hợp cả mơ hình LSTM và thuật tốn tốc độ bit thích
ứng đề xuất (GM LSTM ABR).

Hình 7. Kết nối Exoplayer với webserver Nginx qua mạng
Mahimahi
IV.

B. Kết quả và thảo luận

CÁC KẾT QUẢ THỬ NGHIỆM VÀ ĐÁNH GIÁ HIỆU NĂNG

Quality level

A. Điều kiện thử nghiệm

Trong thử nghiệm này sử dụng một hệ thống phát trực
tuyến video thử nghiệm được xây dựng trên máy chủ web
Nginx [29]. Nginx là một máy chủ web mã nguồn mở sử dụng
phương pháp tiếp cận theo hướng sự kiện, khơng đồng bộ, ở
đó các u cầu được xử lý trong một luồng duy nhất. Kiến trúc
của mô hình thử nghiệm được mơ tả trong Hình 7. Để đánh
giá nhiều tình huống, chúng tơi sử dụng cơng cụ Mahimahi để
tạo ra các mạng có tốc độ và độ trễ đường lên và đường xuống
khác nhau giữa máy chủ web Nginx và ExoPlayer. Mahimahi
là một công cụ gọn nhẹ có thể mơ phỏng các điều kiện mạng
khác nhau và cung cấp khả năng ghi, phát lại nội dung HTTP.

4
2
0
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55

Time (sec)
GM

GM+LSTM

GM+LSTM+QoE

Hình 8. Chuyển đổi các mức chất lượng cho video #1 với
băng thông 1500kbps

Buffer occupancy

Buffer size (sec)


Trong bài báo này sử dụng năm chuỗi video với các nội
dung khác nhau để kiểm tra phương pháp đề xuất. Phương
pháp đề xuất được so sánh với phương pháp của Google được
thực hiện trên phần mềm ExoPlayer [18] dựa trên các yếu tố
ảnh hưởng đến QoE bao gồm mức chiếm dụng bộ đệm, tần
suất chuyển đổi mức chất lượng, mức chất lượng trung bình
và tổng thời gian tải lại bộ đệm. Mức chiếm dụng bộ đệm là
lượng dữ liệu đã sẵn sàng để phát. Đại lượng này phản ánh độ
chính xác của mơ hình để dự đốn băng thơng và lựa chọn
mức chất lượng tối ưu cho đoạn video để tải xuống. Tần suất
chuyển đổi mức chất lượng để chỉ số lần thay đổi mức chất
lượng trong quá trình phát lại dữ liệu. Mức chất lượng trung
bình là mức chất lượng trung bình của các đoạn video trong
quá trình phát lại dữ liệu. Trong nghiên cứu này, các chuỗi
video được mã hóa với 5 mức chất lượng tương ứng với 5 độ
phân giải. Chi tiết của các mức chất lượng của các chuỗi video
được mô tả trong Bảng 3.

ISBN 978-604-80-7468-5

Quality level switching

6

40
30
20
10
0


1 4 7 1013161922252831343740434649525558

GM

Time (sec)

GM+LSTM

GM+LSTM+QoE

Hình 9. Mức chiếm dụng bộ đệm của video #1 với băng
thông 1500kbps

156


Hội nghị Quốc gia lần thứ 25 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2022)

Bảng 4. So sánh các yếu tố ảnh hương QoE của phương pháp đề

[1] Cisco forecast, “Cisco visual networking index (VNI)
global mobile data traffic forecast update, 2017-2022
white paper,” Computer Fraud & Security. pp. 3–5,
2019.

xuất và phương pháp của Google trong băng thông 1500 kbps
Các yếu tố ảnh
hưởng QoE


Mức độ sẵn
sàng của bộ
đệm (giây)

Mức chất lượng
trung bình

Tần suất chuyển
đổi mức chất
lượng

Tổng thời gian
tải lại bộ đệm
(giây)

Chuỗi
video
Video #1
Video #2
Video #3
Video #4
Video #5
Trung
bình
Video #1
Video #2
Video #3
Video #4
Video #5
Trung

bình
Video #1
Video #2
Video #3
Video #4
Video #5
Trung
bình
Video #1
Video #2
Video #3
Video #4
Video #5
Trung
bình

GM
17,82
17,12
14,66
32,62
36,08

GM+LSTM GM+LSTM
+ABR
15,77
18,36
15,12
16,47
13,22

19,00
22,69
26,81
32,85
31,49

23,66
3,32
3,28
3,45
3,45
3,42

19,93
3,09
3,08
3,12
3,08
3,06

22,43
3,05
3,00
3,00
3,00
3,00

3,38
18,00
17,00

20,00
22,00
21,00

3,09
4,00
5,00
5,50
8,00
7,50

3,01
1,00
0,00
0,00
0,00
0,00

19,60
0
0
0
0
0
0

6,00
0
0
0

0
0
0

0,20
0
0
0
0
0
0

[2] F. Dobrian et al., “Understanding the Impact of Video
Quality on User Engagement,” ACM SIGMETRICS
Performance Evaluation Review, vol. 42, no. 1. pp. 367–
379, 2014.
[3] T. Y. Huang, R. Johari, N. McKeown, M. Trunnell, and
M. Watson, “A buffer-based approach to rate adaptation:
Evidence from a large video streaming service,”
Computer Communication Review, vol. 44, no. 4. pp.
187–198, 2015. doi: 10.1145/2619239.2626296.
[4] J. Jiang, V. Sekar, and H. Zhang, “Improving fairness,
efficiency, and stability in HTTP-based adaptive video
streaming with festive,” IEEE/ACM Transactions on
Networking, vol. 22, no. 1. pp. 326–340, 2014. doi:
10.1109/TNET.2013.2291681.
[5] “Dynamic Adaptive Streaming Over HTTP (DASH)—
Part 1: Media Presentation Description and Segment
Formats,” ISO/IEC Stand. 23009-12019, 2019.
[6] I. Sodagar, “The MPEG-DASH standard for multimedia

streaming over the internet,” IEEE Multimedia, vol. 18,
no. 4. pp. 62–67, 2011. doi: 10.1109/MMUL.2011.71.
[7] A. Zambelli and M. T. Evangelist, “IIS Smooth
Streaming Technical Overview,” Whitepaper, Microsoft
Corporation, no. March. 2009.

Hình 8-12 và bảng 4 mô tả mức chiếm dụng bộ đệm và tần
suất chuyển đổi mức chất lượng của ba phương pháp: GM,
GM LSTM và GM LSTM ABR. Từ các kết quả đạt được,
chúng tôi rút ra một số nhận xét sau.

[8] Apple, “HTTP Live Streaming Overview,” [Online].
Available:
/>reaming.

Trong trường hợp băng thông 1500 kbps, phương pháp đề
xuất tốt hơn phương pháp của ExoPlayer về mức chất lượng
trung bình và tần suất chuyển đổi mức chất lượng. Tuy nhiên,
mức chiếm dụng bộ đệm của phương pháp ExoPlayer lại cao
hơn. Lý do là phương pháp đề xuất ước tính băng thơng và
chọn tốc độ bit cao hơn cho mỗi đoạn video. Do đó, thời gian
tải của phương pháp đề xuất là cao hơn. Tổng thời gian tải lại
bộ đệm của ba phương pháp là 0 giây bởi vì trong điều kiện
băng thơng tốt, tốc độ tải xuống cao hơn tốc độ phát ra.
V.

[9] Adobe, “HTTP Dynamic Streaming,” [Online].
Available:
/>[10] J. Roettgers, “Don’t Touch That Dial: How YouTube is
Bringing Adaptive Streaming to Mobile, TVs,”

[Online].
Available:
2017.

KẾT LUẬN

[11] V. K. Adhikari et al., “Unreeling netflix: Understanding
and improving multi-CDN movie delivery,” Proc. IEEE
INFOCOM, pp. 1620–1628, 2012.

Trong bài báo này, chúng tôi đề xuất một phương pháp cải
tiến QoE cho hệ thống video tốc độ bit thích ứng dựa trên mơ
hình LSTM. Cụ thể, mơ hình LSTM được sử dụng để ước tính
băng thơng hiện tại của mạng. Độ chính xác của mơ hình
LSTM được thử nghiệm với dữ liệu Mahimahi với MAE bằng
0,1425 và MSE bằng 0,0542. Dựa trên băng thơng ước tính,
chúng tơi đề xuất một thuật tốn để ước tính tốc độ bit tối ưu
cho đoạn video tiếp theo để đạt được QoE cao nhất. Các kết
quả mô phỏng cho thấy với băng thông 1500 kbps, phương
pháp đề xuất đạt được mức tăng 10% về chất lượng trung bình
và tần suất chuyển đổi mức chất lượng giảm 19 lần so với
phương pháp của Google.

[12] C. J. S. Ahmed H. Zahran, “ARBITER: Adaptive ratebased intelligent HTTP streaming algorithm,” in Proc.
IEEE Int. Conf. Multimedia Expo Workshops (ICMEW),
2016, pp. 1–6.
[13] Z. Li et al., “Probe and adapt: Rate adaptation for HTTP
video streaming at scale,” IEEE J. Sel. Areas Commun,
vol. 32, no. 4, pp. 719–733, 2014.
[14] G. L. Stüber, “Principles of mobile communication,”

Principles of Mobile Communication, vol. 9781461403.
pp. 1–830, 2012. doi: 10.1007/978-1-4614-0364-7.

ACKNOWLEDGMENT
Nghiên cứu này được tài trợ bởi Dự án hợp tác nghiên cứu
giữa PTIT và Naver Corp. theo số tài trợ 04-PTIT-NAVER.

[15] G. Tian and Y. Liu, “Towards agile and smooth video
adaptation in HTTP adaptive treaming,” IEEE/ACM

REFERENCES

ISBN 978-604-80-7468-5

157


Hội nghị Quốc gia lần thứ 25 về Điện tử, Truyền thông và Công nghệ Thông tin (REV-ECIT2022)

Trans. Netw., vol. 24, no. 4, pp. 2386–2399, 2016.

327, 2013.

[16] T. C. Thang, Q. D. Ho, J. W. Kang, and A. T. Pham,
“Adaptive streaming of audiovisual content using MPEG
DASH,” IEEE Trans. Consum. Electron., vol. 58, no. 1,
pp. 78–85, 2012.

[23] A. Mittal, R. Soundararajan, and A. C. Bovik, “Making
a ‘Completely Blind’ Image Quality.pdf,” IEEE Signal

Process. Lett., vol. 20, no. 3, pp. 209–212, 2013.
[24] Z. Akhtar et al., “Oboe: Auto-tuning Video ABR
Algorithms to network conditions,” in Proc. ACM
SIGCOMM, 2018, pp. 44–58.

[17] D. S. Kanhere, “On-move 2016 keynote: Optimizing
HTTP-based adaptive streaming in vehicular
environment using markov decision process,” Proc.
IEEE 41st Conf. Local Comput. Netw. Work. (LCN
Work. Dubai, United Arab Emirates, p. 26, 2016, doi:
10.1109/LCN.2016.019.

[25] “Parametric Bitstream-Based Quality Assessment of
Progressive Download and Adaptive Audiovisual
Streaming Services Over Reliable Transport,” ITU-T
Recomm. Doc. P.1203, 2016.

[18] Exoplayer, “Exoplayer’s Development Document.”

[26] Y. Liu, S. Dey, F. Ulupinar, M. Luby, and Y. Mao,
“Deriving and Validating User Experience Model for
DASH Video Streaming,” IEEE Transactions on
Broadcasting, vol. 61, no. 4. pp. 651–665, 2015. doi:
10.1109/TBC.2015.2460611.

[19] H. Du, Q. Zheng, W. Zhang, and X. Gao, “A Bandwidth
variation Pattern-Differentiated Rate Adaptation for
HTTP Adaptive Streaming Over and LTE Cellular
Network,” IEEE Access, vol. 6, 2018, doi:
10.1109/ACCESS.2017.2788057.


[27] A. Mittal, A. K. Moorthy, and A. C. Bovik, “Noreference image quality assessment in the spatial
domain,” IEEE Trans. Image Process., vol. 21, no. 12,
pp. 4695–4708, 2012, doi: 10.1109/TIP.2012.2214050.

[20] K. Yamagishi and T. Hayashi, “Parametric QualityEstimation Model for Adaptive-Bitrate Streaming
Services (IEEE Transactions on Multimedia),” IEEE
Trans. Multimed., vol. 19, no. 7, pp. 1545–1557, 2017.

[28] X. Yin, A. Jindal, V. Sekar, and B. Sinopoli, “A ControlTheoretic Approach for Dynamic Adaptive Video
Streaming over HTTP,” Comput. Commun. Rev., vol. 45,
no.
4,
pp.
325–338,
2015,
doi:
10.1145/2785956.2787486.

[21] K. Yamagishi, “Audio-visual quality estimation device,
method for esti-mating audio-visual quality, and
program,” 2017.
[22] M. Li and C.-Y. Lee, “A cost-effective and real-time
QoE evaluation method for multimedia streaming
services,” Telecommun. Syst., vol. 59, no. 3, pp. 317–

ISBN 978-604-80-7468-5

[29] Nginx, “Open source,”
/>

158

[Online].

Available:



×