Nghiên cứu công nghệ nén và truyền video streaming hiệu quả qua mạng di động và phát triển ứng dụng

Quá trình này được gọi là buffering và có thể được diễn giải như sau: thay vì được gửi một lần duy nhất, dữ liệu streaming video sẽ được truyền đi thành các gói nhỏ, ban đầu player sẽ lấ

MỤC LỤC

MỤC LỤC I

L I C M ĐO N III

L I C M N IV

D NH MỤC C C K HI U C C CHỮ VI T TẮT V

D NH MỤC C C H NH V Đ TH VI

D NH MỤC C C NG VIII

MỞ ĐẦU IX

CHƯ NG 1: TỔNG QU N VỀ CÔNG NGH NÉN VÀ STRE MING VIDEO 1

1.1 Tổng Quan Về Công Nghệ Nén 1

1.1.1 Khái niệm và mục đích của công nghệ nén 1

1.1.2 Phân lo i các thuật toán nén 1

1.1.3 Một số thuật toán nén dữ liệu 3

1.1.3.1 Mã Huffman 3

1.1.3.2 Thuật toán mã lo t dài - Run Length encoding (RLE) 6

1.1.3.3 Phương pháp nén ảnh JPEG 7

1.2 Tổng Quan Về Streaming Video 10

1.2.1 Giới thiệu streaming video 10

1.2.2 Lịch sử phát triển 13

1.2.3 K thuật cơ bản trong streaming video 14

1.2.3.1 Một số hái niệm được sử dụng trong streaming video 14

1.2.3.2 Các bước thực hiện thuật streaming video 15

1.2.4 Một số giao thức sử dụng trong streaming video 16

1.2.4.1 Giao thức TCP/UDP 16

1.2.4.2 Giao thức RTSP (Real Time Streaming Protocol) 19

1.2.4.3 Giao thức Real-time Transport Protocol (RTP) 23

1.3 Kết Luận Chương 1 26

CHƯ NG 2: THUẬT TO N NÉN SỬ DỤNG TRONG STRE MING VIDEO 27

2.1 Các Chuẩn Nén Video Phổ iến 27

2.2 Chuẩn Nén MPEG 29

2.2.1 Nhóm ảnh (GOP) trong MPEG 30

2.2.2 Quá trình mã hóa và giải mã MPEG 31

2.2.3 Các bước thực hiện thuật toán nén MPEG 33

2.3 Chuẩn Nén Thường Được Sử Dụng Trong Streaming Video Trên M ng Di Động 45

2.4 Kết Luận Chương 2 47

CHƯ NG 3: PH T TRIỂN ỨNG DỤNG 48

3.1 Đặt Vấn Đề 48

3.2 Đặc Tả Ứng Dụng 51

3.2.1 Tính hả thi của ứng dụng 51

3.2.2 Phân tích yêu cầu 52

3.3 Thiết Kế 53

3.3.1 Thiết ế server 54

3.3.2 Thiết ế client 54

3.4 Cài Đặt 56

3.5 So Sánh 59

3.5.1 Tốc độ truyền dữ liệu 59

3.5.2 Dung lượng pin tiêu thụ 60

3.5.3 Dung lượng của ứng dụng 61

3.5.4 Kết luận 61

CHƯ NG 4: K T LUẬN 62

TÀI LI U TH M KH O 63

L C M ĐO N

Tác giả luận v n xin cam đoan đây là công trình nghiên cứu của riêng tác giả luận v n đúc ết từ quá trình nghiên cứu từ việc tập hợp các nguồn tài liệu, các iến thức đã học đến việc tự thu thập các thông tin liên quan và liên hệ thực tế t i đơn vị công tác Các số liệu, ết quả nêu trong luận v n là trung thực và chưa từng được ai công bố trong bất ỳ công trình nào hác

Tác giả luận v n xin cam đoan rằng mọi sự giúp đỡ cho việc thực hiện Luận

v n này đã được cảm ơn và các thông tin trích dẫn trong Luận v n đã được chỉ rõ nguồn gốc

Tác giả luận v n xin chịu trách nhiệm về nghiên cứu của mình

c vi t c i u v

Mai Đức Tru g

L C M N

Trước tiên, tác giả luận v n xin được gửi lời cảm ơn đến tất cả qu thầy cô

đã giảng d y trong chương trình đào t o th c s , Viện Công Nghệ Thông Tin và Truyền Thông, Đ i học ách Khoa Hà Nội, những người đã truyền đ t cho tác giả những iến thức hữu ích về giải thuật cũng như công nghệ nén để làm cơ sở cho tác giả thực hiện tốt luận v n này

Với lòng ính trọng và biết ơn, tác giả luận v n xin được bày tỏ lời cảm ơn tới TS Ph m Đ ng Hải đã huyến hích, tận tình hướng dẫn trong thời gian thực hiện luận v n Mặc dù trong quá trình thực hiện luận v n có giai đo n hông được thuận lợi nhưng những gì thầy đã hướng dẫn, chỉ bảo đã cho tác giả luận v n nhiều inh nghiệm trong thời gian thực hiện đề tài

Sau cùng tác giả luận v n xin gửi lời biết ơn sâu sắc đến gia đình, b n bè đã luôn t o điều iện tốt nhất cho tác giả luận v n trong suốt quá trình học cũng như thực hiện luận v n Do thời gian có h n và inh nghiệm nghiên cứu hoa học chưa nhiều nên luận v n còn nhiều thiếu sót, rất mong nhận được iến góp của Thầy,

Cô và các b n học viên

c vi t c i u v

Mai Đức Tru g

D N MỤC C C U, C C C Ữ V T T T

MB Macro Block: Khối hình chữ nhật

JPEG Joint Photographic Expert Group: Nhóm các chuyên gia về ảnh MPEG Moving Picture Coding Export Group: Nhóm các chuyên gia về

Video GOP Group of picture: Nhóm ảnh

DCT Discrete cosine transform: iến đổi cosin ngược

RTP Real-time Transport Protocol: Giao thức chuẩn định d ng cho

gói tin (packet) video hay audio được truyền trên m ng RTSP Real Time Streaming Protocol: Giao thức m ng điều hiển quá

trình streaming video hay streaming audio OTT Over The Top: Giải pháp cung cấp nội dung cho người sử dụng

dựa trên nền tảng internet

D N MỤC C C ÌN VẼ, ĐỒ T Ị

Hình 1.1 Sơ đồ mã hóa và giải mã theo JPEG [9] - 8

Hình 1.2 Quy trình Streaming Video (Senvietsystem.com) - 12

Hình 1.3 Các bước thực hiện streaming video [8] - 15

Hình 1.4 Mô hình của giao thức TCP [8] - 16

Hình 1.5.Ví dụ về trường hợp dữ liệu streaming nhận về sau thời điểm deadline [8] - 18

Hình 1.6 OPTIONS request - 20

Hình 1.7 DESCRIBE Request - 21

Hình 1.8 SETUP Request - 22

Hình 1.9 PLAY Request - 22

Hình 1.10 PAUSE Request - 23

Hình 1.11 TEARDOWN Request - 23

Hình 1.12 Header của RTP Pac et - 25

Hình 2.1 Cấu trúc GOP mở - 30

Hình 2.2 Cấu trúc GOP đóng - 31

Hình 2.3 ộ Mã hóa MPEG - 33

Hình 2.4 ộ giải mã MPEG - 33

Hình 2.5 Cấu trúc lấy mẫu theo chuẩn 4:4:4 - 34

