THỰC HIỆN CƠ CHẾ CACHE ATOM HEADER CHO DỊCH VỤ TRUYỀN VIDEO TRÊN NỀN TẢNG HỆ THỐNG NHÚNG

Mỗi phương pháp video streaming này lại có một đặc điểm, mục đích riêng khi được phát triển như là giảm thời gian trễ, dễ dàng trong quản lý các tập tin video ở phía máy chủ, hỗ trợ trên

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

Nguy ễn Tiến Thành

KHÓA LU ẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ thông tin

HÀ N ỘI - 2015

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

Nguy ễn Tiến Thành

KHÓA LU ẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ thông tin

Cán bộ hướng dẫn: TS Hoàng Xuân Tùng

HÀ N ỘI - 2015

Footer Page 2 of 113.

VIETNAM NATIONAL UNIVERSITY, HANOI UNIVERSITY OF ENGINEERING AND TECHNOLOGY

Nguyen Tien Thanh

AN IMPLEMENTATION OF ATOM HEADER CACHING FOR VIDEO STREAMING APPLICATIONS ON EMBEDDED DEVICES

Major: Information Technology

Supervisor: Dr Hoang Xuan Tung

HA NOI - 2015

Footer Page 3 of 113.

TÓM T ẮT Tóm t ắt: Ngày nay, các dịch vụ xem video trực tuyến qua mạng internet ngày càng trở

lên quen thuộc đối với mọi người Chúng ta có thể dễ dàng xem một bộ phim, một video

âm nhạc… gần như ngay lập tức chỉ với một trình duyệt hoặc phần mềm có hỗ trợ các phương pháp truyền video streaming Mỗi phương pháp video streaming này lại có một đặc điểm, mục đích riêng khi được phát triển như là giảm thời gian trễ, dễ dàng trong

quản lý các tập tin video ở phía máy chủ, hỗ trợ trên các thiết bị khác nhau… Atom Header Caching (AHC) [12], là phương pháp mới được tạo ra nhằm mục đích giảm thời gian trễ khi bắt đầu xem video trực tuyến Tuy nhiên, phương pháp này mới chỉ dừng ở

việc hỗ trợ trên các thiết bị máy tính cá nhân truyền thống như máy tính để bàn, máy tính xách tay mà chưa được hỗ trợ trên các thiết bị điện thoại Trong khi đó, các thiết bị điện thoại di động thông minh ngày càng được nhiều người dùng quan tâm hơn so với các máy tính cá nhân truyền thống Chính vì vậy khóa luận này sẽ thực hiện đưa phương pháp AHC lên nền tảng hệ điều hành BlackBerry OS 10, hệ điều hành dành cho các thiết

bị điện thoại thông minh Cùng với đó, khóa luận cũng cố gắng trình bày một cách tổng quan về video streaming và định dạng tập tin mp4 được sử dụng trong internet video streaming

T ừ khóa: Video streaming, định dạng mp4, Atom Header Caching, Blackberry 10

ABSTRACT Abstract: Today, video streaming services have become more popular to everybody

We can easily watch a movie and music video… only in a browser or an application that

support varies video streaming methods Every video streaming method is developed

for particular properties and purposes Atom Header Caching (AHC) [12] is one of such

methods It is created in order to reduce start-up time when watching video over the

Internet However, this new method only support for personal computer as desktop or

laptop that runs Linux operating system With the tremendous increasing number of

handset devices, this thesis will inplement AHC on Blackberry 10 operating system, an

operating system for smarthphone devices Together, this thesis also tries to present an

overview of video streaming, mp4 file format used in internet video streaming

Key words: Video streaming, mp4 file format, Atom Header Caching, Blackberry 10

L ỜI CẢM ƠN

Lời đầu tiên, tôi xin gửi lời cảm ơn sâu sắc nhất đến thầy giáo, TS Hoàng Xuân Tùng người đã tận tình chỉ bảo, hướng dẫn tôi trong suốt quá trình thực hiện khóa luận này Tôi xin bày tỏ lời cảm ơn trân thành đến những thầy cô đã giảng dạy tôi trong suốt bốn năm qua, giúp tôi trang bị những kiến thức cơ bản nhất để phát triển trong tương lai Tôi gửi lời cảm ơn tới tập thể lớp K56-CLC đã ủng hộ, khích lệ và luôn sát cánh bên tôi trong suốt quá trình học tập, rèn luyện tại trường

Lời cuối cùng, tôi muốn gửi lời cảm ơn đến cha mẹ, những người luôn ủng hộ, giúp đỡ

và động viên tôi vượt qua những khó khăn trong cuộc sống

Hà Nội, ngày 08 tháng 05 năm 2015 Sinh viên

Nguyễn Tiến Thành

L ỜI CAM ĐOAN

Tôi xin cam đoan nội dung khóa luận này là do tôi thực hiện dưới sự hướng dẫn của TS Hoàng Xuân Tùng

Tất cả những tham khảo từ các nghiên cứu liên quan đều được nêu nguồn gốc một các

rõ ràng từ danh mục tài liệu tham khảo trong khóa luận Trong khóa luận, không có việc sao chép tài liệu, công trình nghiên cứu của người khác mà không chỉ rõ về tài liệu tham

khảo

Hà Nội, ngày 08 tháng 05 năm 2015

Sinh viên

Nguyễn Tiến Thành

M ỤC LỤC

MỞ ĐẦU 1

CHƯƠNG 1 Internet video streaming và các phương pháp streaming phổ biến 2

1.1 Internet video streaming 2

1.2 Kiến trúc chung của video streaming 3

1.3 Các phương pháp hỗ trợ video streaming hiện nay 4

1.3.1 Phương pháp streaming truyền thống 4

1.3.2 Các phương pháp dựa trên HTTP 5

CHƯƠNG 2 MP4 và các phương pháp video streaming dựa trên HTTP-based adaptive streaming 7

2.1 Định dạng MP4 7

2.1.1 Sự phổ biến của định dạng MP4 7

2.1.2 Cấu trúc MP4 7

2.2 Các phương pháp video streaming dựa trên HTTP-base adaptive streaming 14

2.2.1 Microsoft Smooth Streaming 14

2.2.2 Apple HLS 17

2.2.3 MPEG-DASH 20

2.2.4 Atom Header Caching 22

CHƯƠNG 3 Atom Header Caching trên thiết bị di động 25

3.1 Ứng dụng Atom Header Caching trên thiết bị di động 25

3.2 Biên dịch các thư viện mã nguồn mở 27

3.2.1 Các thư viện mã nguồn mở 27

3.2.2 Biên dịch các thư viện mã nguồn mở 28

3.3 Thực hiện trên thiết bị BB10 32

3.3.1 Xây dựng giao diện người dùng 33

3.3.2 Thực hiện cơ chế cache atom header trên thiết bị BB10 35

3.3.3 Hiển thị hình ảnh của video 38

3.3.4 Phát âm thanh của video 42

3.3.5 Đồng bộ hình ảnh và âm thanh 46

CHƯƠNG 4 Thực nghiệm và các kết quả đạt được 47

4.1 Thực nghiệm chương trình AtomPlayer 47

4.2 Kết quả thực nghiệm 50

KẾT LUẬN 51

DANH SÁCH KÝ HI ỆU, CHỮ VIẾT TẮT

DANH SÁCH HÌNH V Ẽ, BẢNG BIỂU

Hình 1 Kiến trúc chung của video streaming [12] 3

Hình 2 Sự phổ biến của định dạng mp4 [16] 7

Hình 3 Cấu trúc tập tin MP4 8

Hình 4 Cấu trúc bên trong hộp moov 9

