Nâng cao chất lượng truyền video streaming trên mạng ngang hàng có cấu trúc

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ




PHÙNG THANH XUÂN









NÂNG CAO CHẤT LƯỢNG
TRUYỀN VIDEO STREAMING
TRÊN MẠNG NGANG HÀNG CÓ CẤU TRÚC







LUẬN VĂN THẠC SĨ
HÀ NỘI - 2009

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ


PHÙNG THANH XUÂN




NÂNG CAO CHẤT LƯỢNG
TRUYỀN VIDEO STREAMING
TRÊN MẠNG NGANG HÀNG CÓ CẤU TRÚC

Ngành
: Công nghệ Thông tin
Chuyển ngành
: Truyền dữ liệu và mạng máy tính
Mã số
: 60 48 15


LUẬN VĂN THẠC SĨ
Cán bộ hướng dẫn
: TS. Nguyễn Hoài Sơn

HÀ NỘI – 2009

i

MỤC LỤC
LỜI CẢM ƠN Error! Bookmark not defined.
LỜI CAM ĐOAN Error! Bookmark not defined.
TÓM TẮT Error! Bookmark not defined.
MỤC LỤC i
DANH MỤC KÝ HIỆU, CHỮ VIẾT TẮT iii
DANH MỤC CÁC HÌNH VẼ iv
MỞ ĐẦU 1
Chƣơng 1: TỔNG QUAN VIDEO STREAMING 4
1.1. Video streaming 4
1.2. Nén truyền hình 5
1.3. Máy chủ luồng – streaming server 8
1.4. Điều khiển chất lƣợng tại điểm phát và nhận. 8
1.5. Giao thức video streaming 14
1.6. Cơ chế đồng bộ video streaming 15
1.7. Dịch vụ phân tán dữ liệu trên mạng 17
1.8. Tổng kết chƣơng 20
Chƣơng 2: TRUYỀN THÔNG MULTICAST 21
2.1. Khái niệm về truyền tin multicast 21
2.2. Multicast tầng mạng - IP Multicast 22
2.3. Multicast tầng ứng dụng 24
2.4. Các mô hình truyền tin multicast tầng ứng dụng 25
2.5. Tổng kết chƣơng 29
Chƣơng 3: VIDEO STREAMING TRÊN DHT P2P 30
3.1. Mạng ngang hàng DHT. 31
3.2. Video streaming trên DHT P2P – CHORD. 37
ii

3.3. Nghiên cứu liên quan 41
3.4. Tổng kết chƣơng 43
Chƣơng 4: BỐI CẢNH VÀ ĐỀ XUẤT GIẢI PHÁP 44
4.1. Bối cảnh và vấn đề video streaming trên DHT P2P 44
4.2. Tổng quan giải pháp 46
4.3. Giải pháp khôi phục lỗi thời gian thực 48
4.4. Tổng kết chƣơng 56
Chƣơng 5: THỰC NGHIỆM VÀ ĐÁNH GIÁ 57
5.1. Ứng dụng video streaming trên CHORD 57
5.2. Triển khai giải pháp khôi phục lỗi thời gian thực 58
5.3. Môi trƣờng thực nghiệm 59
5.4. Đánh giá kết quả 59
Chƣơng 6: KẾT LUẬN 64
TÀI LIỆU THAM KHẢO a
iii


DANH MỤC KÝ HIỆU, CHỮ VIẾT TẮT

KÝ
HIỆU
VIẾT
TẮT
TIẾNG ANH
GIẢI THÍCH
DCT
Discrete Cosine
Transform
Chuyển đổi cosin rời rạc. Đây là mã hoá/giải
mã phục vụ cho việc nén dữ liệu.

DHT
Distributed Hash Table
Bảng băm phân tán. Một trong các cơ chế
quản lý node trong mạng ngang hàng có cấu
trúc.
IGMP
Internet Group
Management Protocol
Giao thức quản lý nhóm mạng của IP
Multicast
IANA
Internet Assigned
Numbers Authority
Giao thức gán địa chỉ IP trong IP Multicast.
MTU
Maximum transit unit
Đơn vị truyền thông tối đa. Nó đƣợc dùng để
tính toán thông lƣợng, phục vụ điều chỉnh tỷ
lệ gửi.
MDC
Multiple Description
Coding
Mã hoá đa mô tả.
(P)FGS
(Progressive) Fine
Granularity Scalability
Các cơ chế mã hoá/giải mã khác phục vụ cho
nén dữ liệu.
P2P
Peer to Peer

Mạng ngang hàng
QoS
Quality of Services
Chất lƣợng dịch vụ.
RTT
Round trip time
Thời gian đi một vòng của một kết nối. Nó
đƣợc dùng để tính toán thông lƣợng.
(S)FEC
Source Forward Error
Connection
Cơ chế điều khiển lỗi bằng cách thêm các
thông tin thừa để bên nguồn có thể khôi phục
lại gói tin.
VCR
Video – Caset –
Recorder
Chức năng của máy ghi âm – đài – video
gồm dừng, tạm dừng/trình diễn tiếp, tua
nhanh lùi/tiến, chạy ngẫu nhiên.

iv


DANH MỤC CÁC HÌNH VẼ

Hình 1.1: Sáu thành phần của video streaming dữ liệu 4
Hình 1.2: a) Mã hóa không mở rộng. b) Giải mã không mở rộng 6
Hình 1.3: a) Mã hóa mở rộng SNR. b) Giải mã mở rộng SNR 6
Hình 1.4 a) Bộ mã hoá FGS. B) Bộ giải mã FGS 7