Hình 2.6 Cấu trúc lấy mẫu theo chuẩn 4:2:2 - 35

Hình 2.7 Cấu trúc lấy mẫu theo chuẩn 4:2:0 - 35

Hình 2.8 Cấu trúc lấy mẫu theo chuẩn 4:1:1 - 36

Hình 2.9 Một chuỗi hung hình trong MPEG với 2 hả n ng tham chiếu: một hung hình P tham chiếu tới một hung hình I và một hung hình tham chiếu tới 2 khung hình P [7] - 37

Hình 2.10 Sơ đồ của dự đoán chuyển động [7] - 38

Hình 2.11 Khu vực tìm iếm của hung hình trước [7] - 39

Hình 2.12 Mô tả lỗi dự đoán [7] - 40

Hình 2.13 Công thức biến đổi Cosin rời r c - 42

Hình 2.14 Công thức nghịch đảo của biến đổi Cosin rời r c - 42

Hình 2.15 ảng trọng số theo tiêu chuẩn tín hiệu chói và tín hiệu màu - 44

Hình 2.16 Các bước thực hiện theo chuẩn nén MPEG [7] - 44

Hình 3.1 Thống ê và dự đoán số lượng điện tho i thông minh trên thế giới

[http://www statista com/] - 48

Hình 3.2 Thống ê và dự đoán số lượng điện tho i thông minh ở Việt Nam [http://www statista com/] - 50

Hình 3.3 iểu đồ Use Case của ứng dụng - 53

Hình 3.4 iểu đồ Class Diagram của server - 54

Hình 3.5 iểu đồ Class Diagram của client - 55

Hình 3.6 Màn hình đ ng nhập - 56

Hình 3.7 Màn hình đ ng - 57

Hình 3.8 Màn hình danh sách b n bè - 57

Hình 3.9 Màn hình hội tho i video - 58

D N MỤC C C B NG

ảng 1.1 Mã hóa Huffman theo xác suất phân bổ 5

ảng 2.1 Một số chuẩn nén video phổ biến và ứng dụng [9] 27

ảng 2.2 So sánh các thuật toán nén video phổ biến [9] 45

ảng 2.3 Các yêu cầu cho thuật toán nén trong các ứng dụng phổ biến [9] 46

ảng 3.1 So sánh tốc độ truyền dữ liệu của các ứng dụng (Sử dụng ứng dụng SpeedTest của Ookla) 59

ảng 3.2 So sánh dung lượng pin tiêu thụ của các ứng dụng 600

ảng 3.3 So sánh dung lượng của các ứng dụng 611

MỞ ĐẦU

Với việc ra đời, phát triển hông ngừng của các máy điện tho i thông minh (Smart phone), cộng với việc phát triển công nghệ 3G, 4G của các nhà m ng di động, chiếc điện tho i bây giờ hông chỉ phục vụ duy nhất mục đích nghe gọi, mà

nó đã dần dần thay thế một chiếc PC nối m ng để phục vụ nhu cầu giải trí của con người

Cùng với dịch vụ truy nhập internet (đọc tin tức, nghe nh c…), cuộc gọi thấy hình (Video Call), VoIP và chat (IM), thì dịch vụ truyền hình streaming (Streaming video) là dịch vụ được nhiều thuê bao di động quan tâm và sử dụng

Mặc dù các m ng di động 3G, 4G hông ngừng cải thiện về tốc độ đường truyền nhưng với công nghệ hình ảnh HD, Full HD và 4K có dung lượng cực ỳ lớn hiện nay, thì làm thế nào để có thể giảm chi phí, t ng chất lượng hi truyền streaming video qua m ng di động?

Với đề tài:

Nghiên cứu công nghệ nén và truyền streaming video hiệu quả qua mạng di động và phát triển ứng dụng

Tác giả hi vọng sẽ là tiền để để có thể giải quyết bài toán đó

Kết quả nghiên cứu chính của luận v n được trình bày trong bốn chương như sau:

 Chương 1 Tổng quan về công nghệ nén và streaming video

 Chương 2 Thuật toán nén sử dụng trong streaming video

 Chương 3 Phát triển ứng dụng

 Chương 4 Kết luận

C Ư NG 1: TỔNG QU N VỀ CÔNG NG NÉN VÀ STRE M NG VIDEO

Trong chương 1 tác giả sẽ giới thiệu tổng quan về công nghệ nén và kỹ thuật video streaming

1.1 Tổ g Qua Về Cô g Ng Nén

1.1.1 ái i m và mục đíc của cô g g é

Nén là quá trình mã hóa thông tin (encoding) để thu được thông tin trong một hình thức nhỏ gọn hơn, mục đích làm giảm số bits (dung lượng) cần để lưu trữ hoặc truyền đi Điều này là cần thiết bởi rất nhiều l do Nhưng hai l do quan trọng nhất

Quá trình ngược l i được gọi là giải mã Hệ thống phần cứng hoặc phần mềm mà

có thể mã hóa và giải mã thì được gọi là bộ giải mã

Dữ liệu có thể là bất ỳ lo i gì (text, âm thanh, video…), nhưng tất cả các thuật nén sẽ có hiệu quả trên một lo i dữ liệu nhất định Trong luận v n này, tác giả

sẽ giới thiệu một số thuật toán nén dữ liệu cơ bản, là cơ sở cho các thuật toán nén

dữ liệu khác

1.1.2 P â oại các t u t toá nén

 Các thuật toán nén không tốn hao:

Trong phương pháp nén hông tốn hao, dữ liệu được nén sau hi giải nén sẽ giống y như ban đầu

Các thuật toán nén hông tốn hao được dùng để nén các file như file thực thi, file

v n bản, word, excel, vv… Các dữ liệu hông thể sai lệch dù chỉ 1 bit, nhất là các file chương trình

Các thuật toán nén hông tốn hao cơ bản:

1 Run-length encoding (RLE)

2 Dictionary coders

3 LZ-77 & LZ-78

4 LZW

5 Burrows and Wheeler transform (BWT)

6 Prediction by partial mactching

 Các thuật toán nén tốn hao

Trong các phương pháp nén tổn hao thì dữ liệu được nén hi giải nén ra sẽ hông giống với dữ liệu gốc, tuy nhiên phải đảm bảo dữ liệu sau hi nén vẫn còn hữu ích Đối với hình ảnh, âm thanh, video, do giới h n của mắt và tai người nên một lượng lớn dung lượng có thể được tiết iệm bằng cách lo i bỏ các phần dư thừa, trong khi chất lượng hầu như hông thay đổi

Trong thực tế, các file hình ảnh âm thanh hay là video được lưu trữ trên máy tính đều đã được nén có tổn hao để tiết iệm dung lượng và b ng thông Đối lập với nén

hông tổn hao các phương pháp nén có tổn hao thường gây giảm chất lượng rất nhanh hi thực hiện nén và giải nén đệ qui nhiều lần Các mẫu hình ảnh âm thanh sẽ được chia thành các phần nhỏ và được biến đổi qua miền hác Các hệ số biến đổi này sẽ được lượng tử hóa sau đó được mã hóa bằng mã Huffman hoặc mã hóa số học

Các mẫu hình ảnh âm thanh trước được sử dụng để dự đoán các mẫu tiếp theo Sai số giữa dữ liệu dự đoán và dữ liệu thực sẽ được lượng tử hóa rồi mã hóa

Ưu điểm của nén tổn hao so với nén hông tổn hao đó là nén tổn hao trong nhiều trường hợp cho tỉ lệ nén cao hơn rất nhiều so với bất cứ thuật toán nén hông tổn hao được biết, trong hi vẫn đảm bảo được chất lượng Nén tổn hao thường được sử dụng để nén ảnh, âm thanh, video Âm thanh có thể nén với tỉ lệ 10:1 mà hầu như hông giảm chất lượng Video có thể nén với tỉ lệ 300:1 với chất lượng giảm ít

1.1.3 Một số t u t toá é dữ i u

Như đã giới thiệu ở phần trước, các phương pháp nén dữ liệu được chia làm 2 loại chính là phương pháp nén không tốn hao và phương pháp nén tốn hao Trong phần này tác giả sẽ giới thiệu một số thuật toán nén đặc trưng của 2 phương pháp nén nói trên

1.1.3.1 Mã Huffman

Mục đích của việc nén là chọn được bộ từ mã nhỏ gọn nhất có thế ằng trực giác, ta nên chọn từ mã ngắn cho hiệu thường xuyên xuất hiện, và từ mã dài cho các hiệu có tần suất xuất hiện ít hơn Vì thế, bộ mã hóa tốt nhất sẽ phải phụ thuộc vào tần suất xuất hiện hác nhau của các tự trong bảng chữ cái

Nếu chúng ta sử dụng các từ mã có độ dài l l1, ,2 ,l k để mã hóa một bảng chữ cái nào đó, thì độ dài trung bình của từ mã trên bảng chữ cái đó là:

1

k

i i i



Mục đích của chúng ta là với một phân bố xác suất bất ỳ p p1, 2, ,p k, tìm được một mã hóa giải mã duy nhất sao cho L là nhỏ nhất

Đây chính là tiền đề để Huffman xây dựng lên thuật toán mã hóa Huffman nổi tiếng Các bước của thuật toán Huffman là một tiến trình đệ quy như bên dưới đây: _ Nếu = 2, có ngh a là bảng chữ cái chỉ có 2 tự và , nên chúng ta có thể gán từ mã 0 và 1 cho chúng

_ Mặt hác, nếu > 2, giả sử và là 2 tự gốc với xác suất xuất hiện nhỏ nhất và Chúng ta sẽ ghép và thành 1 tự mới là và gán cho nó xác suất là + ây giờ, chúng ta sẽ xóa và hỏi bảng chữ cái, thay thế chúng bằng tự mới ảng chữ cái mới có -1 tự Chúng ta l i tiếp tục thực hiện đệ quy để xây dựng mã Huffman cho bảng chữ cái mới

_ Tách tự mới sau hi đã gán từ mã cho nó: Giả sử w là từ mã được gán cho

tự ghép Chúng ta sẽ gán từ mã và cho 2 tự và của bảng chữ cái ban đầu

Ví dụ 1: Chúng ta hãy xây dựng một mã Huffman cho một nguồn gồm 5 tự S =

{a,b,c,d,e} với phân bố xác suất xuất hiện như bên dưới:

p (a) = 0.05, p (b) = 0.15, p (c) = 0.6, p (d) = 0.1, p (e) = 0.1

 Các bước thực hiện mã hóa theo thuật toán Huffman như sau:

- ước 1: Tìm 2 tự có xác suất xuất hiện nhỏ nhất ghép l i thành một, gán xác suất cho tự mới bằng tổng xác suất của 2 tự đem ghép

- ước 2: Trong hi số lượng tự trong danh sách còn lớn hơn 2 thì thực hiện bước 1, nếu hông chuyển sang bước 3

- ước 3: Tách tự cuối cùng và t o cây nhị phân với quy ước bên trái được gán mã 0, bên phải được gán mã 1

- ước 4: Tách tự được ghép thành 2 từ đem ghép, và gán từ mã cho 2

tự đem ghép bằng cách thêm bit 0 và bit 1 vào cuối của từ mã được ghép

 Mã hóa lượng tin

Bảng 1.1 Mã hóa Huffman theo xác suất phân bổ

Theo như những phân tích trong tài liệu [5] và [6] thì ưu điểm của mã hóa Huffman là phương pháp thực hiện nén đơn giản, hệ số nén cao, đòi hỏi ít bộ nhớ,

có thể xây dựng trên các mảng bẻ hơn 64K Nhược điểm của nó là phải chứa cả bảng mã vào tập tin nén thì phía nhận mới có thể giải mã được, do đó hiệu suât nén chỉ cao hi ta thực hiện nén các tập tin lớn

1.1.3.2 Thuật toán mã loạt dài - Run Length encoding (RLE)

Trong quá trình thao tác với dữ liệu, chúng ta thường thấy sự lặp đi lặp l i các

dữ liệu có sự tương đồng hay trùng lặp nhau, liên tiếp hay hông liên tiếp Điều này thường thấy trong các tập tin v n bản, hay trong các tập tin đồ họa d ng bitmap… Một câu hỏi đặt ra là, liệu rằng có thể thay thể lo t dữ liệu liền nhau lặp l i trong tập tin thành một dữ liệu đ i diện hác, mục đích để giảm ích thước dữ liệu gốc? Đây chính là tưởng của của thuật toán mã hóa độ dài lo t – Run Length Encoding (RLE)

Xét bảng chữ cái với 4 tự , B, C, D Một tập tin đầu vào như sau:

BBBBBDDDDBBBBBBBAAAAAAAAAAAACCCCCCCCCCDDDDDDAA

AA

Ta có thể thấy rằng, trong tập tin trên, các tự , B, C, D được lặp l i liên tục rất nhiều lần Ta sẽ áp dụng thuật toán RLE để nén tập tin trên bằng việc thay thế các chuỗi tự , B, C, D lặp l i nhiều lần, bằng một tự lặp l i duy nhất và một

số là số lần mà tự đó lặp l i liên tục Kết quả của thuật toán RLE cho tập tin trên

sẽ là: 5 4D7 12 10C6D4

Theo như [2], ưu điểm của phương pháp mã hóa độ dài lo t – RLE là sẽ đ t hiệu quả hi tập tin chứa nhiều chuỗi lặp lớn hơn 1 ngưỡng nhất định nào đó, nó sẽ giảm được đáng ể dung lượng của dữ liệu Còn nhược điểm của nó là với những

lo i dữ liệu mà thông tin ít lặp thì việc sử dụng RLE hông thật sự hiểu quả Nó t o

ra dữ liệu sau hi nén có dung lượng lờn hơn cả dữ liệu ban đầu Đây được gọi là hiệu ứng ngược Xét ví dụ sau:

Cho tập tin: ABCDABCD Nếu ta dùng 1 byte để biểu diễn 1 tự thì độ lớn của

tập tin này sẽ là #8bytes

Sau khi nén bằng RLE sẽ là: 1 1 1C1D1 1 1C1D, độ lớn của tập tin sau hi nén sẽ là #16bytes, gấp đôi dung lượng dữ liệu ban đầu

1.1.3.3 Phương pháp nén ảnh JPEG

JPEG (Joint Photographic Expert Group) là tên của một tổ chức nghiên cứu về các chuẩn nén ảnh (trước đây là ISO) được thành lập vào n m 1982 N m 1986, JPEG chính thức được thiết lập nhờ sự ết hợp giữa nhóm ISO/IEC và ITV Tiêu chuẩn này có thể được ứng dụng trong nhiều l nh vực: lưu trữ ảnh, Fax màu, truyền ảnh báo chí, ảnh cho y học, camerasố v v

Tiêu chuẩn JPEG được định ra cho nén ảnh t nh đơn sắc và màu Tuy nhiên cũng được sử dụng cho nhiều ứng dụng với ảnh động bởi vì nó cho chất lượng ảnh hôi phục há tốt và ít tính toán hơn so với nén MPEG

Hình 1.1 là sơ đồ mã hoá điển hiển của JPEG

Trước hi đưa vào chuyển đổi DCT, ảnh gốc phải được xử l để nén dải tần tín hiệu hiệu màu và chia ảnh thành các hối Việc nén phổ tín hiệu hiệu màu làm giảm

độ dư thừa tâm sinh lý K thuật này dựa vào đặc trưng hệ thống thị giác của con người (HVS: human visual system) Mắt người ém nhậy với sự thay đổi tín hiệu màu hơn sự thay đổi tín hiệu chói Vì vậy, ta hông cần thiết truyền đi thông tin của tín hiệu màu với tần số như truyền thông tin tín hiệu chói

Theo CCIR 601-2, có rất nhiều phương pháp lấy mẫu thông tin tín hiệu hiệu màu Tỷ lệ lấy mẫu thông dụng là 4:2:2 và 4:1:1 Định d ng 4:2:2 ngh a là cứ 4 mẫu tín hiệu chói thì có 2 mẫu cho mỗi lo i tín hiệu hiệu màu Nói cách khác, cứ 2 mẫu tín hiệu chói có 1 mẫu tín hiệu hiệu màu Định d ng 4:1:1 ngh a là cứ 4 mẫu tín hiệu chói thì có 1 mẫu cho mỗi lo i tín hiệu hiệu màu Giả sử tín hiệu hiệu màu chỉ được lấy mẫu theo chiều dọc và mỗi mẫu có 8 bit, số bit trung bình trên một pixel theo tỷ lệ lấy mẫu 4:2:2 là 8×4/2, hay 16 bit/pixel Theo tỷ lệ 4:1:1 là 8×6/4, 12 bits/pixel K thuật lấy mẫu tín hiệu hiệu màu được áp dụng cả hai chiều ngang và dọc D nhiên, điều này làm giảm hơn nữa lượng thông tin về tín hiệu hiệu màu

nh sẽ được chia thành các hối lớn riêng biệt hông chồng nhau (MB-Marco Block) Mỗi M bao gồm 4 block các tín hiệu chói (Y) và 2, 4 hoặc 8 block các

mẫu tín hiệu hiệu màu (Cr, Cb) Số các bloc của tín hiệu hiệu màu phụ thuộc vào tiêu chuẩn lấy mẫu của tín hiệu video: 4:2:2, 4:1:1 hay 4:2:0 v v

Hình 1.1 Sơ đồ mã hóa và giải mã theo JPEG [9]

Tất cả các bloc có cùng ích thước và mỗi bloc là một ma trận điểm ảnh 8×8 pixel được lấy từ một ảnh màn hình theo chiều từ trái sang phải, từ trên xuống dưới Kích thước bloc là 8×8 được chọn bởi hai l do sau:

a) Thứ nhất, qua việc nghiên cứu cho thấy hàm tương quan suy giảm rất nhanh

hi hoảng cách giữa các pixel vượt quá 8

b) Thứ hai, là sự tiện lợi cho việc tính toán và thiết ế phần cứng Nói chung, độ phức t p về tính toán sẽ t ng nếu ích thước bloc t ng