Hình 5 Cấu trúc tập tin fmp4 được sử dụng trong Microsoft Smooth Streaming [12] 12 Hình 6 Cấu trúc tập tin fmp4 được sử dụng trong MPEG-DASH [12] 12

Hình 7 cấu trúc tập tin mp4 bị phân mảnh trong Microsoft Smooth Streaming [2] 15

Hình 8 Quá trình thực hiện của phương pháp Smooth Streaming [2] 16

Hình 9 Quá trình thực hiện của phương pháp HLS [1] 18

Hình 10 Quá trình thực hiện của phương pháp MPEG-DASH [15] 21

Hình 11 Quá trình thực hiện của phương pháp AHC [12] 22

Hình 12 Tập tin mp4 trước khi bị cắt bởi Proc 1 23

Hình 13 Hai tập tin mới được tạo ra từ tập tin Video.mp4 sau khi cắt 23

Hình 14 Hỗ trợ AHC trên thiết bị di động 25

Hình 15 Kiến trúc chương trình AtomPlayer 26

Hình 16 Sơ đồ hoạt động của chương trình AtomPlayer 33

Hình 17 Hộp thoại nhập liệu 35

Hình 18 Sơ đồ thực hiện cơ chế cache atom header của chương trình AtomPlayer 36

Hình 19 Sơ đồ hiển thị hình ảnh của chương trình AtomPlayer - 1 39

Hình 20 Sơ đồ hiển thị hình ảnh của chương trình AtomPlayer - 2 42

Hình 21 Sơ đồ phát âm thanh của chương trình AtomPlayer 43

Hình 22 Bảng thông số các video được sử dụng để thực nghiệm 47

Hình 23 Bảng thông số kích thước của các tập tin atom header 48

Hình 24 Biểu đồ so sánh thời gian bắt đầu ứng với tốc độ băng thông 1.5 Mbps 48

Hình 25 Biểu đồ so sánh thời gian bắt đầu ứng với tốc độ băng thông 3.0 Mbps 49

Hình 26 Biểu đồ so sánh thời gian bắt đầu ứng với tốc độ băng thông 5.0 Mbps 49

M Ở ĐẦU

Chất lượng dịch vụ video luôn là một trong các yếu tố hàng đầu thu hút người sử

dụng đến với các nhà cung cấp dịch vụ video streaming Và một trong các yếu tố ảnh hưởng tới nó là thời gian trễ khi bắt đầu hiển thị video Thời gian trễ này được tính từ khi người dùng gửi yêu cầu xem video đến máy chủ tới khi hiển thị được khung hình đầu tiên của video trên màn hình người dùng Thời gian trễ này có thể được bù đắp bằng cách tăng tốc độ kết nối internet Tuy nhiên, theo một báo cáo được hãng quản lý lưu lượng và giải pháp công nghệ Akamai [4] của Mỹ công bố vào Quý 1 năm 2014 cho

thấy Internet toàn cầu mới chỉ đạt tốc độ trung bình 3.9 Mbps và đối với Việt Nam là 2 Mbps Tốc độ này vẫn còn khá thấp so với khuyến nghị từ Netflix [20] về tốc độ internet

cần thiết để có thể sử dụng dịch vụ internet video streaming được tốt nhất Do đó, cần

phải có một giải pháp công nghệ đáp ứng được việc giảm thời gian trễ khi bắt đầu hiển

thị video Đã có nhiều các công trình nghiên cứu, giải pháp công nghệ được các công

ty, tổ chức công nghệ đưa ra Các giải pháp có thể kể đến như Microsoft Smooth Streaming [2], Apple HTTP Live Streaming [1], MPEG Dynamic Adaptive Streaming over HTTP [15]… và một giải pháp mới được đề xuất là cache các atom header [12] đối

với các tập tin video MP4

Mục tiêu của khóa luận là chuyển đổi một chương trình xem video có hỗ trợ AHC trên các máy tính cá nhân sang thiết bị di động chạy hệ điều hành Blackberry 10 Bên cạnh

đó khóa luận cũng sẽ trình bày tổng quan về các vấn đề liên quan đến video streaming như các giải pháp hiện có, cấu trúc tập tin mp4 để hiểu rõ hơn phần nào về video streaming và định dạng được sử dụng trong video streaming

Nội dung của khóa luận được chia làm bốn phần như sau:

- Phần 1: Trình bày tổng quan về Internet video streaming, cùng với đó là một số phương pháp video streaming phổ biến hiện nay

- Phần 2: Phần này sẽ trình bày các giải pháp hiện có về video streaming dựa trên HTTP-based adaptive streaming Gồm Smooth Streaming, HLS và MPEG-DASH Đồng thời giới thiệu về phương pháp mới được đề xuất Atom Header Caching

- Phần 3: Thực hiện Atom Header Caching trên nền tảng hệ điều hành BlackBerry

10

- Phần 4: Thực nghiệm, đánh những kết quả đã đạt được và chưa đạt được, đồng

thời đưa ra các phương hướng nghiên cứu trong thời gian tới

CHƯƠNG 1 Internet video streaming và các phương pháp streaming phổ biến 1.1 Internet video streaming

Video được định nghĩa là một loại phương tiện điện tử dùng để lưu trữ, sao chép, phát lại và hiển thị của các chuyển động hình ảnh và âm thanh được ghi lại [18] Ngay

từ khi ra đời, nó đã đóng một vai trò quan trọng trong truyền thông và nhu cầu giải trí

của con người trong Thời kỳ đầu, video được sử dụng chủ yếu trong lĩnh vực truyền hình và xuất hiện trong các rạp chiếu phim Từ những năm 90, cùng với sự phát triển và bùng nổ của internet, khái niệm về video streaming cũng được ra đời Khái niệm video

streaming có nghĩa là dữ liệu video được truyền liên tục từ một nguồn đến một đích nào đó thông qua mạng Internet [12] hoặc cũng có thể là từ nhiều nguồn đến cùng

một đích thông qua mạng chia sẻ ngang hàng

Trước đây, chúng ta chỉ có thể xem nội dung của tập tin video sau khi tải toàn bộ video

đó từ trên internet về máy tính Giờ đây, nhờ sự phát triển không ngừng của công nghệ,

ta có thể xem thông qua các giao thức video streaming mà không cần phải tải toàn bộ

tập tin video về máy

Video streaming thường được sử dụng trong lĩnh vực giải trí, giảng dạy hoặc học tập, cũng như trong các hội nghị trực tuyến Video streaming được chia thành hai loại chính như sau [12]:

- Streaming các tập tin video có sẵn trên máy chủ hay thường được gọi là theo yêu

cầu (on-demand) Người sử dụng có thể thực hiện các thao tác tua nhanh, tạm

dừng… như khi xem một tập tin video có sẵn trên máy tính

- Streaming từ một sự kiện trực tiếp (live), khi đó video không có sẵn, dữ liệu hình ảnh và âm thanh sau khi được thu vào từ một máy quay camera, microphone, thông qua máy chủ sẽ được truyền trực tiếp tới người xem Khi đó người xem sẽ không thể thực hiện các thao tác tua như thông thường vì dữ liệu đó được thu theo thời gian thực

Video streaming sử dụng một kỹ thuật được gọi là kỹ thuật đệm [12]:

- Thay vì được gửi một lần duy nhất, dữ liệu video sẽ được chia thành nhiều gói nhỏ, sau đó liên tục truyền những phần đã được chia ra

- Ban đầu bên nhận sẽ lấy về một phần chia nhỏ của dữ liệu video và hiển thị những

phần video đã nhận được, đồ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ề để kịp cho việc hiển thị tiếp theo