Hình 1.5:a) Phân tán truyền thông unicast. B) Phân tán truyền thông multicast 9
Hình 1.6: Biểu đồ thời gian cho Điều khiển theo bên nhận 13
Hình 1.7: Giao thức stacks cho luồng truyền hình. 15
Hình 1.8: Đồng bộ giữa hình và tiếng. 15
Hình 1.9: Bộ lọc đƣợc đặt trong lớp mạng 18
Hình 1.10:Mô hình hệ thống của bộ lọc mức mạng. 18
Hình 2.1: Công nghệ truyền tin Multicast. 21
Hình 2.2: Phân loại truyền thông Multicast 22
Hình 2.3: Bộ định tuyến trong truyền tin multicast tầng mạng 23
Hình 2.4: Truyền thông multicast tầng mạng và tầng ứng dụng 24
Hình 2.5: Giao thức Narada 27
Hình 2.6: Mạng phủ 7 node (a) và cây multicast xây tƣơng ứng (b) 28
Hình 3.1: Mô hình mạng ngang hàng thuần 31
Hình 3.2: Vòng tròn Chord với 3 node và lƣu trữ 4 khóa 33
Hình 3.3: Mạng Chord với các bảng finger 34
Hình 3.4: Sơ đồ một mạng Chord với 9 node tham gia 36
Hình 3.5: Truyền thông multicast trên mạng Chord 39
Hình 3.6: Sơ đồ cây multicast tƣơng ứng với mạng Chord 40
v


Hình 3.7: Ví dụ một node lỗi 42
Hình 4.1: Giải pháp khôi phục lỗi thời gian thực 47
Hình 4.2: Phát hiện lỗi thực 53
Hình 4.4: Định vị node lỗi 54
Hình 4.5: 3 node lỗi đồng thời 55
Hình 4.6: Lỗi xen kẽ 55
Hình 5.1: Thiết kế ứng dụng video streaming trên Chord 57
1

MỞ ĐẦU

Trong xu hƣớng phát triển mạnh mẽ của Internet, do yêu cầu truyền thông đa phƣơng
tiện trên Web ngày càng nhiều, video streaming trên internet đã thu hút nhiều sự chú ý.
Vào những thập niên 80s, 90s, video streaming bắt đầu ra đời và phát triển theo hai
hƣớng chính: video streaming theo yêu cầu (tiếng Anh: video-on-demand) và video
streaming thời gan thực (tiếng Anh: live video streaming).
Video streaming theo yêu cầu là hình thức ngƣời dùng tải dữ liệu về các thiết bị lƣu
trữ của mình, do đó có thể thực hiện các thao tác tua, dừng Các ứng dụng nổi tiếng
của loại hình truyền thông này nhƣ YouTube, BiTorrent Khác với video streaming
theo yêu cầu, trong video streaming thời gian thực, dữ liệu đƣợc truyền trực tiếp từ
các thiết bị ghi thu dữ liệu tại nguồn phát và hiển thị trực tiếp tại bên nhận. Với tính
chất thời gian thực và cung cấp cho nhiều ngƣời sử dụng cùng một lúc, các ứng dụng
truyền hình trực tuyến, hội thảo trực tuyến, dạy học trực tuyến, chat conference
(Skype) ngày càng đƣợc nhiều ngƣời sử dụng cũng nhƣ các nhà nghiên cứu quan
tâm. Luận văn cũng phát triển theo xu hƣớng này.
Video streaming thời gian thực có những ràng buộc về băng thông cao, độ trễ thấp, tỷ
lệ mất gói tin thấp để đáp ứng những yêu cầu về chất lƣợng hiển thị hình ảnh âm
thanh cao. Tuy nhiên, video streaming trên Internet đang có những khó khăn nhất định.
Thứ nhất, việc áp dụng trên mô hình máy Chủ-Khách truyền thống không đáp ứng
đƣợc nhu cầu do tài nguyên của máy chủ có hạn, dữ liệu truyền thông đa phƣơng tiện
thƣờng lớn, máy chủ rất khó có khả năng cung cấp đƣợc cho nhiều ngƣời dùng. Thứ
hai, băng thông của Internet chƣa đƣợc cao và đồng đều, việc tập trung vào máy chủ
sẽ gây ra tải lớn, hiệu ứng "nút cổ chai" gây tắc nhẽn, gói tin không thể truyền đến
hoặc không kịp thời gian hiển thị. Chính vì vậy mà video streaming trên Internet dần
dần thay thế mô hình Chủ - Khách sang truyền thông multicast tầng ứng dụng trên
mạng ngang hàng.
Truyền thông video streaming trên mạng ngang hàng, đặc biệt là mạng ngang hàng có
cấu trúc, có rất nhiều ƣu điểm. Mạng ngang hàng hay còn gọi là mạng đồng đẳng, xoá

đi ranh giới giữa máy chủ-máy khách; các máy có trách nhiệm nhƣ nhau trong việc sử
dụng tài nguyên và xử lý dữ liệu. Chính vì vậy sẽ giải quyết khó khăn giảm tải cho
máy chủ. Thứ hai, mạng ngang hàng có cấu trúc cung cấp tính năng mở rộng cao. Bất
2