Ví dụ về việc chia thành các bloc của hình ảnh đối với hệ P L Phần tích cực của tín hiệu video với độ phân giải 576×720 sẽ được chia làm 72×90 bloc tín hiệu chói Và như vậy sẽ có 36×45 MB Cấu trúc của M cũng phụ thuộc vào lo i ảnh quét Nếu quét liên tục thì các bloc baogồm các mẫu từ các dòng liên tục (lúc này nén ảnh theo-frame) Ngược l i, trong trường hợp quét xen ẽ, trong một bloc chỉ

có các mẫu của một nửa ảnh (nén ảnh theo-mành) Tóm l i, việc chia hình ảnh thành các ảnh con (MB) sẽ thực sự có ngh a cho bước chuyển vị tiếp theo

1.2 Tổ g Qua Về Streaming Video

1.2.1 Giới t i u streami g video

Streaming video hoặc media streaming là một thuật truyền dữ liệu sao cho nó

có thể được xử l như một dòng ổn định và liên tục Với sự phát triển m nh mẽ của internet thì công nghệ streaming video đang trở nên ngày càng phổ biến và quan trọng hi mà hầu hết người dùng internet hông có quyền truy cập đủ nhanh để tải các tập tin đa phương tiện lớn một cách nhanh chóng Streaming video sẽ cho phép người dùng thay vì phải chờ tải hết tập tin video thì có thể xem nó trong hi đang tải xuống