Theo điều tra của The Guardian [3] đến giữa những năm 2000, phần lớn lưu lượng truy

cập internet đều dựa trên giao thức HTTP và mạng lưới phân phối nội dung (Content Delivery Network - CDN) Do đó, không có gì là ngạc nhiên khi vào năm 2011 Cisco [8] đã đưa ra một dự đoán đến năm 2015, video streaming sẽ chiếm 90% lưu lượng internet toàn cầu Điều đó ngày càng được khẳng định khi mà các dịch vụ cung cấp video streaming thông qua giao thức HTTP ngày càng trở lên phổ biến tới người dùng

Có thể kể đến một loạt các nhà cung cấp dịch vụ có tên tuổi trên thế giới như Netflix,

Hulu, Youku, Youtube… Một vài thống kê trên trang web chia sẻ video lớn nhất thế

giới hiện nay là Youtube cho thấy có tới hơn 1 tỷ người dùng đã đăng ký tài khoản trên Youtube, số giờ người dùng xem trên Youtbe trong một tháng là hơn 6 tỷ giờ, mỗi phút

lại có gần 100 giờ video được đưa lên Hơn 80% lưu lượng truy cập Youtube đến từ các

quốc gia không phải là Mỹ Đặc biệt kỷ lục về video có số lượng người xem cao nhất là

"Gangnam Style" với 2.1 tỷ lượt xem [6]… Những thống kê này đã chứng minh được

phần nào sự phổ biến cũng như triển vọng của internet video streaming ở thời điểm hiện

tại và tương lai

1.2 Ki ến trúc chung của video streaming

Các phương pháp video streaming dù được thực hiện hay triển khai như thế nào (ngoại

trừ mạng chia sẻ ngang hàng) cũng đều tuân theo một mô hình khách – chủ truyền thống

Mô hình này được mô tả bởi hình vẽ dưới đây

Hình 1 Ki ến trúc chung của video streaming [12]

Theo đó, âm thanh và hình sau khi thu vào từ các máy thu như máy quay camera, thiết

bị thu âm, … sẽ được nén lại sử dụng bằng các bộ codec thích hợp Ví dụ với dữ liệu

âm thanh thì sẽ sử dụng bộ codec AAC hoặc đối với hình ảnh thì sử dụng bộ codec H264 Dữ liệu hình ảnh và âm thanh này có thể được lưu trữ riêng biệt hoặc được gộp chung lại trong một hộp container duy nhất, gọi là các một tập tin video Các bộ container phổ biến có thể sử dụng để lưu trữ như matroska (mkv), window media video (wmv), MPEG-4 part 12 (mp4, m4v), …

Tiếp theo, tập tin video này sẽ được đẩy lên một hệ thống máy chủ streaming server Hệ

thống máy chủ streaming server này có thể gồm một hoặc nhiều máy chủ Ví dụ như có

thể sử dụng một số máy để xử lý các yêu cầu xem video được máy khách gửi tới, một

số máy lại được dùng để lưu trữ dữ liệu tĩnh như nội dung tập tin video… Hoặc cũng có

thể sử dụng một máy chủ vừa xử lý các yêu cầu được gửi đến, vừa làm nhiệm vụ quản

lý các tập tin video được đưa lên

Trên phía máy chủ lại có một lớp ứng dụng điều khiển chất lượng dịch vụ (QoS), lớp ứng dụng này làm nhiệm vụ điều phối các luồng âm thanh và hình ảnh ở các chất lượng bitrate khác nhau để gửi tới phía máy khách Các bitrate này có thể thay đổi tăng lên

hoặc giảm đi phụ thuộc vào các thông số như tình trạng mạng, băng thông, khả năng

chịu tải… của máy chủ và cả máy khách

Dữ liệu video streaming được truyền trên mạng internet từ máy chủ tới máy khách có

thể sử dụng thông qua các giao thức ở tầng ứng dụng như HTTP, RTSP, … và cũng có

thể sử dụng TCP hoặc UDP ở tầng giao vận trong các tình huống khác nhau

Ở trên phía máy khách cũng có một lớp ứng dụng điều khiển chất lượng dịch vụ, nó cũng hoạt động tương tự như ở trên phía máy chủ Căn cứ vào các thông số của máy khách mà nó sẽ đưa ra các yêu cầu phù hợp để máy chủ có thể đáp ứng Sau khi nhận được dữ liệu âm thanh và hình ảnh, chương trình chơi video trên máy khách sẽ thực hiện

giải mã những dữ liệu này bằng các bộ giải mã thích hợp tương ứng với hình ảnh và âm thanh Cuối cùng, dữ liệu âm thanh, hình ảnh sau khi giải mã sẽ được đồng bộ với nhau

để hiển thị lên màn hình của người dùng

1.3 Các phương pháp hỗ trợ video streaming hiện nay

Internet ngày nay sử dụng 3 phương pháp video streaming bao gồm: các phương pháp streaming truyền thống, progressive download và adaptive streaming (chuyển

luồng thích ứng) Mỗi một phương pháp lại có các đặc điểm, tính năng, khả năng hỗ trợ trên các thiết bị khác nhau cũng như là mục đích của mỗi phương pháp Ví dụ như đối

với phương pháp progressive download và adaptive streaming được xây dựng dựa trên giao thức HTTP thì sẽ cho phép tiếp cận được một lượng lớn người dùng hơn so với các phương pháp streaming truyền thống được xây dựng dựa trên giao thức RTP…

Trong các phần 1.3.1 và 1.3.2 tiếp theo, khóa luận sẽ trình bày tổng quan về các phương

pháp trên

1.3.1 Phương pháp streaming truyền thống

RTSP (real time streaming protocol) [14] được định nghĩa trong RFC 2326 là một

ví dụ về giao thức streaming truyền thống

Sau khi một phiên giữa máy khách và máy chủ được thiết lập Máy chủ bắt đầu gửi một

luồng liên tục các gói tin đa phương tiện (định dạng của các gói tin này là RTP) Các gói tin RTSP này có thể được truyền bằng UDP hoặc TCP ở tầng giao vận UDP và TCP như đã biết, nó lần lượt các giao thức truyền tin không tin cậy và truyền tin tin cậy Do

đó, khi sử dụng UDP thì tốc độ sẽ nhanh hơn là sử dụng TCP do nếu gói tin có bị mất thì nó sẽ không truyền lại Điều này đặc biệt quan trọng trong một số ứng dụng yêu cầu

thời gian thực ví dụ như khi tham gia vào một cuộc gọi video hội nghị trực tuyến Trong

một số trường hợp, tường lửa hoặc proxy có thể chặn không cho các gói tin UDP đi qua thì TCP sẽ được sử dụng

Ngoài ra cũng còn một số giao thức khác được sử dụng như HTTP…Các trình xem video streaming phía máy khách hiện nay đều hỗ trợ cả RTSP và HTTP Một điểm đáng

chú ý là máy chủ chỉ gửi đủ dữ liệu để phía máy khách lưu vào trong bộ đệm Thông thường, bộ đệm trên máy khách sẽ có kích thước đủ để chứa khoảng từ 1 – 10 giây video Tức là nếu phía máy khách gửi lệnh “PAUSE” thì dù cho ta có chờ 10 phút hay

20 phút thì cũng chỉ có khoảng 5 – 10 giây của video được tải về phía máy khách Việc quy định kích thước của bộ đệm có thể được thực hiện khi lập trình các ứng dụng xem video trên máy khách

1.3.2 Các phương pháp dựa trên HTTP

1.3.2.1 Progressive Download

Progressive Download [2] được phát triển dựa trên giao thức HTTP và được hỗ trợ

