Nghiên cứu các cơ chế adaptive bitrate streaming (ABS) và scalable video coding (SVC) phục vụ các ứng dụng streaming trên mạng có băng thông thay đổi

41 Hình 2-10: Phát liên tục dòng dữ liệu: Khoảng thời gian nối tiếp và thời gian tải xuống của video, khoảng thời gian nối tiếp và thời gian tải xuống của các đoạn video trong điều kiện

Hà nội, ngày 30 tháng 12 năm 2013

Học viên

Phạm Trường Giang

LỜI CẢM ƠN

Trước hết, tôi xin bày tỏ lòng biết ơn sâu sắc tới PGS.TS Nguyễn Chấn Hùng, thầy giáo hướng dẫn khoa học của tôi Thầy đã nhiệt tình hướng dẫn, chỉ bảo, đưa ra những hướng

đi, những đóng góp hết sức quý báu để tôi hoàn thành luận văn thạc sĩ này

Tôi xin chân thành cảm ơn các thầy giáo, cô giáo công tác tại Viện Điện tử Viễn thông, Đại học Bách Khoa Hà Nội đã trang bị cho tôi nền tảng kiến thức vững chắc trong thời gian tôi học tập tại đây

Cuối cùng, tôi xin chân thành cảm ơn các anh chị, đồng nghiệp tại Trung tâm Nghiên cứu

và Phát triển Tổng công ty VTC đã tạo điều kiện và giúp đỡ tôi trong quá trình nghiên cứu, thu thập số liệu cũng như tài liệu tham khảo để tôi hoàn thành luận văn

Trân trọng cảm ơn!

Phạm Trường Giang

MỤC LỤC

BẢN CAM ĐOAN 1

LỜI CẢM ƠN 2

MỤC LỤC 3

DANH MỤC KÝ HIỆU VÀ CHỮ VIẾT TẮT 6

DANH MỤC CÁC BẢNG 7

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ 8

MỞ ĐẦU 10

TÓM TẮT LUẬN VĂN 12

ABSTRACT 13

Chương 1: Tổng quan 14

Chương 2: Lý thuyết cơ sở 19

2.1 Đặc tính mạng không dây 19

2.1.1 Băng thông mạng 19

2.1.2 Độ trễ 19

2.1.3 Lỗi mất gói 20

2.1.4 Tắc nghẽn tại hàng đợi 21

2.1.5 Vấn đề thay đổi nút mạng 21

2.1.6 Mất tín hiệu kết nối 22

2.2 Video Streaming 22

2.2.1 Phương thức Video Streaming truyền thống 23

2.2.2 Phương thức Progressive Download Streaming 26

2.2.3 Phương thức Adaptive Bitrate Streaming 27

2.2.4 Các giải pháp sử dụng Adaptive Bitrate Streaming 32

2.2.5 Apple HTTP Live Streaming 32

2.2.6 Microsoft Silverlight Smooth Streaming 36

2.2.7 Adobe HTTP Dynamic Streaming 38

2.2.8 Đánh giá chất lượng các giải pháp Adaptive Bitrate Streaming 40

2.3 Hệ thống Wowza 44

2.3.1 Giới thiệu 44

2.3.2 Hoạt động 45

2.4 VLC 48

2.4.1 Giới thiệu 48

2.4.2 Ưu điểm 49

2.5 Video codec 53

2.5.1 H.263 53

2.5.2 H.264/MPEG-4 AVC 53

2.5.3 Video quality level 54

2.5.4 Container 55

2.6 Wireless Network Emulator 56

2.7 Lựa chọn thông số đo 57

Chương 3: Quá trình đo đạc tính toán 58

3.1 Mục tiêu 58

3.2 Yêu cầu hệ thống 58

3.3 Mô hình đo 58

3.3.1 Server 58

3.3.3 Wireless Network Emulator 60

3.3.4 Hệ thống đo 62

3.3.5 Kịch bản đo 62

Chương 4: Kết quả 64

Chương 5: Tổng kết 69

TÀI LIỆU THAM KHẢO 70

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

1 IPTV Internet Protocol Television

2 ABS Adaptive Bitrate Streaming

3 HTTP Hypertext Transfer Protocol

7 DASH MPEG Dynamic Adaptive Streaming over HTTP

8 RTP Real-time Transport Protocol

10 MSS Microsoft Smooth Streaming

DANH MỤC CÁC BẢNG

Bảng 2-1: Các mẫu video trong file SMIL 47

Bảng 2-2: Các lệnh client gửi đến Streaming Server 48

Bảng 2-3: Khả năng tương thích với các loại định dạng của VLC Media Player 50

Bảng 2-4: Bảng giới thiệu các loại Codec 54

Bảng 2-5: CODEC video và âm thanh được vài định dạng được hỗ trợ 56

Bảng 3-1: Bảng thông số của các kịch bản đo 63

Bảng 4-1: Kết quả đo độ trễ video đối với HTTP Ở đây đơn vị đo độ trễ là s 64

Bảng 4-2: Kết quả đo độ trễ video đối với RTP Ở đây đơn vị đo độ trễ là s 66

DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ

Hình 1-1: Biểu đồ phân phối lưu lượng dữ liệu mạng theo loại hình dịch vụ 15

Hình 1-2: Sự tăng trưởng của lưu lượng dữ liệu đối với các loại hình dịch vụ mạng 15

Hình 1-3: Mức tăng trưởng của thiết bị di động trong những năm gần đây 16

Hình 1-4: Một hệ thống Adaptive Bitrate Streaming đơn giản 17

Hình 2-1: RTSP client and server communication sequence 24

Hình 2-2: RTP packet format 25

Hình 2-3: HTTP Session 25

Hình 2-4: Sơ đồ khối hệ thống Adaptive Bitrate Streaming 28

Hình 2-5: Đồ thị Apdative Bitrate Streaming 29

Hình 2-6: Streaming cho nhiều Client với nhiều độ phân giải 31

Hình 2-7: Một tập tin danh sách thay đổi HLS minh họa 8 profile đầu ra với tốc độ bit khác nhau 34