cứ node mạng nào cũng có thể tham gia dễ dàng. Do đó có thể cung cấp dịch vụ video
streaming cho nhiều ngƣời sử dụng hơn và cũng tận dụng đƣợc nhiều tài nguyên hơn.
Thứ ba, nó không tốn chi phí quản lý bởi mạng ngang hàng cung cấp những phƣơng
thức các node quản lý lẫn nhau. Tuy nhiên, triển khai video streaming thời gian thực
trên mạng ngang hàng cũng không tránh khỏi những khó khăn.
Khó khăn chính là hiện tƣợng các node ra vào rất linh động, lỗi có thể thƣờng xuyên
xảy ra khiến cho các gói tin truyền thông có thể mất đi, hoặc không đến đƣợc bên
nhận đúng thời gian trình diễn. Mất gói tin hoặc không đến kịp thời sẽ ảnh hƣởng đến
tỷ lệ mất gói tin, độ trễ của việc trình diễn dữ liệu tiếng/hình ở bên nhận; khiến cho
thông tin hiển thị không đúng, không đẹp mắt. Nhằm mục đích nâng cao chất lƣợng
video streaming trên mạng ngang hàng có cấu trúc, luận văn đi sâu vào việc giải quyết
hiện tƣợng node ra/vào và lỗi trong mạng ngang hàng có cấu trúc.
Giải pháp đƣa ra là khôi phục lỗi thời gian thực. Điểm mới của giải pháp là dựa vào
dữ liệu truyền thông video streaming, phát hiện lỗi tức thời và chính xác dựa vào thời
gian timeout. Thời gian này đƣợc tính dựa vào mô hình thông kê hành vi quá khứ của
mỗi node mạng nên đảm bảo sự chính xác và phù hợp.
Giao thức đƣợc triển khai trên mạng ngang hàng có cấu trúc Chord. Dựa trên cấu trúc
mạng phủ Chord, khi có yêu cầu truyền video streaming, các node sẽ liên kết thành
cây multicast. Trong quá trình truyền tin, nếu có sự thay đổi trên cây multicast,
phƣơng pháp khôi phục lỗi thời gian thực sẽ khắc phục sự thay đổi đó, tránh ảnh
hƣởng đến việc truyền tin.
Bên cạnh cơ chế khôi phục lỗi định kỳ của mạng Chord, giải pháp sẽ giúp tìm lỗi vầ
khôi phục lỗi nhanh hơn trong quá trình truyền thông. Điều đó sẽ tránh đƣợc việc mất
mát gói tin trong khi truyền, khiến cho chất lƣợng thông tin bên nhận đƣợc cải thiện.

Giao thức đƣợc thực hiện bằng ngôn ngữ C#, triển khai thí nghiệm trên mạng LAN.
Để tìm hiểu về giải pháp, nội dung luận văn gồm 6 chƣơng:
Chƣơng 1: TỔNG QUAN VIDEO STREAMING
Giới thiệu sáu thành phần trong video streaming nhƣ nén; điều khiển chất lƣợng dịch
vụ tại điểm phát/nhận; dịch vụ phân tán dữ liệu trên mạng; máy chủ luồng; các cơ chế
đồng bộ và giao thức video streaming. Sáu thành phần trên sẽ điều khiển luồng video
streaming từ nguồn đến đích, đồng thời, tại mỗi thành phần cũng có các cơ chế nâng
3


cao chất lƣợng. Để hạn chế, luận văn phát triển theo hƣớng dịch vị phân tán dữ liệu, cụ
thể là multicast tầng ứng dụng.
Chƣơng 2: TRUYỀN THÔNG MULTICAST
Nối tiếp từ chƣơng 1, chƣơng 2 giới thiệu truyền thông mạng ngang hàng multicast.
Xác định những ƣu điểm, nhƣợc điểm của hai cách thức truyền thông multicast IP và
multicast tầng ứng dụng. Từ những ƣu nhƣợc điểm đó, multicast tầng ứng dụng triển
khai vào mạng ngang hàng có cấu trúc có những khó khăn gì. Những nội dung của
chƣơng 2 sẽ tiếp nối với chƣơng 3 để dẫn dắt vào vấn đề video streaming trên mạng
ngang hàng có cấu trúc.
Chƣơng 3:VIDEO STREAMING TRÊN DHT P2P
Chord là đại diện nổi tiếng của mạng ngang hàng có cấu trúc băm phân tán. Ở chƣơng
này, ta sẽ tìm hiểu sâu cách thức quản lý node, gia nhập/ thoát khỏi mạng, cơ chế nhận
biết và khắc phục lỗi trong Chord. Sau đó kết hợp với chƣơng 2, giới thiệu video
streaming bằng giao thức truyền thông multicast trên mạng Chord. Chƣơng cũng đƣa
ra một số nghiên cứu liên quan.
Chƣơng 4: BỐI CẢNH VÀ ĐỀ XUẤT GIẢI PHÁP
Dựa vào chƣơng 3, chƣơng 4 phân tích bối cảnh để đƣa ra đề xuất khôi phục lỗi thời
gian thực. Từ mục tiêu giải pháp sẽ trình bày chi tiếp từ thiết kế đến các thành phần
cho giải pháp.
Chƣơng 5:THỰC NGHIỆM VÀ ĐÁNH GIÁ