bởi hầu hết các trình chơi đa phương tiện và các nền tảng khác nhau bao gồm Adobe flash, Silverlight, Window Media Player, ffplay Nó cho phép các trình chơi video trên máy khách phát video ngay trong quá trình tải về Đặc điểm chính của phương pháp này

đó là các tập tin video phải có phần moov (movie metadata box) chứa thông tin về tập tin video đặt phía trước hộp mdat (media data box) chứa dữ liệu video Khi máy khách yêu cầu một tập tin video không hỗ trợ progessive download thì máy khách buộc phải

tải cả tập tin đó về trước khi người dùng có thể xem Các máy khách hỗ trợ HTTP có

thể tua video trong quá trình xem Progressive download có rất nhiều các ưu điểm được

thừa kế từ giao thức HTTP như được hỗ trợ hỗ trợ trên nhiều thiết bị, hệ điều hành, cũng như là giảm thiểu các chi phí khi vận hành một hệ thống các máy chủ streaming server so với việc sử dụng các phương pháp streaming truyền thống Tuy nhiên nó cũng

có một nhược điểm là vẫn có một khoảng thời gian trễ khi bắt đầu xem một tập tin video,

do progressive download bắt buộc phải lấy được thông tin moov của tập tin video trước khi nó có thể hiển thị nội dung của video đó Tập tin video mà có thời lượng càng dài thì kích thước của moov càng lớn, từ đó dẫn đến thời gian trễ khi bắt đầu xem càng cao

Mặc dù vậy, khi so sánh thời gian chờ đợi với việc phải tải về toàn bộ tập tin video và

việc có thể xem ngay khi đang tải video về cũng đã làm giảm được thời gian phải chờ đợi của người dùng đi rất nhiều

Một số trang web hỗ trợ Progressive Download hiện nay bao gồm Youtube, Vimeo,… bên cạnh việc hỗ trợ progressive download thì các nhà cung cấp dịch vụ này cũng hỗ trợ

cả HTTP-based adaptive streaming, một phương pháp mới có thể được coi là tương lai

của ngành công nghiệp video treaming

1.3.2.2 HTTP-based Adaptive Streaming

Adaptive streaming [2] được phát triển dựa trên progessive download và giao thức HTTP Điểm đặc biệt của nó là sử dụng giao thức HTTP hiện có thay vì đưa ra một giao

thức mới Ý tưởng của phương pháp này là thực hiện chia nhỏ video từ trên phía máy

chủ thành các thành phần độc lập với nhau Sau đó thực hiện tải về từng phần nhỏ (được

gọi là segment), thay vì tải về một cả một tập tin video lớn Phương pháp này yêu cầu

tập tin video sau khi chia nhỏ cần được đánh chỉ mục và lưu vào một tập tin có định

dạng xml, để khi phía máy khách có yêu cầu thì sẽ gửi về đầu tiên

Thông thường, dữ liệu hình ảnh và âm thanh nguồn được cắt thành nhiều segment nhỏ

và được mã hóa ở định dạnh chuyển giao mong muốn Độ dài của chúng thường là khoảng 2 – 4 giây Các segment này là độc lập với nhau

Các segment sau khi mã hóa được đưa lên các máy chủ web HTTP Một máy khách sau khi gửi yêu cầu xem tập tin video cụ thể thì sẽ được phía máy chủ gửi về cho một tập tin chỉ mục Chương trình chơi video trên máy khách sẽ căn cứ vào tập tin chỉ mục này

mà thực hiện gửi các yêu cầu tới máy chủ cũng như hiển thị dữ liệu hình ảnh cũng như

âm thanh đồng bộ theo thứ tự thời gian

Khi hình ảnh, âm thanh nguồn được mã hóa ở các bitrate khác nhau thì sẽ có nhiều segment với độ lớn khác nhau ứng với từng bitrate được tạo ra với độ dài từ 2 – 4 giây Phía máy khách dựa trên tốc độ kết nối, băng thông mạng giữa nó và máy chủ để đưa ra quyết định tải về segment ứng với mỗi bitrate Đây còn được gọi là kỹ thuật chuyển

luồng thích ứng (adaptive streaming) Có thể kể tên một số các phương pháp video streaming dựa trên kỹ thuật chuyển luồng thích ứng như Microsoft Smooth Streaming [2], Apple HLS [1] và MPEG-DASH [15]…

HTTP-based adaptive streaming có nhiều ưu điểm vượt trội so với các phương pháp video streaming truyền thống như:

- Dễ ràng triển khai hơn vì nó có thể sử dụng các máy chủ HTTP cache/proxy phổ

biến mà không cần phải có các máy chủ đặc biệt rành riêng cho nó

- Tính co dãn tốt, dễ dàng mở rộng về số lượng máy chủ khi cần thiết cũng như

thu hẹp lại khi không cần quá nhiều máy chủ

- Cùng với sự bùng nổ của internet là sự phổ biến mạnh mẽ của công nghệ web dựa trên HTTP, do đó nó cho phép tiếp cận tới một số lượng lớn người dùng trên phạm

vi toàn cầu

- Hỗ trợ chuyển luồng video giữa nhiều bitrate

- Thời gian khởi động và thực hiện các thao tác tua nhanh hơn do khởi động/tua có

thể thực hiện ở bitrate thấp nhất trước khi chuyển sang các bitrate cao hơn

- Tiêu thụ tài nguyên như băng thông, phần cứng thấp hơn các giao thức trước

- Cảm giác mượt khi xem video

Trong chương 2, khóa luận sẽ trình bày chi tiết hơn về các phương pháp video streaming

dựa trên HTTP-based adaptive streaming cũng như cấu trúc của định dạng video mp4 được các phương pháp này sử dụng

CHƯƠNG 2 MP4 và các phương pháp video streaming dựa trên HTTP-based adaptive streaming

2.1 Định dạng MP4

2.1.1 S ự phổ biến của định dạng MP4

Vào năm 2012, Sorenson Media [16] đã thực hiện một cuộc khảo sát với sự tham gia của hàng ngàn chuyên gia video về định dạng mà họ sử dụng khi thực hiện mã hóa video đã đưa ra một kết quả được thống kê bởi hình vẽ dưới đây Theo đó, mp4 đã trở thành định dạng phổ biến nhất, được nhiều chuyên gia sử dụng nhất với 69%, xếp thứ hai là FLASH với 54% và đứng cuối cùng là WEBM với 5% Hầu hết các chuyên gia đều sử dụng bộ codec H.264 để mã hóa video

Hình 2 Sự phổ biến của định dạng mp4 [16]

Có nhiều lý do khiến mp4 được sử dụng bởi nhiều chuyên gia như vậy là do các ưu điểm

của nó như khả năng tương thích tốt với các thiết bị máy tính để bàn, máy tính xách tay, máy tính bảng, và các thiết bị điện thoại thông minh Cũng như là khả năng phân mảnh

tập tin mp4 lớn thành các phần mp4 nhỏ hơn (hay còn được gọi là fmp4) giúp cho quá trình streaming được thuận lợi Tất cả những điều thuận lợi này đều đến từ cách thức tổ

chức, cấu trúc của một tập tin mp4 được xây dựng dựa trên các hộp atom Dựa vào cấu trúc của tập tin mp4, một loạt các phương pháp truyền video streaming mới đã được đề

xuất Các phương pháp này sẽ được trình bày trong phần 2.2 của khóa luận

2.1.2 C ấu trúc MP4

Moving Picture ExpertGroup (MPEG)là một nhóm chuyên gia về hình ảnh, được thành lập từ tháng 2 năm 1988 với nhiệm vụ xây dựng các tiêu chuẩn cho tín hiệu âm