Hình 2-8: Một tập tin danh sách HLS từ một dòng trực tuyến mô tả ba đoạn TS hiện có gần nhất 34

Hình 2-9: Phát liên tục dòng dữ liệu theo thông lượng phân mảnh, thông lượng TCP trung bình và tốc độ bit yêu cầu cho phát video dưới các điều kiện băng thông không hạn chế Việc phát lại bắt đầu ở khoảng t = 5s, sau khi người dùng ấn Play khoảng 2s 41

Hình 2-10: Phát liên tục dòng dữ liệu: Khoảng thời gian nối tiếp và thời gian tải xuống của video, khoảng thời gian nối tiếp và thời gian tải xuống của các đoạn video trong điều kiện băng thông không hạn chế Mỗi đoạn dài 2 giây 42

Hình 2-11: Thông lượng theo từng đoạn, thông lượng TCP trung bình và tốc độ bit yêu cầu cho việc truyền video trong điều kiện băng thông thay đổi liên tục Việc phát lại bắt đầu ở khoảng t = 10s, sau khi người dùng ấn Play khoảng 3s 43

Hình 2-12: Khả năng tích hợp DRM của hệ thống Wowza Media 45

Hình 2-13: Biểu đồ trình tự thời gian các bản tin HTTP 46

Hình 2-15: Giao diện VLC Media Player 49

Hình 2-16: Mô hình đơn giản của DummyNet 57

Hình 3-1: So sánh giữa các phương thức đo 62

Hình 4-1: Đồ thị phân bố độ trễ đối với HTTP 65

Hình 4-2: Đồ thị phân bố độ trễ đối với RTP 67

Hình 4-3: So sánh kết quả của 2 hệ thống Ở đây Series 1 là RTP, Series 2 là HTTP 67

MỞ ĐẦU

1 Giới thiệu đề tài

Video Streaming là một trong những công nghệ được sử dụng phổ biến hiện nay Kết hợp với sự phát triển không ngừng của các thiết bị di động, công nghệ này cung cấp cho người xem những trải nghiệm tuyệt vời mọi lúc mọi nơi Tuy nhiên, do nhu cầu xem video tăng quá nhanh, hạ tầng mạng không dây không đáp ứng đủ băng thông cho Video Streaming Điều đó dẫn đến những vấn đề về chất lượng video như trễ hình, mất khung,

vỡ hình đối với những mạng không dây như 3G

Bên cạnh việc không ngừng đầu tư nâng cao chất lượng mạng, các công nghệ Video Streaming mới liên tục được nghiên cứu và triển khai nhằm tối ưu hóa hệ thống sẵn có

Đề tài “Nghiên cứu các cơ chế Adaptive Bitrate Streaming (ABS) và Scalable Video Coding (SVC) phục vụ các ứng dụng Streaming trên mạng có băng thông thay đổi”

được hình thành trong điều kiện như vậy

2 Mục đích nghiên cứu

Mục tiêu của đề tài nghiên cứu là tìm hiểu và đánh giá chất lượng các công nghệ Video Streaming như ABS và SVC Từ những đánh giá đó, nghiên cứu đưa ra tập thông số tối

ưu dành cho hệ thống Video Streaming

3 Kết cấu luận văn

Luận văn được trình bày theo 5 chương:

Chương 1: Tổng quan - Đưa ra cái nhìn tổng quan về các điều kiện hiện tại ảnh hưởng

đến hướng nghiên cứu của đề tài

Chương 2: Cơ sở lý thuyết - Trình bày các khái niệm lý thuyết về ABS và SVC

Chương 3: Mô hình đo đạc hệ thống ABS - Trình bày về một testbed để đo chất lượng

hệ thống ABS

Chương 4: Kết quả - Trình bày kết quả đo và những nhận xét đánh giá

Chương 5: Tổng kết - Đưa ra những kết luận đánh giá và các ứng dụng thực tiễn của hệ

thống này Đồng thời cũng đề xuất những hướng nghiên cứu trong tương lai

TÓM TẮT LUẬN VĂN

Theo “2012 Sourcebook article on the state of mobile video” của tác giả James Careless, hơn một nửa lượng dữ liệu trên các thiết bị di động là nội dung video Một báo cáo khác trong năm 2012 của Chris Osika làm việc cho Cisco chỉ ra rằng, người dùng đang thay đổi hoàn toàn thói quen xem truyền hình bằng việc dành gấp 3 lần thời gian xem video trực tuyến so với video truyền thống Công nghệ Video Streaming ngày càng trở nên quan trọng đối với nhu cầu giải trí của người xem

Tại Việt Nam, số liệu thực tế cho thấy trong năm 2012, sự gia tăng số lượng thuê bao 3G đạt đến 25%, một con số gây ngạc nhiên trong điều kiện kinh tế khó khăn Tuy nhiên, việc đầu tư hạ tầng rất tốn kém, nên chất lượng Video Streaming trên mạng 3G còn khá thấp Đối với các phương thức Video Streaming truyền thống, các vấn đề như giật hình,

vỡ hình, rớt gói xuất hiện thường xuyên Một giải pháp nâng cao chất lượng dịch vụ là áp dụng những công nghệ mới như Adaptive Video Streaming và Scalable Video Coding Những nghiên cứu đánh giá gần đây cho thấy hệ thống ABS tăng đáng kể chất lượng của video so với Video Streaming truyền thống Những điều kiện trên chính là động lực để thực hiện đề tài nghiên cứu về ABS và SVC

Đề tài nghiên cứu này tập trung giải quyết một số vấn đề sau: 1) Tìm hiểu về các công nghệ ABS và SVC, cùng với những ứng dụng thực tế của các công nghệ này Bên cạnh những khả năng mà các công nghệ này đem lại, đề tài cũng tìm ra những vấn đề còn tồn tại của các hệ thống 2) Thiết lập một hệ thống mô phỏng của hệ thống và đưa ra những phương thức đo đạc đánh giá chất lượng 3) Giải quyết một số vấn đề của các công nghệ này bằng cách đưa ra tập tham số cấu hình hệ thống nhằm nâng cao chất lượng dịch vụ