Trong chƣơng 5, ta sẽ triển khai giải pháp khôi phục lỗi thời gian thực trên một ứng
dụng truyền video streaming của mạng Chord. Sau đó ta sẽ thực hiện triển khai trên
môi trƣờng thực nghiệm để so sánh việc áp dụng giải pháp và không áp dụng giải pháp
trên một số thông số. Dựa vào kết quả so sánh sẽ đánh giá tính khả thi của giải pháp.
T
L
= α. TimeoutCalculationEWMA
T
L
= α. TimeoutCalculationUCL
Kết quả thực nghiệm đƣợc mô tả nhƣ hình vẽ sau:
1.1.1.1. EWMA và α =1
(a) Thống kê tỷ lệ lỗi thật sự/số lần báo timeout
4


Nhƣ bảng thống kê bên dƣới và hình vẽ. Với 10 lần thực nghiệm thì trung bình độ
chính xác là 3%.
#
Timeout
Failed
Percentage
EWA1
117
3
2.56
EWA2
730
10
1.37

EWA3
330
6
1.82
EWA4
77
6
7.79
EWA5
26
1
3.85
EWA6
255
6
2.35
EWA7
167
4
2.4
EWA8
478
14
2.93
EWA9
61
4
6.56
EWA10
455

7
1.54
AVR
269.6
6.1
3.317


(b) Số lần timeout/1000Multicast Package:
Thông số này đánh giá mức độ quá tải của giải pháp. Trung bình phải xử lý 13 lần
timeout trong 1000 gói tin Multicast nhận đƣợc.
5



1.1.1.2. EWMA và α =2
(a) Thống kê tỷ lệ lỗi thật sự/số lần báo timeout
Với 5 lần thực nghiệm thì trung bình độ chính xác là 31%. Độ chính xác gấp 10 lần
khi α =1.
#
Timeout
Failed
Percentage
EWA1
3
2
66.67
EWA2
22
6

27.27
EWA3
35
7
20
EWA4
23
4
17.39
EWA5
21
5
23.81
AVR
20.8
4.8
31.028


(b) Số lần timeout/1000Multicast Package
6


Trung bình phải xử lý 0.98 lần timeout trong 1000 gói tin Multicast nhận đƣợc.

1.1.1.3. UCL và α =2
(a) Thống kê tỷ lệ lỗi thật sự/số lần báo timeout
Với 5 lần thực nghiệm thì trung bình độ chính xác là 21%.
#
Timeout

Failed
Percentage
EWA1
36
4
11.11
EWA2
9
2
22.22
EWA3
4
1
25
EWA4
10
3
30
EWA5
21
4
19.05
AVR
16
2.8
21.476


(b) Số lần timeout/1000Multicast Package
7

Trung bình phải xử lý 1.228 lần timeout trong 1000 gói tin Multicast nhận đƣợc

1.1.2. Kết luận
Với kết quả thực nghiệm nói trên, ta có thể thể rằng với công thức EWMA với α =2 là
thực sự có hiệu quả hơn cả. Tỷ lệ chính xác lên đến 31% và chỉ cần xử lý 1 gói tin
timeout trong 1000 gói tin multicast.
Với độ chính xác là 31%, đã ghi nhận đƣợc kết quả khả quan vì mục tiêu giải pháp
không phải đƣa ra con số chính xác node chết mà sau khi khẳng định tạm thời có
timeout, cơ chế sẽ tiếp tục ping lại.
Sau khi ping lại thì tỷ lệ khẳng định lỗi là 100% và có thể hoàn toàn định vị đƣợc số
lƣợng lỗi và vị trí lỗi. Điều đó giúp ích cho việc khôi phục lỗi nhanh của quá trình
truyền multicast.
8


KẾT LUẬN
Đƣa ra kết luận; đánh giá khả năng áp dụng thực tế của giải pháp.
9


CHƢƠNG 2: TỔNG QUAN VIDEO STREAMING
2.1. Video streaming
Từ sự phát triển của Internet và nhu cầu ngày càng phát triển của con ngƣời, video
streaming đã ra đời và phát triển theo hai xu hƣớng chính: video streaming theo yêu
cầu và video streaming thời gian thực.
Sự phát triển về công nghệ thông tin, công nghệ nén, các thiết bị lƣu trữ băng thông
cao và mạng với tốc độ nhanh đã làm cho các dịch vụ truyền video streaming thời gian
thực ngày càng trở lên linh động trên mạng Internet. Video streaming thời gian thực có

các yêu cầu về băng thông, tỷ lệ mất gói tin, độ trể để có thể hiển thị hình ảnh thực với
chất lƣợng tốt.
Tuy nhiên, Internet hiện nay không thể cung cấp một chất lƣợng dịch vụ đủ đảm bảo
có thể video streaming trên Internet. Nhƣ vậy, cơ chế thiết kế, các giao thức về video
streaming trên Internet có rất nhiều thách thức.
Ta sẽ phân tích sâu về video streaming để hiểu cách thách thức đó. Video streaming
bao gồm sáu thành phần then chốt quan hệ nhƣ hình dƣới.


Hình 2.1: Sáu thành phần của video streaming dữ liệu


10