thanh và hình ảnh số Ngày nay, MPEG đã trở thành một kỹ thuật nén âm thanh và hình ảnh phổ biến nhất vì nó không chỉ là một tiêu chuẩn riêng biệt mà tuỳ thuộc vào yêu cầu

cụ thể, nó có thể được tùy biến về cấu trúc sao cho thích hợp nhưng vẫn trên cùng một nguyên lý thống nhất

MPEG-4 là một bộ tiêu chuẩn gồm 28 phần mô tả chỉ tiết về âm thanh, hình ảnh và các thông tin cấu hình đặc biệt khác Trong đó, phần 3 mô tả AAC (Advanced Audio Coding) và Phần 10 mô tả AVC (Advanced Video Coding) Phần 12 mô tả ISO base media file format sử dụng các hộp (box hay còn gọi là atom) với các thông tin chi tiết

Phần 14 định nghĩa định dạng tập tin mp4 với các mẫu âm thanh, hình ảnh được ghép

với nhau theo thứ tự thời gian

Chúng ta thường hay có sự nhầm lẫn giữa MP4 và MPEG-4 MPEG-4 như đã được giải thích ở trên, còn MP4 chỉ là một định dạng chứa dữ liệu được sử dụng để lưu trữ dữ liệu

âm thanh hoặc hình ảnh

2.1.2.1 C ấu trúc tập tin mp4

Thông thường, các tập tin mp4 tuân theo mô tả trong phần 14 của MPEG-4 (ISO/IEC 14496-14) [10] sẽ gồm 2 phần chính là moov (movie box) và mdat (media data)

Hình 3 C ấu trúc tập tin MP4

Trong đó, moov [9] là hộp chứa các trường metadata của video, còn mdat chứa nội dung

của video, bao gồm âm thanh, hình ảnh, phụ đề

Các hộp tiêu đề (box header) mô tả cách tìm, xử lý, truy cập nội dung trong trường dữ

liệu

Tập tin mp4 được tổ chức theo cấu trúc phân cấp, đơn vị lưu trữ trong tập tin mp4 được

gọi là các hộp (box), mỗi hộp sẽ chứa các tiêu đề (box header) và trường dữ liệu Trong

mỗi hộp lại có thể chứa các hộp con Các metadata được lưu trữ trong một hộp duy nhất

gọi là “Movie Box” (moov) Hộp moov có thể đặt ở đầu hoặc cuối tập tin mp4, phụ thuộc vào việc có muốn hỗ trợ video streaming hay không Ví dụ với các tập tin mp4 hỗ

trợ phương pháp “progressive download” thì moov sẽ được đặt ở đầu tập tin, còn đối

với tập tin mp4 được phát trực tiếp trên máy tính thì vị trí đặt moov không phải là vấn

đề vì trình phát video có thể truy cập tức thời vào moov để lấy các thông tin cần thiết cho việc phát video

Có thể sử dụng một số công cụ tiện ích như mp4creator, atomicparsley hoặc mp4box để

kiểm tra vị trí, kích thước của moov trong tập tin mp4

mp4box -info sugar.mp4

* Movie Info *

Timescale 600 - Duration 00:02:35.433

2 track(s)

Fragmented File: no

File suitable for progressive download (moov before mdat)

File Brand mp42 - version 0

Created: GMT Wed Nov 26 06:45:30 2014

Modified: GMT Wed Nov 26 06:45:30 2014

Trên đây là một ví dụ khi sử dụng công cụ mp4box để xem các thông tin cơ bản về tập tin video có tên là sugar.mp4, nó chỉ ra rằng tập tin này thích hợp cho phương pháp progressive download vì có hộp moov đặt trước hộp dữ liệu mdat Ngoài ra, nó còn cho

thấy, tập tin video này không phải là một tập tin bị phân mảnh fmp4 Fmp4 hay còn gọi

là fragmented mp4 là một trong các điểm mạnh nhất khi nói về định dạng mp4 Hầu hết các phương pháp video streaming sử dụng định dạng mp4 đều được xây dựng dựa trên fmp4 Fmp4 cho phép phân mảnh các tập tin mp4 thành các phần nhỏ hơn, thuận tiện trong việc streaming cũng như hỗ trợ chuyển luồng thích ứng (adaptive streaming) Mỗi fmp4 là một cặp metadata/dữ liệu độc lập với các fmp4 khác

Các hộp con trong moov thường gặp,

Hình 4 Cấu trúc bên trong hộp moov

Tùy thuộc vào tập tin mp4 mà có thể đặt một số hộp tùy ý trong tập tin video Tuy nhiên tên của các hộp này đều được đặt theo đúng chuẩn ISO/IEC 14496-12 [9]

Hộp mvhd hay còn gọi là “movie header box” định nghĩa thông tin tổng thể liên quan đến việc trình chiếu video Cú pháp của hộp này được định nghĩa như sau [9]:

aligned(8) class MovieHeaderBox extends FullBox(‘mvhd’, version, 0) {

if (version==1) {

unsigned int(64) creation_time;

unsigned int(64) modification_time;

unsigned int(32) timescale;

unsigned int(64) duration;

} else { // version==0 unsigned int(32) creation_time;

unsigned int(32) modification_time;

unsigned int(32) timescale;

unsigned int(32) duration;

}

}

Trong đó, version là chỉ phiên bản mpeg-4 mà tập tin video mp4 tuân theo Theo phiên

bản ISO/IEC 14496 mới nhất chấp nhận 2 phiên bản là 0 hoặc 1 Các phiên bản này chỉ khác nhau về kích thước 32 bit hoặc 64 bit của các trường dữ liệu trong hộp như thời gian tạo (creation_time), thời gian chỉnh sửa (modification_time), timescale, độ dài video (duration) Trong đó, thời gian khởi tạo và thời gian chỉnh sửa là một số nguyên được lấy mốc từ ngày 01 tháng 01 năm 1904 theo giờ UTC Timescale là số nguyên chỉ

số đơn vị thời gian trong trong một giây Độ dài video được tính theo đơn vị mili giây

Một hộp quan trọng nữa nằm trong moov là hộp trak Có thể có một hoặc nhiều hộp trak

phụ thuộc vào một tập tin mp4 có một hoặc nhiều kênh âm thanh, hình ảnh Các trak là độc lập với nhau Trong mỗi trak lại chứa các hộp metadata khác nhau

Nằm trong hộp trak là hộp tkhd (track header) Mỗi trak sẽ có duy nhất một hộp tkhd

Mỗi hộp tkhd sẽ có một giá trị số nguyên cho cờ (flags) là tổng của các giá trị track_enabled, track_in_movie, track_in_preview Trong đó, track_enabled=1, track_in_movie=7, track_in_preview=7 Ngoài ra còn một số trường khác như track_id, creation_time, modification_time…

Sử dụng công cụ mp4info cho tập tin video này, tìm được 2 track Trong đó, nội dung

của track 1 (là track hình ảnh): gồm các thành phần flags có giá trị 15, các cờ được đặt bao gồm ENABLED, IN-MOVIE, IN-PREVIEW như đã nói ở trên Tương tự đối với track 2

Tiếp theo là hộp mdia (media box), bên trong hộp này chứa các thông tin được bổ sung cho dữ liệu trong một track âm thanh hoặc hình ảnh Bao gồm mã ngôn ngữ được sử

dụng tuân theo chuẩn ISO 639-2, gồm bộ ba ký tự đại diện cho ngôn ngữ được dùng Ví