ABSTRACT

According to “2012 Sourcebook article on the state of mobile video” of James Careless, more than half of data consumption on mobile devices is video content Another report of Chris Osika in 2012 shows that subscribers are completely changing their habit of entertainment by spending time watching online videos three times more than watching traditional videos Video Streaming is playing an important part in human life

In Vietnam, the statistic shows that in 2012 the improvement of 3G subscribers is about

25 percent, making sense in the bad condition of economy However, as the invesment of the infrastructure is very expensive, the wireless network is not met the requirement of Video Streaming.With basic Streaming methods, the performance of video is poor because of the frequency of latency, freezing, or packet loss One solution for this problem is using the new technology of Streaming such as ABS and SVC The recent researches show that the ABS system significantly improve the quality of video comparing to normal Video Streaming That is the motivation for implemanting this thesis

This thesis focuses on solving the following problems: 1) Studying about ABS and SVC technology, and the applying of them Besides, this thesis also finds the issues of these systems 2) Setting up a new testbed to measure the ABS system 3) Solving issues of them by finding a set of parameters that are optimal for the systems

Chương 1: Tổng quan

Streaming là một trong những sản phẩm công nghệ ngày càng được sử dụng rộng rãi thời gian gần đây Dịch vụ này cung cấp cho người xem những nội dung số, nổi bật là Video, được truyền liên tục từ server đến đầu cuối

Do nhu cầu của người xem ngày càng cao, chất lượng video cũng ngày càng tăng lên, trong khi chất lượng đường truyền, tuy có tăng, không kịp đáp ứng, nên các phương thức Streaming liên tục được nghiên cứu và ứng dụng nhằm tối ưu hóa khả năng truyền Adaptive Streaming là một trong số những phương thức như vậy

Theo báo cáo của Allot Mobile năm 2011, dữ liệu truyền đến di dộng ngày càng tăng cao trong những năm gần đây, đặc biệt là dành cho Streaming Dưới đây là một số thống kê

Hình 1-1: Biểu đồ phân phối lưu lượng dữ liệu mạng theo loại hình dịch vụ

Hình 1-2: Sự tăng trưởng của lưu lượng dữ liệu đối với các loại hình dịch vụ mạng

Phần này giới thiệu chung về xu hướng và điều kiện hiện nay đối với công nghệ chung, cũng như mảng công nghệ đồ án này hướng đến Góc nhìn chung nhất đó sẽ dẫn đến mục tiêu, định hướng và giải pháp cho đề tài đặt ra

Với sự tăng trưởng không ngừng của di động, dịch vụ Video Streaming trên nền di động ngày càng trở nên thiết yếu Tuy nhiên, do những vấn đề về công nghệ không theo kịp với nhu cầu của người dùng, dịch vụ này phải đối mặt với những vấn đề lớn:

 Thứ nhất, di động được thiết kế và sản xuất bởi rất nhiều nhà sản xuất khác nhau, với cấu hình và hệ điều hành phong phú và hoàn toàn khác biệt nhau

 Thứ hai, mạng dữ liệu dành cho di động có những đặc tính không ổn định, băng thông còn khá thấp cùng những vấn đề về không dây khác đang cản trở chất lượng xem Video của người dùng

Một trong những hướng giải quyết các vấn đề trên, đặc biệt là vấn đề về băng thông mạng di động, đã được nghiên cứu và triển khai là Adaptive Bitrate Streaming

Hình 1-3: Mức tăng trưởng của thiết bị di động trong những năm gần đây

vào băng thông của mỗi đầu cuối, sẽ có một luồng bitrate phù hợp nhất Các luồng Stream này được phân nhỏ thành các segment để gửi đến các đầu cuối Khi băng thông có thay đổi, đầu cuối yêu cầu thay đổi luồng Stream và hệ thống sẽ nhanh chóng gửi lại một luồng khác phù hợp với băng thông mới hơn

Hình 1-4: Một hệ thống Adaptive Bitrate Streaming đơn giản

Do những vấn đề của mạng không dây như wifi hay 3G ảnh hưởng rất nhiều đến chất lượng Video Streaming, nên có rất nhiều giải pháp được nghiên cứu và ứng dụng của Adaptive Bitrate Streaming dành cho những mạng này Một trong những hệ thống như vậy có tên là Archies dành cho Adaptive live MPEG-4 Video Streaming trên mạng không dây Qua mạng wifi 802.11b, những thông số đánh giá chất lượng video bao gồm Frame Rate, Packet Loss được so sánh giữa Adaptive Bitrate Streaming và Video Streaming truyền thống Kết quả cho thấy hệ thống dùng Adaptive Bitrate Streaming có chất lượng tăng lên đáng kể khi xem video MPEG-4 thời gian thực

Một ví dụ khác của việc nghiên cứu các hệ thống Adaptive Streaming này là test-bed sử dụng chuẩn nén H264/AVC cho hình ảnh và MPEG-4 AAC cho audio dành cho hệ thống trên mạng 3GPP Bằng cách chọn lựa luồng Stream có tốc độ thấp hơn băng thông, hệ thống dùng Adaptive Streaming có chất lượng tăng rõ rệt trong điều kiện không ổn định của mạng 3GPP

Một hệ thống khác có tên là MARC được phá triển bởi nhóm của Koo Hệ thống này có điểm khác biệt là điều chỉnh linh động băng thông truyền dựa trên tình trạng mạng và cả buffer của phía đầu cuối Kết quả đánh giá cho thấy hệ thống này không chỉ tăng giá trị QoE, độ ổn định và sự chấp nhận được về chất lượng trên mạng không dây, mà còn giảm bớt sự đứt quãng của quá trình xem video

Chương 2: Lý thuyết cơ sở

2.1 Đặc tính mạng không dây

