Tài liệu Xây dựng hệ thống digital video transport system (dvts) truyền video chất lượng cao

-1- Lời nói đầu Sự xuất hiện và phát triển của internet tới ngày này đã làm thay đổi hoàn toàn thế giới bởi những đóng góp to lớn của nó. Với những ngày đầu nó chỉ phục vụ cho mục đích quốc phòng của Mỹ vào cuối năm 1960 có tên là ARPANET, qua những năm phát triển sau đó internet được lan rộng và phục vụ cho mục đích dân sự. Với khả năng kết nối mở, Internet đã trở thành một mạng lớn nhất trên thế giới, mạng của các mạng, chúng giao tiếp với nhau qua giao thức. Bởi chính tiện ích internet mang lại, do đó nhiều doanh nghiệp muốn triển khai định hướng kinh doanh trên internet để cung cấp các sản phẩm, dịch vụ cần thiết cho người dùng. Bên cạnh đó một số trường đại học, viện nghiên cứu, cũng cho ra đời nhiều ứng dụng giúp ích cho con người thuận tiện trong việc trao đổi thông tin từ xa. Hội nghị truyền hình trực tiếp là một ứng dụng cụ thể cho thành tựu nghiên cứu của trường đại học Keio, Nhật Bản chạy trên môi trường mạng. khắc phục khó khăn về mặt địa lí cũng như tiết kiệm thời gian và chi phí. Với kỹ thuật mới, ứng dụng giúp trao đổi giữa hai đầu truyền hình đạt chất lượng cao. Tại các bệnh viện, hội chẩn đoán bệnh từ xa nhận ý kiến, thảo luận từ những bác sĩ giỏi trên thế giới qua cầu truyền hình, đưa ra phương pháp tối ưu nhất cho việc điều trị. Hội nghị này tạo điều kiện cho nhiều đơn vị, tổ chức, bệnh viên trao đổi kinh nghiệm, thắt chặt mối liên kết toàn cầu cùng nghiên cứu đưa ra giải pháp trong y khoa . Ngoài ra phục vụ cho các chương trình học từ xa và nhiều ứng dụng hơn nữa. Do sự phát triển ngày càng mạnh mẽ của khoa học và công nghệ tạo ra nhiều ứng dụng trong thực tiễn, chính vì vậy mô hình này cần chú trọng, nghiên cứu và phát triển lan rộng hơn nữa trong tương lai. -2- Chương 1: Tổng quan về hệ thống DVTS 1.1. Hội nghi truyền hình(video conferencing) Để có cuộc hội nghị, hội thảo, diễn đàn từ xa thì một trong những điều kiện không thể thiếu đó là cần phải có sự hỗ trợ của các phương tiện, thiết bị và công nghệ. Sử dụng các thiết bị chuyên dụng dành cho Hội nghị truyền hình (Video Conferencing) là một trong những giải pháp hữu hiệu. Tuy nhiên, thiết bị dành cho hội nghị truyền hình có giá thành cao, không phải đơn vị nào cũng có thể tự mua sắm riêng một bộ, số điểm truy cập từ xa cũng bị hạn chế, việc cài đặt, sử dụng phần mềm điều khiển cần được đào tạo hướng dẫn một thời gian khá dài trước khi có thể sử dụng thành thạo các thiết bị chuyên dụng đó. Một giải pháp đơn giản và hiệu quả hơn được sử dụng phổ biến hiện nay ở nhiều Mạng Nghiên cứu và Đào tạo Quốc gia (NREN) ở các nước khác như: Hàn Quốc, Nhật Bản, Thái Lan, Trung Quốc, Đài Loan, Indonesia, Malaysia, Philippine, Úc, Tây Ban Nha…đó chính là sử dụng phần mềm Hệ thống truyền hình ảnh kỹ thuật số (Digital Video Transport System – DVTS) : Hệ thống đơn giản Kinh phí thấp Dễ sử dụng ( không cần đào tạo nhân lực) 1.2. Digital Video Transport System 1.2.1 Khái niệm Digital Video Transport System viết tắt DVTS là một phần mềm ứng dụng chạy trên đường truyền mạng máy tính 30Mbps không nén video để gửi và nhận hình ảnh, âm thanh chất lượng cao với độ trễ thấp. DVTS có thể chạy trên hệ điều hành khác nhau và hệ thống phân phối hình ảnh chất lượng bằng việc kết nối DVTS với máy tính cá nhân thông qua cổng giao tiếp IEEE1394. -3- Tổng quan DV Mode Application Support IEEE1394 output  Not support IEEE1394 output Please use HDVout tool instead!! HDV Mode Application DVTS Hình 1.1: Minh họa phần mềm DVTS Qua quá trình nghiên cứu triển khai và ứng dụng thực tiễn khi tham gia vào các diễn đàn do CanalAVIST , trường Đại học Kyushu Nhật Bản tổ chức, có thể thấy một số ưu điểm của việc sử dụng DVTS đó là: - Cài đặt phần mềm đơn giản, không mất nhiều thời gian, có thể tải phần mềm về Internet; - Giao diện đơn giản, dễ thao tác và sử dụng; - Các đơn vị thành viên, cá nhân có thể tham gia diễn đàn, hội nghị, hội thảo từ xa, đào tạo từ xa . - Hình ảnh được gửi đi và nhận đến có chất lượng cao…. - Âm thanh phải sử dụng âm li điều chỉnh âm thanh mới chất lượng tốt… - Phần mền không tự lưu trữ, việc lưu trữ phụ thuộc máy quay video. - Không tích hợp truyền text(chat). -4- - Có một khung hình nhận video. 1.2.2. Khả dụng của DVTS mang lại 1.2.2.1. Kết nối toàn cầu Thông qua đường truyền cáp quang băng thông rộng đã liên kết nhiều quốc gia và DVTS là cầu nối cho các chuyên gia cùng nhau chia sẽ thuộc nhiều phạm vi . Hình 1.2 : mô hình mạng nghiên cứu thế giới 1.2.2.2. Ứng dụng trên thế giới Phần mền DVTS ứng dụng rộng rãi: • Các trường Đại học bang Florida Sở Dance sử dụng DVTS " thực hiện hội nghị" • The New World Symphony sử dụng DVTS cho các chương trình học từ xa cho các nhạc sĩ và các lớp học thạc sĩ. • Trung tâm Excellence for Remote and Medically Under Served Areas sử dụng DVTS phục vụ cho giáo dục y tế. -5- • Nghiên cứu bệnh học tại Đại học Pennsylvania hệ thống y tế đang thử nghiệm với DVTS cho telemicroscopy. • DVTS cũng được sử dụng cho các sự kiện văn hóa khoa học, chẳng hạn như nở hoa arum Titan. 1.2.2.3. Ứng dụng mạng nghiên cứu và đào tạo VinaREN VinaREN là mạng Nghiên cứu và Đào tạo[7] Việt Nam hoạt động tháng 3-2008, mang lại nhiều lợi ích trong hoạt động nghiên cứu và đào tạo cho các đơn vị thành viên tham gia kết nối và sử dụng hệ thống DVTS. Một trong những lợi ích thiết thực và đem lại hiệu quả cao cho các thành viên đó chính là việc tổ chức tham gia vào các diễn đàn, hội nghị, hội thảo từ xa qua mạng VinaREN[2], mạng TEIN. Khi tổ chức tham gia các sự kiện, các kỹ sư công nghệ thông tin, các giáo sư, bác sĩ đến từ các trường đại học, bệnh viện trong nước như: Đại học Bách Khoa Hà Nội, Đại học Thuỷ lợi, Đại học Y Hà Nội, Đại học Huế, Bệnh viện Trung ương Quân đội 108, Học viện Quân y, Bệnh viện Bạch Mai, Bệnh viện Nhi Trung ương, Bệnh viện Việt Đức,….đã có điều kiện được phổ biến thêm những kiến thức, kỹ thuật chuyên môn mới. Thông qua việc truyền nhận hình ảnh qua DVTS, các giáo sư, bác sĩ của các bệnh viện đã có điều kiện tham gia các cuộc phẫu thuật nội soi được thực hiện trực tiếp tại các phòng mổ của các bệnh viện ở nước ngoài như: Prince of Wales Hospital, Hong Kong. Mạng VinaREN phối hợp với Bệnh viện 108 tổ chức tham gia sự kiện “International GI Endoscopy Live Demonstration” diễn ra tại Bangkok, Thailan. Tại sự kiện này, các bác sĩ của Việt Nam tiếp tục có dịp tham gia vào những ca mổ được thực hiện trực tiếp tại các phòng mổ của các bệnh viện. Ngoài ra mạng VinaREN và một số đơn vị thành viên đã cùng phối hợp tổ chức thành công khi tham gia các diễn đàn, hội nghị, hội thảo từ xa với các tổ chức, các mạng nghiên cứu và đào tạo nước ngoài như: Về E-Learning: -6- - Diễn đàn CanalAVIST – ICT Forum, ngày 31/7 và 1/8/2008. Các nước tham gia: Việt Nam, Úc, Nhật Bản, Xingapo, Thái Lan. (http://www.canalavist.org/ictforum). - Diễn đàn Asian School on Computer Science, ngày 16 và 17/11/2008. Các nước tham gia: Thái Lan, Việt Nam, Phillipin, Xingapo.( http://www.interlab.ait.ac.th/ascs/) Về Telemedicine: - Diễn đàn Medical, ngày 11 và 19/9/2008. Các nước tham gia:Việt Nam, Inđônêxia, Nhật Bản, Hàn Quốc, Malaixia, Thái Lan, Xingapo. (http://www.canalavist.org/med-forum) - Hội thảo “23rd International WorkshoponTherapeutic Endoscopy” (với phần trình diễn “Live Demonstration of Endoscopy”, tổ chức ngày 9/12/2008. Các nước tham gia: Nhật Bản, Hồng Kông, Thái Lan, Đài Loan, Việt Nam. - Hội thảo chuyên đề “Tele-lecture of Laparoscopic Colo-Rectal Surgery” tại Hội nghi APAN lần thứ 27. (www.apan.net ). 1.3 Xây dựng mục tiêu Thực hiện hội nghị truyền hình(video conferencing) thì một trong những điều kiện không thể thiếu đó là cần phải có sự hỗ trợ của các phương tiện, thiết bị và công nghệ. Sử dụng những thiết bị chuyên dụng này là một trong những giải pháp tốt. Xong bên cạnh đó không phải đơn vị nào cũng trang bị cho riêng một bộ. Từ những khó khăn trang thiết bị nêu trên, đã đưa ra giải pháp xây dựng ra hệ thống Digital Video Transport System(DVTS) có thể truyền hình ảnh, âm thanh chất lượng cao với các mục tiêu chính như sau: - Chạy trên mạng internet: - kết nối từ camera: IEEE 1394, USB 2.0 camera. - kết nối sound on board. - Truyền text(chat). - Lưu trữ video. - Xem lại video. -7- Để thực hiện những mục tiêu đề ra ta cần tới một ứng dụng máy chủ RED5 đây là một máy chủ mã nguồn mở viết bẳng ngôn ngữ java đóng vai trò làm trung gian thực hiện công việc trung chuyển hình ảnh, âm thanh. Trên máy chủ Red5 này ta tạo ra gói AppServer phản hồi các kết nối từ client, lưu trữ video và sreaming video. Ngoài ra tạo một ứng dụng Client có tên LHDVTS viết bằng ngôn ngữ Mxml + ActionScript thực hiện công việc chính truyền, hiển thị hình ảnh, âm thanh nhận từ server, chat và xem lại video. Nghiên cứu các chuẩn nén : ™ Chuẩn nén âm thanh High Efficiency AAC(HE-AAC) Hình 1.3: mô hình tích hợp chuẩn nén HE-AAC ™ Chuẩn nén hình ảnh Moving Picture Experts Group/H264(MPEG4/H264) Hình 1.4: mô hình chia nhỏ hình ảnh cosine trong MPEG-4/H264 -8- ™ Giao thức truyền thời gian thực RTMP(Real Time Messaging protocol) - RTMP chạy trên TCP với port 1935. - RTMP chạy đường hầm trên kết nối HTTP port 80. - RTMPS là RTMPT kết nối bảo mật sử dụng cho HTTPS. RTMP ở chế độ tiêu chuẩn RTMP ở chế độ đường hầm Hình 1.5: gói tin rtmp được cắt nhỏ trong các dạng đường truyền. -9- Chương 2 Mô hình hệ thống và máy chủ Red5 2.1. Mô hình hệ thống 2.1.1. Mô hình Peer to Peer Hình 2. 1: Mô hình Peer to Peer trong DVTS Mô hình Peer to Peer được sử dụng bởi một số phần mềm cung cấp dịch vụ video như Skype, DVTS, … Có nhiều giải pháp cho mô hình Peer to Peer, trong đó DTVS là một hệ thống cho phép chuyển phát hình ảnh, âm thanh giữa các nơi sử dụng mô hình này bằng địa chỉ IP Multicast (như trong hình). Ưu điểm chủ yếu của mô hình này là khả năng tận dụng các máy đầu cuối. Tuy nhiên nhược điểm của nó là không thể quản lý được người dùng nếu ở mô hình Peer to Peer truyền thống. Do đó việc áp dụng rộng rãi mô hình này gặp nhiều khó khăn cho những tổ chức nhỏ. - 10 - 2.1.2. Mô hình Client – Server Hình 2.2: Mô hình Client – Server Mô hình Client – Server là một mô hình thông dụng được sử dụng bởi các nhà cung cấp dịch vụ video nổi tiếng như Yahoo, Youtube,… • Mô hình này có nhiều ưu điểm: - Khả năng đáp ứng nhanh: người dùng có thể kết nối đến server dễ nhành để nhận được sự cung cấp dịch vụ. - Dễ dàng cho việc thi công và cung cấp dịch vụ: nhà cung cấp dịch vụ chỉ cần thiết kế server quản lý và cung cấp dịch vụ của mình. Sau đó để đưa tới tay người sử dụng thì chỉ cần sử dụng thêm tên miền hoặc địa chỉ IP là có thể sẫn sàng đáp ứng dịch vụ cho người dùng. - Dễ dàng quản lý truy cập của người dùng. • Nhược điểm chủ yếu của mô hình này là : - Dễ dàng bị quá tải do số người truy cập tăng. Tuy nhiên có thể giải quyết vấn đề này bằng cách tuỳ thuộc vào khả năng của máy làm server, người quản trị hoặc người thiết kế dịch vụ cần giới hạn khả năng đáp - 11 - ứng của dịch vụ. Hoặc xây dựng các giải pháp về mạng khác để tăng khả năng đáp ứng cho server tránh bị quá tải khi yêu cầu tăng. Với các nhận định trên, trong quá trình phát triển server chuyển phát âm thanh và hình ảnh, em đã sử dụng mô hình Client – Server. 2.1.3 Kiến trúc Server Kiến trúc của server được thiết kế như hình sau: Hình 2.3: Kiến trúc của Server Server hoạt động dựa trên nền tảng giao thức RTMP đóng vai trò như một framework. Các ứng dụng (Application) hoạt động trên Server trong suốt với giao thức, server đảm nhiệm công việc làm trong suốt này và giúp cho ứng dúng chạy trên Server liên lạc được với các Client tham gia vào ứng dụng này. - 12 - Trong một ứng dụng được chia làm nhiều phòng (Room). Trong mỗi phòng có nhiều người dùng (User). Mỗi người dùng này thực chất là một Client đang hoạt động kết nối tới Server với một ứng dụng được cung cấp nào đó của Server. Cũng theo mô hình kiến trúc mỗi Client còn có nhiều kênh (Channel). Các kênh này giúp cho người dùng có thể nhận cùng lúc nhiều loại dữ liệu khác nhau mà không cần phải tạo nhiều kết nối tới Server. Hình minh hoạ trên chỉ ra một Server cung cấp các ứng dụng cho phép các người dùng chia sẻ video, nhạc và một ứng dụng cho phép các bác sĩ tạo và tham gia vào các cuộc hội chẩn từ xa. Mỗi phòng có nhiệm vụ giống như một cuộc hội chẩn. Còn các kênh giúp cho các bác sĩ vừa có thể xem các đoạn video về ca phẫu thuật đang tiến hành, vừa có thể nói chuyện bàn bạc được với nhau. Đồng thời các bác sĩ cũng có thể xem thông tin bệnh nhân và các hình ảnh liên quan tới bệnh nhân này. 2.2 Máy chủ Red5 Red5 là một máy chủ mã nguồn mở Flash Server viết bằng ngôn ngữ Java. Hệ thống Server được xây dựng đã hỗ trợ sẵn các dịch vụ về hình ảnh, âm thanh. Server sử dụng chuẩn nén Video H.264 và Audio HE-AAC. Chuẩn nén H.264 có tỉ số nén cao nhưng vẫn không làm giảm nhiều chất lượng Video. Người ta tính toán ra được đối với chuẩn nén H.264 khi Video có độ phân giải 700x525 và tốc độ frame là 30 frame/sec thì băng thông yêu cầu nhỏ hơn 1.5 Mbps. Với băng thông yêu cầu chỉ khoảng 1.5 Mbps thì hệ thống Server đang được xây dựng có thể hoạt động trên những đường truyền Internet tốc độ trung bình. Nếu so sánh hệ thống đang được xây dựng với các giải pháp phần cứng thì hệ thống đang được xây dựng sẽ có chi phí thấp hơn đáng kể do không cần sử dụng các thiết bị chuyên dụng, không cần phải sử dụng kênh thuê riêng nhưng về chất lượng truyền dẫn thì không đảm bảo bằng vì trên các đường truyền Internet thông thường có thể xảy ra tắc nghẽn. Ngoài ra do sử dụng Web và Flash nên hệ thống đang được xây dựng có tính khả chuyển và mềm dẻo chứ không bị cố định tại một vài địa điểm - 13 - như các hệ thống phần cứng. Việc thêm một địa điểm tham gia vào ứng dụng chỉ cần một máy tính có gắn camera và phone là đủ mà không cần phải đầu tư thêm thiết bị đắt tiền như các hệ thống dựa trên phần cứng. Dưới đây là những hỗ trợ của máy chủ Red5 : • Streaming Video (FLV, F4V, MP4, 3GP) • Streaming Audio (MP3, F4A, M4A, AAC) • Recording Client Streams (FLV and AVC+AAC in FLV container) • Shared Objects • Live Stream Publishing • Remoting • Protocols: RTMP, RTMPT, RTMPS, and RTMPE - 14 - Chương 3 Giao thức truyền và các chuẩn nén 3.1. Giao thức truyền tải dữ liệu thời gian thực 3.1.1. Giới thiệu Mạng Internet vốn được xây dựng để truyền dữ liệu, và các giao thức truyền tải lớp Transport như TCP (Transmission Control Protocol) hay UDP (User Datagram Protocol) chỉ có khả năng truyền dữ liệu từ đầu cuối đến đầu cuối mà không có bất kì cơ chế nào để đảm bảo gói dữ liệu được truyền đến đích trong một thời gian xác định nghĩa là không đảm bảo vấn đề thời gian thực cho âm thanh, hình ảnh. Khi truyền một gói dữ liệu trên mạng Internet có nhiều nguyên nhân khiến gói dữ liệu đến đích không đúng thời gian (có thể đến sớm hoặc đến trễ) chẳng hạn như lưu lượng trên mạng tại thời điểm gửi quá lớn, cũng có thể gói dữ liệu phải đi qua một link có tốc độ thấp, một hoặc vài router bị quá tải… khiến cho gói dữ liệu đến trễ không theo một quy luật nào (jitter). Ngoài ra còn vấn đề mất gói dữ liệu khi Time-to-Live trong gói dữ liệu bị giảm xuống 0, các router drop các gói dữ liệu khi bị quá tải…Tất cả các nguyên nhân trên khiến cho mạng Internet không thật thích hợp để truyền âm thanh,hình ảnh. Tuy nhiên, người ta sử dụng cơ chế “Buffering” (vùng đệm Playback) ở phía nhận để giảm jitter khi truyền âm thanh, hình ảnh trên mạng Internet. Cơ chế này như sau: Hình 3.1: Vùng đệm dùng cho việc playback - 15 - Bên nhận khi nhận được dữ liệu thì không phát ra ngay mà lưu vào vùng đệm K. Khi vùng đệm K đầy thì bên nhận bắt đầu phát hình ảnh và âm thanh (lấy dữ liệu ra khỏi vùng đệm K với một tốc độ không đổi). Trong lúc phát âm thanh, hình ảnh thì nó tiếp tục nhận dữ liệu âm thanh, hình ảnh từ bên gửi bù đắp vào dữ liệu được lấy ra khỏi vùng đệm K để phát. Nếu chỉ có trì hoãn nhỏ xảy ra thì vùng đệm K sẽ không bị cạn kiệt và đảm bảo triệt tiêu jitter, nếu có trì hoãn lớn hoặc mất dữ liệu thì tới một lúc nào đó vùng đệm K sẽ bị cạn kiệt, khi đó bên nhận sẽ dừng phát âm thanh, hình ảnh và phải tiến hành thao tác trên lại từ đầu. Có một vài điểm đáng lưu ý khi chọn kích thước của vùng đệm K. Nếu chọn K lớn thì có thể giảm đáng kể jitter nhưng thời gian chờ đợi trước khi bắt đầu phát âm thanh, hình ảnh sẽ rất lâu. Ngược lại nếu chọn K nhỏ thì thì thời gian chờ đợi trước khi bắt đầu phát âm thanh, hình ảnh sẽ ngắn nhưng trong quá trình phát thường hay dừng để đệm lại dữ liệu. 3.1.2. Giao thức RTP (Real Time Transport Protocol) 3.1.2.1 Định dạng RTP Giao thức này tên là giao thức truyền tải thời gian thực nhưng nó không chứa đựng các cơ chế đảm bảo truyền dữ liệu đúng thời hạn, những đảm bảo này phải được cung cấp bởi hệ thống cơ sở. Thay vì thế, RTP cung cấp hai phương tiện chủ chốt: đánh số thứ tự trong mỗi packet để cho phép nơi nhận phát hiện ra việc chuyển phát không đúng thứ tự hoặc bị mất, và timestamp để cho phép nơi nhận kiểm soát việc playback. Vì RTP được thiết kế để truyền tải nhiều loại dữ liệu thời gian thực khác nhau, bao gồm cả âm thanh và video, nên RTP không bó buộc một cách diễn dịch ngữ nghĩa chung nhất. Thay vì thế, mỗi packet bắt đầu với một phần đầu cố định; các vùng trong phần đầu này xác định cách diễn dịch các vùng còn lại. Sau đây là định dạng phần đầu trong RTP. - 16 - Hình 3.2: Khuôn dạng giao thức RTP Mỗi packet bắt đầu với một số phiên bản (2-bit) của RTP trong vùng V; phiên bản hiện tại là 2. Vùng 16 bit “Sequence number” chứa số thứ tự của packet. Số thứ tự đầu tiên trong một giao dịch được chọn ngẫu nhiên. Có một số ứng dụng định nghĩa sự mở rộng tùy chọn cho phần đầu, được đặt giữa phần cố định và phần payload. Nếu kiểu của ứng dụng cho phép việc mở rộng, thì bit X được sử dụng để xác định xem phần mở rộng có tồn tại trong packet không. Việc diễn dịch của hầu hết các vùng còn lại trong phần đầu tùy thuộc vào vùng 7 bit PT (payload Type) để xác định kiểu playload; nó được sử dụng với việc mã hóa; trong đó yêu cầu dữ liệu được cấp phát theo những khối cố định. Việc diễn dịch của bit M (marker) cũng tùy thuộc vào ứng dụng, nó được sử dụng bởi ứng dụng nào cần đánh dấu các điểm đặc biệt trong dòng dữ liệu. Kiểu payload cũng ảnh hưởng đến việc diễn dịch của vùng Timestamp. Timestamp là một giá trị 32 bit để cho thời gian tại đó octet đầu tiên của dữ liệu số hóa được lấy mẫu, với timestamp ban đầu được chọn ngẫu nhiên. Chuẩn xác định rằng timestamp được tăng liên tục, ngay cả trong những lúc không có tín hiệu hay không có giá trị được gửi đi, nhưng nó không xác định độ gia tăng chính xác. Độ gia tăng được xác định bởi kiểu payload, nghĩa là mỗi ứng dụng có thể chọn một độ gia tăng, cho phép nơi nhận định vị được những mục trong dữ liệu xuất với mục chính xác thích hợp trong ứng dụng. Ví dụ, nếu một dòng dữ liệu thoại được truyền - 17 - qua RTP, thì độ gia tăng timestamp (theo logic) một nhịp đồng hồ cho một mẫu là thích hợp. Tuy nhiên, nếu dữ liệu video được truyền, thì độ gia tăng timestamp cần phải lớn hơn để cho việc playback được trung thực. 3.1.2.2 . Đóng gói RTP Từ tên gọi của nó, RTP là giao thức mức chuyên chở. Nếu nó đóng vai trò như giao thức chuyên chở thông thường, thì RTP sẽ yêu cầu mỗi thông điệp được đóng gói trực tiếp trong một IP datagram. Thực ra, RTP không có chức năng là giao thức chuyên chở; mặc dù nó được phép, nhưng việc đóng gói trực tiếp trong IP không xảy ra trong thực tế. Thay vì thế, RTP chạy trên UDP; có nghĩa là mỗi thông điệp RTP được đóng gói trong một UDP datagram. Ưu điểm chính của việc sử dụng UDP là xử lí song song – một máy tính có thể có nhiều ứng dụng cùng sử dụng RTP. Hình 3.3: Minh họa đóng gói tiêu đề RTP Không giống như nhiều giao thức ứng dụng khác, RTP không sử dụng một giá trị cổng UDP dành riêng. Thay vì thế, một cổng được cấp phát để sử dụng cho mỗi giao dịch, và ứng dụng ở xa phải được thông báo về giá trị cổng này. Theo qui ước, RTP chọn một cổng UDP có số chẵn. 3.1.3. Giao thức RTMP (Real Time Messaging Protocol) 3.1.3.1. Giới thiệu RTMP là giao thức được tạo ra bởi Macromedia (hiện nay là Adobe) dùng để truyền tải các đối tượng Flash và video trên các kết nối mạng. Hiện tại chỉ có 2 máy chủ hỗ trợ giao thức này là Macromedia Media Sever, và server mã nguồn mở Red5. - 18 - Đây là một giao thức đơn giản, được tối ưu cho các kết nối tốc độ thấp. Nó có thể hỗ trợ tối đa 64 luồng dữ liệu trên cùng một kết nối. Trong header của một AMF có chứa chỉ số của luồng dữ liệu mà nó thuộc về. Một message RTMP có thể chứa nhiều hơn một đối tượng AMF. 3.1.3.2. Các chế độ hoạt động của RTMP RTMP ở chế độ tiêu chuẩn chạy trên TCP với cổng mặc định là 1935. Ngoài ra RTMP[8] có thể chạy trong chế độ đường hầm trên một kết nối HTTP sử dụng cổng 80. Hình 3.4: RTMP ở chế độ tiêu chuẩn Hình 3.5: RTMP ở chế độ đường hầm 3.1.3.3. Quá trình bắt tay Hoạt động cơ bản của RTMP như sau : Tất cả quá trình truyền thông được khởi động bởi client. Client khởi tạo một kết nối RTMP bằng cách gửi một byte có giá trị 0x03 – byte này được theo sau bởi một khối dữ liệu 1536 byte. Định dạng của khối dữ liệu này cho đến nay vẫn chưa biết nhưng nó dường như không thực sự được sử dụng bởi giao thức ngoại trừ thao tác bắt tay. Server khi nhận được gói dữ liệu sẽ lưu lại khối dữ liệu 1536 byte này, và cũng gởi 1 byte giá trị 0x03 theo sau bởi hai khối 1536 byte. Khối thứ hai chính là nội dung đã được gửi lên bởi client trước đó. - 19 - Client nhận hai khối dữ liệu 1536 byte từ server, so sánh với khối dữ liệu ban đầu nó gửi lên server, nếu phù hợp thì kết nối được thiết lập, nó cũng gửi trả khối dữ liệu này về lại cho server. Hình 3.6: Quá trình bắt tay giữa Client và Server trong giao thức RTMP Sau thao tác bắt tay Client tiếp tục gửi ba đối tượng AMF lên server để khởi động truyền dữ liệu. Đối tượng đầu tiên là đối tượng connect nhằm thông báo client đã sẵn sàng cho quá trình truyền thông. Đối tượng AMF thứ hai chính là đối tượng NetConnection từ client, lớp Action Script này được sử dụng tạo kết nối tới media server. Đối tượng AMF thứ ba là đối tượng NetStream từ client dùng để xác định file cần stream từ server. 3.1.3.4. Tiêu đề RTMP RTMP có bốn loại tiêu đề đó là tiêu đề 12, 8, 4 hoặc 1 byte. Byte đầu tiên của tiêu đề rất quan trọng, 2 bit đầu tiên của nó xác định kích thước của tiêu đề. • 0x00: tiêu đề 12 byte • 0x01: tiêu đề 8 byte • 0x02: tiêu đề 4 byte - 20 - • 0x03: tiêu đề 1 byte Sáu bít còn lại biểu diễn chỉ số của đối tượng AMF. Một khi đối tượng AMF đã được nhận đầy đủ bởi client thì chỉ số này có thể được tái sử dụng. Hình 3.7: Tiêu đề RTMP 12 byte Đối với tiêu đề 12 byte thì 3 byte tiếp theo là trường timestamp (little-endian), 3 byte tiếp theo nữa là chiều dài của đối tượng AMF (big-endian), byte kế tiếp quy định nội dung của đối tượng AMF (xem hình ?), 4 byte cuối cùng xác định source id. Đối với tiêu đề 8 byte thì bỏ đi trường source id trong tiêu đề 12 byte. Đối với tiêu đề 4 byte thì bỏ đi trường length, content type trong tiêu đề 8 byte. Đối với tiêu đề 1 byte thì bỏ đi trường timestamp trong tiêu đề 4 byte nghĩa là nó chỉ gồm byte đầu tiên chứa kiểu tiêu đề và chỉ số đối tượng AMF.