Dữ liệu truyền hình và truyền thanh thô đƣợc nén trƣớc bằng các giải thuật nén truyền
hình và truyền thanh sau đó đƣợc lƣu ở thiết bị lƣu trữ. Theo yêu cầu của ngƣời dùng,
một máy chủ luồng nhận dữ liệu truyền hình/truyền thanh đã đƣợc nén từ các thiết bị
lƣu trữ và sau đó bộ phận điều khiển chất lƣợng dịch vụ điểm phát/nhận sẽ điều
chỉnh luồng bit truyền hình/truyền thanh theo tình trạng của mạng và theo yêu cầu chất
lƣợng dịch vụ. Sau khi điều chỉnh, các giao thức truyền thông sẽ đóng gói luồng bit
nén và gửi các gói tin truyền hình/truyền thông tới mạng Internet. Các gói tin có thể bị
mất và trễ trong Internet do sự tắc nghẽn. Để cải tiến chất lƣợng của việc truyền, các
dịch vụ phân tán dữ liệu trên mạng đƣợc triển khai trên Internet. Khi các gói tin đến
nơi nhận, đầu tiên nó sẽ truyền qua tầng giao vận và sau đó đƣợc xử lý bởi tầng ứng
dụng trƣớc khi đƣợc giải mã bởi bộ giải mã truyền hình/truyền thanh. Để đáp ứng
đƣợc hiển thị đồng bộ giữa tiếng và hình, cần có cơ chế đồng bộ đa phƣơng tiện.
Nhƣ vậy có thể thấy đƣợc thứ tự cũng nhƣ sự liên kết của sáu thành phần nêu trên. Ở
mỗi giai đoạn, dữ liệu truyền thông có thể đƣợc nâng cao và luận văn sẽ lựa chọn ra
một thành phân dịch vụ phân tán dữ liệu trên mạng để đi sâu nghiên cứu. Nhƣng

trƣớc tiên, ta sẽ nghiên cứu tổng quan về sáu thành phần đó.
2.2. Nén truyền hình
Khi dữ liệu thô tiêu thụ một khối lƣợng băng thông lớn, việc nén thƣờng đƣợc thực
hiện để nhằm mục đích truyền thông hiệu quả hơn.
Về cơ bản, các cơ chế nén truyền hình có thể đƣợc phân thành hai loại: mã hóa mở
rộng và không mở rộng. Để đơn giản, ta chỉ nghiên cứu mã hóa và giải mã trong chế
độ intra và chỉ dùng truyền cosin rời rạc (DCT). Với việc mã hóa truyền hình mở rộng
dạng sóng, ta sẽ có các nghiên cứu khác.
11



Hình 2.2: a) Mã hóa không mở rộng. b) Giải mã không mở rộng


Hình 2.3: a) Mã hóa mở rộng SNR. b) Giải mã mở rộng SNR
Mã hóa không mở rộng sẽ tạo ra một luồng bít nén. Ngƣợc lại, mã hóa mở rộng sẽ nén
truyền hình thô thành nhiều luồng con. Một trong những luồng nén là một luồng con
cơ bản mà có thể đƣợc giải mã độc lập và cung cấp một chất lƣợng hình xấu. Các
luồng con nén khác là các luồng nâng cao, mà có thể đƣợc giải mã đồng thời với luồng
cơ bản và có thể cung cấp chất lƣợng hình tốt hơn. Luồng bit toàn phần (bao gồm sự
gắn kết toàn bộ luồng con) sẽ cung cấp chất lƣợng tốt nhất. So với giải mã toàn phần,
giải mã luồng cơ bản và các luồng khác tạo ra các hình ảnh khác nhau: hoặc kích
thƣớc ảnh nhỏ hơn, hoặc tỷ lệ hình nhỏ hơn.
12



Hình 2.4 a) Bộ mã hoá FGS. B) Bộ giải mã FGS
Ngoài ra còn có các cơ chế nén khác nhƣ mã hoá FGS hay PFGS (PFGS - Progressive

Fine Granularity Scalability).
Tiếp theo, mô tả các yêu cầu chất lƣợng cho các ứng dụng video streaming trong việc
mã hoá và giải mã truyền thông:
- Băng thông: để đạt đƣợc cảm giác chấp nhận đƣợc, một ứng dụng luồng thông
thƣờng có một yêu cầu băng thông tối thiểu. Các ứng dụng video streaming cần
điều khiển tắc nghẽn để tránh tắc nghẽn, hay xảy ra trên mạng có tải lớn. Với
video streaming, điều khiển tắc nghẽn là hình thái khác của điều khiển tỷ lệ; tức
là điều chỉnh tỷ lệ gửi để thích hợp với băng thông còn lại trên mạng. So sánh
với truyền thông không mở rộng, truyền thông mở rộng dễ thích ứng hơn với sự
thay đổi băng thông trên mạng.
- Độ trễ: video streaming yêu cầu độ trễ giới hạn cho các gói tin có thể tới đƣợc
bên nhận đúng thời gian để giải mã và trình diễn. Nếu nhƣ gói tin truyền không
đến đúng thời hạn, việc trình diễn sẽ dừng và điều đó sẽ rất khó chịu với mắt
ngƣời. Một gói tin đến đúng ngƣỡng trễ (còn gọi là thời gian trình diễn) thì
cũng vô nghĩa và có thể coi nhƣ là đã mất vì nó không kịp xử lý để hiển thị.
- Mất mát: mất gói tin là không thể tránh đƣợc trên mạng Internet và có thể làm
hỏng hình ảnh. Do đó, video streaming cần giải quyết đƣợc sự mất gói tin. Mã
hoá đa mô tả là một công nghệ nén để giải quyết sự mất mát gói tin.
13