dụ như vie cho tiếng việt, eng cho tiếng anh và und nếu ngôn ngữ không xác định, … Ngoài ra nó còn chứa các thông tin như xác định một track có kiểu là âm thanh hay hình ảnh

Ngoài hộp moov, hộp mdat (media data) cũng là một hộp quan trọng, nó chứa dữ liệu

âm thanh và hình ảnh được mã hóa bởi các bộ codec như AAC cho âm thanh và H264 cho dữ liệu hình ảnh Qua phần trình bày trên, ta thấy rõ rằng, với một tập tin mp4, nó

sẽ gồm hai phần chính là moov và mdat Khi thực hiện streaming các tập tin video thì

phần đầu tiên các trình chơi video phải lấy về là moov Thay vì mỗi lần gửi yêu cầu xem video thì phải lấy về moov, ta có thể cache phần dữ liệu moov này ở trên thiết bị để giảm

thời gian trễ khi bắt đầu video

2.1.2.2 C ấu trúc fmp4

Điểm mạnh của các tập tin mp4 nằm ở khả năng hỗ trợ phân mảnh video thành các đoạn nhỏ gọi là các fmp4 [9] Các hình vẽ dưới đây thể hiện cấu trúc fmp4 được sử dụng trong các phương pháp video streaming khác nhau

Hình 5 Cấu trúc tập tin fmp4 được sử dụng trong Microsoft Smooth Streaming [12]

Hình 6 C ấu trúc tập tin fmp4 được sử dụng trong MPEG-DASH [12]

Đối với mỗi loại video streaming, MPEG-DASH và Microsoft Smooth Streaming, một

tập tin phân mảnh mp4 sẽ có một cấu trúc với nhiều điểm tương đồng MP4 có khả năng tùy biến cao, một tập tin phân mảnh mp4 có thể chứa các hộp tùy chỉnh khác nhau Với

ví dụ trên, trong track phân mảnh của mpeg-dash sử dụng hộp tfdt thay cho hộp sdtp của Microsoft Smooth Streaming Tuy nhiên giữa chúng luôn bao gồm các hộp chính như moof, mfhd và mdat

Đặc điểm chung của một tập tin phân mảnh mp4 là sẽ gồm nhiều các fmp4, mỗi fmp4

sẽ gồm 2 hộp cơ bản là movie fragment (moof) và media data (mdat) Trong đó, hộp moof chứa dữ liệu metadata cung cấp thông tin cho việc truy cập, đọc nội dung dữ liệu trong hộp mdat

- Mfhd hay còn gọi là “movie fragment header”, chứa số thứ tự (sequence number)

phục vụ cho việc kiểm tra an toàn Số thứ tự này được bắt đầu từ 1 và tăng dần, tuy nhiên không nhất thiết là phải tăng theo thứ tự liên tiếp mà có thể tăng tùy ý Trong video không thể có nhiều hơn một fmp4 có cùng một số thứ tự này Nó đảm

bảo rằng trong trường hợp người xem xem đến một khung hình tiếp theo thì khung hình này phải có số thứ tự cao hơn khung hình hiển thị trước đó Nếu nhỏ hơn thì

tức là không hợp lệ

- Hộp traf hay còn gọi là hộp Track Fragment Hộp này chứa các hộp con dùng cho

việc cung cấp các thông tin metadata để khởi chạy phần dữ liệu trong hộp mdat tương ứng

- Hộp tfhd (track fragment header) chứa thông tin về Track ID, Trong mỗi tập tin mp4 thường có một hoặc nhiều track audio, video Mỗi track này sẽ được đánh số từ 1 đến n Khi ta thực hiện phân mảnh tập tin mp4 (sử dụng công cụ mp4fragment trong bộ Bento4) thì phần fmp4 thuộc track nào (audio hoặc video) thì sẽ được đánh số track ID

của track video hay audio đó Bất cứ chương trình xem video nào cũng phải dựa vào định danh Track ID này để đọc dữ liệu âm thanh, hình ảnh từ tập tin video

- Hộp tfdt (track fragment decode time) nằm trong hộp Track fragment (traf) Cung

cấp vị trí chính xác của mẫu (sample) đầu tiên theo timeline của hộp fragment trong track âm thanh hoặc hình ảnh Thay vì ta cần phải tính tổng thời gian của các fmp4 trước

để suy ra được thời gian bắt đầu của fmp4 hiện thời, thì ta có thể lấy luôn được thông tin được cung cấp trong trường base media decode time Điều này sẽ làm giảm thời gian tính toán xử lý video, đồng thời giảm thời gian chờ khi thực hiện thao tác tua (seeking) video Một điểm chú ý là nếu sử dụng hộp track fragment decode time, thì nó phải được đặt ở sau hộp track fragment header và trước hộp track run

- Hộp trun (track fragment run) có cấu trúc được định nghĩa như ở trong [9] Theo

đó xác định số lượng các mẫu có trong một tập tin fmp4 và data offset Hoặc cũng có

thể có các trường định nghĩa thêm như thời lượng, số lượng mẫu, cũng như một số cờ khác

Một tập fmp4 được sử dụng trong video streaming thông thường sẽ có cấu trúc như sau:

default sample flags = 4001

[trun] size=12+492, flags=305

sample count = 60

data offset = 636

first sample flags = 4002

rộng cho IIS 7.0 [2] Khi mới ra đời, Microsoft Smooth Streaming đã được đưa vào sử

dụng trên trang web của NBC phục vụ video streaming cho thế vận hội Olympic mùa

hè 2008 diễn ra tại Bắc Kinh Thống kê của NBC cho thấy đã thực hiện streaming khoảng 3.4 petabytes [4] dữ liệu video dựa trên Microsoft Smooth Streaming Microsoft Smooth Streaming có thể coi là một trong những kỹ thuật tiên phong cho các phương pháp video streaming dựa trên HTTP-based adaptive streaming

Microsoft Smooth Streaming sử dụng chuẩn định dạng MPEG-4 part 14 (ISO/IEC 14496-12) [9] để lưu trữ và truyền tải dữ liệu video tới người sử dụng Smooth Streaming định nghĩa mỗi đoạn video (segment) như là một MPEG-4 Movie Fragment [9] và lưu

trữ nó trong một tập tin MP4 duy nhất để dễ dàng quản lý cũng như xử lý truy cập ngẫu nhiên tới mỗi segment trong tập tin MP4 [2] Tùy thuộc vào số lượng các bitrate mà máy

chủ hỗ trợ, mỗi tập tin MP4 được tạo ra sau khi thực hiện mã hóa sẽ tương ứng với một bitrate của video Khi máy khách gửi yêu cầu xem video tại một vị trí thời gian cụ thể trong video tới máy chủ IIS thì máy chủ tìm hộp Movie Fragment thích hợp tương ứng

với vị trí thời gian mà máy khách yêu cầu dựa trên khoảng byte dữ liệu yêu cầu trong

tập tin MP4 Sau đó máy chủ sẽ gửi dữ liệu lại cho máy khách

Định dạng của Smooth Streaming gồm 2 phần là định dạng dùng để truyền tải trên mạng

và định dạng lưu trữ [2] Định dạng truyền tải định nghĩa một cấu trúc các phần (chunk) được gửi bởi máy chủ IIS tới máy khách còn định dạng lưu trữu định nghĩa cấu trúc các

tập tin video được lưu trữ trên đĩa

a T ổ chức lưu trữ

Đơn vị cơ bản của một tâp tin video MP4 gọi là hộp Các hộp có thể chứa cả dữ

liệu và metadata Có nhiều cách để tổ chức dữ liệu và các hộp metadata trong

