Đồ án Xây dựng Media Server ứng dụng trong hội chẩn từ xa

LỜI CẢM ƠN Trước hết em xin cảm ơn Viện cơ học và tin học ứng dụng trong thời gian qua đã tạo điều kiện cho em được thực tập tại viện. Em xin được gửi lời cảm ơn chân thành nhất đến thầy Đào Văn Tuyết. Thầy là người trực tiếp hướng dẫn em từng bước tìm tòi, và phát triển đề tài, cung cấp những kinh nghiệm quý báu, hỗ trợ em trong suốt thời gian thực tập. Em cũng xin gửi lời cảm ơn đến các anh, chị tại phòng Công nghệ tính toán và Công nghệ tri thức, Viện cơ học và tin học ứng dụng đã giúp đỡ em trong thời gian thực tập. Em xin chân thành đến quý thầy cô trong Học Viện Công Nghệ Bưu Chính Viễn đã tận tình giảng dạy, cung cấp cho em những kiến thức quý báu trong suốt thời gian học tập tại trường. Em xin gửi lời cảm ơn đến bạn Trần Anh Khoa là người làm chung đề tài với em, người đã cùng em suy nghĩ, tìm tòi, suy nghĩ giải pháp cho đề tài trong thời gian vừa qua và cả thời gian sắp đến. Em xin cảm ơn đến gia đình và bạn bè đã luôn động viên, giúp đỡ em trong thời gian thực tập vừa qua. Sinh Viên Phạm Thái Bảo LỜI CẢM ƠN Trước hết em xin cảm ơn Viện cơ học và tin học ứng dụng trong thời gian qua đã tạo điều kiện cho em được làm việc và nghiên cứu tại viện. Em xin được gửi lời cảm ơn chân thành nhất đến thầy Đào Văn Tuyết. Thầy là người trực tiếp hướng dẫn em từng bước tìm tòi, và phát triển đề tài, cung cấp những kinh nghiệm quý báu, hỗ trợ em trong suốt thời gian thực hiện luận văn. Em cũng xin gửi lời cảm ơn đến các anh, chị tại phòng Công nghệ tính toán và Công nghệ tri thức, Viện cơ học và tin học ứng dụng đã giúp đỡ em nhiều trong khoảng thời gian này. Em xin gửi lời cám ơn chân thành đến quý thầy cô trường Học Viện Công Nghệ Bưu Chính Viễn Thông đã tận tình giảng dạy, cung cấp cho em những kiến thức quý báu trong suốt thời gian học tập tại trường. Em xin gửi lời cảm ơn đến bạn Trần Anh Khoa là người đã cùng em suy nghĩ, tìm tòi, đưa ra các giải pháp cho đề tài trong thời gian vừa qua. Em xin cảm ơn đến gia đình và bạn bè đã luôn động viên, giúp đỡ em trong khoảng thời gian thực hiện luận văn đầy khó khăn và thử thách vừa qua. Sinh Viên Phạm Thái Bảo MỤC LỤC MỤC LỤC i DANH MỤC HÌNH VẼ, BẢNG BIỂU iii CÁC THUẬT NGỮ VIẾT TẮT vi CHƯƠNG I: TỔNG QUAN 1 CHƯƠNG II: LÝ THUYẾT 2 2.1. Mô hình hệ thống 2 2.1.1. Mô hình Peer to Peer 2 2.1.2. Mô hình Client – Server 2 2.2. Kiến trúc Server 3 2.3. Giao thức truyền tải dữ liệu thời gian thực 5 2.3.1. Giới thiệu 5 2.3.2. Giao thức RTP (Real Time Transport Protocol) 6 2.3.2.1. Định dạng RTP 6 2.3.2.2. Đóng gói RTP 7 2.3.3. Giao thức RTMP (Real Time Messaging Protocol) 7 2.3.3.1. Giới thiệu 7 2.3.3.2. Các chế độ hoạt động của RTMP 7 2.3.3.3. Quá trình bắt tay 8 2.3.3.4. Tiêu đề RTMP 8 2.3.3.5. Truyền tải nhiều đối tượng AMF trên cùng một kết nối 9 2.3.4. So sánh giữa RTP và RTMP 11 2.4. Chuẩn mã hoá dữ liệu - AMF (Action Message Format) 11 2.4.1. AMF0 12 2.4.1.1. Giới thiệu 12 2.4.1.2. Kiểu dữ liệu AMF0 12 2.4.2. AMF3 13 2.5. Shared Object 15 2.5.1. Giới thiệu 15 2.5.2. Shared Object và Cookie 15 2.5.3. Kiểu thông điệp của Shared Object 15 2.6. Chuẩn nén âm thanh HE-AAC 16 2.6.1. Số hóa âm thanh 16 2.6.2. Chuẩn AAC 16 2.6.2.1. Giới thiệu 16 2.6.2.2. Đặc tính âm học của tai người 17 2.6.2.3. Hoạt động của thuật toán nén âm thanh AAC 18 2.6.2.4. Mô tả chi tiết về AAC 19 2.6.3. Chuẩn HE-AAC 25 2.6.3.1. Giới thiệu 25 2.6.3.2. Spectral Band Replication – SBR 26 2.6.3.3. Parametric Stereo (PS) 27 2.7. Chuẩn nén hình ảnh MPEG-4/H.264 29 2.7.1. Số hoá hình ảnh 29 2.7.2. Nén hình ảnh 29 2.7.3. Phép biến đổi Cosine rời rạc (Discrete Cosine Transform) 30 2.7.4. Mã hóa chiều dài thay đổi VLC (Variable Length Coding) 32 2.7.4.1. Giới thiệu chung 32 2.7.4.2. Mã Huffman 33 2.7.5. Kĩ thuật nén ảnh JPEG 34 2.7.6. Kĩ thuật nén Video H.264 34 2.7.6.1. Bộ mã hóa và giải mã 34 2.7.6.2. Cơ bản về H.264 36 2.8. Chuẩn hình ảnh DICOM và hệ thống PACS dùng trong y tế 39 2.8.1. Hệ thống PACS 39 2.8.1.1. Lịch sử hình thành và phát triển 39 2.8.1.2. Thành phần của hệ thống PACS 40 2.8.1.3. Kiến trúc PACS 43 2.8.1.4. Các yêu cầu trong việc thiết kế hệ thống PACS 47 2.8.2. Hệ thống MyFreePACS 49 2.8.3. Chuẩn hình ảnh DICOM dùng trong y tế 49 2.8.3.1. Tổng quan về DICOM 49 2.8.3.2. Phạm vi và lĩnh vực ứng dụng của DICOM 51 2.8.3.3. Thích nghi DICOM 51 2.8.3.4. Mục tiêu của ảnh DICOM 52 2.8.3.5. Cấu trúc của chuẩn DICOM 52 2.8.3.6. Khuôn dạng file DICOM 57 2.8.4. DICOM Toolkit 58 2.8.4.1. DCMTK 58 2.8.4.2. DCM4CHE 59 2.9. Hệ thống thông tin y tế và chuẩn dữ liệu văn bản HL7 62 2.9.1. Hệ thống thông tin y tế 62 2.9.1.1. Giới thiệu 62 2.9.1.2. Kiến trúc hệ thống 62 2.9.1.3. Các nhiệm vụ của hệ thống HIS 64 2.9.2. Hệ thống FreeMED 64 2.9.3. Chuẩn dữ liệu văn bản HL7 65 2.10. Giải pháp mở rộng 66 2.10.1. Giải pháp 1: sử dụng Cluster Server 66 2.10.2. Giải pháp 2: phát triển thêm tính năng mở rộng cho Server 67 2.10.3. Giải pháp 3: kết hợp giữa hai giải pháp 1 và 2 69 CHƯƠNG III: THỰC HÀNH 70 3.1. Tạo một ứng dụng chạy trên Server WebF 70 3.2. Tính năng chia sẻ và lưu trữ Video 72 3.2.1. Giới thiệu 72 3.2.2. Bắt tay trên giao thức RTMP 73 3.2.3. Thực hiện kết nối 74 3.2.4. Chia sẻ âm thanh, hình ảnh và lưu trữ tại Server 75 3.3. Tính năng Shared Object 78 3.4. Tính năng lấy thông tin của bệnh nhân trong FreeMED 80 3.5. Tính năng lấy ảnh trong MyFreePACS và chuyển thành ảnh JPEG 82 CHƯƠNG IV: THẢO LUẬN 86 CHƯƠNG V: KẾT LUẬN 87 TÀI LIỆU THAM KHẢO 88 DANH MỤC HÌNH VẼ, BẢNG BIỂU Hình 2. 1: Mô hình Peer to Peer trong DVTS 2 Hình 2. 2: Mô hình Client – Server 3 Hình 2. 3: Kiến trúc của Server 4 Hình 2. 4: Vùng đệm dùng cho việc playback 5 Hình 2. 5: Khuôn dạng giao thức RTP 6 Hình 2. 6: Minh họa đóng gói tiêu đề RTP 7 Hình 2. 7: RTMP ở chế độ tiêu chuẩn 7 Hình 2. 8: RTMP ở chế độ đường hầm 7 Hình 2. 9: Quá trình bắt tay giữa Client và Server trong giao thức RTMP 8 Hình 2. 10: Tiêu đề RTMP 12 byte 9 Bảng 2. 11: Một số giá trị trong trường Content Type 9 Hình 2. 12: Các khối dữ liệu của một đối tượng AMF có chỉ số là 0x03 10 Hình 2. 13: Truyền các khối dữ liệu xen kẽ nhau. 11 Bảng 2. 14: Kiểu dữ liệu trong AMF0 12 Hình 2. 15: Kiểu dữ liệu của AMF3 14 Bảng 2. 16: Kiều thông điệp Shared Object 16 Hình 2. 17: Ngưỡng âm thanh của tai người phụ thuộc vào tần số 17 Hình 2. 18: Ngưỡng âm thanh của tai người phụ thuộc vào thời gian 18 Hình 2. 19: Ngưỡng âm thanh theo tần số, thời gian, và biên độ 18 Hình 2. 20: Biểu đồ hoạt động của thuật toán nén âm thanh 18 Hình 2. 21: Ba loại profile của AAC 20 Hình 2. 22: Bộ mã hoá âm thanh AAC 21 Hình 2. 23: Bộ giải mã âm thanh AAC 22 Hình 2. 24: Module mã hoá và giải mã điều chỉnh khuếch đại 23 Hình 2. 25: Tập 12 dải tần số và đặc tả 24 Hình 2. 29: Mức tần số giới hạn cho thuật toán dự đoán 25 Hình 2. 30: Họ chuẩn nén AAC 26 Hình 2. 31: Việc chuyển đổi trong quá trình tạo ra dãy tần số cao 26 Hình 2. 32: Chỉnh đường biên của dãy tần số cao 27 Hình 2. 33: Nguyên lý cơ bản của quá trình xử lý PS 28 Hình 2. 34: Biểu đồ bộ mã hoá HE-AAC 28 Hình 2. 35: Biểu đồ bộ mã hoá HE-AAC 28 Hình 2. 36: So sánh hiệu quả của các chuẩn nén họ AAC 29 Hình 2. 37: So sánh hiệu quả giữa chuẩn nén HE-AAC và các chuẩn nén khác 29 Hình 2. 38: Minh họa cách chia ảnh thành các khối trước khi biến đổi Cosine 30 Hình 2. 45: Phép biến đổi hai chiều được phân thành bước biến đổi một chiều 31 Hình 2. 49: Ví dụ về một bảng mã 32 Hình 2. 50: Sơ đồ nén ảnh JPEG 34 Hình 2. 51: Sơ đồ giải nén ảnh JPEG 34 Hình 2. 52: Sơ đồ bộ mã hóa MPEG-4/H.264 35 Hình 2. 53: Sơ đồ bộ giải mã MPEG-4/H.264 35 Hình 2. 54: Thứ tự khối ảnh được mã hóa 36 Hình 2. 55 Các cách chia khối ảnh nhỏ hơn 37 Hình 2. 56: Minh họa cách chia các khối ảnh khi mã hóa 37 Hình 2. 57: Tinh vector chuyển động 37 Hình 2. 58: Nhãn của các mẫu dự đoán 38 Hình 2. 59: Các chế độ mã hóa khối ảnh 38 Hình 2. 60: Ví dụ minh họa cho các chế độ mã hóa khối 39 Hình 2. 61: Cấu trúc hệ thống PACS 41 Hình 2. 62: Sơ đồ hoạt động của cổng nhận ảnh 42 Hình 2. 63: Luồng dữ liệu khái quát của kiến trúc stand – alone. 43 Hình 2. 64: Luồng dữ liệu tổng quát của kiến trúc client-server. 45 Hình 2. 65: Máy chủ chứa ảnh dựa vào web 47 Hình 2. 66: Các thiết bị tạo,lưu trữ và truyền ảnh DICOM 50 Bảng 2. 67: So sánh các dung lượng các ảnh của một số chuẩn DICOM hỗ trợ 51 Hình 2. 68: DICOM và mô hình tham chiếu OSI 53 Hình 2. 69: Ví dụ về ảnh MRI 53 Hình 2. 70: Ví dụ về một số trường của ảnh DICOM 54 Hình 2. 71: Lớp dịch vụ và lớp đối tượng 55 Hình 2. 72: Minh họa đối tượng ảnh 56 Hình 2. 73: Các dịch vụ của DICOM 56 Hình 2. 74: Các dịch vụ DIMSEs tiêu chuẩn 57 Hình 2. 75: Ví dụ các lớp đối tượng và lớp dịch vụ được truyền giữa SCU và SCP 57 Hình 2. 76: Khuôn dạng file DICOM 58 Hình 2. 77 Mô hình hệ thống dcm4chee 61 Bảng 2. 78: Một số tính năng của dcm4chee 61 Hình 2. 79: Mô hình kiến trúc của hệ thống HIS 62 Hình 2. 80: Hệ thống máy chủ tập trung 63 Hình 2. 81: Hệ thống tập trung + hệ thống song song ở phòng xét nghiệm 63 Hình 2. 82: Hệ thống hướng đến máy trạm với cơ sở dữ liệu tập trung 63 Hình 2. 83: Chức năng và cơ sở dữ liệu của mỗi bộ phận độc lập nhau. 64 Hình 2. 84: Định dạng một file HL7 65 Hình 2. 85: Mô hình cơ bản 66 Hình 2. 86: Một mô hình cụ thể cho hệ thống Java 67 Hình 2. 87: Cơ chế hoạt động của tính năng mở rộng 68 Hình 2. 88: Di chuyển User 68 Hình 3. 1: Giao diên web của Client 71 Hình 3. 2: Khởi động Server WebF 72 Hình 3. 3: Kết nối thành công 72 Hình 3. 4: Bắt tay RTMP giai đoạn một 73 Hình 3. 5: Bắt tay giai đoạn 2 74 Hình 3. 6: Bắt tay giai đoạn 3 74 Hình 3. 7: Sơ đồ gửi, trả lời thông điệp kết nối giữa client và server. 75 Hình 3. 8: Sơ đồ gửi, trả lời thông điệp publish giữa client và server. 76 Hình 3. 9: Sơ đồ gửi, trả lời thông điệp play giữa client và server. 76 Hình 3. 10: Mô hình luồng dữ liệu giữa client và server khi chuyển dữ liệu video 77 Hình 3. 11: Kết quả thử nghiệm 77 Hình 3. 12: Kết nối tới Server 78 Hình 3. 13: Kết nối thành công 79 Hình 3. 14: Tính năng Shared Object 79 Hình 3. 15: Thông điệp thiết lập dữ liệu của Shared Object được gửi về Server 80 Hình 3. 16: Sử dụng tính năng Shared Object 80 Hình 3. 17: Tìm kiếm thông tin bệnh nhân 81 Hình 3. 18: Thông điệp “searchPatient” giúp tìm kiếm bệnh nhân 81 Hình 3. 19: Thông điệp “getFreemedInfo” lấy thông tin của bệnh nhân trong FreeMED 82 Hình 3. 20: thông tin bệnh nhân được hiển thị lên sau khi đã nhận kết quả từ Server 82 Hình 3. 21: Thông điệp “getDicomofPatient” giúp lấy ID ảnh thông qua ID của bệnh nhân 83 Hình 3. 22: Thông điệp lấy ảnh Thumbnail của ảnh DICOM tương ứng 83 Hình 3. 23: Ảnh thumbnail được hiện thị sau khi lấy về từ Server 84 Hình 3. 24: Ảnh thật tương ứng với ảnh thumbnail được chọn. 84 Hình 3. 25: Thông điệp “getDICOMInformation” giúp lấy thông tin chứa trong ảnh DICOM 85 Hình 3. 26: Kết quả thông tin chứa trong ảnh DICOM sau khi được lấy về 85 CÁC THUẬT NGỮ VIẾT TẮT AAC Advanced Audio Coding 17, 20, 21, 24, 25, 26, 27, 28, 30 AMF Action Message Format 8, 9, 10, 11, 12, 13, 14 DCMTK DICOM Toolkit 59 DCT Discrete Cosine Transform 32 DICOM Digital Imaging and Communications in Medicine 55, 56, 57, 58, 59 DIMSE DICOM Message Sevice Elements 57 DVTS Digital Video Transport System 2, 3 HE-AAC High Efficiency AAC 5, 17, 26, 30 HIS Hospital Information System 41, 43, 44, 49, 63 HL7 Health Level Seven 2, 48, 49, 66, 67 JPEG Joint Photographic Experts Group 31, 35, 48 LC Low Complexity 21 MDCT Modified Discrete Cosine Transform 24, 25 MPEG Moving Picture Experts Group 17, 20, 26, 27, 28, 29, 31, 36 PACS Picture Archiving & Communication System 46, 47, 48, 49, 50 PS Parametric Stereo 26, 27, 29 RLC Run Length Coding 31 RTMP Real Time Messaging Protocol 2, 8, 9, 10, 12, 70, 71 RTP Realtime Transport Protocol , 7, 8, 12 SBR Spectral Band Replication 26, 27, 28, 29, 30 SSR Scalable Sampling Rate Profile 21 TCP Transmission Control Protocol 6, 8, 12, 44, 49, 71, 87 UDP User Datagram Protocol 6, 8 VLC Variable Length Coding 31, 33, 35 CHƯƠNG I: TỔNG QUAN Việc sử dụng các ứng dụng mạng có tính chất tương tác trong việc tổ chức hội nghị, hội thảo, giám sát hoạt động,… đã được thực hiện rất nhiều trong và ngoài nước. Một sản phẩm thường được sử dụng trong hội nghị, hội thảo là DVTS (Digital Video Transport System). Đối với giáo dục trong nước việc ứng dụng này thường chỉ dừng lại ở việc truyền hình ảnh, âm thanh giữa giáo viên và học viên chứ chưa có nhiều tương tác hai chiều, còn giáo dục ở nước ngoài đã có các sản phẩm hỗ trợ rất mạnh cho giáo viên và học viên. Ngoài ra trong y tế các nước phát triển cũng đã bắt đầu sử dụng các ứng dụng mạng có tính chất tương tác này trong khám chữa bệnh từ xa, nhưng ở nước ta thì đây là một vấn đề khá mới mẻ. Chính vì thế em quyết định thực hiện đề tài “XÂY DỰNG MEDIA SERVER ỨNG DỤNG TRONG HỘI CHẨN TỪ XA” để tạo ra một ứng dụng mạng có khả năng tương tác tốt trợ giúp các bác sĩ trong việc hội chẩn từ xa. Tại sao cần phải thực hiện đề tài này ? Bởi vì trong quá trình khám và điều trị bệnh có những trường hợp bệnh khó diễn biến bất ngờ, những ca mổ phức tạp… cần phải có sự tham gia hội chẩn của nhiều bác sĩ, chuyên gia để đưa quyết định chính xác, kịp thời mang lại lợi ích cao nhất cho người bệnh. Đôi khi bác sĩ ở xa nên không thể gặp thể gặp trực tiếp bệnh nhân, không thể hội chẩn trực tiếp được. Hoặc là một bệnh viện tuyến dưới cần sự giúp đỡ trực tiếp của các bác sĩ bệnh viện tuyến trên, nước ngoài… Chính vì thế việc hỗ trợ hội chẩn từ xa là khá cấp thiết. Để phục vụ cho việc hội chẩn thì các bác sĩ cần thông tin các về bệnh nhân như bệnh án, hình ảnh về bệnh nhân, âm thanh để thảo luận, ngoài ra còn có các phim chụp X-Quang, CT, siêu âm, điện tâm đồ…Để có thể thực hiện đề tài, luận văn tập trung tìm hiểu các nội dung sau: Mô hình hệ thống Server và mô hình để ứng dụng vào trong hội chẩn từ xa. Vấn đề số hóa âm thanh và hình ảnh. Các chuẩn nén âm thanh và hình ảnh. Chuẩn DICOM & HL7 được dùng trong y tế. Chia sẻ dữ liệu dùng chung (Shared Object). Vấn đề đóng gói các đối tượng và gọi hàm từ xa. Vấn đề truyền tải dữ liệu thời gian thực. Vấn đề cơ sở hạ tầng cần thiết để hệ thống có thể hoạt động. Hệ thống lưu trữ và truyền tải hình ảnh (PACS), hệ thống thông tin y tế (HIS) Các giải pháp mở rộng Server. CHƯƠNG II: LÝ THUYẾT Mô hình hệ thống 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ỏ. 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 ứ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, nhóm đã sử dụng mô hình Client – Server. 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. 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. Yêu cầu cơ sở hạ tầng Hệ thống Server đang đượ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 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. Giao thức truyền tải dữ liệu thời gian thực 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ườ