- Chức năng giống Máy ghi âm-castset-video (VCR): một số ứng dụng yêu cầu
chức năng giống VCR nhƣ có thể dừng, tạm dừng/trình diễn lại, chạy tua nhanh
trƣớc, chạy tua nhanh lùi và chạy ngẫu nhiên.
- Độ phức tạp giải mã: một số thiết bị nhƣ điện thoại nhỏ hoặc PDAs yêu cầu tốn
ít năng lƣợng điện. Do đó, các ứng dụng truyền thông truyền hình chạy trên
thiết bị đó cần đơn giản. Đặc biệt độ phức tạp giải mã là phải chấp nhận đƣợc.
Trong các yêu cầu chất lượng trên thì để giảm việc mất mát gói tin còn có các cơ
chế về truyền thông mạng. Đó có thể là cơ chế khôi phục lỗi trên mạng, giảm thời
gian lỗi xảy ra. Làm được điểu đó, gói tin sẽ được truyền thông liên tục, kịp thời.

2.3. Máy chủ luồng – streaming server
Máy chủ luồng đóng một vai trò quan trọng trong việc cung cấp dịch vụ video
streaming. Để đƣa ra những dịch vụ chất lƣợng cao, máy chủ luồng cần phải xử lý dữ
liệu đa phƣơng tiện với sự ràng buộc về thời gian. Ngoài ra, máy chủ luồng cũng cần
hỗ trợ các hoạt động điều khiển VCR. Hơn nữa, nó cũng cần cung cấp chức năng
truyền thông kiểu đồng bộ.
Để làm đƣợc điều đó, thông thƣờng, máy chủ luồng gồm các thành phần sau:
- Bộ phiên dịch: Một bộ phiên dịch tham gia vào tầng ứng dụng và các giao thức
vận tải đƣợc thực hiện trong máy chủ. Thông qua bộ biên dịch, các máy khách
có thể giao tiếp với một máy chủ và nhận nội dung đa phƣơng tiện một cách
liên tục và đồng bộ.
- Hệ điều hành: Khác với hệ điều hành thông thƣờng, hệ điều hành cho máy chủ
luồng cần phải có thời gian thực an toàn cho các ứng dụng luồng.
- Hệ lưu trữ: phải hỗ trợ lƣu trữ truyền thông liên tục và có thể truy cập đƣợc.
Tiếp theo, ta sẽ mô tả về các cơ chế điều khiển chất lƣợng dịch vụ, là cơ chế thích ứng
luồng bit truyền thông theo trạng thái của mạng và yêu cầu chất lƣợng dịch vụ cho nó.
2.4. Điều khiển chất lƣợng tại điểm phát và nhận.
Mục đích của điều khiển chất lƣợng dịch vụ tầng ứng dụng là để tránh tắc nghẽn và tối
đa hoá chất lƣợng truyền thông trong trƣờng hợp mất mát gói tin. Các công nghệ điều
khiển chất lƣợng dịch vụ tầng ứng dụng bao gồm điều khiển tắc nghẽn và điều khiển
lỗi. Những công nghệ này đƣợc thực hiện ở các điểm phát và nhận.
14


2.4.1. Điều khiển tắc nghẽn
Việc lỗi nhiều và độ trễ quá mức có một hiệu ứng rất xấu tới chất lƣợng trình diễn
truyền hình và thƣờng do nguyên nhân tắc nghẽn mạng. Do đó, cơ chế điều khiển tắc
nghẽn ở điểm cuối là cần thiết để giúp giảm tỷ lệ mất gói tin và giảm độ trễ.
Trong video streaming, điều khiển tắc nghẽn giống nhƣ điều khiển tỷ lệ. Điều khiển tỷ
lệ tối thiểu hoá khả năng tắc nghẽn của mạng bằng việc chọn tỷ lệ video streaming phù

hợp với băng thông mạng còn lại.
2.4.1.1. Điều khiển tỷ lệ
Điều khiển tỷ lệ là công nghệ đƣợc sử dụng để xác định tỷ lệ gửi của truyền thông
truyền hình dựa vào ƣớc lƣợng băng thông còn lại trên mạng. Cơ chế điều khiển tỷ lệ
có thể chia theo ba loại chính: điều khiển tỷ lệ theo nguồn, theo bên nhận và kết hợp.
(a) Điều khiển tỷ lệ theo nguồn:
Trong điều khiển tỷ lệ theo nguồn, bên gửi sẽ có trách nhiệm lựa chọn tỷ lệ truyền
truyền hình thích hợp. Thông thƣờng cơ chế điều khiển tỷ lệ dựa vào đáp trả của bên
nhận để điều chỉnh lại tỷ lệ truyền. Điều khiển tỷ lệ bên nguồn có thể áp dụng vào cả
unicast và multicast nhƣ Hình 2.5.

Hình 2.5:a) Phân tán truyền thông unicast. B) Phân tán truyền thông multicast
Với truyền hình unicast, cơ chế này sẽ thực hiện hai cách tiếp cận: tiếp cận theo điều
tra và tiếp cận theo mô hình.
15


- Cách tiếp cận theo điều tra (tiếng Anh: probe). Việc điều tra nguồn với băng
thông mạng hiện có bằng việc điều chỉnh tỷ lệ gửi theo cách mà có thể bảo trì tỷ
lệ mất gói tin p dƣới một ngƣỡng P
th
. Có hai cách để điều chỉnh: 1) tăng cấp số
cộng và giảm cấp số nhân và 2) tăng cấp số nhân và giảm cấp số nhân. Chi tiết
không đƣợc đề cập trong luận văn, tham khảo mục [7].
- Cách tiếp cận theo mô hình dựa vào mô hình quá trình của kêt nối giao thức
điều khiển truyền thông (TCP). Thông lƣợng của một kết nối TCP có thể đƣợc
đặt dựa vào công thức

