ĐỒ ÁN TỐT NGHIỆP
XÂY DỰNG MEDIA SERVER ỨNG DỤNG TRONG HỘI CHẨN TỪ XA
Sinh viên thực hiện : Phạm Thái Bảo
Người hướng dẫn : Th.S Đào Văn Tuyết
CHƯƠNG II: LÝ THUYẾT
2.1. Mô hình hệ thống
2.1.1. Mô hình Peer to Peer
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ỏ.
2.1.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.
2.2. Kiến trúc Server
Kiến trúc của server được thiết kế như hình sau:
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.
2.3. Giao thức truyền tải dữ liệu thời gian thực
2.3.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:
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.
2.3.2. Giao thức RTP (Real Time Transport Protocol)
2.3.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.
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 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.
----------------------------------------
MỤC LỤC
DANH MỤC HÌNH VẼ, BẢNG BIỂU
CÁC THUẬT NGỮ VIẾT TẮT
CHƯƠNG I: TỔNG QUAN
CHƯƠNG II: LÝ THUYẾT
2.1. Mô hình hệ thống
2.1.1. Mô hình Peer to Peer
2.1.2. Mô hình Client – Server
2.2. Kiến trúc Server
2.3. Giao thức truyền tải dữ liệu thời gian thực
2.3.1. Giới thiệu
2.3.2. Giao thức RTP (Real Time Transport Protocol)
2.3.2.1. Định dạng RTP
2.3.2.2. Đóng gói RTP
2.3.3. Giao thức RTMP (Real Time Messaging Protocol)
2.3.3.1. Giới thiệu
2.3.3.2. Các chế độ hoạt động của RTMP
2.3.3.3. Quá trình bắt tay
2.3.3.4. Tiêu đề RTMP
2.3.3.5. Truyền tải nhiều đối tượng AMF trên cùng một kết nối
2.3.4. So sánh giữa RTP và RTMP
2.4. Chuẩn mã hoá dữ liệu - AMF (Action Message Format)
2.4.1. AMF
2.4.1.1. Giới thiệu
2.4.1.2. Kiểu dữ liệu AMF
2.4.2. AMF
2.5. Shared Object
2.5.1. Giới thiệu
2.5.2. Shared Object và Cookie
2.5.3. Kiểu thông điệp của Shared Object
2.6. Chuẩn nén âm thanh HE-AAC
2.6.1. Số hóa âm thanh
2.6.2. Chuẩn AAC
2.6.2.1. Giới thiệu
2.6.2.2. Đặc tính âm học của tai người
2.6.2.3. Hoạt động của thuật toán nén âm thanh AAC
2.6.2.4. Mô tả chi tiết về AAC
2.6.3. Chuẩn HE-AAC
2.6.3.1. Giới thiệu
2.6.3.2. Spectral Band Replication – SBR
2.6.3.3. Parametric Stereo (PS)
2.7. Chuẩn nén hình ảnh MPEG-4/ H.
2.7.1. Số hoá hình ảnh
2.7.2. Nén hình ảnh
2.7.3. Phép biến đổi Cosine rời rạc (Discrete Cosine Transform)
2.7.4. Mã hóa chiều dài thay đổi VLC (Variable Length Coding)
2.7.4.1. Giới thiệu chung
2.7.4.2. Mã Huffman
2.7.5. Kĩ thuật nén ảnh JPEG
2.7.6. Kĩ thuật nén Video H. 264
2.7.6.1. Bộ mã hóa và giải mã
2.7.6.2. Cơ bản về H.
2.8. Chuẩn hình ảnh DICOM và hệ thống PACS dùng trong y tế
2.8.1. Hệ thống PACS
2.8.1.1. Lịch sử hình thành và phát triển
2.8.1.2. Thành phần của hệ thống PACS
2.8.1.3. Kiến trúc PACS
2.8.1.4. Các yêu cầu trong việc thiết kế hệ thống PACS
2.8.2. Hệ thống MyFreePACS
2.8.3. Chuẩn hình ảnh DICOM dùng trong y tế
2.8.3.1. Tổng quan về DICOM
2.8.3.2. Phạm vi và lĩnh vực ứng dụng của DICOM
2.8.3.3. Thích nghi DICOM
2.8.3.4. Mục tiêu của ảnh DICOM
2.8.3.5. Cấu trúc của chuẩn DICOM
2.8.3.6. Khuôn dạng file DICOM
2.8.4. DICOM Toolkit
2.8.4.1. DCMTK
2.8.4.2. DCM4CHE
2.9.1. Hệ thống thông tin y tế
2.9.1.1. Giới thiệu
2.9.1.2. Kiến trúc hệ thống
2.9.1.3. Các nhiệm vụ của hệ thống HIS
2.9.2. Hệ thống FreeMED
2.9.3. Chuẩn dữ liệu văn bản HL
2.10. Giải pháp mở rộng
2.10.1. Giải pháp 1: Sử dụng Cluster Server
2.10.2. Giải pháp 2: Phát triển thêm tính năng mở rộng cho Server
2.10.3. Giải pháp 3: Kết hợp giữa hai giải pháp 1 và 2
CHƯƠNG III: THỰC HÀNH
3.1. Tạo một ứng dụng chạy trên Server WebF
3.2. Tính năng chia sẻ và lưu trữ Video
3.2.1. Giới thiệu
3.2.2. Bắt tay trên giao thức RTMP
3.2.3. Thực hiện kết nối
3.2.4. Chia sẻ âm thanh, hình ảnh và lưu trữ tại Server
3.3. Tính năng Shared Object
3.4. Tính năng lấy thông tin của bệnh nhân trong FreeMED
3.5. Tính năng lấy ảnh trong MyFreePACS và chuyển thành ảnh JPEG
CHƯƠNG IV: THẢO LUẬN
CHƯƠNG V: KẾT LUẬN
TÀI LIỆU THAM KHẢO
--------------------------------------------
Keyword: download,do an tot nghiep,xay dung,media server,ung dung,trong hoi chan,tu xa,pham thai bao
Nhận xét
Đăng nhận xét