Kiến trúc DASH đƣợc tạo thành bởi:
- Các thành phần phía máy chủ (DASH server) - Các thành phần phía máy khách (DASH client)
Trong đó, các khối màu đen trong hình trên là những thành phần bắt buộc phải tuân theo đặc tả về các thành phần này của DASH. Còn những khối màu trắng là những thành phần không bắt buộc phải tuân theo đặc tả của DASH. Các khối màu khác là các thành phần tuân theo các đặc tả khác, không phải của DASH. Máy chủ và máy khách DASH tuân thủ theo quy định một về một máy chủ/máy khách tại RFC 2616 [13].
Máy khách DASH sử dụng các gói tin HTTP GET hoặc HTTP yêu cầu phạm vi byte theo quy định tại RFC 2616 để truy cập tới các phân đoạn dữ liệu đa phƣơng tiện trên máy chủ DASH (chính là các khối có màu khác trong hình trên). Có thể sử dụng giao thức HTTPS trong việc phân phối nội dung dữ liệu đa phƣơng tiện trong kiến trúc DASH.
Dữ liệu đa phƣơng tiện trên máy chủ DASH gồm 2 phần:
- Tệp tin mô tả trình bày phƣơng tiện truyền thông (Media presentation description MPD)
- Định dạng phân đoạn (Segment format)
Tệp tin mô tả trình bày phƣơng tiện truyền thông (Media presentation description MPD):
MPD là một tệp tin XML, mô tả chỉ mục của tập tin dữ liệu đa phƣơng tiện, địa chỉ URL, các phân đoạn, các đoạn, và các đặc điểm khác của tập tin này.
Hình 2.4: Cấu trúc tệp tin trình bày phương tiện truyền thông của DASH
Hình vẽ 2.4 mô tả sự phân cấp của dữ liệu trong tệp tin MPD. MPD bao gồm một hoặc nhiều giai đoạn (period). Mỗi giai đoạn là một khoảng thời gian của tệp tin dữ liệu đa phƣơng tiện, bao gồm thông tin về thời gian bắt đầu và kết thúc của đoạn dữ liệu và ngoài ra còn chứa thông tin về các bộ thích ứng của đoạn dữ liệu nằm trong tệp tin dữ liệu đa phƣơng tiện đó.
Một bộ thích ứng (Adaptation set) cung cấp thông tin về một đoạn của dữ liệu truyền thông đa phƣơng tiện và các phần đƣợc mã hóa với tốc độ bit khác nhau của đoạn này. Ví dụ nhƣ trên hình, bộ thích ứng 1 chứa thông tin về đoạn với thời gian bắt đầu tại giây thứ 60. Đoạn này đƣợc mã hóa ở các tốc độ bit khác nhau lần lƣợt là 5 Mbps, 2Mbps, 500 kbps, trick mode tạo thành 4 đoạn với cùng một nội dung nhƣng khác nhau về tốc độ bit. Trong mỗi đoạn đó lại chứa thông tin về các đoạn nhỏ hơn (thời gian bắt đầu, đƣờng link trực tiếp tới đoạn trên máy chủ,…)
Định dạng phân đoạn (Segment format):
Nội dung của tệp tin video có thể đƣợc chia thành một tập hợp các phân đoạn. Mỗi phân đoạn đƣợc định nghĩa là phần dữ liệu thực tế của gói tin trả lời mà máy khách nhận đƣợc sau khi yêu cầu dữ liệu sử dụng HTTP GET hoặc HTTP GET theo phạm vi byte.
Các dòng của dữ liệu truyền thông đƣợc chia thành một hoặc nhiều đoạn liên tiếp. Mỗi đoạn của phƣơng tiện truyền thông đƣợc gán cho một “url” duy nhất (có thể có chứa thông tin về phạm vi byte), một chỉ số, và thời gian bắt đầu.
- Định dạng phân đoạn theo định dạng tệp tin dữ liệu truyền thông đa phƣơng tiện cơ sở (ISO Base Media File Format) nhƣ định nghĩa tại ISO/IEC 14496-12 (MP4 fragmented)
- Định dạng phân đoạn MPEG-2 Transport Stream nhƣ định nghĩa tại ISO/IEC 13818-2 Format
2.2.3 Giao thức Microsoft Smooth Streaming
Microsoft Smooth Streaming [15]là một giao thức truyền thông dữ liệu đa phƣơng tiện đƣợc Microsoft đề xuất (2008) và phát hành lần đầu tiên nhƣ một phần mở rộng cho IIS 7.0.
Microsoft Smooth Streaming sử dụng video định dạng MP4 (MPEG-4 Part 12 ISO/IEC 14496-12:2008) cho việc lƣu trữ và truyền thông dữ liệu đa phƣơng tiện. Đặc biệt, Smooth Streaming định nghĩa đặc điểm kỹ thuật cho mỗi đoạn nhỏ „chunk‟ có cấu trúc nhƣ một đoạn MP4 phân mảnh (MP4-movie fragment) và lƣu trữ tất cả các „chunk‟ đó trong một tập tin MP4 trên đĩa. Các tập tin MP4 nhỏ của cùng một tệp tin dữ liệu đa phƣơng tiện sẽ có tốc độ bit khác nhau.
Hình 2.5: Cấu trúc định dạng tệp tin MP4 dùng cho Microsoft Smooth Streaming
Khi một khách hàng yêu cầu một đoạn ở thời gian cụ thể của tệp tin MP4 nguồn, máy chủ sẽ tự động tìm kiếm đoạn phù hợp từ tập tin MP4 đó (tập tin này đang đƣợc lƣu trữ thực tế trên đĩa) và gửi đoạn đó nhƣ một tập tin độc lập cho khách hàng. Chính vì vậy, đối với Smooth streaming, các đoạn đƣợc tạo ra theo mỗi yêu cầu của khách hàng, và tệp tin video MP4 thực tế đƣợc lƣu trữ trên đĩa là tập tin có độ dài đầy đủ theo từng tốc độ bit.
Smooth Streaming sử dụng “.isma” và “.ismv” làm hai phần mở rộng của tập tin MP4.
- Phần mở rộng “.ismv” sử dụng cho tập tin video (có thể có âm thanh), mỗi một tệp tin ismv đƣợc mã hóa với 1 tốc độ bit của video.
- Phần mở rộng “.isma” sử dụng cho tập tin âm thanh. Trong các video có chứa âm thanh, các track âm thanh sẽ đƣợc ghép vào tập tin .ismv, thay vì tạo ra một tập tin .isma riêng biệt.
Smooth Streaming sử dụng 2 tập tin chỉ mục cho mỗi tệp tin video.
Tập tin chỉ mục của máy chủ sử dụng phần mở rộng “.ism”, mô tả mối quan hệ giữa các track của dữ liệu truyền thông đa phƣơng tiện, tốc độ bit và thông tin các tệp tin trên đĩa. Các tập tin chỉ mục này chỉ đƣợc sử dụng bởi máy chủ smooth streaming, các máy khách không đƣợc quyền truy cập tới các tập tin này.
Tập tin chỉ mục của ngƣời dùng cũng sử dụng phần mở rộng “.ism”, mô tả các dòng sẵn có cho máy khách, các codec đƣợc sử dụng, tốc độ bit đã đƣợc dùng để mã hóa, độ phân giải video, ghi chú,... Đây cũng là tập tin phân phối đầu tiên cho máy khách. Các tập tin chỉ mục của máy chủ và ngƣời dùng đều tuân theo định dạng XML.
2.2.4 Giao thức HLS
HTTP Live Streaming [16] (HLS) là một giao thức truyền thông dữ liệu đa phƣơng tiện đƣợc đề xuất bởi Apple Inc vào năm 2009. HLS sử dụng video định dạng MPEG-2 Transport Stream.
Hình 2.7: Các thành phần và hoạt động của HLS
Giải pháp HLS bao gồm 3 thành phần: ứng dụng khách hàng, thành phần máy chủ và thành phần phân phối.
- Thành phần máy chủ gồm nhiều ứng dụng có nhiệm vụ xử lý các dòng phƣơng tiện truyền thông đầu vào và mã hóa chúng, sau đó đóng gói thành một định dạng phù hợp để phân phối.
- Các thành phần phân phối bao gồm: hệ thống máy chủ web tiêu chuẩn, có trách nhiệm đáp ứng yêu cầu của các khách hàng và phân phối dữ liệu đa phƣơng tiện tới khách hàng, ngoài ra đối với một một hệ thống phân phối quy mô lớn, các hệ thống mạng cạnh (edge networks) hoặc các hệ thống phân phối nội dung (Content delivery network CDN) có thể đƣợc kết hợp sử dụng.
- Các ứng dụng khách hàng chịu trách nhiệm xác định các dữ liệu đa phƣơng tiện phù hợp với yêu cầu của ngƣời dùng, tải về các dòng dữ liệu đa phƣơng tiện đƣợc phân phối từ máy chủ, sau đó ghép chúng lại sao cho các dòng này đƣợc trình chiếu cho ngƣời sử dụng nhƣ một dòng liên tục.
Các ứng dụng trên máy chủ:
- Ứng dụng mã hóa dữ liệu đa phƣơng tiện (media encoder) có nhiệm vụ xử lý các tín hiệu đầu vào đƣợc cung cấp từ các thiết bị ghi âm thanh, hình ảnh kỹ thuật số sau đó mã hóa và đóng gói các dữ liệu này để phục vụ cho việc truyền tải. Hiện nay định dạng dùng để phân phối khi sử dụng HLS là MPEG-2 Transport Streams. Ứng dụng mã hóa dữ liệu đa phƣơng tiện sẽ phân phối các dữ liệu đƣợc mã hóa trong các dòng MPEG-2 Transport Streaming qua hệ thống mạng nội bộ cho ứng dụng stream segmenter.
- Ứng dụng stream segmenter trên máy chủ có nhiệm vụ đọc các dòng dữ liệu đƣợc truyền tải trên hệ thống mạng nội bộ sau đó chia nhỏ thành một loạt các tập tin nhỏ. Ứng dụng này cũng tạo ra tập tin chỉ mục (Index file) chứa thông tin tham chiếu đến các tập tin. Mỗi lần ứng dụng stream segmenter tạo ra
một tập tin phƣơng tiện truyền thông mới từ các dòng đƣợc truyền tải, tập tin chỉ mục sẽ đƣợc cập nhật lại.
Hình 2.8 : Định dạng tập tin chỉ mục của HLS
Nhƣ trên hình vẽ, một tập tin chỉ mục của HLS (phần mở rộng m3u8) sẽ chứa 3 thông tin chỉ mục con bên trong. 3 thông tin chỉ mục con này lần lƣợt tham chiếu đến các đoạn có tốc độ bit cao, vừa, và thấp của tập tin dữ liệu đa phƣơng tiện.
3.1 Động cơ của đề xuất
Thời gian bắt đầu (start up time) của video định dạng MP4 khi streaming là lớn, do tại bƣớc đầu tiên của quá trình streaming, phần mềm play dữ liệu đa phƣơng tiện tại máy khách phải tiến hành tải về toàn bộ nội dung atom header của tệp tin video và xử lý phần nội dung này trƣớc khi gửi tiếp các yêu cầu lấy dữ liệu video thực sự (phần dữ liệu atom MDAT).
Đối với các tệp tin video định dạng MP4 có thời lƣợng ngắn, phần nội dung atom header này nhỏ, nhƣng với các tệp tin video định dạng MP4 thời lƣợng dài, phần nội dung atom header này khá lớn. Điều này dẫn tới việc tải về toàn bộ nội dung atom header mất khá nhiều thời gian, và trực tiếp làm tăng thời gian bắt đầu của video định dạng MP4 khi streaming.
Thời gian bắt đầu của video lớn sẽ ảnh hƣởng đến tâm lý của ngƣời dùng khi sử dụng các ứng dụng streaming video. Thời gian bắt đầu lớn làm cho ngƣời dùng cảm thấy khó chịu và có thể sẽ chuyển sang sử dụng dịch vụ của các nhà cung cấp khác hoặc chuyển sang nội dung video khác.
Ngoài ra các phƣơng pháp, giao thức streaming video giới thiệu ở chƣơng II vẫn chƣa tối ƣu đƣợc thời gian bắt đầu của định dạng video MP4, chƣa tận dụng đặc điểm của định dạng MP4 giúp giảm thời gian bắt đầu khi streaming định dạng video này. Hơn nữa các giao thức streaming nhƣ HLS, Microsoft Smooth Streaming, MPEG-DASH tiến hành chia tệp tin video thành nhiều tập tin nhỏ với thời gian ngắn làm cho số lƣợng các tập tin nhỏ này trên máy chủ streaming rất lớn, gây khó khăn cho việc quản lý. Đồng thời máy khách (client) phải tải về trƣớc tập tin chỉ mục của video làm cho thời gian bắt đầu khi streaming video chƣa đƣợc tối ƣu.
Chính vì vậy tác giả đề xuất phƣơng pháp Atom Caching nhằm giảm thời gian bắt đầu cho các ứng dụng streaming định dạng này. Ý tƣởng chính của Atom Caching là thực hiện chủ động lấy trƣớc các thông tin header của các tệp tin video trên máy chủ ngay cả khi ngƣời dùng chƣa thực sự thực hiện thao tác xem video. Các nội dung header này đƣợc cache lại trong ứng dụng máy khách để sẵn sàng phục vụ cho một phiên xem lại nội dung video stream từ trên máy chủ dịch vụ. Sự sẵn sàng của các thông tin header này sẽ giúp giảm đáng kể thời gian trễ khởi động (start up time). Giá phải trả cho ƣu điểm đó là máy khách phải tốn một phần dung lƣợng lƣu trữ cũng nhƣ năng lực tính toán để phục vụ cho việc lấy trƣớc thông tin header.
3.2 Mô hình hoạt động của Atom Caching
Hình 3.1: Mô hình hoạt động của phương pháp đề xuất
Hệ thống Atom Caching hoạt động dựa trên mô hình máy chủ-máy khách. Bao gồm hai phần: các ứng dụng tại máy chủ MP4_atom_caching (máy chủ streaming), và các ứng dụng tại máy khách MP4_atom_caching (máy khách streaming). Trên hình vẽ 3.1, những phần có màu khác màu trắng là những phần liên quan trực tiếp và quan trọng trong phƣơng pháp đề xuất của tác giả, còn những phần có màu trắng là những phần hỗ trợ cho phƣơng pháp Atom Caching đƣợc đề xuất.
Ban đầu, các tập tin video định dạng MP4 đƣợc các phần mềm tại máy khách upload lên khu vực “Publishing area” của máy chủ MP4_atom_caching (Mp4_atom_caching server), máy chủ streaming sẽ liên tục tiến hành chia tách mỗi video nằm trong “publising area” thành 2 tệp tin nhỏ hơn: tệp tin atom header và tệp tin MDAT sau đó đẩy 2 tệp tin này vào khu vực “Public area” của máy chủ Mp4_atom_caching.
Khi ngƣời dùng (Mp4_atom_caching client) có nhu cầu xem một video đang có trên máy chủ Mp4_atom_caching, phần mềm phía máy khách sẽ tiến hành kiểm tra xem trong cache của máy khách đã có tệp tin atom header của video đó chƣa. Nếu trên cache của máy khách đã có tệp tin atom header của video đó, thì phần mềm play dữ liệu đa phƣơng tiện tại máy khách (Player) sẽ chỉ tiến hành yêu cầu lấy nội dung của tệp tin MDAT của video đó từ khu vực “Public area” của máy chủ Mp4_atom_caching và trình chiếu nội dung video
cho ngƣời dùng. Nếu trên cache của máy khách chƣa có tệp tin atom header của video đó, thì Player sẽ tiến hành yêu cầu lấy nội dung của của hai tệp tin: atom header và MDAT của video đó từ khu vực “Public area” trên máy chủ Mp4_atom_caching và sau đó trình chiếu nội dung video cho ngƣời dùng.
Thời gian bắt đầu của một video sẽ giảm xuống nếu tại cache của máy khách đã có sẵn tệp tin atom header của video đó.
Quá trình Prefetching:
Ứng dụng tại máy khách sẽ chủ động tiến hành lấy trƣớc dữ liệu atom header của video và lƣu trữ tại ứng dụng phía máy khách (Prefetching). Quá trình này đƣợc thực hiện khi máy khách rảnh rỗi hoặc trong quá trình đang play một video khác.
Số lƣợng các atom header của video đƣợc cache và thời điểm lấy trƣớc atom header của các video này do ngƣời sử dụng tự cấu hình hoặc sẽ đƣợc thiết lập mặc định tùy thuộc vào bộ nhớ thiết bị của ngƣời dùng và việc dự đoán nhu cầu sử dụng của ngƣời dùng đối với các video.
3.3 Các thành phần trên máy chủ MP4_atom_caching
Hình 3.2: Các thành phần trên máy chủ MP4_atom_caching
Máy chủ Mp4_atom_caching có 3 dịch vụ chạy ở chế độ thƣờng trực (daemon):
- Dịch vụ upload video: dịch vụ này có nhiệm vụ tiếp nhận các video do ngƣời dùng upload lên “Publishing area” của máy chủ MP4_atom_caching.
- Dịch vụ Mp4_atom_caching: dịch vụ này có 2 nhiệm vụ chính: + Giám sát các video tệp tin đƣợc upload lên máy chủ.
+ Tiến hành chia tách mỗi video thành 2 tệp tin: một tệp tin atom header và một tệp tin MDAT sau đó đẩy 2 tệp tin này vào thƣ mục “Publish area” của máy chủ MP4_atom_caching.
- Dịch vụ phân phối video: dịch vụ này sẽ tiến hành streaming các tệp tin trong khu vực “Publish area” của máy chủ MP4_atom_caching cho các máy khách khi nhận đƣợc yêu cầu hợp lệ phía máy khách.
3.3.1 Hoạt động của máy chủ MP4_atom_caching
Hoạt động của máy chủ MP4_atom_caching chủ yếu dựa vào hoạt động của 3 dịch vụ:
- Dịch vụ upload video.
- Dịch vụ Mp4_atom_caching. - Dịch vụ phân phối video.
3.3.1.1 Hoạt động của dịch vụ upload video
Hình 3.3 : Hoạt động của dịch vụ upload video
Dịch vụ upload video sẽ hoạt động thƣờng trực và luôn lắng nghe, đáp ứng các yêu cầu của các khách hàng. Sau khi ứng dụng phía máy khách đã kết
nối tới dịch vụ upload video, dịch vụ upload video cho phép các ứng dụng này
có quyền upload tệp tin với định dạng quy định trƣớc (MP4) lên vùng “Publishing area” của máy chủ streaming.
“Publishing area” sẽ là khu vực chứa toàn bộ các video MP4 do các ứng dụng tại máy khách upload lên máy chủ MP4_atom_caching.
Quá trình upload video có thể sử dụng các giao thức truyền tải nội dung nhƣ FTP, HTTP, HTTPS…
3.3.1.2 Hoạt động của dịch vụ MP4_atom_caching
Dịch vụ MP4_atom_caching cũng là một dịch vụ hoạt động thƣờng trực. Khi hoạt động, dịch vụ MP4_atom_caching bao gồm 2 process hoạt động đồng thời (M_process và S_process).
M_process và S_process cùng xử lý một hàng đợi dạng vòng (Q_ring) đƣợc chia sẻ trong bộ nhớ chung của các tiến trình. Q_ring dùng để chứa thông tin các tệp tin video MP4 đã đƣợc các máy khách upload lên máy chủ