Với:
λ: thông lượng của một kết nối TCP.

MTU: maximum transit unit là kích thước gói tin được dùng trong kết nối.
RTT: rount-trip time của một kết nối.
p: tỷ lệ mất gói tin của kết nối.
Điều khiển tỷ lệ theo nguồn cho multicast: ngƣời gửi sẽ sử dụng một kênh để truyền
luồng truyền hình tới các bên nhận. Multicast đó đƣợc gọi là multicast kênh đơn và áp
dụng cơ chế điều khiển tỷ lệ dựa vào điều tra cho mỗi kênh đơn.
(b) Điều khiển tỷ lệ theo bên Nhận
Bên nhận sẽ tính toán tỷ lệ nhận của video streaming bằng việc thêm hoặc bỏ đi các
kênh; bên gửi không tham gia vào điều khiển tỷ lệ. Thông thƣờng, điều khiển tỷ lệ
theo bên nhận đƣợc sử dụng trong truyền hình mở rộng multicast, nơi mà có nhiều
tầng trong truyền hình mở rộng và mỗi tầng tƣơng ứng với một kênh trong cây
multicast. Tƣơng tự với điều khiển tỷ lệ theo bên gửi, các cơ chế của bên nhận có hai
loại tiếp cận: tiếp cận theo điều tra và tiếp cận theo mô hình.
(c) Điều khiển tỷ lệ kết hợp
Bên nhận sẽ tính tỷ lệ của video streaming bằng việc thêm/bỏ các kênh trong khi bên
nhận cũng điều chỉnh tỷ lệ truyền của mỗi kênh thông qua đáp trả của bên nhận.
2.4.1.2. Hình thái tỷ lệ
Mục đích của hình thái tỷ lệ là điều chỉnh tỷ lệ của luồng bít truyền hình trƣớc khi nén
với các ràng buộc về tỷ lệ. Bộ hình thái (hay bộ lọc) sẽ thực hiện hình thái hoá theo
16


yêu cầu của bộ điều khiển tỷ lệ ở bên nguồn. Vì nhiều trƣờng hợp dữ liệu đƣợc nén
theo tỷ lệ không phù hợp với băng thông hiện có trên mạng. Có nhiều bộ lọc nhƣ bộ
lọc giải mã, bộ lọc bỏ frame, bộ lọc bỏ tầng, lọc tuần tự, lọc lƣợng tử hoá đƣợc mô tả
cụ thể dƣới đây.
- Lọc giải mã: là giải mã và nén một video streaming. Nó thƣờng đƣợc sử dụng
để thực hiện chuyển mã từ cơ chế nén này sang cơ chế nén khác nhau.
- Lọc bỏ frame: có thể phân biệt các loại frame (I, P, B trong MPEG) và bỏ một
số frame theo một thứ tự ƣu tiên. Ví dụ thứ tự bỏ nên bắt đầu từ frame B, sau đó

đến P và cuối cùng là I. Bộ lọc bỏ frame đƣợc dùng để giảm tỷ lệ dữ liệu của
luồng bit truyền thông bằng việc loại bỏ một số frame và truyền các frame còn
lại với tỷ lệ thấp hơn. Bộ lọc bỏ frame có thể đƣợc sử dụng ở bên nguồn cũng
nhƣ ở mức mạng.
- Bộ lọc bỏ tầng: có thể phân biệt các tầng và bỏ các tầng theo mức độ quan
trọng. Thứ tự bỏ có thể từ tầng mở rộng cao nhất đến tầng cơ bản.
- Bộ lọc tuần tự: thực hiện ở tầng nén. Nó sẽ thực hiện tuần tự (ví dụ theo hệ số
DCT). Cơ chế bộ lọc tuần tự bao gồm lọc luồng chậm, lọc giảm màu. Lọc luồng
chậm là để bỏ đi hệ số DCT của các tuần suất cao. Lọc giảm màu thực hiện
hành động tƣơng tự lọc luồng chậm với thông tin màu sắc trong video
streaming. Trong MPEG, cơ chế lọc màu sẽ thực hiện thay tất cả các khối màu
bằng một khối trống. Không giống cơ chế bỏ frame, cơ chế lọc tuần tự giảm
băng thông mà không ảnh hƣởng đến tỷ lệ frame.
- Lọc lượng tử hoá: thực hiện trên tầng nén (ví dụ hệ số DCT). Bộ lọc sẽ đƣa ra
các hệ số DCT từ video streaming đa nén thông qua kỹ thuật tƣơng tự giải
lƣợng tử hoá sau đó nó sẽ lƣợng tử hoá lại theo hệ số DCT với bƣớc nhảy lƣợng
tử lớn hơn giảm tỷ lệ hơn.
Tổng kết lại, mục tiêu của điều khiển tắc nghẽn là giảm thiểu tắc nghẽn. Nói cách khác,
mất mát gói tin là không thể tránh đƣợc trong Internet và có thể ảnh hƣởng lớn tới chất
lƣợng. Điều đó thúc đẩy việc thiết kế cơ chế để tối đa hoá chất lƣợng trình diễn truyền
thông với các gói tin bị mất. Điều khiển lỗi là cơ chế nhƣ vậy và sẽ đƣợc trình bày tiếp
theo đây.
2.4.2. Điều khiển lỗi
Cơ chế điều khiển lỗi bao gồm FEC, truyền lại và mã hoá co giãn lỗi và che giấu lỗi.
17