Phần này sẽ trình bày tóm tắt các thuộc tính của kết nối không dây, vốn vẫn tồn tại những thách thức trong việc truyền dữ liệu một cách hiệu quả Các kết nối không dây thường có băng thông tương đối thấp, độ trễ và tỷ lệ lỗi cao Từ đó, có thể đưa ra một số nhận xét xem các thuộc tính này liên quan đến các yêu cầu cho người giả lập mạng như thế nào

2.1.1 Băng thông mạng

Tốc độ đường truyền của kết nối WAN không dây không thường vượt quá vài chục kilobit trên giây Những đường truyền tốc độ như vậy chủ yếu dành cho người dùng modem quay số Với một số kết nối không dây, tốc độ đường truyền có thể thay đổi theo thời gian, do sự thay đổi số lượng nguồn sóng dành cho người dùng hoặc sự thay đổi hệ thống mã hóa kênh Tốc độ đường truyền có thể bất đối xứng, như khi sử dụng một vài loại kết nối vệ tinh hoặc GPRS Như vậy, thiết bị giả lập cần tạo ra tốc độ đường truyền mong muốn bằng cách làm trễ các gói dữ liệu và tạo ra các cách để giả lập sự thay đổi trong tốc độ đường truyền, độc lập trên cả 2 hướng Đối với phần lớn các đường truyền WAN không dây, tốc độ lên tới 100 kbps là đủ Tuy nhiên việc mô hình hóa các mạng không dây băng thông rộng trong tương lai sẽ yêu cầu tốc độ đường truyền tối thiểu là 2 Mbps

2.1.2 Độ trễ

Sự trễ khi lan truyền của các kết nối không dây thường cao Trễ thường xuất phát từ các

hệ thống truyền đặc biệt trong kết nối không dây và từ việc xử lý trễ của các thành phần

phần cứng trong kết nối Ví dụ, Hệ thống thông tin di động toàn cầu (GSM) sử dụng kỹ thuật chèn dữ liệu vào kết nối sóng vô tuyến để giảm ảnh hưởng của khối lỗi và việc này tạo ra một khoảng trễ 90 ms độc lâp với kích thước gói tin Độ trễ còn bị tăng thêm khi sử dụng dịch vụ dữ liệu GSM còn do kết nối với nhà cung cấp dịch vụ Internet (ISP) và thời gian xử lý trong hệ thống GSM Tổng độ trễ một chiều lên tới 200 - 300 ms Thiết bị giả lập cần chuẩn hóa một cách chính xác độ trễ này bằng cách thêm vào một khoảng trễ lan truyền cho mỗi gói tin Độ trễ thay đổi có thể xuất hiện trên kết nối không dây do rất nhiều lý do, ví dụ như khôi phục ARQ ở lớp liên kết, nguồn sóng vô tuyến (phân bổ và chuyển vùng chỉ là một vài Đó có thể là một khả năng để tăng độ trễ ngẫu nhiên cho dòng gói tin)

2.1.3 Lỗi mất gói

Một số kết nối không dây buộc phải thay đổi một lượng dữ liệu đáng kể do lỗi khi truyền

Tỷ lệ lỗi phụ thuộc vào điều kiện sóng vô tuyến hiện tại và độ mạnh của hệ thống mã hóa kênh Ví dụ, ở dịch vụ dữ liệu GSM trong suốt, tỷ lệ lỗi bit (BER) chấp nhận được của kết nối có thể cao hơn Phương pháp sửa lỗi chuyển tiếp (FEC) Các điều kiện sóng vô tuyến có thể thay đổi đáng kể Trong điều kiện lý tưởng, mọi đơn vị dữ liệu giao thức được truyền một cách chính xác, và trong trường hợp xấu nhất không một đơn vị nào có thể truyền chính xác qua kết nối Để thuận tiện hơn và tăng độ chính xác của các quá trình giả lập, thiết bị giả lập có thể làm rớt gói trên cơ sở từng gói tin hoặc sử dụng xác suất lỗi Lỗi khi truyền qua kết nối có thể thấy ở các lớp trên như trễ khi truyền dữ liệu (lớp liên kết tin cậy), mất PDU (phát hiện lỗi ở lớp liên kết) hoặc gói dữ liệu bị thay đổi (lớp liên kết trong suốt) Thiết bị giả lậpcần đưa ra cả 3 trường hợp

2.1.4 Tắc nghẽn tại hàng đợi

Kết nối không dây thường là cổ chai trên đường truyền dòng dữ liệu, do các mạng cố định nhanh và tin cậy hơn nhiều so với khả năng của kết nối không dây Các thiết bị định tuyến đóng một vai trò đáng kể vì mất gói dữ liệu do tắc nghẽn thường xảy ra tại hàng đợi nút cổ chai Số lượng giới hạn bộ đệm có thể được phân bổ trong thiết bị định tuyến tại điểm cuối cùng theo người sử dụng Thiết bị giả lập cần chứa một hàng đợi tại kết nối

cổ chai được giả lập và tạo ra các phương pháp để giới hạn kích thước của hàng theo byte

và số lượng gói tin Ngoài ra có thể sử dụng một bộ đếm để giới hạn thời gian một gói tin nằm trong bộ đệm Các thuật toán quản lý hàng đợi và chính sách về gói nên được đưa vào

2.1.5 Vấn đề thay đổi nút mạng

Trong một mạng di động tế bào, tính di dộng được hiện thực hóa bằng cách thay đổi các điểm truy cập mà người dùng kết nối vào, theo vị trí hiện tại của người dùng Tiến trình chuyển giao có thể gây ra mất gói dữ liệu và gây ra sự thay đổi lớn về dịch vụ được cung cấp, khi người dùng di chuyển từ một vùng dịch vụ ít bận sang một vùng đông người dùng hơn Việc chuẩn hóa sự chuyển giao có thể gây ra sự thay đổi cùng lúc về số lượng các tham số mô phỏng Ví dụ, trong một mạng tín hiệu vô tuyến, vùng dịch vụ mới có thể