Với các định d ng file video truyền thống, dữ liệu chỉ có thể hiển thị hi đã được tải xuống toàn bộ, vì vậy đối với các tập tin video chất lượng cao có dung lượng lớn thì công việc này sẽ tiêu tốn rất nhiều thời gian Streaming video thì khác, nó tiết iệm thời gian cho người dùng bằng cách sử dụng các công nghệ giải nén ết hợp với player hiển thị dữ liệu đồng thời trong lúc vẫn tiếp tục tải xuống

Quá trình này được gọi là buffering và có thể được diễn giải như sau: thay vì được gửi một lần duy nhất, dữ liệu streaming video sẽ được truyền đi thành các gói nhỏ, ban đầu player sẽ lấy về một phần chia nhỏ đó của dữ liệu video trước hi hiển thị, đồng thời trong lúc hiển thị các gói dữ liệu còn l i sẽ lần lượt được lấy về để ịp cho việc hiển thị tiếp theo

Trước hi công nghệ streaming ra đời vào n m 1995, các trang Web đơn thuần vẫn chỉ là các trang t nh, nghèo nàn về hình ảnh động và âm thanh Mặc dù công nghệ streaming ra đời đã cho phép phát video trực tiếp trên các trang web nhưng so sánh chất lượng hình ảnh âm thanh với TV truyền thống thì chất lượng của video online là rất thấp, hông chấp nhận được

Ngày nay, công nghệ streaming video phát triển rất nhanh, các nhà nghiên cứu và phát triển dường như rất hứng thú trong l nh vực này Và chất lượng của streaming video đã được cải thiện rất nhiều, nó hầu như đ t được mức chất lượng TV truyền thống, thậm chí có những video đã đ t chuẩn HD, full HD

Với công nghệ streaming, các nhà cung cấp dịch vụ có thể t o, phân phối và hiển thị các streaming video dưới các định d ng của công nghệ streaming (như RM, MOV và ASF) Streaming Video thường được sử dụng trong l nh vực giải trí hoặc

d y học, dùng để lưu trữ các tuyển tập các file video hoặc các bài học, cung cấp cho người dùng các tiện ích như tìm iếm, liệt ê, và hả n ng hiển thị hoặc hiển thị l i các dữ liệu video theo yêu cầu

Streaming Video được thể hiện dưới hai d ng: video theo yêu cầu (on demand)

và video thời gian thực (live event)

Video theo yêu cầu là các dữ liệu video được lưu trữ trên multimedia server và được truyền đến người dùng hi có yêu cầu, người dùng có toàn quyền để hiển thị cũng như thực hiện các thao tác (tua, dừng, nhẩy qua ) với các đo n dữ liệu này Video thời gian thực là các dữ liệu video được chuyển đổi trực tiếp từ các nguồn cung cấp dữ liệu theo thời gian thực (máy camera, microphone, các thiết bị phát dữ liệu video ) Các dữ liệu này sẽ được multimedia phát quảng bá thành các ênh, người dùng sẽ chỉ có quyền truy nhập bất ỳ ênh ưa thích nào để hiển thị dữ liệu