một tập tin video Ta có thể đẩy metadata lên trước dữ liệu, khi đó chương trình trên phía máy khách sẽ có nhiều thông tin hơn về tập tin video mà nó chuẩn bị phát Tuy nhiên nó chỉ hữu ích trong trường hợp tập tin video đã có sẵn.Trong trường hợp streaming trực tuyến thì các dữ liệu này vẫn chưa được biết đầy đủ

Metadata càng nhỏ thì thời gian đáp ứng sẽ nhanh hơn Với các lý do đó, MP4 ISO Base Media File Format [9] được thiết kế để cho phép các hộp metadata được tổ chức trong các tập tin fmp4, mỗi tập tin fmp4 sẽ gồm 1 cặp metadata/dữ

liệu video Thông thường, mỗi tập tin fmp4 này có độ dài khoảng 2 giây

Hình 7 cấu trúc tập tin mp4 bị phân mảnh trong Microsoft Smooth Streaming [2]

Mỗi một bitrate sẽ tương ứng với một tập tin chứa MP4 được phân mảnh thành các phần fmp4 Ở đây, các tập tin fmp4 sẽ được lưu trữ chung trong một tập tin mp4 thay vì để riêng Các phần fmp4 này có kích thước cố định về thời gian Nhưng kích thước các tập tin chứa MP4 sẽ khác nhau Bitrate càng cao thì kích thước tập tin chứa MP4 càng lớn

b Định dạng tập tin

Khi máy khách yêu cầu một video tại một thời gian cụ thể tử máy chủ Web IIS, thì máy chủ tìm kiếm phần bắt đầu trong tập tin MP4 và lấy phần đó ra rồi gửi về máy khách Smooth Streaming sử dụng 2 loại tập tin có đuôi mở rộng là ismv (chứa cả hình ảnh và âm thanh) và isma (chỉ chứa dữ liệu âm thanh) [2]

Các tập tin có phần mở rộng là ismv thường sẽ chứa cả dữ liệu hình ảnh và âm thanh hoặc chỉ lưu trữ dữ liệu hình ảnh Tuy tập tin này không có phần mở rộng

là MP4 nhưng cấu trúc bên trong nó đã tuân theo chuẩn MPEG-4 part 14 (ISO/IEC 14496-12) [9]

Mỗi một tập tin ismv sẽ tương ứng với một bitrate của video Khi đó, để cung

cấp một dịch vụ video streaming tốt tới người dùng thì mỗi một tập tin video sẽ được xử lý để lưu trữ ở nhiều bitrate khác nhau, phục vụ cho việc chuyển luồng thích ứng (adaptive switching) giữa các bitrate thấp và cao của cùng một video Chúng ta cũng cần phải lưu ý rằng bitrate các cao thì dung lượng tập tin càng lớn,

băng thông đòi hỏi càng cao Do đó cần phải có sự cân đối giữa chất lượng video

và chất lượng dịch vụ video streaming

Các tập tin có phần mở rộng là *.isma thường chỉ lưu trữ dữ liệu audio

Ngoài ra còn một số các đuôi mở rộng khác được phục vụ cho các mục đích khác nhau như:

• *.ism Đây thực chất là một tập chỉ mục, lưu trữ tất cả các thông tin về tập tin video tương ứng Như số lượng các track, bitrate, mỗi quan hệ giữa chúng… Tập tin này chỉ được dùng bởi máy chủ phục vụ cho việc quản lý video dễ ràng hơn

• *.ismc Đây là một tập tin có định dạng văn bản, nó chứa thông tin về các bitrate, bộ mã hóa/giải mã, độ phân giải, … được sử dụng bởi máy khách

Đây cũng chính là tập tin đầu tiên được máy chủ gửi về máy khách để cung cấp các thông tin được cần thiết cho máy khách xử lý tập tin video khi thực hiện streaming

Hình ảnh dưới đây mô tả quy trình xử lý của Microsoft Smooth Streaming

Hình 8 Quá trình th ực hiện của phương pháp Smooth Streaming [2]

Từ đầu vào bất kỳ có thể là các video gốc chưa được xử lý, máy quay hay thu âm trực tuyến, sẽ được mã hóa bới các nhà cung cấp dịch vụ, phần mềm Đầu ra của nó có thể

là video định dạng H264, âm thanh AAC, … cùng với các tập tin khác như *.ism,

*.ismc Ở đây, Windows Server đóng vai trò là một máy chủ truyền thống, sử dụng IIS cài đặt thêm dịch vụ IIS Media Services hỗ trợ cho Smooth Streaming

Hiện tại thì Smooth Streaming được hỗ trợ trên IIS 7.0 trở lên Tuy nhiên nó chỉ được cung cấp dưới dạng mở rộng Do vậy, muốn máy Chủ hỗ trợ Smooth Streaming thì cần cài đặt thêm IIS Media Services 4 Trong IIS Media Services lại bao gồm Live Smooth Streaming (phục vụ cho streaming video trực tuyến) và Smooth Streaming (phục vụ cho streaming video theo yêu cầu) IIS Media Servcies là một dịch vụ cunng cấp tính an toàn, co dãn, dễ quản lý các website động, các ứng dụng, dịch vụ chạy trên nền HTTP IIS 7.0 được hỗ trợ trên các phiên bản Windows Server 2008, Windows 7, Windows Vista SP2, Windows 8.1 trở lên

Máy khách yêu cầu các đoạn video trong tập tin *.ismc từ máy chủ web, tải chúng về qua giao thức HTTP Máy khách sẽ hiển thị các đoạn video này theo thứ tự đã yêu cầu

Dựa trên các thông tin về tình trạng mạng, CPU, băng thông…, máy khách sẽ thực hiện chuyển giữa các luồng âm thanh, hình ảnh khác nhau được định nghĩa trong tập tin

*.ismc Một trong các phương pháp dùng để xác định tình trạng hiện tại của mạng là

dựa vào thời gian tải về đoạn video và kích thước của đoạn video đó Từ đó, nó xác định được bitrate, độ phân giải thích hợp Việc chuyển này có thể diễn ra liên tục

Một ví dụ về yêu cầu máy khách gửi cho máy chủ:

http://192.168.206.137:8800/Wildlife.ism/QualityLevels(230000)/Fragments(video=20020000)

Trong URL này sẽ bao gồm chất lượng và số thứ tự của phần video được yêu cầu

2.2.2 Apple HLS

HTTP Live Streaming (HLS) [1] được Apple phát triển từ năm 2009 với mục đích cung cấp giải pháp streaming video tới các thiết bị của hãng ở các tốc độ băng thông khác nhau Giải pháp của Apple được phát triển cũng dựa trên HTTP-base adaptive streaming Tuy nhiên nó lại sử dụng định dạng MPEG-2 để mã hóa video chứ không

phải là MPEG-4

HTTP Live Streaming cho phép gửi dữ liệu audio và video qua giao thức HTTP từ một máy chủ Web truyền thống tới một chương trình Player chạy trên các thiết bị chạy iOS bao gồm iPhone, iPad, iPod touch và Apple TV cùng với các máy tính chạy hệ điều hành Mac OS Các thiết bị của Apple mặc định được hỗ trợ HLS Tuy nhiên với các hệ điều hành khác thì chỉ cần một chương trình chơi video hỗ trợ HLS thì cũng có thể xem được HLS hỗ trợ cả 2 dạng truyền video trực tuyến và video theo yêu cầu Với dạng truyền video trực tuyến thì chúng ta có thể truyền trực tiếp hình ảnh, âm thanh từ một máy quay camera tới trực tiếp người dùng cũng thông qua HTTP Nó hữu ích khi tổ

chức các hội nghị trực tuyến với sự tham gia của nhiều bên