có nhiều người dùng sử dụng cùng một trạm hơn là khu vực trước đó; người dùng sẽ thấy điều này do băng thông có sẵn thấp hơn sau khi chuyển vùng Thêm vào đó, bản thân tiến trình chuyển giao có thể gây ra trễ hoặc mất gói khi truyền dữ liệu Thiết bị giả lập cần có khả năng cho phép thay đổi một tập hợp các tham số tại cùng một thời điểm để giả lập sự thay đổi dịch vụ mạng

2.1.6 Mất tín hiệu kết nối

Các kết nối không dây dễ bị gián đoạn dịch vụ tạm thời Một ví dụ điển hình là mất vùng phủ sóng; điều này có thể xảy ra do lái xe trong đường hầm hoặc di chuyển ra xa điểm truy cập đang phục vụ Mất tín hiệu có gây ra tình huống như trong một khoảng thời gian, không có dữ liệu người dùng nào được truyền đi thành công qua kết nối Nếu việc hỗ trợ QoS được thực hiện trong mạng không dây, lưu lượng các gói tin có độ ưu tiên cao hơn cũng có thể gây ra tắc nghẽn với các gói tin có độ ưu tiên thấp hơn Thiết bị giả lập cần tạo ra các phương pháp để xác định khoảng thời gian mất kết nối và xử lý các PDU trong thời gian đó, như loại bỏ hoặc lưu các PDU trong khoảng thời gian mất kết nối

2.2 Video Streaming

Streaming là một phương thức truyền dữ liệu trên Internet Công nghệ streaming cho phép các multimedia server truyền đi qua mạng Internet (IP) các dòng dữ liệu liên tiếp có thể giải nén và hiển thị ngay lập tức khi tới phía người dùng Để download về một đoạn phim ngắn cũng có thể mất tới vài phút trong khi các dữ liệu video sử dụng công nghệ streaming chỉ mất vài giây để có thể hiển thị Tính năng này khiến các công nghệ streaming tiết kiệm được thời gian cho người sử dụng

Với các định dạng file video truyên thống, dữ liệu chỉ có thể hiển thị khi đã được download toàn bộ, vì vậy đối với các file 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 kiệ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 kết hợp với player hiển thị dữ liệu đồng thời trong lúc vẫn tiếp tục download 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ỏ

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 Có thể hoàn toàn hy vọng chất lượng của video streaming đạt được mức chất lượng TV truyền thống, thậm chí bằng cả chất lượng DVD

Video Stream sử dụng các giao thức RTP, MMS hay HTTP 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 khả năng nén dữ liệu tại nhiều mức nén, nhiều kí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 để tối ưu hoá việc truyền

dữ liệu qua mạng Cũng chính vì vậy việ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 Video Streaming Server

2.2.1 Phương thức Video Streaming truyền thống

RTSP (Giao thức dòng thời gian thực) là một ví dụ của giao thức dòng truyền thống Người ta định nghĩa RTSP là giao thức có trạng thái (stateful protocol), nghĩa là máy chủ luôn lưu giữ thông tin và trạng thái của máy khách từ khi máy khách kết nối đến máy chủ lần đầu tiên đến khi ngắt kết nối Máy khách trao đổi tình trạng của nó với máy chủ bằng cách khởi tạo các lệnh như PLAY, PAUSE hoặc TEARDOWN (bắt buộc phải có 2 lệnh đầu tiên, lệnh cuối cùng được dùng để ngắt kết nối từ máy chủ và đóng phiên trao đổi dòng dữ liệu)

Hình 2-1: RTSP client and server communication sequence

Sau khi 1 phiên trao đổi thông tin giữa máy khách và máy chủ được thiết lập, máy chủ bắt đầu truyền dữ liệu và một dòng ổn định các gói tin nhỏ (các gói tin này được truyền dưới dạng RTP) Kích thước chuẩn của gói tin RTP là 1452 bytes, nghĩa là nếu dòng video được mã hóa với tốc độ 1 Megabit 1 giây (Mbps) thì mỗi gói tin truyền đi 11 mili giây video Trong RTSP gói tin có thể được truyền qua cả 2 giao thức UDP hoặc TCP TCP thường được chọn khi tường lửa hoặc proxy chặn các gói tin UDP nhưng có thể làm tăng độ trễ (gói tin TCP sẽ được truyền lại đến khi bên kia nhận được)

Hình 2-2: RTP packet format

Ngược lại, HTTP là giao thức phi trạng thái Nếu một máy khách HTTP yêu cầu dữ liệu, máy chủ sẽ trả lời bằng cách gửi lại dữ liệu, nhưng nó sẽ không ghi nhớ máy khách hoặc thông tin của máy khách Mỗi yêu cầu HTTP được xử lý hoàn toàn trong một phiên độc lập

Hình 2-3: HTTP Session

Các dịch vụ của Windows Media (Windows Media Services) hỗ trợ truyền dữ liệu theo dòng qua cả RTSP và HTTP Nhưng HTTP là giao thức phi trạng thái, vậy nó sẽ được sử dụng để truyền dòng dữ liệu như thế nào? Các dịch vụ của Windows Media sử dụng một phiên bản sửa đổi của HTTP, có tên là MS-WMSP (còn được gọi là Windows Media HTTP Streaming Protocol trong các giao thức của Windows media, hoặc được gọi tắt là Windows Media HTTP) MS-WMSP sử dụng giao thức HTTP chuẩn để truyền dữ liệu và thông điệp nhưng cũng dùng để duy trì trạng thái của phiên, chuyển dữ liệu thành dòng một cách hiệu quả như giao thức RTSP Các dịch vụ của Windows media cũng hỗ trợ dòng dữ liệu RTSP từ năm 2003 (trong Windows Media Services) trên cả UDP và TCP

Và giao thức được đưa vào thực tế dưới cái tên MS-RTSP Silverlight chỉ hỗ trợ truyền

dữ liệu dựa trên HTTP từ Windows Media Services Những điều quan trọng nhất cần nhớ

về các giao thức truyền dòng dữ liệu truyền thống như RTSP và Windows Media HTTP (MS-WMSP) là:

