Header Page of 113 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Nguyễn Tiến Thành 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 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 Footer Page of 113 Header Page of 113 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Nguyễn Tiến Thành 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 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 hướng dẫn: TS Hoàng Xuân Tùng HÀ NỘI - 2015 Footer Page of 113 Header Page 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 of 113 Header Page of 113 TÓM TẮT Tóm tắt: Ngày nay, dịch vụ xem video trực tuyến qua mạng internet ngày trở lên quen thuộc người Chúng ta dễ dàng xem phim, video âm nhạc… gần với trình duyệt phần mềm có hỗ trợ phương pháp truyền video streaming Mỗi phương pháp video streaming lại có đặc điểm, mục đích riêng phát triển giảm thời gian trễ, dễ dàng quản lý tập tin video phía máy chủ, hỗ trợ thiết bị khác nhau… Atom Header Caching (AHC) [12], phương pháp tạo nhằm mục đích giảm thời gian trễ bắt đầu xem video trực tuyến Tuy nhiên, phương pháp dừng việc hỗ trợ thiết bị máy tính cá nhân truyền thống máy tính để bàn, máy tính xách tay mà chưa hỗ trợ thiết bị điện thoại Trong đó, thiết bị điện thoại di động thông minh ngày nhiều người dùng quan tâm so với máy tính cá nhân truyền thống Chính khóa luận thực đưa phương pháp AHC lên tảng hệ điều hành BlackBerry OS 10, hệ điều hành dành cho thiết bị điện thoại thông minh Cùng với đó, khóa luận cố gắng trình bày cách tổng quan video streaming định dạng tập tin mp4 sử dụng internet video streaming Từ khóa: Video streaming, định dạng mp4, Atom Header Caching, Blackberry 10 Footer Page of 113 Header Page of 113 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 Footer Page of 113 Header Page of 113 LỜI CẢM ƠN Lời đầu tiên, xin gửi lời cảm ơn sâu sắc đến thầy giáo, TS Hoàng Xuân Tùng người tận tình bảo, hướng dẫn suốt trình thực khóa luận Tôi xin bày tỏ lời cảm ơn trân thành đến thầy cô giảng dạy suốt bốn năm qua, giúp trang bị kiến thức để phát triển 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ệ sát cánh bên suốt trình học tập, rèn luyện trường Lời cuối cùng, muốn gửi lời cảm ơn đến cha mẹ, người ủng hộ, giúp đỡ động viên vượt qua khó khăn sống Hà Nội, ngày 08 tháng 05 năm 2015 Sinh viên Nguyễn Tiến Thành Footer Page of 113 Header Page of 113 LỜI CAM ĐOAN Tôi xin cam đoan nội dung khóa luận thực hướng dẫn TS Hoàng Xuân Tùng Tất tham khảo từ nghiên cứu liên quan nêu nguồn gốc rõ ràng từ danh mục tài liệu tham khảo khóa luận Trong khóa luận, việc chép tài liệu, công trình nghiên cứu người khác mà không rõ 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 Footer Page of 113 Header Page of 113 MỤC LỤC MỞ ĐẦU CHƯƠNG Internet video streaming phương pháp streaming phổ biến 1.1 Internet video streaming 1.2 Kiến trúc chung video streaming 1.3 Các phương pháp hỗ trợ video streaming 1.3.1 Phương pháp streaming truyền thống 1.3.2 Các phương pháp dựa HTTP CHƯƠNG MP4 phương pháp video streaming dựa HTTP-based adaptive streaming 2.1 Định dạng MP4 2.1.1 Sự phổ biến định dạng MP4 2.1.2 Cấu trúc MP4 2.2 Các phương pháp video streaming dựa 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 Atom Header Caching thiết bị di động 25 3.1 Ứng dụng Atom Header Caching thiết bị di động 25 3.2 Biên dịch 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 thư viện mã nguồn mở 28 3.3 Thực 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 chế cache atom header thiết bị BB10 35 3.3.3 Hiển thị hình ảnh video 38 3.3.4 Phát âm video 42 3.3.5 Đồng hình ảnh âm 46 CHƯƠNG Thực nghiệm kết đạt 47 4.1 Thực nghiệm chương trình AtomPlayer 47 4.2 Kết thực nghiệm 50 KẾT LUẬN 51 Footer Page of 113 Header Page of 113 DANH SÁCH KÝ HIỆU, CHỮ VIẾT TẮT Atom Header Caching AHC Apple HTTP Live Streaming HLS Fragmented mp4 fmp4 Hypertext Transfer Protocol HTTP Moving Picture ExpertGroup MPEG MPEG Dynamic Adaptive Streaming over HTTP MPEG-DASH Footer Page of 113 Header Page 10 of 113 DANH SÁCH HÌNH VẼ, BẢNG BIỂU Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Hình Kiến trúc chung video streaming [12] Sự phổ biến định dạng mp4 [16] Cấu trúc tập tin MP4 Cấu trúc bên hộp moov Cấu trúc tập tin fmp4 sử dụng Microsoft Smooth Streaming [12] 12 Cấu trúc tập tin fmp4 sử dụng MPEG-DASH [12] 12 cấu trúc tập tin mp4 bị phân mảnh Microsoft Smooth Streaming [2] 15 Quá trình thực phương pháp Smooth Streaming [2] 16 Quá trình thực phương pháp HLS [1] 18 10 Quá trình thực phương pháp MPEG-DASH [15] 21 11 Quá trình thực phương pháp AHC [12] 22 12 Tập tin mp4 trước bị cắt Proc 23 13 Hai tập tin tạo từ tập tin Video.mp4 sau cắt 23 14 Hỗ trợ AHC thiết bị di động 25 15 Kiến trúc chương trình AtomPlayer 26 16 Sơ đồ hoạt động chương trình AtomPlayer 33 17 Hộp thoại nhập liệu 35 18 Sơ đồ thực chế cache atom header chương trình AtomPlayer 36 19 Sơ đồ hiển thị hình ảnh chương trình AtomPlayer - 39 20 Sơ đồ hiển thị hình ảnh chương trình AtomPlayer - 42 21 Sơ đồ phát âm chương trình AtomPlayer 43 22 Bảng thông số video sử dụng để thực nghiệm 47 23 Bảng thông số kích thước tập tin atom header 48 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 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 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 Footer Page 10 of 113 Header Page 48 of 113 50*1024*1024 Trong đó, MAX_DATABASE_ARRAY_SIZE số lượng tập tin tối đa chứa nhớ cache, MAX_DATABASE_SIZE kích thước tối đa nhớ cache tính theo đơn vị byte Khi đó, nhớ cache đầy theo hai trường hợp sau: TH1 Tổng số lượng tập tin atom header lớn số lượng tập tin tối đa chứa đệm, thực xóa #define DELETE_STEP_NUMBER 20 tập tin atom header có giá trị freq nhỏ nhớ cache TH2 Tổng kích thước tập tin atom header lớn kích thước tối đa đệm, thực xóa tập tin atom header nhớ cache có trường giá trị freq nhỏ đủ #define DELETE_STEP_MB 10*1024*1024 byte lớn Tuy nhiên, áp dụng thuật toán LFU, video có số lần xem cực lớn mãi lưu trữ lại thiết bị dù tương lai không truy cập nhiều nữa, làm giảm tính hiệu thuật toán Chính mà trường timestamp thêm vào để đảm bảo sau khoảng thời gian xác định, tập tin video mà có khoảng thời gian dài không truy cập #define MAX_STORED_DAYS (int64_t)3 (tính theo ngày) video bị giảm nửa giá trị counter Nếu giá trị counter sau thực phép chia lấy phần nguyên gán B5 Dữ liệu ghi vào tập tin sở liệu database.txt nhớ thông qua hàm write_database() Cơ chế cache atom header thực chương trình AtomPlayer chưa phải lựa chọn tốt nhất, cần phải có nghiên cứu tìm hiểu sâu để chế cache tốt Tuy nhiên, chế cache đơn giản trình bày đủ tốt nhớ có dung lượng nhỏ thiết bị di động 3.3.3 Hiển thị hình ảnh video Các tập tin video thường mã hóa chứa định dạng mp4, avi…, Trong tập tin video gồm luồng hình ảnh có luồng âm khác Mỗi luồng lại mã hóa codec khác Ví dụ âm ACC với hình ảnh H264 Đơn vị liệu sở luồng gọi “frame” Dữ liệu đọc từ luồng đóng gói lại thành gói packet Mỗi gói packet chứa nhiều frame (trong trường hợp đọc liệu từ luồng âm thanh) Để xử lý luồng video thường tuân theo quy tắc chung B1 Tìm số định danh (id) luồng hình ảnh tập tin video B2 Tìm giải mã thích hợp để giải mã cho luồng hình ảnh B3 Đọc “frame” từ luồng tương ứngvà đóng thành gói packet Footer Page 48 of 113 38 Header Page 49 of 113 B4 Hiển thị “frame” giải mã giải mã Lặp lại bước kết thúc Trước hết phải khởi tạo thành phần hỗ trợ thư viện libavformat để hỗ trợ giao thức, định dạng codec sử dụng chương trình AtomPlayer hàm av_register_all() Do chương trình AtomPlayer cần phải gửi nhận liệu truyền qua mạng nên cần khởi tạo thành phần mạng thư viện FFMPEG hỗ trợ với avformat_network_init() Hình vẽ thể sơ đồ làm việc chương trình AtomPlayer Hình 19 Sơ đồ hiển thị hình ảnh chương trình AtomPlayer - Chương trình tạo thread để làm việc decode_thread, video_thread thread tạo lúc khởi động AtomPlayer main Trong đó, decode_thread làm nhiệm vụ đọc liệu từ luồng video, sau đóng lại thành gói packet đưa vào hàng đợi thông qua lời gọi hàm packet_queue_put() Hàng đợi có cấu trúc sau: typedef struct PacketQueue Footer Page 49 of 113 39 Header Page 50 of 113 { AVPacketList *first_pkt, *last_pkt; int nb_packets; int size; SDL_mutex *mutex; SDL_cond *cond; } PacketQueue; Trong first_pkt last_pkt trỏ trỏ đến vị trí đầu cuối hàng đợi danh sách liên kết nb_packets size số lượng gói kích thước danh sách liên kết Ngoài có hai trỏ đặc biệt mutex cond Vì AtomPlayer sử dụng thread để đọc liệu lấy liệu từ hàng đợi PacketQueue dùng chung Do hai trỏ cần thiết để đảm bảo thời điểm có thread quyền truy cập vào PacketQueue Trong hàm decode_thread(), ta tìm mở tập tin video để lấy thông tin video lời gọi hàm avformat_open_input() Hàm trả trỏ chứa thông tin cần thiết video codec để giải mã, độ dài video, thông tin luồng (stream) hình ảnh, âm tập tin…thông tin lưu trữ trỏ AVFormatContext *pFormatCtx Dựa vào trỏ này, ta tìm số định danh (video_index) luồng video tập tin Từ hàm stream_component_open() gọi kèm theo đối số video_index Tiếp đó, vòng lặp for vô đặt hàm decode_thread() để liên tục lấy liệu từ luồng video nhờ hàm av_read_frame() có thư viện ffmpeg đặt vào gói packet để đưa vào hàng đợi PacketQueue thông qua hàm packet_queue_put() Trở lại với hàm stream_component_open(), sau gọi từ decode_thread(), tiến hành tìm codec thích hợp để giải mã video Sau kiểm tra lại xem luồng liệu video (hàm viết lại phần sau để xử lý liệu audio) AVMEDIA_TYPE_VIDEO hàm tạo thread video_thread để xử lý liệu video Thread tạo nhờ SDL_CreateThread() Khi SDL_CreateThread() nhận đối số tên hàm video_thread liệu VideoState VideoState làm cấu trúc định nghĩa: typedef VideoState { AVFormatContext *pFormatCtx; int videoStream; AVStream *video_st; PacketQueue videoq; VideoPicture pictq[VIDEO_PICTURE_QUEUE_SIZE]; int pictq_size, pictq_rindex, pictq_windex; SDL_mutex *pictq_mutex; SDL_cond *pictq_cond; Footer Page 50 of 113 40 Header Page 51 of 113 SDL_Thread *parse_tid; SDL_Thread *video_tid; char filename[1024]; struct SwsContext *sws_ctx; }VideoState; Trong đó, video_st trỏ kiểu AVStream định nghĩa FFMPEG Nó trỏ đến luồng hình ảnh âm tập tin video videoq hàng đợi dùng để lưu gói packet thuộc luồng video (khác với luồng liệu audio) đọc sau gọi hàm av_read_frame() Các hình ảnh thu sau giải mã gói packet codec thích hợp chuyển định dạng YUV mà SDL hỗ trợ hiển thị Sau lưu vào mảng pictq có kiểu VideoPicture pictq_size dùng để ghi lại kích thước thời mảng pictq Mỗi có hình ảnh giải mã đưa vào mảng pictq_size tăng thêm một, sau hình ảnh lấy hiển thị hình pictq_size giảm pictq_rindex pictq_windex lưu vị trí thời để đọc ghi mảng pictq Parse_tid video_tid ghi lại thông tin định danh (id) thread tạo giành cho decode_thread video_thread Thông tin dùng để quản lý thread, dùng để hủy thread muốn kết thúc chương trình AtomPlayer filename tên tập tin video yêu cầu Cuối sws_ctx sử dụng để phục vụ cho việc chuyển đổi ảnh sang không gian màu YUV để hiển thị hình Chỉ tồn thực thể VideoState suốt chương trình Do dùng chung nhiều thread khác Trong video_thread, vòng lặp vô hạn tạo làm nhiệm vụ lấy gói packet PacketQueue để thực giải mã hàm avcodec_decode_video2() cung cấp FFMPEG Hàm nhận bốn đối số codec dùng để giải mã, AVFrame dùng để lưu lại hình ảnh sau giải mã, đối số xác nhận thực giải mã hình ảnh thành công cuối packet cần giải mã Ngay sau giải mã thành công, AVFrame truyền vào hàm queue_picture() để chuyển định dạng YUV SDL hỗ trợ hiển thị, sau đặt vào hàng đợi picq VideoState Sau giải xong việc giải mã hình ảnh video, phần hiển thị hình ảnh lên hình Một hàm event_loop() gọi từ hàm main() chương trình thực nhiệm vụ lắng nghe kiện tạo SDL hàm SDL_WaitEvent() Nếu bắt kiện FF_REFRESH_EVENT Sự kiện gửi từ hàm schedule_refresh() sau khoảng thời gian xác định, dùng để tạo trễ thời Footer Page 51 of 113 41 Header Page 52 of 113 gian hiển thị khung hình hình Sau đó, hàm video_refresh_timer() gọi để tính toán thời gian trễ cần thiết hai lần hiển thị Tiếp đó, hàm video_display() gọi để hiển thị hình ảnh Nó biểu diễn hình vẽ Hình 20 Sơ đồ hiển thị hình ảnh chương trình AtomPlayer - Hàm SDL_WaitEvent() thực kiểm tra hàng đợi EventQueue 100 lần giây (khoảng 10 mili giây / lần) EventQueue cung cấp thư viện SDL 3.3.4 Phát âm video Trong phần này, hàm trình bày phần “Hiển thị hình ảnh video” không trình bày lại, nhiên có số hàm sử dụng lại decode_thread(), stream_component_open() Thông qua hàm decode_thread(), sau đọc gói packet từ luồng tương ứng âm hình ảnh Sẽ có lệnh điều kiện: if (packet->stream_index == is->videoStream) { packet_queue_put(&is->videoq, packet); } else if (packet->stream_index == is->audioStream) { Footer Page 52 of 113 42 Header Page 53 of 113 packet_queue_put(&is->audioq, packet); } Hình vẽ mô tả việc phát âm từ video chương trình AtomPlayer Hình 21 Sơ đồ phát âm chương trình AtomPlayer Nếu gói packet thuộc luồng hình ảnh đặt vào hàng đợi PacketQueue hình ảnh, luồng âm đặt vào hàng đợi âm Do struct VideoState, hàng đợi dành cho luồng hình ảnh videoq cần định nghĩa thêm hàng đợi dành cho âm PacketQueue audioq; Tiếp theo đó, hàm stream_component_open() cần thay đổi để làm việc Cũng giống hình ảnh, liệu âm cần có giải mã (decoder) yêu cầu thông qua hàm avcodec_find_decoder() với đối số số nguyên đại diện cho codec (FFMPEG gọi codec_id) Tiếp theo đó, SDL_OpenAudio() gọi Hàm có tác dụng mở loa để phát âm Nó nhận hai đối số có kiểu wanted_spec, real_spec có kiểu SDL_AudioSpec định nghĩa SDL Trong đó, wanted_spec chứa tham số thiết lập từ trước để mở thiết bị âm wanted_spec.channels = wanted_nb_channels; Footer Page 53 of 113 43 Header Page 54 of 113 wanted_spec.freq = codecCtx->sample_rate; wanted_spec.format = AUDIO_S16SYS; wanted_spec.samples = SDL_AUDIO_BUFFER_SIZE; wanted_spec.callback = audio_callback; wanted_spec.userdata = is; Trong đó, channels số lượng kênh âm thanh, ví dụ chuẩn âm mono có kênh, với âm stereo 2… Freq tần số lấy mẫu, tức số lần lấy mẫu giây Format xác định độ rộng mẫu âm (ở 16 bit) Giá trị samples định nghĩa kích thước đệm âm (số lượng mẫu chứa đệm, có kích thước đệm tính theo đơn vị byte) Bộ đệm dùng đề chứa liệu âm sau lần gọi hàm callback Giá trị samples SDL khuyến nghị nằm khoảng từ 512 đến 8096 Trong chương trình AtomPlayer, giá trị đặt 1024 Callback trỏ hàm trỏ đến hàm audio_callback() Hàm gọi tự động SDL Userdata trỏ đến liệu truyền vào hàm callback đối số Sau gọi hàm SDL_OpenAudio(&wanted_spec, &real_spec), vào thông số đặt wanted_spec mà SDL trả thông số đặt real_spec SDL tạo quản lý trực tiếp thread âm Một số thông tin lấy từ real_spec lưu lại AudioParams audio_prm; với AudioParams định nghĩa sau: typedef struct AudioParams { int freq; int channels; int64_t channel_layout; enum AVSampleFormat fmt; int frame_size; int bytes_per_sec; } AudioParams; Với freq channels giống SDL_AudioSpec Ngoài có channel_layout, FFMPEG định nghĩa phần tử mảng channel_layout_map[] gồm tên gọi, số lượng kênh, layout theo cấu trúc sau: static const struct { const char *name; int nb_channels; uint64_t layout; } channel_layout_map[] Footer Page 54 of 113 44 Header Page 55 of 113 Ví dụ với layout có name stereo nb_channels tương ứng với hai loa trái phải Layout có giá trị AV_CH_LAYOUT_STEREO Trong AV_CH_LAYOUT_STEREO lại định nghĩa là: #define AV_CH_LAYOUT_STEREO (AV_CH_FRONT_LEFT|AV_CH_FRONT_RIGHT) Với AV_CH_FRONT_LEFT 0x00000001 AV_CH_FRONT_RIGHT 0x00000002 Khi thực phép toán “or” ta giá trị 0x00000003 Vậy điều có nghĩa gì? FFMPEG định nghĩa rằng, số lượng bit tương ứng với với giá trị layout với số kênh có layout Do 0x00000003 biểu diễn hai bit 1, số kênh Tuy nhiên để SDL gọi đến hàm audio_callback() tự động cần phải gọi hàm SDL_PauseAudio() với đối số sau gọi hàm SDL_OpenAudio() Hàm audio_callback() có ba tham số void *userdata, Uint8 *stream, int len Ở đây, userdata cấu trúc VideoState định nghĩa stream trỏ, trỏ tới đệm âm Bộ đệm chứa liệu âm phát loa len tham số kích thước đệm âm trên, len SDL tính toán tự đặt vào hàm audio_callback() liệu âm ta cần phải tự giải mã đặt vào đệm âm Việc thực thông qua lời gọi hàm audio_decode_frame() Trong hàm audio_decode_frame(), gói packet lấy từ hàng đợi audioq nhờ hàm packet_queue_get() Gói packet đặt vào biến pkt có kiểu AVPacket Sau đó, lời gọi hàm avcodec_decode_audio4(is→audio_st→codec, &is→audio_frame, &got_frame, pkt) thực để giải mã gói tin packet biến pkt Các đối số truyền vào theo thứ tự bao gồm thông tin codec dùng để giải mã, AVFrame dùng để lưu trữ liệu giải mã got_frame biến để kiểm tra xem trình giải mã có thành công hay không, không thành công có giá trị pkt liệu cần giải mã Dữ liệu thô sau giải mã thực downsampling, downmixing thư viện libswresample cung cấp thư viện FFMPEG Downsampling có nghĩa giảm tốc độ lấy mẫu âm ban đầu xuống Ví dụ với tập tin nhạc có tốc độ lấy mẫu 48kHz sau thực downsampling xuống 44.1kHz Còn downmixing thực giảm số kênh, ví dụ với chuẩn âm 5.1 có kênh định nghĩa libavutil/channel_layout.h giảm xuống kênh ứng với chuẩn âm stereo Dữ liệu âm cuối đưa vào đệm tạm thời có tên audio_buf hàm audio_decode_frame() Sau thực xong thao xử lý liệu hàm audio_decode_frame(), hàm audio_callback() thực chép chép liệu từ đệm audio_buf vào đệm trỏ tới trỏ stream hàm audio_callback() Đây đệm mà SDL dùng để phát âm loa Footer Page 55 of 113 45 Header Page 56 of 113 3.3.5 Đồng hình ảnh âm Trong tập tin video, với hình ảnh có giá trị gọi presentation timestamp (pts) Giá trị xác định thời điểm mà hình ảnh hiển thị hình Với hình ảnh đầu tiên, ta hiển thị sau giải mã xong Tuy nhiên từ hình ảnh tiếp theo, phải xác định giá trị trễ để hình ảnh hiển thị sau đồng Trước hết cần phải xác định giá trị pts hình ảnh Giá trị lấy thông qua hàm av_frame_get_best_effort_timestamp() với đối số AVFrame, AVFrame thu cách giải mã gói tin video nói phần “3.3.3 Hiển thị hình ảnh video” Giá trị pts với hình ảnh tương ứng đưa vào hàng đợi VideoPicture Hàm video_refresh_timer() làm nhiệm vụ tính giá trị trễ hai hình ảnh hiển thị Sau từ hàm video_refesh_timer() gọi đến hàm schedule_refresh() để thực tạo trễ Sau khoảng thời gian trễ hình ảnh hiển thị hình lời gọi hàm video_display() Đối với âm thanh, mẫu âm tái tạo lại cần phải có tần số lấy mẫu số mẫu giống thông tin âm tập tin video Tuy nhiên hình ảnh âm chưa thực khớp với cần phải thay đổi thêm Footer Page 56 of 113 46 Header Page 57 of 113 CHƯƠNG Thực nghiệm kết đạt 4.1 Thực nghiệm chương trình AtomPlayer Sau xây dựng chương trình AtomPlayer, chương trình thực nghiệm để đo lường hiệu phương pháp Atom Header Caching thiết bị động Các thức thực nghiệm thực sau: - Chuẩn bị máy chủ VPS có hỗ trợ giao thức atomcaching [12] Tiến hành đo thời gian bắt đầu 04 tập tin video có thông số kỹ thuật bảng Với video, đo tương ứng có sử dụng AHC không sử dụng AHC Với tập tin video thực lần đo, sau lấy giá trị trung bình lần đo Thông số kỹ thuật tập tin video Tên tập tin video VideoT est1_4 mp4 VideoT est2_20 mp4 VideoT est3_60 mp4 VideoT est4_12 0.mp4 Mã hóa video Độ phân giải video Bitrate video (kbps) Tốc độ Mã hóa khung âm hình (fps) Bitrate âm (kbps) Tần số lấy mẫu Số kênh Thời âm âm lượng thanh (phút) (KHz) H264 640x360 712 23 aac 96 44.1 H264 720x404 764 23 aac 109 48 20 H264 1280x72 1646 25 aac 192 44.1 60 H264 1280x72 1760 25 aac 192 44.1 120 Hình 22 Bảng thông số video sử dụng để thực nghiệm Dựa theo khuyến nghị tốc độ kết nối internet dùng để xem video trực tuyến Netflix [20] Ba kịch sau thiết lập để đánh giá thực nghiệm chương trình AtomPlayer hỗ trợ AHC thiết bị di động Kịch thứ nhất: Giới hạn tốc độ kết nối phía máy chủ xuống 1.5 Mbps Tốc độ kết nối tối thiểu khuyến nghị Kịch thứ hai: Thiết lập tốc độ kết nối phía máy chủ mức 3.0 Mbps tương ứng với video xem chất lượng SD Footer Page 57 of 113 47 Header Page 58 of 113 Kịch thứ ba: Thiết lập tốc độ kết nối phía server mức 5.0 Mbps tương ứng với việc xem video chất lượng HDBảng thể rõ kích thước atom header cắt từ tập tin video để áp dụng AHC Kích thước Atom Header 68 KB 588 KB 1.1 MB 2.2 MB Tập tin video VideoTest1_4.mp4 VideoTest2_20.mp4 VideoTest3_60.mp4 VideoTest4_120.mp4 Hình 23 Bảng thông số kích thước tập tin atom header Có thể thấy rõ rằng, với tập tin video có thời lượng dài kích thước Atom Header lớn Kịch thứ nhất, biểu đồ thể thời gian bắt đầu video tương ứng với tốc độ kết nối 1.5 Mbps sử dụng AHC không sử dụng AHC (đơn vị tính: giây) So sánh thời gian bắt đầu - 1.5 Mbps Tốc độ kết nối: 1.5 Mbps có AHC Tốc độ kết nối: 1.5 Mbps không AHC VideoTest4_120.mp4 VideoTest3_60.mp4 VideoTest2_20.mp4 VideoTest1_4.mp4 Tốc độ kết nối: 1.5 Mbps có AHC Tốc độ kết nối: 1.5 Mbps không AHC 10 12 14 VideoTest1_4.mp VideoTest2_20.m VideoTest3_60.m VideoTest4_120 p4 p4 mp4 1.8109224 2.267984 3.4627088 4.7948142 1.7577424 4.595794 7.4968956 12.7568294 ĐƠN VỊ TÍNH: GIÂY 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 Footer Page 58 of 113 48 Header Page 59 of 113 Biểu đồi thu sau thực kịch thứ 2, ứng với tốc độ kết nối 3.0 Mbps sử dụng AHC không sử dụng AHC (đơn vị tính: giây) So sánh thời gian bắt đầu - 3.0 Mbps Tốc độ kết nối: 3.0 Mbps có AHC Tốc độ kết nối: 3.0 Mbps không AHC VideoTest4_120.mp4 VideoTest3_60.mp4 VideoTest2_20.mp4 VideoTest1_4.mp4 VideoTest1_4.mp VideoTest2_20.m VideoTest3_60.m VideoTest4_120 p4 p4 mp4 1.535759 1.8433538 2.7476058 3.0300212 Tốc độ kết nối: 3.0 Mbps có AHC Tốc độ kết nối: 3.0 Mbps không AHC 1.3860906 2.8453032 4.7990448 6.6214484 ĐƠN VỊ TÍNH: GIÂY 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 Bảng thể kết thực nghiệm chương trình AtomPlayer với tốc độ kết nối 5.0 Mbps tới máy chủ sử dụng AHC không sử dụng AHC (đơn vị tính: giây) So sánh thời gian bắt đầu - 5.0 Mbps Tốc độ kết nối: 5.0 Mbps có AHC Tốc độ kết nối: 5.0 Mbps không AHC VideoTest4_120.mp4 VideoTest3_60.mp4 VideoTest2_20.mp4 VideoTest1_4.mp4 Tốc độ kết nối: 5.0 Mbps có AHC Tốc độ kết nối: 5.0 Mbps không AHC 0.5 1.5 2.5 3.5 VideoTest1_4.mp VideoTest2_20.m VideoTest3_60.m VideoTest4_120 p4 p4 mp4 1.5861184 1.8395264 2.407983 2.5931036 1.3208256 1.9321874 3.1134164 3.7644622 ĐƠN VỊ TÍNH: GIÂY 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 Footer Page 59 of 113 49 Header Page 60 of 113 4.2 Kết thực nghiệm Từ kết phần “4.1 Thực nghiệm chương trình AtomPlayer”, ta thấy thời gian bắt đầu video sử dụng phương pháp Atom Header Caching cho hiệu rõ rệt Tuy nhiên có trường hợp ngoại lệ tập tin VideoTest1_4.mp4, thời gian bắt dầu video sử dụng AHC lại cao so với không sử dụng AHC (khoảng 0.2 giây) Vì tập tin video có độ dài phút, kích thước atom header nhỏ, khoảng 68 KB Với tập tin có thời lượng thấp tính hiệu phương pháp AHC không nhìn thấy rõ rệt kích thước tập tin atom header nhỏ Tuy nhiên tập tin video khác đo kịch thể rõ tính hiệu phương pháp AHC Cụ thể là: - - - Đối với kịch thứ nhất, tốc độ kêt nối 1.5 Mbps có sử dụng AHC, cho thấy tập tin VideoTest2_20.mp4, VideoTest3_60.mp4 VideoTest4_120.mp4 có thời gian trễ chênh lệch bắt đầu thấp 2.32, 4.04 12.76 giây so với không sử dụng AHC Đối với kịch thứ hai, tốc độ kêt nối 3.0 Mbps có sử dụng AHC, cho thấy tập tin VideoTest2_20.mp4, VideoTest3_60.mp4 VideoTest4_120.mp4 có thời gian trễ chênh lệch bắt đầu 1.00, 2.05 3.59 giây so với không sử dụng AHC Đối với kịch thứ ba, tốc độ kết nối 5.0 Mbps có sử dụng AHC, cho thấy tập tin VideoTest2_20.mp4, VideoTest3_60.mp4 VideoTest4_120.mp4 có thời gian trễ chênh lệch bắt đầu 0.09, 0.71 1.17 giây so với không sử dụng AHC Nhìn chung, với video có độ dài trung bình, lớn phương pháp AHC mang lại hiệu lớn việc giảm thời gian trễ bắt đầu streaming video qua mạng internet Footer Page 60 of 113 50 Header Page 61 of 113 KẾT LUẬN Trên đây, qua trình tìm hiểu nghiên cứu, khóa luận đạt kết quả: - Tìm hiểu kiến thức internet video streaming phương pháp hỗ trợ video streaming qua giao thức HTTP sử dụng phổ biến Chuyển đổi thành công chương trình xem video máy tính cá nhân truyền thống sang thiết bị điện thoại thông minh Xây dựng giao diện người dùng đơn giản cho chương trình AtomPlayer Thực chế cache atom header để tối ưu hóa phương pháp AHC thiết bị điện thoại thông minh Thông qua thực nghiệm đánh giá tính hiệu phương pháp AHC thực thiết bị di động Bên cạnh điều đạt được, khóa luận số hạn chế như: - - Trong trình chuyển đổi chương trình AtomPlayer sang thiết bị di động phần đồng âm hình ảnh chưa thật tốt Cơ chế cache atom header đơn giản chưa đánh giá tính hiệu chế Cần phải có nghiên cứu sâu để chế cache atom header tốt áp dụng cho phương pháp AHC thiết bị điện thoại thông minh Giao diện người dùng đơn giản chưa thật thân thiện với người dùng Tuy nhiên, chương trình AtomPlayer trình hoàn thiện, để tương lai không xa có chương trình chơi video hỗ trợ AHC hoàn thiện từ giao diện, chức chế cache atom header hiệu Từ hướng tới hệ điều hành cho thiết bị di động khác, ứng dụng thiết bị giải trí gia đình Footer Page 61 of 113 51 Header Page 62 of 113 TÀI LIỆU THAM KHẢO [1] Apple Inc, "HTTP Live Streaming Overview", 2014 [2] Alex, ZAMBELLI "IIS smooth streaming technical overview" Microsoft Corporation, 2009 [3] Alex, ZAMBELLI "A history of media streaming and the future of connected TV" The Guardian, 2013 [4] BELSON, David "Akamai state of the Internet report, q1 2014", pp.14, 39 [5] CAO, Pei; IRANI, Sandy "Cost-Aware WWW Proxy Caching Algorithms" Usenix symposium on internet technologies and systems 1997 pp 193-206 [6] CARLA, MARSHALL "33 amazing youtueb facts & stats to tweet & share", reelseo, 2014 [7] FIELDING, Roy "Hypertext transfer protocol–HTTP/1.1, 1999" RFC2616, 2006 [8] INDEX, Cisco Visual Networking "Forecast and Methodology, 2010–2015", 2011 [9] ISO/IEC, “14496-12 Information technology — Coding of audio-visual objects — Part 12: ISO base media file format”, 2012 [10] ISO/IEC, “14496-14 Information technology — Coding of audio-visual objects — Part 14: MP4 file format”, 2003 [11] MILLER, P "SVP/GM Digital Media at NBC Sports", keynote 2009 [12] Nguyen Tien Nam; Hoang Xuan Tung, “Optimizing video streaming over internet using header caching for reducing start-up time in mp4 video streaming applications”, master's thesis, 2014 [13] RESCORLA, Eric "Http over tls" 2000 [14] SCHULZRINNE, Henning "Real time streaming protocol (RTSP)" 1998 [15] SODAGAR, Iraj "The MPEG-DASH Standard for Multimedia Streaming Over the Internet" IEEE Multimedia, 2011, 18: 62-67 [16] Sorenson Media, Mp4 is the king of formats, 2012 [17] http://dranger.com/ffmpeg/ [18] http://en.wikipedia.org/wiki/Video [19] http://www.videolan.org/developers/x264.html [20] https://help.netflix.com/en/node/306 [21] https://www.ffmpeg.org/ [22] https://www.libsdl.org/ Footer Page 62 of 113 52 .. .Header Page of 113 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ Nguyễn Tiến Thành 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 KHÓA... (phục vụ cho streaming video trực tuyến) Smooth Streaming (phục vụ cho streaming video theo yêu cầu) IIS Media Servcies dịch vụ cunng cấp tính an toàn, co dãn, dễ quản lý website động, ứng dụng, dịch. .. có video streaming dựa HTTP-based adaptive streaming Gồm Smooth Streaming, HLS MPEGDASH Đồng thời giới thiệu phương pháp đề xuất Atom Header Caching Phần 3: Thực Atom Header Caching tảng hệ điều