Hình 9 Quá trình th ực hiện của phương pháp HLS [1]

Đối với dạng video theo yêu cầu thì tập tin video đã có sẵn ở trên máy chủ và đã được chia ra thành các phần nhỏ hơn bằng một bộ chia (gọi là segmenter) Khi đó người sử

dụng có thể thực hiện các thao tác tua nhanh, dừng,… HLS cũng hỗ trợ chuyển luồng video ở các tốc độ khác nhau, và phần mềm chạy trên phía máy khách có thể chuyển đổi

giữa các luồng video này dựa vào sự thay đổi của băng thông và tình trạng tài nguyên trên máy khách Một điểm mạnh nữa của HLS là cung cấp cơ chế mã hóa đa phương

tiện và xác thực người dùng qua HTTPS [1] Điều mà ít có giải pháp nào hiện nay có

thể so sánh được

Cơ chế làm việc của HLS gồm ba bước chính:

- Thực hiện mã hóa/chuyển hóa video đầu vào, sử dụng các bộ mã hóa hình ảnh/âm thanh như H.264, AAC

- Thông thường, với mỗi video đầu vào sẽ được chuyển đổi sang một vài các độ phân giải/bitrate khác nhau phục vụ cho việc streaming Ví dụ một video có bitrate 6134 kbps sẽ được chuyển sang các bitrate 110 kbps, 300kbps, 480 kbps, 3000 kbps… đáp ứng được hầu hết với cấu hình phần cứng của các thiết bị khác nhau cũng như các điều

kiện mạng khi sử dụng thông qua mạng 3G, Wifi, hay Ethernet…

- Các tập tin video sau khi được mã hóa/chuyển hóa sẽ được đưa qua một bộ chia

để phân đoạn video thành các tập tin *.ts nhỏ hơn Các tập tin này thường có độ dài khoảng 2-10 giây Cùng với việc chia nhỏ các tập tin video là tạo ra các tập tin chỉ mục

*.m3u8 tương ứng với mỗi bitrate

Trong trường hợp một tập tin video được hỗ trợ ở nhiều bitrate khác nhau thì ngoài việc

tạo ra các tập tin *.m3u8 tương ứng thì một tập tin *.M3U8 cũng được tạo ra để đánh

chỉ mục vị trí lưu trữ tập tin *.m3u8 Điều này tiện cho việc quản lý video ở phía máy

chủ Máy khách sẽ căn cứ vào tập tin *.M3U8 này để thực hiện yêu cầu các chất lượng video phù hợp

Một ví dụ về nội dung của tập tin chỉ mục

Wildlife_Apple_HLS_h264_SF_16x9_720p_001.m3u8 của một video gồm có mô tả bitrate, độ phân giải, bộ codec dùng để giải mã, chỉ mục index.m3u8 ứng với từng bitrates nếu video có hỗ trợ nhiều bitrate

#EXTINF:2, frag-2.ts

#EXTINF:2, frag-3.ts

…

#EXT-X-ENDLIST

Độ dài của mỗi tập tin *.ts trên là 2 giây được chỉ rõ trong thẻ #EXTINF: 2 cùng với đó

là tên của các tập tin được lưu trữ trên phía máy chủ như frag-1.ts, frag-2.ts…

HLS hỗ trợ các định dạng hình ảnh và âm thanh [1] sau:

HLS có thể chạy trên bất cứ máy chủ Web nào, bất cứ hệ điều hành nào mà không yêu

cầu phải có các cấu hình hay thành phần đặc biệt Các máy chủ có thể bao gồm: IIS, Lighttpd, Apache… chạy trên các nền tảng hệ điều hành Mac OS, Windows, Linux, …

Hầu hết các thiết bị chạy iOS hay Mac OS đều hỗ trợ HLS hoặc các chương trình, phần

mềm hỗ trợ HLS tương thích với H.264 trên các hệ điều hành khác Một số chương trình

phổ biến phía máy khách bao gồm Safari, VLC, Flash player, JW player…

2.2.3 MPEG-DASH

HLS và Microsoft Smooth Streaming đều sử dụng giao thức HTTP Tuy nhiên,

mỗi phương pháp lại sử dụng các tập tin chỉ mục có cấu trúc khác nhau Ngoài ra cách

tổ chức lưu trữ, truy cập tập tin video trên máy chủ cũng khác nhau Như của Microsoft

là *.ismv, *.isma, *.ism, *.ismc còn của Apple là *.ts, *.m3u8 Do đó để nhận dữ liệu

đa phương tiện từ máy chủ, mỗi một thiết bị phải có giải pháp hỗ trợ tương ứng cho các giao thức này Do đó, cần phải có một chuẩn thống nhất cho HTTP Streaming cho phép

mọi thiết bị tuân theo các chuẩn cơ bản này đều có thể giao tiếp được với các máy chủ Streaming Nắm bắt được yêu cầu đó, vào năm 2009, MPEG đã khởi động một dự án

với mục tiêu là đưa ra được một chuẩn mới dùng trong video streaming Hai năm sau, MPEG đã đưa ra một tiêu chuẩn chung thống nhất và được biết đến với tên gọi MPEG Dynamic Adaptive Streaming over HTTP viết tắt là DASH (MPEG-DASH ISO/IEC 23009-1) Cũng trong năm đó, DASH đã được phê duyệt bởi tổ chức tiêu chuẩn hóa

quốc tế và ủy ban kỹ thuật điện quốc tế ISO/IEC để trở thành chuẩn chung chính thức vào tháng 11 năm 2011 [15]

Các thành phần trong DASH bao gồm:

- Các thành phần phía máy khách

- Các thành phần phía máy chủ

Các thiết bị hỗ trợ DASH đều tuân thủ theo một quy định về máy khách, máy chủ theo chuẩn RFC 2616 [7]

Phía máy chủ sử dụng một máy chủ Web dùng để lưu chữ các Media Presentation

Description (MPD) [15] và Segments [15] MPD thực chất là một tập tin xml chứa các thông tin về các bitrate sẵn có của video, thông tin các bộ codec âm thanh, hình ảnh dùng để giải mã dữ liệu, địa chỉ nguồn url,… và các thông tin khác có liên quan Segments chứa dữ liệu video có thể được lưu trữ trong một hoặc nhiều tập tin nhỏ hơn Trong các segment là các fmp4 đã được trình bày chi tiết ở phần 2 của khóa luận, với

độ dài thời gian cố định (thường là khoảng 2 giây)

MPEG DASH sử dụng ISO Base Media File Format [9] hoặc MPEG-2 Transport Streams [15] để tổ chức lưu chữ các segments

MPEG DASH được vận hành theo mô hình sau:

Hình 10 Quá trình th ực hiện của phương pháp MPEG-DASH [15]

Phía máy khách sử dụng một chương trình chơi video hỗ trợ MPEG DASH, máy khách

gửi yêu cầu về tập tin video tới máy chủ qua phương thức GET của giao thức HTTP

Một tập tin MPD sẽ được máy chủ gửi về cho phía máy khách, trong tập tin MPD mô tả các thông tin về video được yêu cầu Máy khách đọc tập tin MPD, và thực hiện các yêu

cầu chuyển luồng thích ứng như yêu cầu video với chất lượng hình ảnh, âm thanh tốt hơn hoặc kém hơn tới phía máy chủ

Do MPEG DASH là chuẩn quốc tế, một trong các mục đích ban đầu của MPEG DASH

là dễ ràng triển khai, do đó nó có thể chạy trên bất cứ máy chủ web nào, bất cứ hệ điều hành nào mà không yêu cầu phải có thiết bị đặc biệt hay các cấu hình phức tạp