Các ví dụ khác của giao thức truyền dòng dữ liệu truyền thống có thể kể đến Giao thức RTMP (Real Time Message Protocol) của Adobe và RTSP trên giao thức RDT (Real Data Transport) của RealNetworks Tính năng chuyển dòng (Dynamic Streaming stream

- switching) trong nền tảng Adobe® Flash® dựa trên giao thức RTMP và do đó, được coi như một phương pháp truyền dòng dữ liệu truyền thống - truyền dòng dữ liệu không tự điều chỉnh

2.2.2 Phương thức Progressive Download Streaming

Một dạng truyền dữ liệu phổ biến nữa trên nền Web hiện nay là tải xuống liên tục Có thể hiểu một cách đơn giản như là tải xuống 1 tập tin đơn giản từ máy chủ Web HTTP Tải

nhạc, như Adobe Flash, Silverlight và Windows Media Player Cụm từ “liên tục” bắt nguồn từ thực tế là hầu hết các máy trạm dùng để xem phim đều cho phép các tập tin có thể được phát lại khi việc tải xuống vẫn đang tiếp diễn - trước khi toàn bộ tập tin được ghi lên đĩa (chủ yếu là lên bộ đệm của trình duyệt Web) Những máy khách hỗ trợ tiêu chuẩn kỹ thuật HTTP 1.1 cũng có thể di chuyển đến các vị trí chưa được tải xuống trong tập tin bằng cách thực hiện các yêu cầu truy xuất khoảng byte đến máy chủ Web (giả định rằng nó cũng hỗ trợ HTTP 1.1)

Các trang web chia sẻ video phổ biến hiện nay như YouTube, Vimeo, MySpace, và MSN Soapbox, hầu như chỉ sử dụng phương pháp tải xuống liên tục Không như các máy chủ truyền dòng dữ liệu truyền thống, hiếm khi gửi hơn 10 giây dữ liệu âm thanh / hình ảnh đến máy khách tại một thời điểm, các máy chủ HTTP Web liên tục truyền dữ liệu đến khi việc tải xuống kết thúc Khi tạm dừng, video đang được tải xuống liên tục vẫn sẽ được tải hết xuống bộ đệm của trình duyệt, cho phép xem toàn bộ video một cách trôi chảy mà không có một sự gián đoạn nào Phương pháp này cũng có nhược điểm là nếu người dùng

đã tải xuống được 30 giây của một đoạn video 10 phút mà họ lại quyết định không xem nữa, thì cả người dùng và nhà cung cấp nội dung đều lãng phí băng thông cho 9 phút 30 giây còn lại Để giảm thiểu vấn đề này, IIS 7.0 đã đưa ra một phần mở rộng gọi là Bit Rate Throttling, cho phép nhà cung cấp nội dung điều chỉnh tốc độ tải xuống theo đúng cách máy chủ truyền dữ liệu dòng sẽ làm để giảm chi phí

2.2.3 Phương thức Adaptive Bitrate Streaming

 Giới thiệu về Adaptive Streaming

Công nghệ streaming tốc độ bit thích ứng (adaptive bitrate streaming) được sử dụng thông qua các mạng máy tính Nếu như trước đây các công nghệ streaming được thực hiện dựa trên các giao thức RTP như RTSP thì hiện nay công nghệ adaptive streaming

được thực hiện trên giao thức HTTP và được thiết kế để hoạt động hiệu quả trên các mạng HTTP phân tán cỡ lớn như Internet

Adaptive streaming hoạt động bằng cách phát hiện băng thông và hiệu năng CPU của người dùng theo thời gian thực và từ đó điều chỉnh chất lượng luồng video phù hợp tương ứng Công nghệ này yêu cầu sử dụng một bộ encoder có thể encode nhiều bitrate khác nhau từ một video nguồn duy nhất Player người dùng sẽ lựa chọn giữa các video bitrate khác nhau phụ thuộc vào tài nguyên khả dung Kết quả là có rất ít buffer, thời gian bắt đầu nhanh và trải nghiệm tốt với cả các kết nối tốc độ cao và tốc độ thấp

Điều đặc biệt và được triển khai hiện nay là Adaptive Bitrate streaming là một phương thức streaming thông qua giao thức HTTP, nội dung nguồn được encode với nhiều bitrate, sau đó mỗi luồng bitrate khác nhau lại được chia nhỏ thành nhiều phần thời gian vài giây Streaming Client nhận biết các luồng với các bitrate khác nhau và các phần được chia nhỏ dựa vào các file manifest Khi bắt đầu, client yêu cầu các segment từ luồng

có bitrate thấp nhất Nếu client phát hiện ra tốc độ download lớn hơn so với bitrate của segment đã được download thì nó sẽ gửi yêu cầu các segment có bitrate cao hơn kế tiếp Nếu client phát hiện tốc độ download segment thấp hơn bitrate của segment, khiến lưu lượng mạng suy giảm, thì nó lại yêu cẩu segment có bitrate thấp hơn Kích thước segment

có thể thay đổi phục thuộc vào các ứng dụng khác nhau, nhưng thông thường trong khoảng 2 đến 10 giây

Hình 2-4: Sơ đồ khối hệ thống Adaptive Bitrate Streaming

Hình 2-5: Đồ thị Apdative Bitrate Streaming

 Các yêu cầu đảm bảo giao cắt và kết nối mạng

Khi kết nối trong một mạng chưa được quản lý, các thiết bị định tuyến (router), tường lửa (firewall) và các cổng được mở có thể chưa được xác định Trong một mạng, có thể có các tường lửa cá nhân, các thiết bị định tuyến, các phần mềm bảo mật hoạt động Trong một mạng Wifi, các cổng truy nhập có thể bị giới hạn vì lý do bảo mật Điều này là một trở ngại rất lớn với các ứng dụng mạng và nó được khắc phục bằng cách sử dụng giao thức HTTP trong truyền thông HTTP sử dụng cổng 80 cho các yêu cầu Các yêu cầu đến cổng này hầu hết được cho phép qua bất kỳ tường lửa hoặc router, và nó được dùng cho tất cả các web HTTP sử dụng một kết nối TCP đầy đủ trạng thái, do đó bất kỳ vấn đề phát sinh bởi các mạng dựa trên NAT cũng được khắc phục

 Yêu cầu quản lý băng thông