mà hông được thực hiện các thao tác tua, dừng vv trên các dữ liệu đó (giống như

TV truyền thống)

Video Stream sử dụng các giao thức RTP, MMS hay RTSP vv… để truyền dữ liệu theo d ng streaming qua m ng internet, đồng thời sử dụng các chuẩn nén để giảm dung lượng dữ liệu, cung cấp hả n ng nén dữ liệu t i nhiều mức nén, nhiều ích thước hiển thị để có thể phù hợp với độ rông b ng thông của nhiều m ng truyền dẫn khác nhau để tối ưu hoá việc truyền dữ liệu qua m ng Cũng chính vì vậy việc truyền các Streaming Video qua m ng sẽ phụ thuộc rất nhiều vào các sản phẩm phần mềm Streaming Video Server Trong những n m gần đây có rất nhiều các chuẩn công nghệ video streming được phát triển với các player:

Emblaze (http://www emblaze com/)

Liquid Audio (http://www liquidaudio com/)

Macromedia Shockwave (http://www macromedia com/shockwave/)

Microsoft Windows Media (http://www microsoft com/)

RealNetworks RealMedia (http://www real com/)

VDOLive (http://www vdo net/)

Vosiac (http://www vosaic com/)

Audioactive (http://www audioactive com/)

Apple QuickTime (http://www apple com/quicktime/)

Một vấn đề lớn được đặt ra cùng với sự phát triển của các công nghệ streaming video là sự gia t ng của các định d ng dữ liệu riêng và sự hông tương thích của chúng Hơn 8 ứng dụng hác nhau và các plugin của chúng sẽ phải tải về máy người dùng để có thể hiển thị được tất cả các huôn d ng của video qua internet

ởi vậy các định d ng streaming video chỉ giới h n bởi ba công ty được coi là dẫn đầu trong công nghệ streaming với các sản phẩm: pple với Quic Time, RealNetwor s với RealMedia, và Microsoft với Windows Media

Các hãng này đều cung cấp các bộ công cụ trọn gói gồm Streaming Video Server (lưu trữ, truyền phát dữ liệu theo các giao thức hỗ trợ ), Video Player (hiển thị dữ liệu t i phía người dùng), và công cụ iến t o dữ liệu với các chuẩn nén

Hình 1.2 Quy trình Streaming Video (Senvietsystem.com)

1.2.2 Lịc sử p át triể

Trong đầu những n m 1920, George O Squier đã được cấp bằng sáng chế cho một hệ thống về việc truyền tải và phân phối các tín hiệu qua đường dây điện, đó là

cơ sở thuật cho những gì sau này trở thành Muza , một công nghệ streaming âm

nh c liên tục cho các hách hàng thương m i mà hông cần sử dụng đài thu thanh

Đã có nhiều nỗ lực để hiển thị các tập tin media trên các máy tính từ những ngày đầu tiên sơ hai của nền công nghiệp máy tính giữa thế ỷ 20 Tuy nhiên, có ít tiến

bộ đã được thực hiện trong nhiều thập ỷ, chủ yếu do chi phí cao và hả n ng h n chế về phần cứng máy tính Đến những n m 1990, máy tính cá nhân trở nên m nh

mẽ, đủ để hiển thị các tập tin media hác nhau Các vấn đề thuật của máy client

để phục vụ việc streaming là CPU và b ng thông mainboard có đủ sức m nh để hỗ trợ tốc độ các dữ liệu yêu cầu hay không, đã được giải quyết Tuy nhiên, các m ng máy tính vẫn h n chế, cả về m ng lưới, đường truyền, b ng thông, … Khi này, việc hiển thị các tập tin media được thực hiện bằng cách các máy client sẽ tải tập tin từ một máy chủ, rồi lưu nó vào một ổ đ a cứng trên máy tính hoặc lưu trữ nó như là một tập tin thuật số và phát l i từ đ a CD-ROM

"Severe Tire Damage" là ban nh c đầu tiên đã thực hiện phát nh c trực tiếp trên internet Vào ngày 24 tháng 6 n m 1993, ban nh c đã chơi một buổi biểu diễn t i Xerox P RC trong hi ở những nơi hác các nhà hoa học đã thảo luận về công nghệ mới (Mbone) phát sóng trên internet bằng cách sử dụng Multicasting Đây là bằng chứng về công nghệ của họ, ban nh c đã được phát sóng trực tiếp và có thể được nhìn thấy trực tiếp t i Úc và các nơi hác thông qua Internet

RealNetwor s cũng đi tiên phong trong thị trường streaming media, khi phát sóng một trận bóng chày giữa New Yor Yankees và Seattle Mariners qua internet vào n m 1995

Cùng n m này, buổi hòa nh c Concert đầu tiên của dàn nh c giao hưởng trên Internet đã diễn ra t i nhà hát Paramount ở Seattle, Washington vào ngày 10 tháng

11 n m 1995 uổi hòa nh c là một sự hợp tác giữa nh c giao hưởng Seattle và các

nghệ s hách mời hác nhau như Slash (Guns 'n Roses, Velvet Revolver), Matt Cameron (Soundgarden, Pearl Jam), và Barrett Martin (Screaming Trees)

Âm nh c trực tuyến cũng lần đầu được streaming lên Internet, bản nh c đầu tiên được streaming là " ig Wheel" bởi Karthi Swaminathan và tiếp theo là " When

We Were Poor " với Marc Ribot và Christine ard

Trong thời gian cuối những n m 1990 và đầu những n m 2000, b ng thông

m ng đã lớn hơn rất nhiều, đặc biệt là sự cải tiến ở đường truyền Server/Client – ết nối từ các máy chủ đến các máy hách truy cập đã cho phép công nghệ streaming video có những bước phát triển m nh mẽ

1.2.3 ỹ t u t cơ bả tro g streaming video

1.2.3.1 Một số khái niệm được sử dụng trong streaming video

- Streaming video (luồng video) thực chất là quá trình truyền các frame của tập

tin video đến người nhận

- Demand streaming (stream theo yêu cầu) là quá trình streaming một file

video có sẵn (đã được lưu trên ổ cứng) đến người nhận

- Live streaming (stream từ một nguồn t o video) là quá trình streaming trực

tiếp từ các frame video được t o ra từ các thiết bị thu nhận video (như camera) tới người nhận

- Bitstream là hái niệm ám chỉ một luông video từ máy chủ streaming tới

máy hách nhận các frame video dựa vào giao thức MMS hay RTP

- RTSP (Real Time Streaming Protocol) là giao thức m ng điều hiển quá

trình streaming video

- RTP (Real-time Transport Protocol) là giao thức chuẩn định d ng cho gói tin

(packet) video được truyền trên m ng

1.2.3.2 Các bước thực hiện kỹ thuật streaming video

Hình 1.3 Các bước thực hiện streaming video [8]

Có bốn bước chính trong thuật streaming video:

- ước 1: Phần mềm máy hách (media player, web browser, …) cần ết nối

và xác định file video trên máy streaming server muốn xem

- ước 2: Yêu cầu streaming file video đó sẽ được gửi tới streaming server

- ước 3: Streaming server tìm iếm file video được yêu cầu, sau đó chương trình thực hiện streaming ch y trên máy streaming server sẽ chia file video thành các frame ( hung ảnh), và gửi các frame đó tới máy yêu cầu sử dụng giao thức rằng buộc về thời gian (RTSP, RTP)

- ước 4: Khi các frame về máy hách, sẽ được lưu trữ trong vùng đệm và nội dung các frame sẽ được giải mã (decode) và hiển thị

Để có thể thực hiện được 4 bước trên một cách trơn tru, thì vấn đề đầu tiên cần phải giải quyết là thiết ế các giao thức ở tầng giao vận (transport layer) hay tầng ứng dụng (application) giữa hệ thống máy hách (client) và máy chủ streaming (streaming server) Từ đó sẽ giúp chúng ta xác định được tài nguyên của hệ thống (resource identification system), điều hiển trình diễn (playback control), đồng bộ hóa dữ liệu, xác thực người dùng (authentication), quản l bản quyền số, … Vấn đề

thứ hai cần giải quyết là các vấn đề liên quan đến việc truyền dữ liệu như: lập lịch trình truyền dữ liệu để đảm bảo tính liên tục của thông tin đa phương tiện, truyền dữ liệu với tốc độ bit thay đổi (variable bit-rate media streamings) và làm cho các dòng

dữ liệu thích nghi hi các điều iện của hệ m ng thay đổi

1.2.4 Một số giao t ức sử dụ g tro g streaming video

1.2.4.1 Giao thức TCP/UDP

Trước hi tìm hiểu về các giao thức chuyên biệt cho streaming, chúng ta sẽ xem xét tính hả thi của việc dùng các giao thức internet hiện có cho các ứng dụng streaming Internet đã hỗ trợ giao thức ở tầng giao vận (transport) đó là TCP (Transmission Control Protocol) và UDP (User Datagram Protocol) TCP được sử dụng bởi hầu hết các ứng dụng internet như WWW, FTP, Telnet, … Đây là giao thức hướng ết nối và trong đó bao gồm các thành phần: điều hiển lỗi, điều hiển luồng, tránh tắc nghẽn, Nói cách hác TCP cung cấp 1 lá chắn giúp cho các ứng dụng tránh hỏi các phức t p trong quản l lưu lượng dữ liệu qua m ng internet Điều này làm đơn giản hóa việc phát triển ứng dụng và TCP có các thuộc tính mong muốn – chia sẻ tài nguyên m ng với các luồng c nh tranh lưu lượng m ng theo cách hợp l Vậy một câu hỏi đặt ra là TCP có giúp cho việc streaming video 1 cách thuận tiện hông?

Hình 1.4 Mô hình của giao thức TCP [8]

Câu trả lời phụ thuộc vào b ng thông (banwidth) yêu cầu, đặc tính m ng và chất lượng mong muốn của dịch vụ… Ví dụ nếu b ng thông m ng lớn hơn tốc độ dữ liệu thì streaming qua TCP sẽ ho t động tốt Theo cách đó, hi người dùng yêu cầu nội

dung đa phương tiện dùng giao thức siêu v n bản HTTP thì web server sẽ gửi dữ liệu đa phương tiện đó qua giao thức HTTP 1 cách đơn giản, và các giao thức này

sử dụng giao thức TCP để chuyển dữ liệu Khi web server hông thực hiện streaming dữ liệu đa phương tiện một cách rõ ràng, nó sẽ truyền dữ liệu này với tốc

độ như tốc độ mà m ng cho phép bất chấp tần số dữ liệu thực (data rate) của dữ liệu

đa phương tiện này như thế nào Phía client (máy khách), sau hi đã nhận được chắn chắn 1 lượng dữ liệu về sẽ bắt đầu thực hiện hiển thị (playback) ngay mà hông cần đợi toàn bộ dữ liệu của đối tượng được nhận về đầy đủ Chỉ cần luồng dữ liệu đa phương tiện thỏa mãn tôc độ dữ liệu của quá trình playbac thì ết quả nhận được sẽ giống như streaming

Streaming qua HTTP có nhiều thuận tiện rõ nét Thứ nhất, hi web server được dùng để phục vụ nội dung đa phương tiện, nhà cung cấp hông cần phải đầu tư thêm media server chuyên dụng Thứ hai, việc triển hai đơn giản và lưu lượng

m ng được coi như lưu lượng của dịch vụ web và cho phép nó trở nên trong suốt với fireware và gateway Thứ ba, với sự hộ trợ giao thức HTTP rộng rãi, sẽ giúp nâng cao tính tương thích với các ứng dụng phía client

Tuy nhiên, nhược điểm của việc streaming qua HTTP/TCP chính là hiệu n ng (performance) Ở tầng ứng dụng, web server hông được thiết ế để chuyển các dữ liệu đa phương tiện nh y cảm thời gian và do đó hông phải lúc nào cũng cho phép đảm bảo việc playbac dữ liệu đa phương tiện một cách trơn tru, hông giật hi server phục vụ một lượng lớn người dùng Ở tầng giao vận (transport), giao thức TCP được thiết ế cho các ứng dụng nói chung và do đó hông có sự hỗ trợ đặc biệt nào cho các ứng dụng nh y cảm về mặt thời gian và thông lượng như streaming media

Ví dụ, thuật toán điều hiển tắc nghẽn của TCP sẽ làm giảm tốc độ truyền dữ liệu sau hi thiết lập ết nối (thuật toán slow-start) bất chấp thông lượng mà ứng dụng đòi hỏi Hơn thế nữa, đặc tính điều hiển lỗi của TCP yêu cầu tính đúng đắn và tính tuần tự của dữ liệu Ngh a là nếu 1 đo n dữ liệu bị mất, thì bên gửi sẽ phải gửi l i

đến hi bên nhận thông báo là nhận được đúng đo n dữ liệu đó hoặc là nó sẽ hủy bỏ quá trình truyền và ngắt ết nối Trong ứng dụng streaming đây hông phải là điều luôn mong muốn, vì mỗi dữ liệu đa phương tiện có 1 thông tin định thời và nó phải được playbac ở thời điểm định trước, nếu hông dữ liệu đó sẽ trở nên vô ích Theo

đó, nếu việc truyền l i làm cho dữ liệu được nhận về sau thời điểm deadline dành cho đo n dữ liệu đó thì dữ liệu đó sẽ hông có ích và sẽ được hủy bỏ bởi nơi nhận Trong trường hợp này, thông lượng dành cho việc truyền l i là lãng phí Trong trường hợp xấu nhất, thuật toán điều hiển tắc nghẽn (congestion control algorithms) của giao thức TCP sẽ coi gói tin bị mất như một dấu hiệu của việc nghẽn m ng, theo đó nó sẽ giảm tốc độ truyền bằng cách giảm ích thước cửa sổ nghẽn Nó hiến cho bên gửi sẽ hông gửi thêm được dữ liệu đến hi ích thước cửa sổ nghẽn trở l i bình thường sau hi nhận được đủ số gói tin phản hồi (ack) từ phía bên nhận dữ liệu Điều này sẽ gây ra 1 vấn đề trong hệ thống streaming media

đó là: việc trì hoãn truyền dữ liệu đa phương tiện sẽ hiến cho chúng bị vượt quá thời h n deadline, do đó dữ liệu đó sẽ bị bỏ qua mặc dù chúng thực sự được truyền

đi qua m ng và được client nhận về

Hình 1.5.Ví dụ về trường hợp dữ liệu streaming nhận về sau thời điểm deadline

[8]

Ngược l i, Giao thức UDP (User Datagaram Protocol) hông gặp phải các vấn đề trên của TCP do tính đơn giản của nó UDP hông có bộ điều hiển nghẽn, điều hiển lỗi, điều hiển luồng Do đó bản thân giao thức này hông gây trễ thêm (bỏ qua thời gian xử l và việc trễ gói tin) như các thuật toán điều hiển luồng, điều hiển nghẽn của TCP, do đó nó thích hợp trong việc truyền các dữ liệu đa phương tiện nh y cảm thời gian Tuy nhiên, trong streaming media đôi hi vẫn cần phải thực hiện điều hiển luồng, chống tắc nghẽn, cũng như lấy l i gói tin bị mất Điểm mấu chốt là hi thực hiện các chức n ng này cần phải cân nhắc tính toán sao cho phù hợp với bộ định thời và thông lượng yêu cầu của hệ thống Điều này có thể thực hiện bằng cách xây dựng một layer của giao thức streaming trên cơ sở UDP, ở đó giao thức streaming sẽ thực hiện chức n ng streaming chuyên biệt trong hi dùng UDP được dùng 1 cách đơn giản để truyền dữ liệu và điều hiển luồng

Qua nhiều n m một số giao thức streaming được xây dựng và phát triển bởi các các công ty thương m i và cộng đồng internet Về phía thương m i, các công ty giải pháp streaming thường phát triển các giao thức streaming của riêng họ để sử dụng cho các sản phẩm của mình Ví dụ, Microsoft phát triển dịch vụ Microsoft Media Services (MMS) để dùng trong hệ thống Window Media RealNetwor s cũng phát triển giao thức RealNetwor Data Transport (RDT)

ên c nh đó, cộng động internet cũng phát triển các chuẩn mở dành cho streaming media Các chuẩn này bao gồm: Real Time Streaming Protocol (RTSP) được định ngh a trong chuẩn RFC 2326, Real Time Transport Protocol (RTP) và RTP Control Protocol (RTCP) trở thành chuẩn từ n m 2004

1.2.4.2 Giao thức RTSP (Real Time Streaming Protocol)

RTSP (Real Time Streaming Protocol) là một giao thức điều hiển trên m ng được thiết ế để sử dụng giao tiếp giữa máy client và máy streaming server Giao thức này được sử dụng để thiết lập và điều hiển phiên giao dịch giữa các máy tính (end points)

Về hình thức giao thức RTSP cũng có nét tương đồng với giao thức HTTP, RTSP định ngh a một bộ các tín hiệu điều hiển tuần tự, phục vụ cho việc điều hiển quá trình playbac Trong hi giao thức HTTP là giao thức hông có tr ng thái thì RTSP là giao thức có xác định tr ng thái Một định danh được sử dụng hi cần thiết để theo dõi các phiên giao dịch hiện t i của quá trình streaming video gọi

là số hiệu session Cũng giống như HTTP, RTSP sử dụng TCP là giao thức để duy trì một ết nối đầu cuối tới đầu cuối và các thông điệp điểu hiển của RTSP được gửi bởi máy client tới máy server Nó cũng thực hiện điều hiển l i các đáp trả từ máy server tới máy client Cổng mặc định được sử dụng bởi giao thức này là 554

Để thực hiện thuật streaming video theo giao thức RTSP nhất thiết máy client phải gửi lên máy server (streaming server) những request sau và phải theo một trình

miêu tả chi tiết phiên giao dịch (Session Description Protocol – SDP) Ngoài ra trong thông điệp trả về từ máy server còn liệt ê các đường lin thích hợp hơn tới file video cần phát hi mà trong file video đó có trộn lẫn giữa phụ đề và âm thanh

Và điều quan trọng nhất ở trong bản tin miêu tả phiên giao dịch này là streaming của luồng video và streaming của luồng âm thanh hi mà đo n video đó có lồng âm thanh vào trong các frame

Hình 1.7 DESCRIBE Request

Sau khi máy client nhận được thông điệp đáp trả từ máy server sau yêu cầu DESCRIPTION thì máy client sẽ tiếp tục gửi tiếp yêu cầu SETUP tới máy server Một yêu cầu SETUP sẽ chỉ ra cách mà một dòng dữ liệu (single media stream) bắt buộc phải được truyền đi như thế nào Và yêu cầu SETUP bắt buộc phải được hoàn thành trước hi một yêu cầu PL Y được gửi từ máy client Yêu cầu SETUP bao gồm một đường lin tới file video cần streaming và một thông tin đặc tả cho phần giao vận Đặc tả này bao gồm 2 cổng trong đó có một cổng cục bộ trên máy client dành cho việc nhận cac gói tin RTP (audio và video) và cổng còn l i dùng để nhận các gói tin RTCP (meta information) Máy server sẽ đáp trả l i bằng các xác nhận các tham số đã được lựa chọn, và điền vào các phần còn thiếu ví dụ như máy server

có thể chọn l i cổng của mình Mỗi luồng dữ liệu sẽ được cấu hình cụ thể sau hi yêu cầu SETUP được hoàn tất trước hi máy client gửi yêu cầu PL Y

Hình 1.8 SETUP Request

Sau hi hoàn tất yêu cầu SETUP, cấu hình được các luồng dữ liệu để chuẩn bị streaming, máy client sẽ gửi yêu cầu PL Y để thực hiện truyền các frame dữ liệu thật sự từ máy server tới máy client , và các frame dữ liệu này sẽ được lưu trong một bộ đệm của máy client, các frame này sẽ được giải mã (decode), rồi được hiển thị bởi trình phát file video và âm thanh (VLC) Yêu cầu PL Y bao gồm một đường dẫn trỏ tới file video cần phát giống như các yêu cầu trước đó Đường lin này có thể là đường tổng hợp (để phát các luồng dữ liệu) hoặc là môt đường lin đơn lẻ (chỉ phát một luồng dữ liệu duy nhất) Trong yêu cầu PL Y, máy client cũng

sẽ chỉ ra một dải (range) chỉ rõ một cách cụ thể số hiệu frame bắt đầu được gửi và

số hiệu frame ết thúc, Nếu như hông chỉ rõ tham số này, thì toàn bộ các frame sẽ được gửi tới máy client Và nếu như luồng dữ liệu có bị t m dừng (pause) thì luồng

dữ liệu này cũng sẽ được phục hồi ở frame mà nó t m dừng truyền

Hình 1.9 PLAY Request

Trong quá trình streaming video, nếu như người dùng muốn t m dừng quá trình streaming thì sẽ gửi yêu cầu P USE tới máy server, yêu cầu này sẽ làm t m dừng một hay nhiều luồng dữ liệu đang truyền các frame về máy client Máy server sẽ

t m dừng gửi các frame dữ liệu tới máy client

Hình 1.10 PAUSE Request

Trong quá trình streaming video, nếu như người dùng muốn dừng hẳn quá trình streaming thì sẽ gửi yêu cầu TE RDOWN để dừng truyền và ết thúc một phiên giao dịch của giao thức RTSP Máy server sẽ đáp trả l i thông điệp xác nhận cho yêu cầu TE RDOWN và sẽ dừng gửi các frame tới máy client

Hình 1.11 TEARDOWN Request 1.2.4.3 Giao thức Real-time Transport Protocol (RTP)

RTP (Real-time Transport Protocol) định d ng một gói tin RTP được dùng để truyền trên luồng dữ liệu video hay audio dựa trên địa chỉ IP RTP được sử dụng trong phiên giao dịch giữa các hệ thống giải trí hoặc giao tiếp mà có triển hai thuật streaming video như là telephony, ứng dụng hội họp từ xa, hệ thống giám sát bằng hình ảnh dựa trên IP

RTP được sử dụng ết hợp với giao thức RTCP (RTP Control Protocol) Trong

đó, RTP được sử dụng để đóng gói các frame dữ liệu (audio và video) để truyền trên luồng dữ liệu thì RTCP được sử dụng để giám sát chất lượng của dịch vụ (QoS) hoặc để thống ê theo các tiêu chí trong quá trình truyền tải Thường thì giao thức RTP sử dụng cổng có số hiệu chẵn còn giao thức RTCP sử dụng cổng có số hiệu lẻ

RTP được thiết ế cho quá trình streaming theo thời gian thực từ theo iểu điểm tới điểm Giao thức này cung cấp tiện ích để dò ra những gói tin RTP đã quá h n Trên thực tế, gói tin RTP sử dụng địa chỉ IP trên m ng để định danh các máy tính gửi và nhận RTP cũng hỗ trợ truyền dữ liệu tới nhiều điểm đích thông qua địa chỉ

IP multicast

RTP được phát triển bởi tổ chức udio / Video Transport của tổ chức tiêu chuẩn IETF RTP được sử dụng ết hợp với các giao thức hác như H.323 và giao thức RTSP Chuẩn RTP định ngh a một cặp giao thức làm việc với nhau đó là RTP và RTCP RTP được sử dụng để truyền tải dữ liệu đa phương tiện và giao thức RTCP được sử dụng để gửi các thông tin điều hiển với các tham số QoS

Các giao thức thành phần: Đặc tả RTP gồm 2 giao thức con là RTP và RTCP

Giao thức truyền, RTP, quy định cách thức truyền dữ liệu theo thời gian thực Thông tin được cung cấp bởi giao thức này bao gồm thời gian đồng bộ (timestamps), số thứ tự gói tin (phục vụ cho việc tìm gói tin bi l c) và chi phí cho việc mã hóa định d ng dữ liệu

Giao thức điều hiển, RTCP được sử dụng cho việc iểm tra chất lượng (QoS) luồng dữ liệu và thực hiện đồng bộ giữa các luồng dữ liệu So với RTP, thì b ng thông của RTCP sẽ nhỏ hơn, vào cỡ 5%

Một giao thức cho phép miêu tả dữ liệu đa phương tiện nhưng hông bắt buộc phải èm theo là giao thức miêu tả phiên (Session Description Protocol – SDP)

Phiên (Session): Một phiên RTP được thiết lập cho mỗi luồng dữ liệu Một phiên bao gồm một địa chỉ IP với một cặp cổng của giao thức RTP và RTCP Ví dụ, các luồng video và audio sẽ có các phiên RTP khác nhau, bên nhận sẽ nhận một cách riêng biệt giữa dữ liệu video và audio thông qua 2 cổng hác nhau cho 2 giao thức RTP và RTCP Thường thì số hiệu cổng của RTP là một số chẵn trong hoảng 1024 tới 65535 và cổng của RTCP là một số lẻ ế tiếp

Hình 1.12 là hình ảnh của một header của gói tin RTP

Hình 1.12 Header của RTP Packet

Kích thước nhỏ nhất của một header của gói tin RTP là 12 bytes Sau phần header chính, là phần header mở rộng và hông cần thiết phải có phần header này Chi tiết các trường trong một header như sau:

 Version (2 bits): Cho biết phiên bản của giao thức này Phiên bản hiện t i là phiên bản 2

 P (Padding) (1 bit): Cho biết số các byte mở rộng cần thêm vào cuối của gói tin RTP Ví dụ trong trường hợp ta muốn sử dụng các thuật toán mã hóa, ta

có thể thêm vào một số byte vào phần ết thúc của gói tin để tiến hành mã hóa frame trên đường truyền

 X (Extension) (1bit): Cho biết có thêm phần header mở rộng vào sau phần header chính hay không

 CC (CSRC Count) (4 bit): Chứa con số định danh CSRC cho biết ích thước

cố định của header

 M (Marker) (1 bit): Cho biết mức của ứng dụng và được định ngh a bởi một profile Nếu được thiết lập, có ngh a là dữ liệu hiện t i đã được tính toán chi phí một cách thích hợp

 PT (Payload Type) (7 bit): Cho biết định d ng của file video Đây là một đặc

tả được định ngh a bởi một profile RTP

 Sequence Number (16 bits): số hiệu của frame Và sẽ được t ng lên 1 đơn vị cho mỗi gói tin RTP trước hi gửi và được sử dụng bởi bên nhận để dò ra các gói bị l c và có thể phục hồi l i gói có số thứ tự đó

 Timestamp (32 bits): Được sử dụng thông báo cho bên nhận biết để phát l i frame này trong hoảng thời gian thích hợp

 SSRC (32 bits): Định danh cho nguồn streaming Mỗi nguồn cho phép streaming video sẽ định danh bởi một phiên RTP duy nhất

1.3 t Lu C ươ g 1

Chương 1, tác giả đã trình bày tổng quan về công nghệ nén và streaming video, với mục đích giúp người đọc hiểu được nền tảng các công nghệ được sủ dụng hi phát triển một ứng dụng streaming video

Tiếp theo chương 2, tác giả xin trình bày về các thuật toán nén video phổ biến hiện nay Phân tích các thuật toán nén và lựa chọn thuật toán nén phù hợp nhất cho việc phát triển ứng dụng streaming video trên m ng di động

C Ư NG 2: T UẬT TO N NÉN SỬ DỤNG TRONG STRE M NG V DEO 2.1 Các C uẩ Né Video P ổ Bi

Một câu hỏi đầu tiên đặt ra là t i sao cần phải dùng thuật toán nén?

Chúng ta cùng xem xét phép tính đơn giản sau:

Video có độ phân giải 640x480 pixels với tốc độ hung hình là 25 fps (frame per secon), hi streaming video sẽ yêu cầu dung lượng b ng thông sau:

640 x 480 x 24 x 25 = 184.32 Mbits/sec

Còn với một video full HD (High Definition) mà đang ngày càng phổ biến hiện này thì con số đó sẽ là:

1920 x 1080 x 24 x 60 = 2.98 Gbits/sec

Ngay với một hệ thống máy tính với bộ vi xử l m nh, dung lượng lưu trữ lớn và

b ng thộng rộng, thì với lượng dư liệu đó vẫn gây ra nhu cầu tính toán cực cao cho quản l dữ liệu Nhưng một điều may mắn là, video thuật số chứa há nhiều thành phần dư thừa Vì thế nó phù hợp để nén và có thể làm giảm dung lượng đáng

ể Với thuật nén tốn hao, sẽ cung cấp 1 tỷ lệ nén cao cho dữ liệu video Tuy vậy, trong phát triển ứng dụng luôn luôn có một sự liên quan giữa ích thước dữ liệu và chất lượng Việc mã hóa và giải mã video cần phải tính toán xem xét tài nguyên, để có thể lựa chọn được thuật toán nén phù hợp với ứng dụng của mình ảng dưới đây, là các tiêu chuẩn nén video phổ biến và các ứng dụng được phát triển theo các chuẩn nén đó, èm theo đó là tốc độ luồng bít của các chuẩn nén đó cũng hác nhau:

Bảng 2.1 Một số chuẩn nén video phổ biến và ứng dụng [9]

MPEG-2 Viễn thông, truyền hình quàng bá 2-20 Mb/s

Hội nghị video qua PSTN