2.4.2.1. FEC
Nguồn gốc của FEC (tiếng Anh: Forward Error Connection) là thêm các thông tin thừa
để gói tin nguồn có thể tái tạo lại khi gói tin bị mất. Ta sẽ phân loại các cơ chế FEC

hiện có thành ba loại: FEC dựa vào mã hoá kênh, mã hoá nguồn và mã hoá
nguồn/kênh kết hợp.
Với các ứng dụng internet, mã hoá kênh là loại thƣờng đƣợc sử dụng để mã hoá các
khối. Một video streaming là sẽ đƣợc chặt ra thành nhiều đoạn, mỗi đoạn sẽ đƣợc đóng
gói thành k gói tin; do đó với mỗi đoạn, một cách mã hoá khối đƣợc áp dụng cho k gói
tin để tạo ra khối n gói tin với n>k. Để có thể khôi phục lại một đoạn, ngƣời dùng chỉ
cần nhận đƣợc bất cứ k gói tin trong khối n gói.
FEC dựa trên mã hoá nguồn (tiếng Anh: SFEC - Source Forward Error Connection)
thƣờng đƣợc biến đổi theo FEC của truyền hình Internet. Giống nhƣ mã hoá kênh,
SFEC cũng thêm các thông tin dƣ thừa để khôi phục lỗi. Ví dụ gói tin thứ n sẽ chứa
khối thứ n của nhóm (tiếng Anh: GOB - Group of blocks), mà là một phiên bản đã nén
của GOB thứ (n-1) với lƣợng tử rộng hơn.
Mã hoá kênh/nguồn kết nối là một cách tiếp cận để tối ƣu phân bổ tỷ lệ giữa mã hoá
nguồn và mã hoá kênh.
2.4.2.2. Truyền lại với ràng buộc trễ
Truyền lại thƣờng không đƣợc ƣu chuộng để khôi phục gói tin trong truyền thông thời
gian thực vì gói tin truyền lại có thể lỡ mất thời gian trình diễn. Tuy nhiên, nếu thời
gian truyền lại là ngắn và thỏa mãn độ trễ cho phép, thì cách tiếp cận theo phƣơng
hƣớng truyền lại với ràng bộc độ trễ là một lựa chọn có thể cho điều khiển lỗi.
Với unicast, bên nhận có thể thực hiện cơ chế truyền lại ràng buộc độ trễ. Khi bên
nhận phát hiện mất gói tin N. If (T
c
+ RTT + D
s
< T
d
(N)) thì sẽ gửi yêu cầu gói tin N
tới bên nhận.
Với T
c

là thời gian hiện tại.
RTT: thời gian ước lượng chu trình,
D
s
: cụm từ chểnh mảng,
T
d
(N): thời gian khi gói tin N được lập kế hoạch hiển thị.
18



Hình 2.6: Biểu đồ thời gian cho Điều khiển theo bên nhận
2.4.2.3. Mã hoá đàn hồi lỗi
Mục đích của mã hoá đàn hồi lỗi là tăng cƣờng sức mạnh của luồng nén đối với việc
mất gói tin. Cơ chế mã hoá đàn hồi lỗi chuẩn gồm đánh dấu đồng bộ lại, chia dữ liệu
và khôi phục dữ liệu. Khi một gói tin mất có thể gây ra sự mất mát của dữ liệu
hình/nội dung, cơ chế đánh dấu điểm đồng bộ lại, chia dữ liệu và khôi phục lại dữ liệu
có thể hữu ích với các ứng dụng truyền hình Internet. Do đó, chúng ta sẽ không giới
thiệu về các công cụ đàn hồi lỗi chuẩn. Thay vào đó, sẽ mô tả mã hoá đa mô tả (tiếng
Anh: MDC – Multiple Description Coding).
Với mã hoá đa mô tả một thứ tự truyền hình thô sẽ đƣợc nén thành nhiều luồng (gọi là
các mô tả) nhƣ sau: mỗi mô tả cung cấp một chất lƣợng chấp nhận đƣợc, càng kết nối
mô tả thì càng cung cấp chất lƣợng tốt hơn. Ƣu điểm của mã hoá đa mô tả là:
- Sức mạnh với lỗi: thậm chí nếu bên nhận chỉ nhận đƣợc một mô tả (tất cả các
mô tả khác mất) thì nó vẫn có thể tái cấu trúc lại truyền hình với chất lƣợng
chấp nhận đƣợc.
- Mở rộng chất lượng: nếu bên nhận có nhiều mô tả hơn thì nó có thể gắn kết lại
với nhau và tái cấu trúc thành truyền hình có chất lƣợng tốt hơn.
Tuy nhiên, những ƣu điểm đó có cái giá của nó. Để tạo một mô tả cung cấp các chất

lƣợng chấp nhận đƣợc, mỗi mô tả cần phải đƣa ra các thông tin cần thiết về truyền
hình ban đầu. Thêm vào đó, mặc dù càng kết nối mô tả để cung cấp chât lƣợng tốt hơn,
sự đúng đắn của việc kết hợp các mô tả có thể làm cho chất lƣợng nén sau này giảm đi.