Tính nhất quán của băng thông là một vấn đề lớn Nếu một người dùng đang xem một video và một người khác trên cùng mạng đột ngột chuyển file, băng thông khả dung cho các video có thể bị ảnh hưởng nghiêm trọng Để duy trì một chất lượng trải nghiệm tốt, nội dung do đó cần được encode ở bitrate khác và giao thức truyền phải có khả năng tự động chuyển đổi bitrate mà không có sự gián đoạn trong việc phát lại hoặc thao tác của người dùng

Giao thức HTTP là một giao thức đồng bộ client đến server nên chỉ cần một yêu cầu duy nhất được thực hiện cho một video Việc chuyển đổi bitrate do đó không thể thực hiện giữa một giao dịch HTTP Để giải quyết vấn đề này, các video phải được cắt nhỏ thành các “chunk” Mỗi chunk thường từ hai đến mười giây Kích thước chunk được tham chiếu từ khung I (I Frame) ở đầu mỗi chunk được đồng bộ

Server có thể lưu trữ một vài bitrate khác nhau được encode từ cùng một video Mỗi bitrate mã hóa một danh sách chạy riêng biệt, được định nghĩa bằng một playlist tổng thể Các playlist này thông thường có dạng m3u8 và chứa một danh sách các chunk theo thứ

tự Khi một client phát hiện hoặc băng thông không đủ hoặc băng thông khả dụng nhiều hơn, nó có thể chuyển sang một trong hai playlist có bitrate thấp hoặc cao hơn và download các chunks trong danh sách đó Do mỗi chunk được đồng bộ với các dòng bitrate khác, nên có một quá trình chuyển đồi liền mạch giữa chúng để play video không

bị gián đoạn Điều này đã duy trì chất lượng trải nghiệm cao

 Nhiều độ phân giải màn hình và client

Khi xuất hiện ngày càng nhiều các thiết bị kết nối Internet với khả năng duyệt và play video ngày càng lớn, độ phân giải và bitrate cần thiết để hỗ trợ các thiết bị này tăng theo cấp số nhân Trong quá khứ, nhiều thiết bị đã giao tiếp thông qua một giao thức độc quyền Điều này không khả thi để có các bộ mã hóa riêng biệt, do đó hệ thống DRM và server cho mỗi thiết bị cần được hỗ trợ

HTTP Adaptive streaming có khả năng cung cấp nhiều độ phân giải và bitrate trên một giao thức chung, mở Điều này cho phép củng cố cơ sở hạ tầng server, bộ mã hóa cho một hệ thống quản lý duy nhất Một thiết bị mới có thể được thêm vào một cách đơn giản thông qua một profile mã hóa mới

Hình 2-6: Streaming cho nhiều Client với nhiều độ phân giải

 Bảo mật nội dung

Phương pháp phát quảng bá thông thường hạn chế truy nhập nội dung live được thực hiện bằng việc mã hóa các dòng truyền đi Phương pháp này đã được áp dụng thành công để truyền trực tiếp video qua mạng Internet: nội dung được mã hóa giữa bộ mã hóa và server một lần nữa giữa server và client

Tuy nhiên, nguy cơ của phương pháp này là nội dung được ghi tạm thời vào bộ nhớ cache trong server trước khi truyền lại ngay lập tức và một lần nữa lại được ghi vào bộ nhớ cache của client trước khi phát và xóa Trong những khoảng thời gian ngắn, nội dung tồn tại rõ rang, và điều này tiềm ẩn nguy cơ về bảo mật Ngoài ra, với các dịch vụ truyền hình Catchup, VOD, nội dung sẽ được lưu trên các server trong mạng hoặc các thiết bị client và phải được bảo mật để tránh vi phạm bản quyền HTTP Adaptive streaming cho phép mã hóa các chunk riêng biệt cho cả live streaming và VOD/Catchup Nội dung được

mã hóa trong hoặc ngay sau khi encode và được duy trì như thế trong quá trình truyền qua mạng cũng như khi lưu trữ trên các server hoặc thiết bị client

2.2.4 Các giải pháp sử dụng Adaptive Bitrate Streaming

Hiện cũng có nhiều công nghệ truyền dòng dữ liệu có khả năng thích nghi khác

Move từng là công cụ để phổ biến phương pháp truyền dòng dữ liệu có khả năng thích nghi trên giao thức HTTP và có nhiều bằng sáng chế về công nghệ này (dù truyền dòng

dữ liệu được phân đoạn đã được sử dụng trước khi Move phổ biến nó)

Truyền dòng dữ liệu HTTP có khả năng thích nghi 3GPP (AHS) là một phần của chuẩn 3GPP phiên bản phát hành thứ 9 (xem AHS) Và 3GPP bản 10 cũng hoạt động với chuẩn

có tên gọi là DASH

Open TV Forum có chuẩn HTTP Adaptive Streaming (HAS) (xem HAS)

Công nghệ MPEG Dynamic Adaptive Streaming trên nền HTTP (DASH) dựa trên AHS của 3GPP và HAS của Open TV Forum và gần hoàn thiện Nó quy định rõ cách sử dụng

cả MP4 hay các đoạn của dòng dữ liệu (TS - transport stream) và các bản tin XML (được gọi là mô tả biểu diễn dữ liệu hoặc MPD) được tải đi tải lại DASH rất có nhiều khả năng trở thành lựa chọn định dạng của tương lai, nhưng hiện tại, do số lượng máy khách hỗ trợ còn hạn chế nên chuẩn này chỉ có ưu điểm trên lý thuyết DASH thực sự được sử dụng trong nhiều trường hợp, kể cả tách hoặc nối các dòng âm thanh, video và dữ liệu, cũng như mã hóa Tuy nhiên, nhìn chung nó có nhiều nhược điểm như các ưu điểm, vì nó khiến khách hàng gặp khó khăn trong thực thi

Nhiều nhà cung cấp DRM có những thay đổi riêng đối với các hệ thống này

2.2.5 Apple HTTP Live Streaming

Không như Microsoft và Adobe, Apple đã lựa chọn không sử dụng định dạng tập tin MPEG của ISO - một định dạng dựa trên định dạng MOV của Apple - trong công nghệ

mảnh nó thành một chuỗi các tập tin MPEG-2 TS để đóng gói cả âm thanh và video Các đoạn này được đặt trên bất kỳ máy chủ HTTP nào cùng với các tập tin trong danh sách Tập tin kê khai danh sách (hoặc danh mục) là tập tin văn bản (dựa trên định dạng tâp tin m3u của Winamp) với phần mở rộng m3u8 Chi tiết đầy đủ có thể xem tại [HLS]

HLS định nghĩa 2 loại tập tin danh sách: thông thường và thay đổi Tập tin danh sách thông thường liệt kê các URL trỏ đến các đoạn sẽ được phát tuần tự Các tập tin danh sách thay đổi trỏ đến một bộ các tập tin danh sách thông thường khác nhau, mỗi tập tin dành cho một profile đầu ra Siêu dữ liệu được truyền trong tập tin danh sách như các ý kiến - các dòng có ký tự # phía trước Trong trường hợp các tập tin danh sách bình thường, siêu dữ liệu bao gồm một số đánh thứ tự chuỗi dùng để kết hợp các đoạn từ các profile khác nhau, thông tin về độ dài đoạn, một chỉ dấu báo hiệu xem các đoạn có được lưu trên bộ đệm không, vị trí của khóa giải mã, loại dòng, và thông tin về thời gian Trong trường hợp danh sách thay đổi, siêu dữ liệu bao gồm tốc độ bit của profile, độ phân giải, độ mã hóa, và một ID có thể được dùng để kết hợp các mã khác nhau của cùng một nội dung Hình 9 và Hình 10 minh họa một ví dụ về tập tin danh sách thay đổi HLS

và tập tin danh sách thông thường

Hình 2-7: Một tập tin danh sách thay đổi HLS minh họa 8 profile đầu ra với tốc độ bit

khác nhau

Các địa chỉ URL của tập tin m3u8 có liên quan đến nhau, nhưng có thể thêm 'http:// ' Trong ví dụ này, mỗi danh sách của profile nằm trong một thành phần đường dẫn riêng biệt của URL

Hình 2-8: Một tập tin danh sách HLS từ một dòng trực tuyến mô tả ba đoạn TS hiện có

gần nhất

Nhãn #EXT-X-MEDIA-SEQUENCE xác định số thứ tự chuỗi của đoạn đầu tiên, 505.ts;

nó được dùng để sắp xếp các đoạn từ các profile khác nhau Cần lưu ý rằng tên đoạn không chứa thông tin cụ thể nào về dòng dữ liệu Nhãn #EXT-X-TARGETDURATION:11 là khoảng thời gian dự kiến (10 giây) của các chuỗi, dù khoảng thời gian này có thể thay đổi Nhãn #EXT-X-KEY:METHOD=NONE thể hiện rằng không có sự mã hóa nào được sử dụng trong chuỗi này Các nhãn #EXTINF:10 thể hiện

độ dài của mỗi đoạn Như trong tập tin danh sách thay đổi, các địa chỉ URL liên quan đến địa chỉ URL cơ sở được sử dụng để truy xuất danh sách

Trong HLS, một tập tin danh sách tương ứng với một dòng dữ liệu trực tuyến cần được tải đi tải lại vì vậy máy khách có thể biết các địa chỉ URL của hầu hết các đoạn có sẵn gần nhất Danh sách được tải xuống mỗi lần một đoạn được phát, và do đó, để giảm thiểu

nhiên, kích thước của tập tin danh sách nhỏ hơn so với bất kỳ nội dung video nào, và máy khách sẽ duy trì một kết nối TCP mở đến máy chủ, vì vậy mạng chịu tải không đáng kể

Có thể dùng các đoạn ngắn hơn Điều này cho phép máy khách điều chỉnh cho phù hợp với tốc độ bit nhanh hơn Các danh sách video theo yêu cầu (VoD) được phân biệt với các danh sách trực tuyến bởi các nhãn #EXT-X-PLAYLIST-TYPE and #EXT-X-ENDLIST

HLS là giao thức duy nhất không yêu cầu các đoạn phải bắt đầu với các khung hình IDR

Nó có thể tải xuống các đoạn từ 2 profile và trao đổi bộ giải mã giữa các profile trên một khung hình IDR xuất hiện ở giữa một đoạn Tuy nhiên, việc này sẽ ngốn thêm băng thông

do hai đoạn tương ứng với cùng một phần của video sẽ được tải về đồng thời

HLS có một số ưu điểm sau:

 Là một giao thức đơn giản dễ sửa đổi Các danh sách có thể được truy cập dễ dàng

và định dang văn bản giúp đơn giản hóa việc sửa đổi phục vụ cho các ứng dụng như phát sóng lại hoặc chèn quảng cáo

 Ứng dụng của tập tin TS là tạo ra một hệ sinh thái phong phú để thử nghiệp và kiểm tra tính tương thích của tập tin

 Tập tin TS có thể chứa các siêu dữ liệu khác, như các tín hiệu SCTE35 hoặc nhãn ID3 (xem HLSID3)

 HLS vốn được dùng trên các thiết bị iOS phổ biến, mà ở đó người dùng thường hay trả tiền cho các ứng dụng và dịch vụ khác Do đó, HLS dễ kiếm tiền hơn Tuy nhiên HLS có một số nhược điểm sau:

 HLS vốn không được hỗ trợ trên nền tảng hệ điều hành Windows

 Tập tin TS ghép âm thanh, video và dữ liệu với nhau Điều này có nghĩa là việc hỗ trợ đa ngôn ngữ sẽ dẫn đến chi phí cho việc gửi đi mọi ngôn ngữ trong đoạn hoặc