Media Server(DATN Pham Thai Bao)

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ênPhạm Thái Bảo

HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNGCƠ SỞ TẠI THÀNH PHỐ HỒ CHÍ MINH

---------------------------------------------

ĐỒ ÁN TỐT NGHIỆP HỆ ĐẠI HỌC

Ngành : Công Nghệ Thông Tin Hệ : Chính quy Niên khóa : 2004-2008

Đề tài :XÂY DỰNG MEDIA SERVER ỨNG DỤNG TRONG HỘI

CHẨN TỪ XAMã số đ ề tài : 40417002

Sinh viên thực hiện : Phạm Thái BảoMã số sinh viên : 404170005Người hướng dẫn : Th.S Đào Văn Tuyết

Năm 2008

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ênPhạm Thái Bảo

Báo cáo Đồ án tốt nghiệp MỤC LỤC

MỤC LỤC

MỤC LỤC...................................................................................................................................iDANH MỤC HÌNH VẼ, BẢNG BIỂU.....................................................................................iiiCÁC THUẬT NGỮ VIẾT TẮT................................................................................................viCHƯƠNG I: TỔNG QUAN.......................................................................................................1CHƯƠNG II: LÝ THUYẾT.......................................................................................................22.1. Mô hình hệ thống........................................................................................................22.1.1. Mô hình Peer to Peer...................................................................................................22.1.2. Mô hình Client – Server..............................................................................................22.2. Kiến trúc Server..........................................................................................................32.3. Giao thức truyền tải dữ liệu thời gian thực.................................................................52.3.1. Giới thiệu....................................................................................................................52.3.2. Giao thức RTP (Real Time Transport Protocol).........................................................62.3.2.1. Định dạng RTP.......................................................................................................62.3.2.2. Đóng gói RTP.........................................................................................................72.3.3. Giao thức RTMP (Real Time Messaging Protocol)....................................................72.3.3.1. Giới thiệu................................................................................................................72.3.3.2. Các chế độ hoạt động của RTMP...........................................................................72.3.3.3. Quá trình bắt tay......................................................................................................82.3.3.4. Tiêu đề RTMP.........................................................................................................82.3.3.5. Truyền tải nhiều đối tượng AMF trên cùng một kết nối.........................................92.3.4. So sánh giữa RTP và RTMP.....................................................................................112.4. Chuẩn mã hoá dữ liệu - AMF (Action Message Format).........................................112.4.1. AMF0........................................................................................................................122.4.1.1. Giới thiệu..............................................................................................................122.4.1.2. Kiểu dữ liệu AMF0...............................................................................................122.4.2. AMF3........................................................................................................................132.5. Shared Object............................................................................................................152.5.1. Giới thiệu..................................................................................................................152.5.2. Shared Object và Cookie..........................................................................................152.5.3. Kiểu thông điệp của Shared Object..........................................................................152.6. Chuẩn nén âm thanh HE-AAC.................................................................................162.6.1. Số hóa âm thanh........................................................................................................162.6.2. Chuẩn AAC...............................................................................................................162.6.2.1. Giới thiệu..............................................................................................................162.6.2.2. Đặc tính âm học của tai người..............................................................................172.6.2.3. Hoạt động của thuật toán nén âm thanh AAC......................................................182.6.2.4. Mô tả chi tiết về AAC...........................................................................................192.6.3. Chuẩn HE-AAC........................................................................................................252.6.3.1. Giới thiệu..............................................................................................................252.6.3.2. Spectral Band Replication – SBR.........................................................................262.6.3.3. Parametric Stereo (PS)..........................................................................................272.7. Chuẩn nén hình ảnh MPEG-4/H.264........................................................................292.7.1. Số hoá hình ảnh.........................................................................................................292.7.2. Nén hình ảnh.............................................................................................................292.7.3. Phép biến đổi Cosine rời rạc (Discrete Cosine Transform)......................................302.7.4. Mã hóa chiều dài thay đổi VLC (Variable Length Coding).....................................322.7.4.1. Giới thiệu chung....................................................................................................322.7.4.2. Mã Huffman..........................................................................................................332.7.5. Kĩ thuật nén ảnh JPEG..............................................................................................34

Phạm Thái Bảo – Đ04THA1 i

Báo cáo Đồ án tốt nghiệp MỤC LỤC

2.7.6. Kĩ thuật nén Video H.264.........................................................................................342.7.6.1. Bộ mã hóa và giải mã............................................................................................342.7.6.2. Cơ bản về H.264...................................................................................................362.8. Chuẩn hình ảnh DICOM và hệ thống PACS dùng trong y tế...................................392.8.1. Hệ thống PACS.........................................................................................................392.8.1.1. Lịch sử hình thành và phát triển............................................................................392.8.1.2. Thành phần của hệ thống PACS...........................................................................402.8.1.3. Kiến trúc PACS.....................................................................................................432.8.1.4. Các yêu cầu trong việc thiết kế hệ thống PACS...................................................472.8.2. Hệ thống MyFreePACS............................................................................................492.8.3. Chuẩn hình ảnh DICOM dùng trong y tế..................................................................492.8.3.1. Tổng quan về DICOM..........................................................................................492.8.3.2. Phạm vi và lĩnh vực ứng dụng của DICOM.........................................................512.8.3.3. Thích nghi DICOM...............................................................................................512.8.3.4. Mục tiêu của ảnh DICOM.....................................................................................522.8.3.5. Cấu trúc của chuẩn DICOM.................................................................................522.8.3.6. Khuôn dạng file DICOM......................................................................................572.8.4. DICOM Toolkit........................................................................................................582.8.4.1. DCMTK................................................................................................................582.8.4.2. DCM4CHE...........................................................................................................592.9. Hệ thống thông tin y tế và chuẩn dữ liệu văn bản HL7............................................622.9.1. Hệ thống thông tin y tế..............................................................................................622.9.1.1. Giới thiệu..............................................................................................................622.9.1.2. Kiến trúc hệ thống.................................................................................................622.9.1.3. Các nhiệm vụ của hệ thống HIS...........................................................................642.9.2. Hệ thống FreeMED...................................................................................................642.9.3. Chuẩn dữ liệu văn bản HL7......................................................................................652.10. Giải pháp mở rộng....................................................................................................662.10.1. Giải pháp 1: sử dụng Cluster Server.........................................................................662.10.2. Giải pháp 2: phát triển thêm tính năng mở rộng cho Server.....................................672.10.3. Giải pháp 3: kết hợp giữa hai giải pháp 1 và 2.........................................................69CHƯƠNG III: THỰC HÀNH..................................................................................................703.1. Tạo một ứng dụng chạy trên Server WebF...............................................................703.2. Tính năng chia sẻ và lưu trữ Video...........................................................................723.2.1. Giới thiệu..................................................................................................................723.2.2. Bắt tay trên giao thức RTMP....................................................................................733.2.3. Thực hiện kết nối......................................................................................................743.2.4. Chia sẻ âm thanh, hình ảnh và lưu trữ tại Server......................................................753.3. Tính năng Shared Object..........................................................................................783.4. Tính năng lấy thông tin của bệnh nhân trong FreeMED..........................................803.5. Tính năng lấy ảnh trong MyFreePACS và chuyển thành ảnh JPEG........................82CHƯƠNG IV: THẢO LUẬN...................................................................................................86CHƯƠNG V: KẾT LUẬN.......................................................................................................87TÀI LIỆU THAM KHẢO........................................................................................................88

Phạm Thái Bảo – Đ04THA1 ii

Báo cáo Đồ án tốt nghiệp DANH MỤC HÌNH VẼ, BẢNG BIỂU

DANH MỤC HÌNH VẼ, BẢNG BIỂU

Hình 2. 1: Mô hình Peer to Peer trong DVTS.............................................................................2Hình 2. 2: Mô hình Client – Server.............................................................................................3Hình 2. 3: Kiến trúc của Server..................................................................................................4Hình 2. 4: Vùng đệm dùng cho việc playback............................................................................5Hình 2. 5: Khuôn dạng giao thức RTP........................................................................................6Hình 2. 6: Minh họa đóng gói tiêu đề RTP.................................................................................7Hình 2. 7: RTMP ở chế độ tiêu chuẩn........................................................................................7Hình 2. 8: RTMP ở chế độ đường hầm.......................................................................................7Hình 2. 9: Quá trình bắt tay giữa Client và Server trong giao thức RTMP................................8Hình 2. 10: Tiêu đề RTMP 12 byte.............................................................................................9Bảng 2. 11: Một số giá trị trong trường Content Type...............................................................9Hình 2. 12: Các khối dữ liệu của một đối tượng AMF có chỉ số là 0x03.................................10Hình 2. 13: Truyền các khối dữ liệu xen kẽ nhau.....................................................................11Bảng 2. 14: Kiểu dữ liệu trong AMF0......................................................................................12Hình 2. 15: Kiểu dữ liệu của AMF3.........................................................................................14Bảng 2. 16: Kiều thông điệp Shared Object.............................................................................16Hình 2. 17: Ngưỡng âm thanh của tai người phụ thuộc vào tần số..........................................17Hình 2. 18: Ngưỡng âm thanh của tai người phụ thuộc vào thời gian......................................18Hình 2. 19: Ngưỡng âm thanh theo tần số, thời gian, và biên độ.............................................18Hình 2. 20: Biểu đồ hoạt động của thuật toán nén âm thanh....................................................18Hình 2. 21: Ba loại profile của AAC........................................................................................20Hình 2. 22: Bộ mã hoá âm thanh AAC.....................................................................................21Hình 2. 23: Bộ giải mã âm thanh AAC.....................................................................................22Hình 2. 24: Module mã hoá và giải mã điều chỉnh khuếch đại................................................23Hình 2. 25: Tập 12 dải tần số và đặc tả.....................................................................................24Hình 2. 29: Mức tần số giới hạn cho thuật toán dự đoán..........................................................25Hình 2. 30: Họ chuẩn nén AAC................................................................................................26Hình 2. 31: Việc chuyển đổi trong quá trình tạo ra dãy tần số cao...........................................26Hình 2. 32: Chỉnh đường biên của dãy tần số cao....................................................................27Hình 2. 33: Nguyên lý cơ bản của quá trình xử lý PS..............................................................28Hình 2. 34: Biểu đồ bộ mã hoá HE-AAC.................................................................................28Hình 2. 35: Biểu đồ bộ mã hoá HE-AAC.................................................................................28Hình 2. 36: So sánh hiệu quả của các chuẩn nén họ AAC........................................................29Hì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......................29Hình 2. 38: Minh họa cách chia ảnh thành các khối trước khi biến đổi Cosine.......................30Hì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......................31Hình 2. 49: Ví dụ về một bảng mã............................................................................................32Hình 2. 50: Sơ đồ nén ảnh JPEG..............................................................................................34Hình 2. 51: Sơ đồ giải nén ảnh JPEG.......................................................................................34Hình 2. 52: Sơ đồ bộ mã hóa MPEG-4/H.264..........................................................................35Hình 2. 53: Sơ đồ bộ giải mã MPEG-4/H.264..........................................................................35Hình 2. 54: Thứ tự khối ảnh được mã hóa................................................................................36Hình 2. 55 Các cách chia khối ảnh nhỏ hơn.............................................................................37Hình 2. 56: Minh họa cách chia các khối ảnh khi mã hóa........................................................37Hình 2. 57: Tinh vector chuyển động.......................................................................................37Hình 2. 58: Nhãn của các mẫu dự đoán....................................................................................38Hình 2. 59: Các chế độ mã hóa khối ảnh..................................................................................38Hình 2. 60: Ví dụ minh họa cho các chế độ mã hóa khối.........................................................39

Phạm Thái Bảo – Đ04THA1 iii


Hình 2. 61: Cấu trúc hệ thống PACS........................................................................................41Hình 2. 62: Sơ đồ hoạt động của cổng nhận ảnh......................................................................42Hình 2. 63: Luồng dữ liệu khái quát của kiến trúc stand – alone.............................................43Hình 2. 64: Luồng dữ liệu tổng quát của kiến trúc client-server..............................................45Hình 2. 65: Máy chủ chứa ảnh dựa vào web............................................................................47Hình 2. 66: Các thiết bị tạo,lưu trữ và truyền ảnh DICOM......................................................50Bảng 2. 67: So sánh các dung lượng các ảnh của một số chuẩn DICOM hỗ trợ......................51Hình 2. 68: DICOM và mô hình tham chiếu OSI.....................................................................53Hình 2. 69: Ví dụ về ảnh MRI..................................................................................................53Hình 2. 70: Ví dụ về một số trường của ảnh DICOM...............................................................54Hình 2. 71: Lớp dịch vụ và lớp đối tượng.................................................................................55Hình 2. 72: Minh họa đối tượng ảnh.........................................................................................56Hình 2. 73: Các dịch vụ của DICOM.......................................................................................56Hình 2. 74: Các dịch vụ DIMSEs tiêu chuẩn............................................................................57Hì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................57Hình 2. 76: Khuôn dạng file DICOM.......................................................................................58Hình 2. 77 Mô hình hệ thống dcm4chee...................................................................................61Bảng 2. 78: Một số tính năng của dcm4chee............................................................................61Hình 2. 79: Mô hình kiến trúc của hệ thống HIS......................................................................62Hình 2. 80: Hệ thống máy chủ tập trung...................................................................................63Hình 2. 81: Hệ thống tập trung + hệ thống song song ở phòng xét nghiệm.............................63Hình 2. 82: Hệ thống hướng đến máy trạm với cơ sở dữ liệu tập trung...................................63Hình 2. 83: Chức năng và cơ sở dữ liệu của mỗi bộ phận độc lập nhau...................................64Hình 2. 84: Định dạng một file HL7.........................................................................................65Hình 2. 85: Mô hình cơ bản......................................................................................................66Hình 2. 86: Một mô hình cụ thể cho hệ thống Java..................................................................67Hình 2. 87: Cơ chế hoạt động của tính năng mở rộng..............................................................68Hình 2. 88: Di chuyển User......................................................................................................68Hình 3. 1: Giao diên web của Client.........................................................................................71Hình 3. 2: Khởi động Server WebF..........................................................................................72Hình 3. 3: Kết nối thành công...................................................................................................72Hình 3. 4: Bắt tay RTMP giai đoạn một...................................................................................73Hình 3. 5: Bắt tay giai đoạn 2..................................................................................................74Hình 3. 6: Bắt tay giai đoạn 3...................................................................................................74Hình 3. 7: Sơ đồ gửi, trả lời thông điệp kết nối giữa client và server.......................................75Hình 3. 8: Sơ đồ gửi, trả lời thông điệp publish giữa client và server......................................76Hình 3. 9: Sơ đồ gửi, trả lời thông điệp play giữa client và server...........................................76Hình 3. 10: Mô hình luồng dữ liệu giữa client và server khi chuyển dữ liệu video.................77Hình 3. 11: Kết quả thử nghiệm................................................................................................77Hình 3. 12: Kết nối tới Server...................................................................................................78Hình 3. 13: Kết nối thành công.................................................................................................79Hình 3. 14: Tính năng Shared Object.......................................................................................79Hình 3. 15: Thông điệp thiết lập dữ liệu của Shared Object được gửi về Server.....................80Hình 3. 16: Sử dụng tính năng Shared Object..........................................................................80Hình 3. 17: Tìm kiếm thông tin bệnh nhân...............................................................................81Hình 3. 18: Thông điệp “searchPatient” giúp tìm kiếm bệnh nhân..........................................81Hình 3. 19: Thông điệp “getFreemedInfo” lấy thông tin của bệnh nhân trong FreeMED.......82Hì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.............82Hình 3. 21: Thông điệp “getDicomofPatient” giúp lấy ID ảnh thông qua ID của bệnh nhân. .83Hình 3. 22: Thông điệp lấy ảnh Thumbnail của ảnh DICOM tương ứng.................................83Hình 3. 23: Ảnh thumbnail được hiện thị sau khi lấy về từ Server..........................................84Hình 3. 24: Ảnh thật tương ứng với ảnh thumbnail được chọn................................................84

Phạm Thái Bảo – Đ04THA1 iv


Hình 3. 25: Thông điệp “getDICOMInformation” giúp lấy thông tin chứa trong ảnh DICOM...................................................................................................................................................85Hình 3. 26: Kết quả thông tin chứa trong ảnh DICOM sau khi được lấy về............................85

Phạm Thái Bảo – Đ04THA1 v

Báo cáo Đồ án tốt nghiệp CÁC THUẬT NGỮ VIẾT TẮT

CÁC THUẬT NGỮ VIẾT TẮT

AAC Advanced Audio Coding ..................................17, 20, 21, 24, 25, 26, 27, 28, 30AMF Action Message Format ....................................................8, 9, 10, 11, 12, 13, 14DCMTK DICOM Toolkit ..................................................................................................59DCT Discrete Cosine Transform ..............................................................................32DICOM Digital Imaging and Communications in Medicine ...........55, 56, 57, 58, 59DIMSE DICOM Message Sevice Elements .................................................................57DVTS Digital Video Transport System ...................................................................2, 3HE-AAC High Efficiency AAC ........................................................................5, 17, 26, 30HIS Hospital Information System ..................................................41, 43, 44, 49, 63HL7 Health Level Seven ......................................................................2, 48, 49, 66, 67JPEG Joint Photographic Experts Group ...................................................31, 35, 48LC Low Complexity .................................................................................................21MDCT Modified Discrete Cosine Transform ......................................................24, 25MPEG Moving Picture Experts Group ............................17, 20, 26, 27, 28, 29, 31, 36PACS Picture Archiving & Communication System .....................46, 47, 48, 49, 50PS Parametric Stereo ..................................................................................26, 27, 29RLC Run Length Coding ...........................................................................................31RTMP Real Time Messaging Protocol .........................................2, 8, 9, 10, 12, 70, 71RTP Realtime Transport Protocol............................................................, 7, 8, 12SBR Spectral Band Replication .......................................................26, 27, 28, 29, 30SSR Scalable Sampling Rate Profile ......................................................................21TCP Transmission Control Protocol ......................................6, 8, 12, 44, 49, 71, 87UDP User Datagram Protocol ..........................................................................6, 8VLC Variable Length Coding .......................................................................31, 33, 35

Báo cáo Đồ án tốt nghiệp CHƯƠNG I: TỔNG QUAN

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.

Phạm Thái Bảo – Đ04THA1 1

Báo cáo Đồ án tốt nghiệp CHƯƠNG II: LÝ THUYẾT

CHƯƠNG II: LÝ THUYẾT

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ỏ.

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ểmKhả 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ùngNhượ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 ServerKiế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ầngHệ 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ệuMạ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 2. 4: Vùng đệm dùng cho việc playback

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 RTPGiao 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.

Hình 2. 5: 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 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.



2.3.2.2. Đóng gói RTPTừ 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 2. 6: 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.

2.3.3. Giao thức RTMP (Real Time Messaging Protocol)

2.3.3.1. Giới thiệuRTMP 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.

Đâ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.

2.3.3.2. Các chế độ hoạt động của RTMPRTMP ở chế độ tiêu chuẩn chạy trên TCP với cổng mặc định là 1935. Ngoài ra

RTMP 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 2. 7: RTMP ở chế độ tiêu chuẩn

Hình 2. 8: RTMP ở chế độ đường hầm



2.3.3.3. Quá trình bắt tayHoạ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 đó.

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 2. 9: 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.

2.3.3.4. Tiêu đề RTMPRTMP 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 0x03: tiêu đề 1 byteSá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 2. 10: 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.

Bảng 2. 11: Một số giá trị trong trường Content Type

2.3.3.5. Truyền tải nhiều đối tượng AMF trên cùng một kết nốiMỗi đối tượng AMF được chia thành các khối dữ liệu có kích thước 128 byte

(ngoại trừ audio có kích thước 64 byte) . Khối đầu tiên thường được gắn tiêu đề 12



byte, các khối tiếp theo thường được gắn tiêu đề 1 byte, trong bất kì loại tiêu đề nào cũng có chứa chỉ số của đối tượng AMF tương ứng.

Hình 2. 12: Các khối dữ liệu của một đối tượng AMF có chỉ số là 0x03

Để có thể truyền nhiều đối tượng AMF trên một kết nối đơn người ta không truyền các khối dữ liệu của một đối tượng AMF liên tiếp nhau mà truyền xen kẽ các khối dữ liệu của nhiều đối tượng AMF.



Hình 2. 13: Truyền các khối dữ liệu xen kẽ nhau.

2.3.4. So sánh giữa RTP và RTMPHai giao thức RTP và RTMP rõ ràng không cung cấp cơ chế để chuyển phát đúng

thời hạn, điều này phải được đảm bảo hệ thống cơ sở. Chúng chỉ cung cấp cơ chế timestamp để kiểm soát việc playback. Trong RTP có sequence number để kiểm tra trật tự các gói còn trong RTMP việc này được đảm bảo bởi TCP. Cả hai cùng phải sử dụng cơ chế vùng đệm để giảm jitter.

Có thể nói khả năng của hai giao thức này là tương đương nhau. Việc chọn RTMP trong đề tài là do nó gắn liền với Flash. Sở dĩ sử dụng Flash là vì tính đơn giản, khả chuyển và mềm dẻo của nó.

2.4. Chuẩn mã hoá dữ liệu - AMF (Action Message Format)AMF là một định dạng dùng ghép nối tiếp các dữ liệu được dùng để giao tiếp thông

qua môi trường mạng. AMF giúp mã hoá và định nghĩa các kiểu dữ liệu cần tương tác giữa hai hệ thống. Thông qua AMF, các hệ thống đầu cuối sẽ hiểu được dữ liệu được chuyền từ hệ thống khác là kiểu dữ liệu gì. AMF được giới thiệu đầu tiên 2001 trong Flash Player 6 là AMF0. Sau này được phát triển thêm thành AMF 3 trong Flash Player 9. Tuy nhiên AMF0 vẫn còn được hỗ trợ để tương thích lùi.



2.4.1. AMF0

2.4.1.1. Giới thiệuNhư đã giới thiệu ở trên AMF0 là phiên bản đầu tiên của AMF giúp ghép nối các

đối tượng dữ liệu, chứa thông tin về kiểu của của dữ liệu. AMF0 cũng hỗ trợ truyền các kiểu dữ liệu phức tạp bằng cách dùng tham chiếu để tránh dư thừa dữ liệu.

2.4.1.2. Kiểu dữ liệu AMF0Trong AMF0, các kiểu dữ liệu được đánh dấu bằng một 1 byte. Theo sau đó là dữ

liệu theo đúng những gì đã được mô tả ở byte đánh dấu phía trước.Các kiểu dữ liệu của AMF0 được liệt kê ngay sau đây:

Kiểu số 0x00

Kiểu logic 0x01

Kiểu chuỗi 0x02

Kiểu đối tượng 0x03

Kiểu null 0x05

Kiểu tham chiếu 0x07

Kiểu mảng ECMA 0x08

Đánh dấu kết thúc đối tượng 0x09

Kiểu mảng dày 0x0A

Kiểu ngày tháng 0x0B

Kiểu chuỗi dài 0x0C

Kiểu XML 0x0F

Kiểu lớp 0x10 Bảng 2. 14: Kiểu dữ liệu trong AMF0

Kiểu số được dùng để mã hoá một số ActionScript. Dữ liệu theo sau một marker luôn luôn là 8 byte số dấu chấm động double IEEE-754

Kiểu_số = đánh_dấu DOUBLE Kiểu logic được dùng để mã hoá kiểu nguyên thuỷ logic của ActionScript. Một

byte đánh dấu là kiểu logic, theo sau đó là một byte chỉ giá trị của dữ liệu logic. Giá trị này bằng 0 là false, bằng 1 là true.

Kiểu_logic = đánh_dấu U8 (số nguyên không dấu 8 bit) Kiểu chuỗi được dùng để mã hoá bất kì một chuỗi nào có độ dài nhỏ hơn 65525

kí tự. Nếu chuỗi nào dài hơn độ dài này thì sẽ chuỗi kiểu chuỗi dài.Kiểu_chuỗi = đánh_dấu UTF-8

Kiểu đối tượng được dùng để mã hoá kiểu object của ActionScript. Kiểu này tương đối phức tạp được ghép nối như sau:

Kiểu_đối_tượng = đánh_dấu (UTF-8 giá_trị)(UTF-8 giá_Trị)…(UTF-8 giá_Trị) UTF-8_rỗng đánh_dấu_kết_thúc

Kiểu null chỉ được biểu diễn bằng byte đánh dấu kiểu, và không có thông tin đính kèm theo sau.



Kiểu_null = đánh_dấu Kiểu tham chiếu được dùng để chỉ lại dối tượng đã mã hoá phía trước mà không

cần phải truyền lại, tránh dư thừa dữ liệu. Kiểu dữ liệu tham chiếu sử dụng số nguyên 16 bit đề dùng như một chỉ mục và bắt đầu bằng 0.

Kiểu_tham_chiếu = đánh dấu U16 Kiểu mảng ECMA được xem như là một kiểu phức tạp của AMF0. Kiểu này có

thể được sử dụng kèm với kiểu tham chiếu cho dữ liệu của nó. Sau byte đánh dấu là một byte chỉ kích thước của mảng, và tiếp theo sau đó là dữ liệu của mảng.

Kiểu_mảng_ECMA = đánh_dấu U32 U32*(UTF-8 gia_tri) UTF-8_rỗng đánh_dấu_kết_thúc

Kiểu mảng dày chứa dữ liệu cần truyền đi. Kiểu_mảng_dày = dánh dấu U32 U32*giá_tri

Kiểu chuỗi dài được sử dụng trong AMF0 để mã hoá một chuỗi chiếm chiều dài nhiều 65535.

Kiểu_chuỗi_dài = dánh_dấu UTF-8_dài Kiểu ngày tháng được dùng để mã hoá số lượng ms đã qua để từ ngày 1 tháng 1

năm 1970 giờ UTCMúi_giớ = S16 (số nguyên có dấu 16 bit)Kiểu_ngày_tháng = đánh_dấu DOUBLE Múi_giờ

Kiểu XML cũng được hỗ trợ trong AMF0 khi dùng để ghép nối dữ liệu trong chuỗi XML. AMF0 coi Kiểu XML giống như những kiẻu chuỗi dài khác.

Kiểu_XML = đánh_dấu UTF-8_dài Kiểu lớp là kiểu được dùng để ghép nối các dữ liệu trong một lớp lại thành một

chuỗi gửi đi. Kiểu lớp cũng có thể được sử dụng kèm với kiểu tham chiếu.Tên_lớp = UTF-8Kiểu_lớp = đánh_dấu Tên_lớp (UTF-8 giá_trị) (UTF-8 giá_trị) … (UTF-8 giá_trị) UTF-8_rỗng đánh_dấu_kết_thúc

2.4.2. AMF32.4.2.1. Giới thiệu

AMF3 là một phiên bản mới của AMF, nhằm cải tiến những hạn chế của AMF0. Cải tiến của AMF3 là hạn chế lại việc truyền dư thừa dữ liệu và bổ sung thêm một số kiểu dữ liệu mới.

2.4.2.2. Kiểu dữ liệu AMF3Trong AMF3, mỗi kiểu dữ liệu cũng được bắt đầu bằng một byte chiều dài, tiếp

theo là dữ liệu tương ứng với dữ liệu được mô tả ở byte đánh dấu. Giá trị của byte đánh dấu có ý nghĩa như sau:

Kiểu undefined 0x00

Kiểu null 0x01

Kiểu logic false 0x02

Kiểu logic true 0x03

Kiểu số nguyên 0x04

Kiểu số double 0x05

Kiểu chuỗi 0x06



Kiểu văn bản XML 0x07

Kiểu ngày tháng 0x08

Kiểu mảng 0x09

Kiểu đối tượng 0x0A

Kiểu XML 0x0B

Kiểu mảng byte 0x0C Hình 2. 15: Kiểu dữ liệu của AMF3

Kiểu undefined chỉ được biểu diễn bằng byte đánh dấu không có dữ liệu đi kèm theo sau.

Kiểu_undefined = đánh_dấu Kiểu null cũng giống như Kiểu undefined chỉ được biểu diễn bằng byte đánh

dấu và không có dữ liệu đi kèm theo sau.Kiểu_null = đánh_dấu

Kiểu logic false, Kiểu logic true được dùng để thay thế cho Kiểu logic ở AMF0, cái giá trị logic được biểu diễn kèm theo byte đánh dấu.

Kiểu_logic_false = đánh_dấu_logic_falseKiểu_logic_true = đánh_dấu_logic_true

Kiểu số nguyên được dùng để mã hoá số nguyên không dấu 29 bit theo cú pháp ABNF (Augmented Backus-Naur Form)

Kiểu_số_nguyên = đánh_dấu U29 Kiểu double được dùng để mã hoá một số, Kiểu này cũng được dùng thay cho

Kiểu số nguyên nếu số có giá trị lớn hơn 229. Kiểu này bao gồm một số dấu chấm động IEEE-754 theo sau một byte đánh dấu.

Kiểu_double = đánh_dấu DOUBLE Kiểu chuỗi được dùng để biểu diễn một chuỗi trong AMF3 và dùng tương

đương như chuỗi dài trong AMF0Kiểu_chuỗi = đánh_dấu UTF-8-vr

Kiểu văn bản XML được dùng để mã hoá Kiểu XMLDocument trong ActionScript. Chiều dài của một văn bản XML được giới hạn trong 256MB

Kiểu_văn_bản_XML = đánh_dấu UTF-8 Kiểu ngày tháng có ý nghĩa giống như trong AMF0.

Kiểu_ngày_tháng = đánh_dấu (U29_1 | U29_2 DOUBLE)U29_1 có bit đầu tiên là 0 chỉ kiểu ngày tháng tham chiếu, U29_2 có bit đấu tiên là 1 tiếp theo sau là một DOUBLE chỉ số lượng ms từ ngày 1 tháng 1 năm 1970 tới thời điểm hiện tại tính theo giờ UTC.

Kiểu mảng được sử dụng thay cho kiểu ECMA, mảng dày đặc của AMF0.Kiểu_mảng = đánh_dấu (U29_1 | U29_2 (Kiểu_ECMA | Kiểu_mảng_dày))

Kiểu đối tượng được dùng để chất lượng đối với các kiểu Object của ActionScript và kiểu lớp của người dùng

Kiểu_mảng = đánh_dấu (kiểu_đối_tượng | kiểu_lớp) Kiểu XML được dùng để mã hoá đối tượng XML của ActionScript có hỗ trợ cú

pháp E4X. Nội dung của kiểu này được xử lý giống như một UTF-8Kiểu_XML = đánh_dấu (U29_1 | U29_2 UTF-8)



Kiểu mảng byte là một kiểu mới được hỗ trợ trong AMF3 so với AMF0. Kểu này cũng tượng tự như kiểu mảng của AMF3 nhưng các phần tử của nó là các byte.

Kiểu_mảng_byte = đánh_dấu (U29_1 | U29_2 n*(U8))

2.5. Shared Object

2.5.1. Giới thiệuShared Object cũng giống như Cookie của giao thức HTTP, là chứa một số dữ liệu

nào đó được sử dụng chung giữa Server và Client, và giữa các Client với nhau. Ngoài ra Shared Object còn cho phép gửi các thông điệp lẫn nhau giữa các đối tượng sử dụng chung cùng một Shared Object. Có hai loại Shared Object là Shared Object cục bộ và Shared Object từ xa.

Shared Object cục bộ được lưu trữ cục bộ trên máy của người dùng và Shared Object này chỉ được sử dụng chung bởi Client và Server.

Shared Object từ xa được lưu trên Server, và được sử dụng chung giữa các Client, hỗ trợ cho các Client trong việc chia sẻ dữ liệu dùng chung. Với loại Shared Object này Server có nhiệm vụ đồng bộ dữ liệu của Shared Object mỗi khi Client thay đổi giá trị của nó.

2.5.2. Shared Object và CookieBảo mậtShared Object và Cookie đều hoạt động dựa trên cơ chế giống nhau dựa trên truy

cập cục bộ và xác thực dựa trên domain.Kích thước tập tinTất cả các Server khi thiết kế đều giới hạn số cookie được lưu trên máy của người

dùng. Đặc tả Cookie trong giao thức HTTP có thể xem trong RFC 2190. Thông thường một trình duyệt web giới hạn khoảng 300 Cookie (20 Cookie mỗi domain). Và kích thước của mỗi Cookie là 4000 byte.

Shared Object thì ngược lại được lưu mà không có giới hạn về kích thước. Tuy nhiên, người dùng sẽ được hỏi là có đồng ý tiếp tục lưu hay không khi Shared Object lớn 100KB.

Kiểu dữ liệuKhi sử dụng Cookie, kiểu dữ liệu sẽ bị giới hạn. Còn Shared Object hỗ trợ rất nhiều

kiểu dữ liệu trong đó bao gồm cả kiểu chuỗi, XML, số, boolean, null, mảng, object. Hơn nữa với Shared Object có hỗ trợ kiểu class do người dùng định nghĩa.

2.5.3. Kiểu thông điệp của Shared ObjectĐể Server dễ dàng quản lý các đối tượng Shared Object, các thông điệp sau được định nghĩa:

0×01 Kết nối 0×02 Huỷ kết nối0×03 Thiết lập thuộc tính0×04 Cập nhật dữ liệu0×05 Cập nhật thuộc tính0×06 Gửi thông điệp0×07 Trạng thái0×08 Xoá nội dung dữ liệu



0×09 Xoá dữ liệu0x0A Xoá thuộc tính0x0B Khởi tạo dữ liệu

Bảng 2. 16: Kiều thông điệp Shared Object

2.6. Chuẩn nén âm thanh HE-AAC

2.6.1. Số hóa âm thanhNếu muốn thực hiện truyền âm thanh trên mạng số, trước tiên cần phải số hóa nó

bằng cách dùng bộ chuyển đổi tín hiệu từ tín hiệu tương tự sang tín hiệu số (A/D Analog-to-Digital).Để đạt độ chính xác cao khi khôi phục tín hiệu âm thanh thì tần số lấy mẫu phải lớn hơn hai lần tần số của tín hiệu âm thanh. Trong mạng thoại người ta thường sử dụng tần số lấy mẫu là 8 KHz nhưng để phục vụ cho việc hội chẩn từ xa thì cần sử dụng tần số lấy mẫu cao hơn 11 KHz, 22 KHz,…bởi vì âm thanh trong hội chẩn từ xa không chỉ là giọng nói của bác sĩ mà có thể là nhịp tim, nhịp thở của bệnh nhân nên cần phải được truyền một cách chính xác.

Chuẩn được sử dụng để nén âm thanh là HE-AAC được phát triển từ chuẩn AAC. Chuẩn này cung cấp khả năng nén âm thanh với hiệu suất cao nhưng vẫn đáp ứng được chất lượng tốt.

2.6.2. Chuẩn AAC

2.6.2.1. Giới thiệuChuẩn nén AAC trước đây là một phần của MPEG-2, nhưng sau này được mở rộng

và bổ sung thêm như là một phần của MPEG-4. AAC là kết quả của một nỗ lực lớn có tính chất quốc tế của nhiều công ty và cá nhân. Dự án phát triển AAC được khởi động 1994 khi có số lượng lớn đề nghị được đệ trình lên uỷ ban của MPEG. Uỷ ban này sau đó đã tiến tới xây dựng một cấu trúc cho chuẩn AAC bao gồm nhiều module khác nhau mà các module này đóng vai trò như là các thành phần độc lập nhau. Các module này được phát triển và kiểm tra một cách riêng biệt trước khi hợp lại thành sản phẩm cuối cùng. Các module chính bao gồm:

Điểu chỉnh khuếch đại (Gain Control) Bộ lọc (FilterBank) Dự đoán (Prediction) Lượng tử (Quantization) Mã hoá Huffman (Noiseless Huffman Coding) Ghép luồng bit (Bitstream Multiplexing) Nắn nhiễu (Temporal Noise Shaping - TNS) Mid/side (M/S) stereo coding Mã hoá cường độ (Intensity Stereo Coding)

2.6.2.2. Đặc tính âm học của tai ngườiCác nhà khoa học, các kĩ sư và các chuyên gia đã áp dụng đặc tính của hệ thống

cảm nhận âm thanh của con người để thực hiện việc nén âm thanh. Các nhà khoa học khi nén âm thanh đã làm giảm hoặc loại bỏ hoàn thành những phần âm thanh mà con người không cảm nhận được. Hình sau đây mô tả chi tiết về đặc tính cảm nhận âm thanh của tai người. Trong hình có một đường cong biểu diễn ngưỡng nghe của tai người. Nếu âm thanh có các đặc tính âm học nằm phía dưới đường cong này thì tai



người không cảm nhận được. Theo như hình, đặc tính cảm nhận âm thanh của tai người phụ thuộc nhiều vào tần số. Ngưỡng dưới biên độ của âm thanh cao ở cả tần số cao và tần số thấp. Để âm thanh ở các tần số này có thể nghe được, thì nó cần phải được khuếch đại lên cao hơn mức ngưỡng. Ngưỡng mà tai người có thể nghe được thấp nhất ở trong khoảng tần số từ 3KHz – 5KHz, điều này cho thấy rằng tai người rất nhạy cảm với âm thanh ở tần số này và có thể nhận biết những âm thanh dù là nhỏ nhất

Hình 2. 17: Ngưỡng âm thanh của tai người phụ thuộc vào tần số

Tuy nhiên vẫn còn có những điểm mà tại đó tai người cũng không thể nghe thấy được mặc dù cường độ âm thanh lớn hơn mức ngưỡng. Trên hình có một đường cong đứt nét chỉ ra rằng với những âm thanh ở khoảng tần số này, tai người không thể nghe thấy được những âm thanh có cường độ cao hơn mức biểu diễn của đường cong đứt nét này.

Thời gian cũng là một nhân tố ảnh hưởng tới khả năng cảm nhận âm thanh. Hình sau đây biểu diễn một ngưỡng khác về khả năng cảm nhận âm thanh của tai. Lúc đầu một âm thanh 60dB (ở một tần số f nào đó) kéo dài trong vòng 5ms, tai người có thể cảm nhận được âm thanh này. Nhưng nếu âm thanh “x” 30 dB xuất hiện sau đó 5ms thì không thể nghe được vì nó bị lấn át bởi âm thanh 60dB xuất hiện trước đó. Nhưng cũng với âm thanh “x” 30 dB này xuất hiện sau đó 10ms thì tai có thể nghe được. Như vậy, tai người cũng có thể bị lấn át bởi các âm thanh lớn trong vòng một khoảng thời gian mà trong khoảng thời gian này tai người không thể bị kích thích bởi các âm thanh khác nữa.



Hình 2. 18: Ngưỡng âm thanh của tai người phụ thuộc vào thời gian

Tiếp theo sau đây là hình biểu diễn tính chất âm học của tai ở các khía cạnh tần số thời gian và biên độ.

Hình 2. 19: Ngưỡng âm thanh theo tần số, thời gian, và biên độ

2.6.2.3. Hoạt động của thuật toán nén âm thanh AACDựa vào tính chất này của tai, thuật toán nén mất âm thanh theo tần số và thời gian

làm việc theo các bước sau.

Hình 2. 20: Biểu đồ hoạt động của thuật toán nén âm thanh

Đầu tiên các tin hiệu âm thanh sau khi đã lấy mẫu được gom thành những nhóm gối lên nha (tức là dùng những cửa sổ trượt) rồi đưa vào bộ lọc (Filter Bank). Tại bộ lọc, mỗi cửa sổ sẽ được chuyển thành các giá trị tần số. Các giá trị này tương ứng với một khoảng của tần số (dải tần số) và chỉ ra cường độ của âm thanh ở dải tần số này.

Sử dụng các giá trị này để quyết định nhưng âm thanh bị che (loại bỏ). Khi quyết định âm thanh nào bị che, một mô hình cảm giác (Perceptual model) được sử dụng. Mô hình này đưa ra các thông số về ngưỡng cụ thể cho từng loại tần số để quyết định xem những giá trị tần số nào là không quan trọng.

Các giá trị tần số sẽ được lượng tử rồi được mã hoá bằng loại mã có chiều dài thay đổi. Các từ mã này là kết quả của cả quá trình trên.



Nhiệm vụ đầu tiên của bộ mã hoá là lấy các mẫu âm thanh rồi tính toán ra các tần số của sóng âm thanh biểu diễn những âm thanh này. Trên thực tế là các khoảng âm thanh (hay dải âm thanh) được tính toán ra, và một hệ số tần số ( hay hệ số phổ) được tính toán cho một dải âm thanh. Độ rộng của dải phải không được vượt quá bộ rộng của dải âm thanh của tai người. Điều này được hoàn thành bởi ngân hàng bộ lọc. Đối với mp3, 512 mậu được lưu trong bộ đệm và được tính toán cho 32 dải tần số. Sau đó 32 mẫu âm thanh tiếp theo được chuyển vào bộ đệm và quá trình được lặp lại. Còn đối vời AAC cũng thực hiện như trên nhưng sử dụng 2048 mẫu âm thanh, tính toán cho 1024 hệ số phổ, mỗi hệ số biểu diễn cho một dải băng tần rộng 23.4 Hz, và sau đó 1024 mẫu âm thanh tiếp theo được chuyển vào trong bộ đệm.

Thành phần tiếp theo là mô hình cảm giác. Nó quyết định độ cao của ngưỡng cho mỗi dải tần số. Trong mp3, mô hình này không được đặc tả chi tiết và do đó mỗi nhà thiết kế lại cho ra những mô hình của riêng họ. Sự thành công của mỗi mô hình phụ thuộc nhiều vào sự chi tiết và sự giống nhau của nó với mô hình của tai người. Còn AAC cũng tương tự với mô hình cảm giác mà không đặc tả hoạt động chính xác của nó.

Đối với mỗi dải tần số, bộ mã hoá so sánh hệ số của phổ so với ngưỡng của dải tần số. Nếu hệ số phổ nhỏ hơn ngưỡng thì hệ số được lượng tử theo dải tần số tương ứng. Nếu lượng tứ quá nhiều sẽ làm giảm chất lượng của âm thanh và nhiễu rất cao. Ngược lại nếu lượng tử không đủ thì sẽ không đáp ứng được tốc độ bit đề ra.

Do đó AAC bổ sung thêm một số công cụ phục vụ cho việc tăng chất lượng của quá trình lượng tử:

TNS là một thuật toán tinh vi mà làm giảm thiểu ảnh hưởng của “trải rộng thời gian” Điều này làm tăng hầu hết khả năng lượng tử của các tín hiệu giọng nói.

Module dự đoán tăng hiệu suất của bộ lượng tử trong trường hợp âm thanh gốc giống với mẫu cò sẵn, như là âm giọng cao (âm thanh có dạng hình sin).

Bước kế tiếp là mã hoá (coding). Hệ số phổ sau được lượng tử sẽ được mã hoá. Bước này cũng đóng góp vào việc làm tăng khả năng nén bởi vì hệ số được thay thế bởi các từ mã có kích thước thay đổi, nhưng với cách mã hoá này thì không làm mất dữ liệu. Cả mp3 và AAC đều sử dụng mã Huffman.

Như vậy, AAC chia sẻ những điểm mạnh của mp3 dồng thời có nhưng cải tiến như sau:

Ngân hàng bộ lọc lớn hơn với 1023 hệ số phổ được tao ra từ cửa sổ 2048 mẫu âm thanh, dẫn tới dải tần số hẹp hơn do đó có chất lượng âm thanh khi giải nén tốt hơn mp3.

Temporal noise shaping (TNS) một thuật toán mới cho phép giải thiểu đến thấp nhất ảnh hưởng của … điều này đặc biệt hữu dụng đối với nén tín hiệu giọng nói.

Module dự đoán làm tăng khả năng lượng tử cho nhưng âm thanh theo chu kì hoặc những âm thanh theo mẫu có sẵn.

2.6.2.4. Mô tả chi tiết về AACSau đây là phầm mô tả chi tiết về AAC được định nghĩa trong MPEG-2 và những

tính năng được thêm vào AAC trong MPEG-4.AAC hỗ trợ 3 loại profile. Mỗi loại profile là một hồ sơ miêu tả cấu hình cấu hình

khác của các thuật toán cơ bản và các profile này cung cấp các thoả hiệp khác nhau



giữa hiệu suất nén và độ phức tạp của bộ mã hoá (ảnh hưởng đến khả năng thực hiện của máy tính). Một chỉ mục 2 bit chỉ profile nào sử dụng sẽ được lưu lại sau khi nén.

Index Profile0123

ChínhĐộ phức tạp thấpTốc độ lấy mẫu thay đổiDự trữ

Hình 2. 21: Ba loại profile của AAC

Index 0, profile chính (Main Profile). Trong profile này, AAC đưa ra khả năng nén tốt nhất cho bất cứ tốc độ bit và tốc độ lấy mẫu nào. Tất cả các module, các hàm, và các công cụ của đặc tả ( ngoại trừ công cụ điểu chỉnh khuếch đại) đều được miêu tả. Đây là profile thông dụng và nó được thực hiện khi có đủ bộ nhớ và năng lực xử lý (hiện nay thì tất cả các máy tính đều có thể áp dụng được).

Index 1, profile độ phức tạp thấp (Low Complexity Profile – LC Profile). Điều chỉnh khuếch đại và dự đoán không được sử dụng. Và TNS cũng bị giới hạn còn 12. Mặt khác, LC là một profile con của profile chính cho nên là LC có thể được giải mã bởi bộ giải mã của profile chính.

Index 2, profile tốc độ lấy mẫu thay đổi (Scalable Sampling Rate Profile - SSR). Profile này được thiết kế để làm đơn giản độ phức tạp tính toán khi dữ liệu âm thanh gốc chỉ gồm những khoảng tần số giới hạn (như vậy sẽ làm giảm băng thông sau khi được mã hoá). Công cụ điều chỉnh khuếch đại được yêu cầu trong SSR và công cụ này chỉ được sử dụng duy nhất trong SSR. Order của TNS và băng thông cũng bị giới hạn. Một luồng nén của LC có thế giải mã được bởi SSR nhưng kết quả của âm thanh sau khi giải mã sẽ bị giới hạn

Index 3 được dự trữ cho profile trong tương lai.

Điều chỉnh khuếch đại là công cụ tiền xử lý và chỉ được sử dụng trong profile SSR. Nó bao gồm nhiều module lọc, nhận dạng độ khuếch đại, thay đổi độ khuếch đại. Điều chỉnh khuếch đại bắt đầu bằng việc lọc dữ liệu đầu vào tạo thành bốn băng tần rộng 6 KHz. Các hệ số phổ của mỗi dải tần số được kiểm tra bởi bộ nhận dạng dộ khuếch đại, Bộ nhận dạng tìm kiếm các thay đổi mạnh trong độ khuếch đại của tín hiệu (nghĩa là các hệ số liên tục nhau rất khác nhau về kích thước). Bộ thay đổi độ khuếch đại sử dụng các kết quả này để thêm vào các hệ số này nhằm làm tăng khả năng nén tín hiệu âm thanh đầu vào.



Hình 2. 22: Bộ mã hoá âm thanh AAC



Hình 2. 23: Bộ giải mã âm thanh AAC



Hình 2. 24: Module mã hoá và giải mã điều chỉnh khuếch đại

Filtering, bộ mã hoá AAC chuyển đổi các mẫu âm thanh thành các hệ số tần số bằng biến đổi cosin rời rạc cải biên (MDCT). Quá trình xử lý giống với mp3, nhưng với độ phân giải tần số cao hơn và có nhiều cải tiến hơn. Bộ mã hoá sử dụng hai loại cửa sổ: dài và ngắn. Cửa sổ dài gồm có 2048 mẫu liên tục nhau và được biến đổi để tạo ra 1024 hệ số tần số (biến đổi dài). Một cửa sổ ngắn hơn có 256 mẫu và đưa ra kết quả là 128 hệ số (biến đổi ngắn). Một khi hệ số của một cửa sổ đã được tính toán thì bộ mã hoá chuyển vào thêm một số mẫu mới bằng với ½ kích thước của cửa sổ.

Cửa sổ dài tạo ra nhiều hệ số, do đó mỗi hệ số sẽ tương ứng với một dải tần số hẹp hơn. Điều này dẫn tới việc lượng tử sẽ chính xách hơn và giúp ích cho việc làm giảm băng thông vì sẽ có thể bỏ nhiều đoạn âm thanh nằm trong vùng tần số mà không có tác động tới tai người.

Độ rộng của dải tần số tuỳ thuộc vào tốc độ lấy mẫu (số lượng mẫu âm thanh trong một giây), số lượng kênh (hai cho âm thanh nổi) và số lượng dải tần số. AAC cung cấp đặc tả và bảng thống kê cho 12 loại tốc độ lấy mẫu sau (tính bằng Hz): 96000, 88200, 64000, 48000, 44100, 32000, 24000, 16000, 12000, 11025, 8000. Đối với tốc độ lấy mẫu 48000 Hz và có 2 kênh, mỗi kênh được lấy mẫu ở tốc độ 24000 Hz.



Hình 2. 25: Tập 12 dải tần số và đặc tả

Công thức cho MDCT của bộ mã hoá được cho như sau:

Trong đó Zi,n là một mẫu âm thanh, i là chỉ số khối, n là mẫu âm thanh ở cửa sổ hiện tại, k là chỉ số của hệ số tần số X, N là kích thước cửa sổ (2048 hoặc 256) và n0= (N/2+1)/2.

Lượng tử trong AAC cũng giống như những tính năng khác của AAC đều cải tiến từ mp3. Quy tắc lượng tử như sau:

Trong đó sign là bit dấu của hệ số x(i), nint là hàm làm tròn số nguyên gần nhất và sf liên quan tới hệ số tỉ lệ. Thêm vào đó, giá trị lượng tử giới hạn trong vòng 8191 giá trị.

Quy tắc lượng tử bao gồm hệ số tỉ lệ. Mỗi hệ số tần số đều được co giãn trong suốt quá trình lượng tử bởi một đại lượng liên quan tới hệ số tỉ lệ. Hệ số này là một số nguyên không dấu 8 bit. Khi 1024 hệ số tần số của một cửa sổ dài được lượng tử, chúng được gom nhóm thành các dải hệ số tỉ lệ, mỗi dải là tập hợp hệ số tần số được tỉ lệ bởi một hệ số tỉ lệ.

Mã hoá Huffman không nhiễu. khi hệ số tần số đã được lượng tử, chúng sẽ được thay thế bởi mã Huffman. Điều này làm tăng tỉ lệ nén nhưng không hao hụt, do đó nó được gọi là “không nhiễu”. Có 12 bảng mã Huffman. Một khối 1024 hệ số đã được lượng tử sẽ được chia thành nhiều vùng mà mỗi vùng chứa một hoặc nhiều dải hệ số tỉ lệ. Một bảng mã được sử dụng cho tất cả các hệ số của một vùng, nhưng các vùng khác nhau có thể sẽ sử dụng các bảng mã khác nhau. Độ dài của mỗi vùng (theo đơn vị dải hệ số tỉ lệ) và một chỉ mục cho bảng mã Huffman sử dụng để mã hoá cho vùng phải được thêm vào luồng dữ liệu kết quả.


2. 26

2. 27

2. 28


Cũng có ý kiến cho rằng trong mỗi vùng cần sử dụng thuật toán mà hoá Huffman thích ứng để giảm thiểu tổng số lượng bit khi mã hoá một khối. Do đó, bộ mã hoá phải hoạt động một thuật toán phức tạp hơn.

Temporal Noise Shaping (TNS). Module này của AAC nhằm giải quyết vấn đề pre-echo, một vấn đề được tạo ra khi tín hiệu âm thanh khi được nén có thời gian xuất hiện ngắn, thay đổi nhanh chóng. Một cửa sổ lọc dài chứa 2048 mẫu. Cửa sổ này biểu diễn được một khoảng thời gian rất ngắn. Với tốc độ lấy mẫu 44100 mẫu/giây, thì 2048 mẫu tương đương với khoảng thời gian 0.46 giây, một khoảng thời gian rất ngắn. Nếu âm thanh gốc không thay đổi nhiều trong suốt khoảng thời gian này, bộ mã hoá AAC sẽ quyết định đúng ngưỡng che và thực hiện lượng tử đúng. Tuy nhiên nếu tín hiệu âm thanh thay đổi nhiều trong suốt khoảng thời gian này, thì quá trình lượng tử sẽ sai vì nhiễu lượng tử sẽ xuất hiện trong mỗi cửa sổ lọc. module TNS làm giảm bớt vấn đề preecho bằng cách nắn lại và điều chỉnh cấu trúc của nhiễu lượng tử. Nguyên lý làm việc của TNS dựa trên sự tương đồng giữa các mẫu âm thanh cũng giống như các điểm ảnh gần nhau. Đối với âm thanh ngắn, các mẫu âm thanh sẽ không tương đồng.

Dự đoán. Công cụ này tăng khả năng nén bằng cách dự đoán hệ số tần số từ những hệ số tương ứng trong 2 cửa sổ trước và lượng tử, mã hoá sự trên sự khác nhau khi dự đoán. Dự đoán này được sử dụng khi có sự tương đồng giữa các mẫu âm thanh. Trong AAC, cửa sổ ngắn được sử dụng khi bộ mã hoá cho rằng âm thanh đang được nén thì không ổn định. Do đó, dự đoán chỉ được sử dụng cửa sổ dài.

Thuật toán dự đoán thì khá phức tạp và yêu cầu nhiều khả năng tính toán. Nên bộ mã hoá cho thuật toán dự đoán thường thì rất phức tạp, và nó chỉ được sử dụng trong profile chính. Ở mỗi cửa sổ dài, dự đoán được thực hiện ở những tần số thấp và sẽ dừng ở tần số cực đại nào đó phụ thuộc vào tốc độ lấy mẫu.

Hình 2. 29: Mức tần số giới hạn cho thuật toán dự đoán

Trong bảng chỉ ra rằng nếu tốc độ lấy mẫu là 48 kHz, dự đoán có thể được sử dụng ở 40 dải tần số tỉ lệ đầu tiên và dừng tại tần số 15.75 kHz.

2.6.3. Chuẩn HE-AAC

2.6.3.1. Giới thiệuMPEG-4 HE-AAC v2 là sự kết hợp của 3 công nghệ: Advance Audio Coding

(AAC), Spectral Band Replication (SBR), và Parametric Stereo (PS). Tất cả 3 công nghệ này được đặc tả trong ISO/IEC 14496-3 và được kết hợp sử dụng trong HE-AAC v2. Sự kết hợp chỉ giữa AAC và SBR thì được gọi là HE-AAC v1, chuẩn này được đặc tả trong ISO/ICE 14496-3:2001/Amd.1



Viện tiêu chuẩn viễn thông châu âu đã tiêu chuẩn hoá HE-AAC v2 trong trong đặc tả kĩ thuật TS 102005 “Đặc tả kĩ thuật cho mã hoá hình ảnh và âm thanh trong việc truyền phát trực tiếp video số trên IP” và TS 101 154 “Hướng dẫn thiết kế cho việc mã hoá hình ảnh và âm thanh trong ứng dụng truyền phát dựa trên luồng truyền dữ liệu MPEG-2”. Dựa trên những nỗ lực tiêu chuẩn hoá này, HE-AAC v2 sẵn sàng cho việc tích hợp vào tất cả các loại dịch vụ truyền phát video số.

Trên thị trường các sản phẩm của HE-AAC v1 được biết dưới các tên aacPlus v1, AAC+, còn HE-AAC v2 được biết dưới các tên thương mại như eAAC+, aacPlus v2Kiến trúc

Bộ mã hoá nằm trong lõi của HE-AAC v2 được biết đến nhiều nhất là bộ mã hoá AAC. AAC được xem như là chuẩn âm thanh tuyệt vời cho chất lượng âm thanh ở tốc độ 128 kbps. Dưới tốc độ này, chất lượng âm thanh của AAC bắt đầu bị suy giảm, và cần được cải thiện với kĩ thuật SBR và PS. SBR là kỹ thuật mở rộng băng thông cho phép bộ mã hoá – giải mã âm thanh truyền có chất lượng tương đương như trước nhưng tốc độ bit giảm đi một nửa. Còn PS làm tăng hiệu quả mã hoá bằng cách khai thác sự biễu diễn thông số của hình ảnh lập thể được cho bởi tín hiệu đầu vào. Do đó, HE-AAC v2 là một tập hợp mở rộng của AAC với khả năng cho chất lượng âm thanh tốt với tốc độ bit thấp.

Hình 2. 30: Họ chuẩn nén AAC

2.6.3.2. Spectral Band Replication – SBRTrong mã hoá âm thanh truyền thống, khoảng thông tin có ý nghĩa được dùng để

mã hoá tần số cao. Sự ra đời của SBR dựa trên ý tưởng về sự nhận biết được sự tương đồng mạnh giữa vùng tần số cao và vùng tần số thấp của tín hiệu âm thanh, một sự xấp xỉ tốt của tính hiệu âm thanh gốc cao có thể đạt được bằng một chuyển đổi từ tín hiệu âm thanh ở dải tần thấp.

Hình 2. 31: Việc chuyển đổi trong quá trình tạo ra dãy tần số cao



Bên cạnh việc chuyển đổi thông thường này, việc tái tạo lại âm thanh ở dải tần cao cần phải được chỉ dẫn bởi những thông tin chuyển đổi như đường bao phổ của tín hiệu đầu vào để bù đắp những những thiếu xót quan trọng khác của các thành phần tần số cao. Những hướng dần này được xem như là dữ liệu của SBR. Như vậy hiệu quả của đóng gói dữ liệu SBR rất quan trọng để đạt được tốt độ bit như yêu cầu.

Phía mã hoá, tín hiệu đầu vào cần phải được phân tích, đường biên của dải tần số cao và các đặc tính của nó trong sự liên quan tới dải tần số thấp được mã hoá và kết quả này là dữ liệu của SBR sẽ tiếp tục được ghép vào luồng dữ liệu chung cần truyền đi. Ở phía nhận cần phải tách dữ liệu SBR ra, sau đó nhân giải mã bắt đầu hoạt động dựa trên luồng dữ liệu kết quả của phía phát kết hợp với việc sử dụng dữ liệu của SBR. Một giải mã không hỗ trợ SBR vẫn đó thể tương thích được nhưng kết quả sẽ bị giới hạn vể băng tần tín hiệu.

Hình 2. 32: Chỉnh đường biên của dãy tần số cao

Cách tiếp cận của SBR tuy có vẻ đơn giản, nhưng để làm cho cách tiếp cận này làm việc hiệu quả và có thể đáp ứng được các yêu cầu sau thì quả là không đơn giản:

Độ phân giải phổ phù hợp Khoảng thời gian tồn tại của dải tần số đủ lâu để tránh hiện tượng pre-echo Trường hợp độ tương đồng giữa tần số cao và thấp trong âm thanh giọng nói của con người không đạt yêu cầu thì cần phải tinh chỉnh đường biên và sự chuyển đổi sao cho phù hợp Tốc độ dữ liệu thấp cần phải đáp ứng để đạt được băng thông như yêu cầu.Trong các nghiên cứu và thử nghiệm cách tiếp cận trên đã đem lại kết quả tốt và

đáp ứng được đầy đủ tiêu chuẩn trên. Sự kết hợp của AAC va SBR được biết với tên HE-AAC v1 đã được tiêu chuẩn hoá trong MPEG-4 năm 2003.

2.6.3.3. Parametric Stereo (PS)Kỹ thuật PS là bước chính tiếp theo để tăng hiệu quả nén cho âm thanh ở tốt độ bit

thấp. PS được tiêu chuẩn hoá trong MPEG-4. PS được tối ưu cho khoảng tốc độ bit 16-40 kbps và sẽ đạt chất lượng cao ở tốc độ bit khoảng 24 kbps.

Dựa trên ý tưởng của SBR, khả năng làm việc của SBR sẽ tăng cao nếu tín hiệu âm thanh đầu vào có độ tương đồng cao về tần số. Bộ mã hoá PS tách phần âm thanh nền của tín hiệu âm thanh gốc nên sự tương đồng của tín hiệu sẽ cao giúp ích cho quá trình mã hoá âm thanh ở SBR.

Ở bộ mã hoá, tín hiệu của nhiều kênh âm thanh sau khi tách phần âm thanh nền sẽ được trộn lại thành một kênh âm thanh duy nhất. Việc này sẽ giúp ích nhiều cho việc nén âm thanh hơn là nén từng kênh âm thanh riêng lẻ. Bộ mã hoá âm thanh PS sau khi



đã trộn các kênh âm thanh lại với nhau sẽ gửi đi kèm với dữ liệu về phần âm thanh đã được tách.

Ở bộ giải mã, tín hiệu âm thanh sẽ được tách ra thành những kênh như ban đầu rồi kết hợp lại với thông tin về âm thanh nền được gửi kèm đi. Hình … miêu tả nguyên lý cơ bản của quá trình xử lý của PS.

Hình 2. 33: Nguyên lý cơ bản của quá trình xử lý PS

Hình 2. 34: Biểu đồ bộ mã hoá HE-AAC

Hình 2. 35: Biểu đồ bộ mã hoá HE-AAC

Điều cần phải lưu ý là chất lượng của các tín hiệu âm thanh sau khi bị nén phụ thuộc rất nhiều vào tốc độ bit. Hình … sẽ đưa ra các nhìn tổng quan về chất lượng âm thanh sau khi được nén với các chuẩn nén của họ AAC. Trong hình ta thấy ở tốc độ bit 48 kbps thì chất lượng của HE-AAC v2 và HE-AAC v1 tương đương nhau.



Hình 2. 36: So sánh hiệu quả của các chuẩn nén họ AAC

Năm 2003, liên đoàn phát thanh châu Âu đã tổng kết những kết quả thử nghiệm của nhiều chuẩn nén khác nhau gồm có HE-AAC, AAC ở tốc độ bit 48 kbps. Trong kết quả thử nghiệm ưu thế thuộc về HE-AAC, tiếp theo là mp3Pro (một sự kết hợp giữa mp3 và SBR)

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

2.7. Chuẩn nén hình ảnh MPEG-4/H.264

2.7.1. Số hoá hình ảnhCũng như âm thanh hình ảnh trước khi truyền trên mạng số thì cũng cần được số

hóa. Đối với các máy quay phim tương tự hay các máy ảnh phim thì chúng ta cần đưa dữ liệu qua các thiết bị chuyển đổi sang tín hiệu số, còn đối với máy quay phim kĩ thuật số hay máy ảnh kĩ thuật số thì tín hiệu đầu ra đã là tín hiệu số nên không cần phải chuyển đổi.

2.7.2. Nén hình ảnhBao gồm nén ảnh và nén nhiều ảnh liên tiếp trong một đoạn Video. Phương pháp

nén thường dùng đối với ảnh là JPEG (Joint Photographic Experts Group), đối với nhiều ảnh liên tiếp trong một đoạn Video là MPEG (Moving Picture Experts Group). Hai phương pháp này có đặc điểm chung là sử dụng phép biến đổi Cosine rời rạc DCT (Discrete Cosine Transform) và tiếp theo là một thuật toán mã hóa như RLC (Run



Length Coding), VLC (Variable Length Coding),…Đối với nén MPEG thì người ta sử dụng thêm một số kĩ thuật nén chuyển động…

2.7.3. Phép biến đổi Cosine rời rạc (Discrete Cosine Transform)Người ta không thực hiện biến đổi Cosine trên toàn bộ vùng ảnh mà người ta chia

ảnh thành các khối có kích thước 8x8 (đối với JPEG, MPEG-2) hoặc là 16x16, 8x8, 16x8, 4x4,… (đối với H.264).

Hình 2. 38: Minh họa cách chia ảnh thành các khối trước khi biến đổi Cosine

Biến đổi Cosine một chiềuPhép biến đổi Cosine rời rạc một chiều được cho bởi công thức

Trong đó u= 0, 1, 2,…, N-1. Tương tự phép biến đổi ngược được cho bởi công thức

Trong đó x= 0, 1, 2,…, N-1.Trong cả hai công thức trên thì α(u) được xác định bởi

Rõ ràng với u=0 thì . Do đó hệ số đầu tiên của phép biến đổi là giá

trị trung bình của tất cả các mẫu. Người ta gọi hệ số này là hệ số DC, tất cả các hệ số còn lại của phép biến đổi được gọi là hệ số AC.

Phép biến đổi Cosine rời rạc hai chiềuPhép biến đổi Cosine rời rạc hai chiều là một sự mở rộng trực tiếp của phép biến

đổi Cosine rời rạc một chiều và được cho bởi công thức


2. 39

2. 40

2. 41


Trong đó u,v = 0, 1, 2,…, N-1. Phép biến đổi ngược được cho bởi công thức

Trong đó x,y = 0, 1, 2,…, N-1. Với α(u), α(v) được xác định tương tự như phép biến đổi Cosine rời rạc một chiều.

Các tính chất của DCT: Decolleration : Lợi ích chủ yếu của phép biến đổi là loại bỏ sự dư thừa giữa các

pixel lân cận. Điều này dẫn đến những hệ số của phép biến đổi không có tương quan có thể được mã hóa một cách độc lập.

Energy Compaction : Hiệu quả của phép biến đổi là biến dữ liệu đầu vào thành một số ít các hệ số nhất có thể. Điều này cho phép bộ lượng tử hóa bỏ bớt các hệ số gần bằng nhau mà vẫn không làm giảm nhiều chất lượng của ảnh được tái tạo.

Seperability : Công thức biến đổi Cosine rời rạc hai chiều ở phần trên có thể được viết thành

Trong đó u,v = 0, 1, 2,…, N-1.Tính chất này cho phép phép biến đổi hai chiều có thể được thực hiện bằng hai

phép biến đổi một chiều, một phép biến đổi theo dòng và một phép biến đổi theo cột. Điều này được minh họa trong hình dưới đây

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

Symmetry: một cách nhìn khác của công thức biến đổi theo dòng và cột là

Trong đó A là ma trận của phép biến đổi kích thước NxN với các phần tử được cho bởi

Còn f là ma trận ảnh có kích thước NxN.Lợi ích lớn nhất của tính chất này là ma trận A của phép biến đổi có thể được tính

toán trước sau đó áp dụng để tính hệ số của phép biến đổi điều này làm tăng tốc tính toán lên rất nhiều.


2. 42

2. 43

2. 44

2. 46

2. 47


Orthogonality: Công thức biến đổi ngược có thể viết lại ở dạng

Với ma trận ngược của A chính là ma trận chuyển vị của A nghĩa là A-1 = AT.Tính chất này cũng góp phần giảm tính toán khi thực hiện phép biến đổi ngược.

2.7.4. Mã hóa chiều dài thay đổi VLC (Variable Length Coding)

2.7.4.1. Giới thiệu chungTheo lý thuyết mã, mã có độ dài thay đổi là một loại mã mà các kí hiệu nguồn được

ánh xạ thành các kí hiệu mã có số lượng bit không bằng nhau. Mã có độ dài thay đổi cho phép các kí hiệu nguồn được nén và giải nén mà không bị mất dữ liệu (lossless data compression) và còn có thể giải mã theo từng kí hiệu. Chiến lược mã này liên quan tới lượng tin (entropy) của từng kí hiệu. Một số loại mã được nhiều người biết tới theo chiến lược mã hóa này là: mã Huffman, mã LZ (Lempel-Ziv), mã số học.

Kích thước của một từ mã: được ánh xạ từ một chuỗi các bit độ dài xác định ban đầu thành một những cụm các bit có độ dài xác định sau đó.

Mã không suy biến là loại mã mà mỗi kí hiệu của từ mã ban đầu được ánh xạ thành một cụm bit không rỗng khác nhau.

Ví dụ một ánh xạ M1={(a,0), (b,0), (c,1)} là không loại ánh xạ không suy biến bởi vì nó ánh xạ cả hai kí hiệu “a” và “b” thành một cụm bit giống nhau “0”, bất kì kích thước nào của từ mã loại này đều tạo ra việc mất dữ liệu. loại mã suy biến này vẫn còn hữu dụng khi mã hóa đối với một số nguồn thông tin cho phép tổn thất dữ liệu ( như trong nén audio và video)

Tuy nhiên ánh xạ M2={(a,0), (b,1), (c,00), (d,01) là loại một ánh xạ không suy biến, rất phù hợp khi dùng cho truyền dữ liệu.

Từ mã có thể giải mã duy nhất: là một từ mã được gọi là có thể giải mã duy nhất nếu kích thước của nó không suy biến.

Ví dụ: dối với ánh xạ không suy biến M2 không phải là loại giải mã duy nhất bởi vì chuỗi nguồn “aa” được ánh xạ thành chuỗi bit “00”, khi giải mã có thể lầm lẫn với kí hiệu “c”. với kích thước từ mã của ánh xạ M3={(a,0), (b,01), (c,001)} có thể giải mã duy nhất, bởi vì mỗi cụm bit đều kết thúc ngay khi một bit 0 xuất hiện, nó là dấu hiệu cho thấy một từ mã mới.

Mã tức thời (mã có tính prefix) là loại mã trong cùng một ánh xạ, với các kí hiệu khác nhau thì không có chuỗi bit nào sau khi ánh xạ là prefix của một chuỗi bit đã ánh xạ khác. Điều này giúp cho kí hiệu có thể được giải mã tức thời ngay sau khi toàn bộ từ mã đã nhận được.

Ánh xạ M3 không phải là loại mã tức thời bởi vì không thể giải mã thành kí tự “a” sau khi nhận chuỗi bit “0”, nó là prefix của kí hiệu “b” và “c” sau khi đã giải mã.

Một ví dụ của loại mã tức thời có độ dài thay đổi:

Hình 2. 49: Ví dụ về một bảng mã


2. 48


Chuỗi kí hiệu nguồn bao gồm các kí hiệu: a, b, c, d. Từ mã nhị phân được cho như trên. Sau đây là một minh họa cho việc mã hóa và giải mã đối vời loại mã tức thời.

Kết quả: aabacda 001001101110 |0|0|10|0|110|111|0| aabacdaThuận lợi: những kí hiệu nguồn ít xuất hiện có thể được gán cho các kí hiệu dài

hơn những kí hiệu nguồn xuất hiện nhiều. ví dụ: nếu xác suất xuất hiện của (a, b, c, d) là (1/2, 1/4, 1/8, 1/8), thì entropy của nó là: 1x1/2 + 2x1/4 + 3x1/8 + 3x1/8 = 7/4 = 1,75. Với loại mã này thì kí hiệu nguồn được nén nhiều nhất có thể và giải mã được mà không bị mất dữ liệu.

2.7.4.2. Mã HuffmanTrong khoa học máy tính và lý thuyết thông tin, mã Huffman là một thuật toán mã

hóa dùng để nén dữ liệu. Nó dựa trên bảng tần suất xuất hiện các kí tự cần mã hóa để xây dựng một bộ mã nhị phân cho các kí tự đó sao cho dung lượng (số bít) sau khi mã hóa là nhỏ nhất.

Mã tiền tố (prefix-free binary code)Để mã hóa các kí hiệu (kí tự, chữ số, ...) ta thay chúng bằng các xâu nhị phân, được gọi là từ mã của kí hiệu đó. Chẳng hạn bộ mã ASCII, mã hóa cho 256 kí hiệu là biểu diễn nhị phân của các số từ 0 đến 255, mỗi từ mã gồm 8 bít. Trong ASCII từ mã của kí tự "a" là 1100001, của kí tự "A" là 1000001. Trong cách mã hóa này các từ mã của tất cả 256 kí hiệu có độ dài bằng nhau (mỗi từ mã 8 bít). Nó được gọi là mã hóa với độ dài không đổi.Khi mã hóa một tài liệu có thể không sử dụng đến tất cả 256 kí hiệu. Hơn nữa trong tài liệu chữ cái "a" chỉ có thể xuất hiện 1000000 lần còn chữ cái "A" có thể chỉ xuất hiện 2, 3 lần. Như vậy ta có thể không cần dùng đủ 8 bít để mã hóa cho một ký hiệu, hơn nữa độ dài (số bít) dành cho mỗi kí hiệu có thể khác nhau, kí hiệu nào xuất hiện nhiều lần thì nên dùng số bít ít, ký hiệu nào xuất hiện ít thì có thể mã hóa bằng từ mã dài hơn. Như vậy ta có việc mã hóa với độ dài thay đổi. Tuy nhiên, nếu mã hóa với độ dài thay đổi, khi giải mã ta làm thế nào phân biệt được xâu bít nào là mã hóa của ký hiệu nào. Một trong các giải pháp là dùng các dấu phẩy (",") hoặc một kí hiệu quy ước nào đó để tách từ mã của các kí tự đứng cạnh nhau. Nhưng như thế số các dấu phẩy sẽ chiếm một không gian đáng kể trong bản mã. Một cách giải quyết khác dẫn đến khái niệm mã tiền tố

Mã tiền tố là bộ các từ mã của một tập hợp các kí hiệu sao cho từ mã của mỗi ký hiệu không là tiền tố (phần đầu) của từ mã một ký hiệu khác trong bộ mã ấy.

Đương nhiên mã hóa với độ dài không đổi là mã tiền tố. Ví dụ: Giả sử mã hóa từ "ARRAY", tập các ký hiệu cần mã hóa gồm 3 chữ cái

"A","R","Y". Nếu mã hóa bằng các từ mã có độ dài bằng nhau ta dùng ít nhất 2 bit cho một

chữ cái chẳng hạn "A"=00, "R"=01, "Y"=10. Khi đó mã hóa của cả từ là 0001010010. Để giải mã ta đọc hai bit một và đối chiếu với bảng mã.

Nếu mã hóa "A"=0, "R"=01, "Y"=11 thì bộ từ mã này không là mã tiền tố ví từ mã của "A" là tiền tố của từ mã của "R". Để mã hóa cả từ ARRAY phải đặt dấu ngăn cách vào giữa các từ mã 0,01,01,0,11

Nếu mã hóa "A"=0, "R"=10, "Y"=11 thì bộ mã này là mã tiền tố. Với bộ mã tiền tố này khi mã hóa xâu "ARRAY" ta có 01010011.Biểu diễn mã tiền tố trên cây nhị phân

Nếu có một cây nhị phân n lá ta có thể tạo một bộ mã tiền tố cho n ký hiệu bằng cách đặt mỗi ký hiệu vào một lá. Từ mã của mỗi kí hiệu được được tạo ra khi đi từ gốc tới lá chứa ký hiệu đó, nếu đi qua cạnh trái thì ta thêm số 0, đi qua cạnh phải thì thêm số 1.



Ví dụ: Cây 3 lá sau đây biểu diễn bộ mã của A,R,Y trong ví dụ trên * 0/ \1 A * 0/ \1 R Y

Từ mã của "A" là 0, của "R" là 10, của "Y" là 11.

2.7.5. Kĩ thuật nén ảnh JPEG Sơ đồ nén ảnh như sau

Hình 2. 50: Sơ đồ nén ảnh JPEG

Người ta chia ảnh gốc thành các khối kích thước 8x8, sau đó thực hiện biến đổi Cosine trên các khối này, sau khi biến đổi Cosine là bước lượng tử hóa. Ở bước này người các hệ số của phép biến đổi có giá trị gần bằng nhau được lược bỏ và chỉ chọn một hệ số duy nhất để biểu diễn. Sau bước lượng tử hóa là đến bước mã hóa, ở bước này người ta sử dụng một thuật toán mã hóa lossless để mã hóa như Huffman, VLC (Variable Length Code),…

Sơ đồ giải nén như sau

Hình 2. 51: Sơ đồ giải nén ảnh JPEG

Đầu tiên là thực hiện giải mã sau đó đảo ngược thao tác lượng tử hóa và cuối cùng là biến đổi ngược để tái tạo ảnh ban đầu.

2.7.6. Kĩ thuật nén Video H.264

2.7.6.1. Bộ mã hóa và giải mãSơ đồ bộ mã hóa



Hình 2. 52: Sơ đồ bộ mã hóa MPEG-4/H.264

Chiều tới (dùng để gửi đi): một frame Fn được mã hóa gồm một tập các khối macroblock. Mỗi khối macroblock được mã hóa theo một trong hai chế độ: dự đoán bên trong hoặc bên ngoài. Trong chế độ dự đoán bên trong, một dự đoán PRED được hình thành từ những mẫu trong lát hiện tại đã được mã hóa , giãi mã trước. Trong chế độ dự đoán bên ngoài, PRED được hình thành bằng một dự đoán bù đắp chuyển động từ một hoặc hai hình tham chiếu được chọn nằm trong danh sách 0 hoặc danh sách 1 của các lát trước hoặc sau lát hiện tại. Trong sơ đồ, hình tham chíếu được chọn để mã hóa cho một khối hiện tại có thể là là khối nằm trong hình đã được mã hóa trước F’

n-1 hoặc khối tiếp theo của khối hiện tại. Khối đã được dự đoán PRED sẽ được trừ đi với khối hiện tại để lấy ra khối Dn biểu diễn sự khác nhau của 2 khối trên. Khối Dn này sẽ được chuyển đổi và lượng tử (T, Q) thành những hệ số X mà sau đó được sắp thứ tự. mã hóa entropy và truyền đi trên mạng.

Chiều lui (dùng để tái tạo): quá trình cũng giống như phần mã hóa bên trên nhưng dến khi tạo được X thì nó được áp dụng phép tính Q-1, T-1 để tạo thành một khối D’

n khác. Một dự đoán PRED được thêm vào để tạo lại khối uF’

n (một phiên bản giải mã của khối gốc và chưa được lọc) . Sau đó một bộ lọc được thêm vào để làm mượt ảnh F’

n (ảnh này có thể được dủng cho việc dự đoán ảnh trong quá trình mã hóa tiếp theo)Sơ đồ bộ giãi mã

Hình 2. 53: Sơ đồ bộ giải mã MPEG-4/H.264

Một giải mã sẽ nhận luồng bit đã được nén trên môi trường mạng và giải mã entropy và sắp thứ tự để thu được tập các hệ số lượng tử X. Sau đó D’

n cũng được dựng lại từ X qua Q-1 và T-1. Sau đó bộ giải mã sử thông tin trong header để tạo ra một dự đoán PRED giống với dự đoán gốc khi mã hóa. Ảnh chưa được lọc uF’

n được tạo ra từ



PRED tiếp tực được đưa qua bộ lọc để tạo ra ảnh trơn mượt F’n có chất lượng tương

đương ảnh gốc.

2.7.6.2. Cơ bản về H.264Quản lý ảnh tham chiếu:Những ảnh đã mã hóa sẽ được lưu trữ trong bộ đệm tham chiếu. Bộ mã hóa và giải

mã quản lý danh sách các ảnh được mã hóa (lấy ttrong danh sách 0) để sử dụng vào việc dự đoán bù đắp chuyển động.

Danh sách 0 có thể chứa những ảnh trước và sau ảnh hiện tại theo thứ tự hiển thị, và danh sách này có thể chứa cả những ảnh tham chiếu dài hạn và ngắn hạn. Mặc định, một ảnh đã được mã hóa khi được tái tạo lại chính bởi bộ giải mã thì được đánh dấu là ảnh ngắn hạn được dùng cho việc dự đoán. Ảnh dài hạn là những ảnh cũ hơn có thể được sử dụng cho việc dự đoán và còn tồn tại trong bộ đệm tham chiếu cho đến khi nào nó bị xoá hay bị thay thế.

Danh sách 1 là danh sách chứa những ảnh trong tương lai, gần với ảnh hiện tại nhất.

Lát ảnh:Lát ảnh có hai loại loại I và loại P. Loại I chỉ chứa những khối bên trong (khối ảnh

được mã hoá bằng phương pháp dự đoán bên trong). Và loại P chỉ chứa những khối ảnh bên ngoài (khối ảnh được mã hóa bằng phương pháp dự đoán bên ngoài).

Dự đoán khối:Một khối ảnh hiện tại trong một lát H.264 được dự đoán từ dữ liệu đã được mã hóa

trước. Tuy nhiên thứ tự mã hóa khối có thể như trong ảnh.

Hình 2. 54: Thứ tự khối ảnh được mã hóa

Dự đoán bên ngoàiDự đoán bên ngoài là một mô hình dự đoán từ một hoặc nhiều khung ảnh đã được

mã hóa trước đó dựa trên yếu tố bù chuyển động. Sự khác biệt quan trong so với những phương pháp cũ hơn ở chỗ phương pháp mới này hỗ trợ kích thước khối thay đổi (từ 16x16 xuống 4x4) và còn hỗ trợ cả những vector chuyển động



Hình 2. 55 Các cách chia khối ảnh nhỏ hơn

Hình 2. 56: Minh họa cách chia các khối ảnh khi mã hóa

Vector chuyển động: một khối ảnh được dự đoán từ một vùng của một ảnh khác (ảnh tham chiếu). Phần duy chuyển giữa hai vùng ảnh sẽ được dùng làm thông tin biểu diễn sự sai khác giữa hai ảnh.

(a) Khối 4x4 đang mã hóa(b) Khối tham chiếu vector(1,-1) (c) Khối tham chiếu vector(0.75,-0.5)Hình 2. 57: Tinh vector chuyển động

Dự đoán bên trongTrong chế độ dự đoán bên trong một khối được hình thành dựa trên những khối đã

được mã hóa và dựng lại trước đó. Các mẫu được dùng để dự đoán có 13 mẫu (từ A-M) còn các mẫu được dự đoán có 16 mẫu (từ a-p)



Hình 2. 58: Nhãn của các mẫu dự đoán

Các chế độ dự đoán: có 9 chế độ: Chế độ 0: các mẫu A, B, C, D được dùng để dự đoán theo chiều dọc Chế độ 1: các mẫu I, J, K, L được dùng để dự đoán theo chiều ngang. Chế độ 2: giá trị trung bình của các mẫu A…D và I…L được dùng để dự đoán. Chế độ 3: các mẫu được dự đoán theo đường chéo trên phải - dưới trái. Chế độ 4: các mẫu được dự đoán theo đường chéo trên trái - dưới phải. Chế độ 5: các mẫu được dự đoán theo đường chéo trên trái - dưới phải. Chế độ 6: các mẫu được dự đoán theo đường xiên đứng từ bên trái sang bên

phải góc 26,6o

Chế độ 7: các mẫu được dự đoán theo đường xiên đứng từ bên phải sang bên trái góc 26,6o.

Chế độ 8: các mẫu được dự đoán theo đường xiên ngang từ dưới lên góc 26,6o

Hình 2. 59: Các chế độ mã hóa khối ảnh

Ví dụ:

Ảnh gốc



b) Chế độ 0 (c) Chế độ 1 (d) Chế độ 2

(e) Chế độ 3 (f) Chế độ 4 (g) Chế độ 5

(h) Chế độ 6 (i) Chế độ 7 (j) Chế độ 8 Hình 2. 60: Ví dụ minh họa cho các chế độ mã hóa khối

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ểnTrong thực tế, quá trình khám bệnh thông qua hình ảnh chỉ cần rất ít các dữ liệu

dưới dạng văn bản. Vì thế việc xử lý, lưu trữ, phân phối và hiển thị các dữ liệu dạng hình ảnh đóng vai trò rất quan trọng. Từ các yêu cầu này đã đưa đến sự ra đời của một hệ thống nhằm mục đích thu nhận và lưu trữ ảnh từ các thiết bị tạo ảnh gồm ảnh X-quang, ảnh siêu âm, ảnh chụp cộng hưởng từ…, và thực hiện việc phân phối ảnh thông qua hệ thống truyền thông phục vụ cho việc chẩn đoán, điều trị và chăm sóc bệnh nhân. Hệ thống đó chính là hệ thống lưu trữ và truyền thông ảnh PACS.

Khái niệm PACS được thảo luận lần đầu tiên là trong cuộc gặp của các bác sĩ xét nghiệm vào năm 1982. Rất nhiều người đã ghi nhận cho sự ra đời của PACS, như là tiến sĩ Andre Duerinckx, tiến sĩ Samuel Dwyer, hay tiến sĩ Harold Glass… Trong giai đoạn đầu phát triển, do sự hạn chế của công nghệ nên hệ thống PACS bộc lộ nhiều yếu kém trong việc liên kết các thành phần hoạt động chung nhau, định tuyến, quản lý lỗi, mở rộng hệ thống…

Từ năm 1990, với sự phát triển mạnh mẽ của khoa học công nghệ, hệ thống PACS đã phát triển rộng khắp và ngày càng trở nên hoàn thiện. Bắt đầu là từ khu vực Bắc



Mỹ, PACS được nghiên cứu và phát triển dưới sự hỗ trợ của chính phủ và các nhà sản xuất. Sau đó, PACS đã được đẩy mạnh tại châu Âu và Nhật Bản. Hiện nay, hệ thống PACS đã được ứng dụng rộng rãi. Ví dụ như ở Mỹ, 33% bệnh viện có cài đặt hệ thồng PACS, và 32% khác có kế hoạch triển khai hệ thống PACS trong cơ sở của mình (theo báo cáo thường niên năm 2005 của Healthcare Information and Management Systems Society). Nhiều công ty phần mềm của Trung Quốc cũng đã nghiên cứu triển khai hàng loạt giải pháp nhằm tổ chức hệ thống lưu trữ và truyền ảnh.

Việt Nam cũng đã bắt đầu có những nghiên cứu về y tế từ xa (telemedicine) nói chung cũng như hệ thống PACS nói riêng. Rất nhiều dự án liên quan đến lĩnh vực y tế đã được triển khai như là: dự án “Bệnh viện vệ tinh của Bệnh viện Việt Đức” đã được Nhà nước và Bộ Y tế phê duyệt từ năm 2003 đến năm 2007, dự án “Y học từ xa” của Bộ Quốc phòng đang triển khai tại Bệnh viện Trung ương quân đội 108 (Hà Nội) và Quân y viện 175 (TP. Hồ Chí Minh).

Nhiều đơn vị, công ty của Việt Nam đang xây dựng các sản phẩm phần mềm trong lĩnh vực chăm sóc y tế. Các kỹ sư phát triển phần mềm SaigonTech đang trong quá trình hoàn tất Hệ thống thông tin và lưu trữ hình ảnh PACS. Hệ thống PACS đã được xây dựng trên kiến trúc 3 lớp (Web, xử lý, dữ liệu), với các thành phần mạng, thử nghiệm và phát triển. Ngoài ra SaigonTech đang trong giai đoạn thiết kế Bệnh án điện tử (Electronic Medical Record - EMR) cho giải pháp bệnh viện điện tử (Hệ thống hông tin bệnh viện - HIS, Hệ thống thông tin X Quang - RIS, Hệ thống thông tin dược phẩm - PhIS, v.v...)

2.8.1.2. Thành phần của hệ thống PACSHệ thống lưu trữ và truyền ảnh PACS gồm có các thành phần chính: Cổng nhận ảnh và dữ liệu Máy chủ lưu trữ và điều khiển PACS Máy chủ ứng dụng, máy chủ web Máy trạm hiển thị Hệ thống mạngCác bộ phận này được liên kết lại với nhau thông qua mạng. PACS đơn giản có thể

là một thiết bị số hóa film được liên kết lại với trạm hiển thị ảnh hoặc phức tạp hơn là hệ thống quản lý ảnh bệnh viện đầy đủ. Vào những năm 1980, PACS được thiết kế chủ yếu nhằm vào việc phục vụ công việc của các khối nhỏ trong khoa X-quang, trong đó mỗi module của PACS độc lập với nhau, không thực hiện trao đổi thông tin với nhau. Yếu kém này bộc lộ rõ khi các module của PACS được liên kết thành mạng. Khi đó việc duy trì, định tuyến, phối hợp hoạt động, quản lý lỗi và mở rộng hệ thống là rất khó khăn. Hệ thống PACS bây giờ đã dần khắc phục được các nhược điểm trên. Đó là mộ hệ thống thể dàng mở rộng, mềm dẻo và linh động. Các bộ phận của hệ thống đã được liên kết với nhau thông qua mạng, và được áp dụng ở rất nhiều bệnh viện trên thế giới. PACS được ứng dụng để xứ lý, lưu trữ, phân phối, hiển thị các dữ liệu dạng hình ảnh. PACS thực hiện nhiệm vụ là thu nhận vào lưu trữ ảnh từ những thiết bị tạo ảnh như ảnh Xquang, ảnh huỳnh quang số, ảnh số C-Arm, ảnh MR, ảnh siêu âm,…



Hình 2. 61: Cấu trúc hệ thống PACS

Cổng nhận ảnh và dữ liệuĐây là bộ phận rất quan trọng vì: Các thiết bị tạo ảnh không thuộc về hệ thống PACS. Các nhà sản xuất cung cấp

các thiết bị khác nhau, tuy phải tuân theo chuẩn DICOM, nhưng có thể sẽ có những phần khác biệt nhau.

Cổng nhận ảnh luôn hoạt động chậm hơn so với các bộ phận khác trong hệ thống.

Ảnh và dữ liệu bệnh nhân lấy từ thiết bị thỉnh thoảng có chứa những định dạng không được hệ thống PACS hỗ trợ.

Vì thế, máy tính cổng nhận ảnh tích hợp nhiều chương trình phần mềm đểthực hiện việc thu nhận ảnh từ các thiết bị tạo ảnh hoặc các module PACS khác,chuyển đổi thành chuẩn DICOM sử dụng trong hệ thống PACS và gởi đến máychủ lưu trữ và điều khiển PACS.Các đặc điểm của máy tính cổng nhận ảnh và dữ liệu: Duy trì toàn vẹn dữ liệu ảnh từ các thiết bị tạo ảnh truyền đến Trong suốt đối với người dùng và tự động hóa việc nhận ảnh và lưu trữ ảnh Phân phối ảnh đến máy chủ lưu trữ. Các khó khăn trong việc xây dựng một cổng thu nhận ảnh và dữ liệu Cổng thu nhận ảnh và dữ liệu phải giao tiếp với nhiều thiết bị tạo ảnh và các

module PACS khác nhau. Do đó, giao thức kết nối là rất phức tạp vì các thiết bị, module có định dạng ảnh, giao thức truyền khác nhau và phụ thuộc vào nhà sản xuất.

Cần phải có cơ chế kiểm soát lỗi khi các dữ liệu nhập vào trong quá trình tạo ảnh không chính xác.

Một cổng thu nhận ảnh và dữ liệu lý tưởng phải tự động hóa hoàn toàn để hệ thống hoạt động tốt và giảm thiểu lỗi.

Chi phí thiết kế. Thông thường, cổng thu nhận ảnh và dữ liệu thực hiện qua 4 bước chính: nhận

ảnh, định dạng ảnh, gửi ảnh và xóa ảnh.



Hình 2. 62: Sơ đồ hoạt động của cổng nhận ảnh

Các tiến trình tại máy tính cổng nhận ảnh: Tiến trình 1: kiểm tra xem có lệnh gởi từ cổng DICOM PACS hay không? Tiến trình 2: Nếu nhận được lệnh, nó kích hoạt tiến trình 2 là kiểm tra định

dạng DICOM và lưu thông tin vào máy tính cổng nhận ảnh. Tiến trình 3: đưa file nhận được vào hàng đợi để đưa tới bộ điều khiển PACS

để lưu trữ.Máy chủ lưu trữ và điều khiển PACSMáy chủ lưu trữ và điều khiển PACS là trung tâm của hệ thống PACS. Bộ phận điều khiển (PACS Controller) bao gồm kiến trúc phần cứng và phần mềm

thực hiện quá trình trao đổi thông tin với các bộ phận khác, cụ thể là nhận ảnh từ máy tính cổng nhận ảnh và truyền đến trạm hiển thị ảnh.

Còn hệ thống lưu trữ ảnh thực hiện việc lưu trữ thông tin hình ảnh với các mức độ về thời gian (ngắn hạn, trung bình, hay dài hạn).

Ảnh và dữ liệu nhận được từ các cổng nhận ảnh và dữ liệu khác nhau sẽ được xếp vào trong đĩa từ của server lưu trữ và được xóa đi khi đã hết mục đích sử dụng (bệnh nhân đã xuất viện hoặc chuyển qua khoa khác) hay ảnh được lưu trữ quá lâu so với khi thực hiện việc chẩn đoán, điều trị.

Các nhiệm vụ của bộ điều khiển: Nhận ảnh Sắp xếp và lưu trữ ảnh Định tuyến ảnh Nhóm gộp xét nghiệm Giao diện với HIS và RIS Thao tác trên cơ sở dữ liệu Truy xuất ảnh Nạp trước ảnhNhững yêu cầu đối với các thiết bị lưu trữ ảnh: Dữ liệu luôn sẵn sàng Có thể nâng cấp về khả năng lưu trữ và hiệu suất Khả năng bảo mật caoTrạm hiển thịTrạm hiển thị là thành phần cuối cùng trong một hệ thống PACS. Tại đây, các ảnh

của bệnh nhân và thông tin liên quan sẽ được hiển thị để thực hiện công việc chẩn đoán và gởi kết quả đến hệ thống HIS/RIS để lưu trữ.

Các thành phần cơ bản của trạm hiển thị gồm: máy chủ, bảng mạch video, màn hình hiển thị, và bộ nhớ cục bộ.

Ảnh khi được gởi đến sẽ được lưu trong bảng mạch video. Nếu bộ nhớ trong bảng mạch không lưu trữ hết sẽ lưu tạm sang bộ nhớ cục bộ. Sau đó, máy chủ sẽ điều khiển quá trình truyền dữ liệu từ bảng mạch video đến màn hình để hiền thị ảnh.

Nhiệm vụ chính của các trạm hiển thị là:



Nạp trước ảnh và thông tin cần thiết cho việc chẩn đoán Lựa chọn các xét nghiệm cho bệnh nhân. Sắp xếp và nhóm ảnh để thuận tiện cho việc quan sát.Máy chủ ứng dụngNhững máy chủ ứng dụng được kết nối với máy chủ lưu trữ và điều khiển PACS.

Thông qua những máy chủ ứng dụng này, dữ liệu PACS có thể được lọc, biến đổi phù hợp cho những ứng dụng khác nhau. Ví dụ như hiển thị hình ảnh trên Web.

Hệ thống mạngGiao thức truyền tải trong mạng nên theo đúng chuẩn, ví dụ như TCP/IP hay giao

thức truyền thông DICOM (mức cao hơn của TCP/IP). Việc phân bố đường truyền và băng thông trong hệ thống mạng cần được tính toán kỹ lưỡng. Ví dụ như đường truyền kết nối từ cổng nhận ảnh và dữ liệu đến máy chủ lưu trữ không cần tốc độ cao, vì tiến trình thu nhận ảnh không đòi hỏi thời gian truy xuất dữ liệu nhanh. Ngược lại, kết nối từ máy trạm hiển thị đến máy chủ lưu trữ cần phải được ưu tiên tốc độ cao.

2.8.1.3. Kiến trúc PACSCó 3 kiến trúc cơ bản của PACS là : Stand – Alone, Client – Server và Web –

based .Stand – Alone PACS ModelBa yếu tố chính: Ảnh được gởi một cách tự động đến máy trạm được thiết kế cho việc đọc và

hiển thị lại từ máy server. Máy trạm có thể cũng truy vấn hay truy xuất ảnh từ máy server. Máy trạm có bộ nhớ lưu trữ trong một thời gian gắn.Lưu đồ dữ liệu cho mô hình stand-alone được thể hiện ở hình bên dưới :

Hình 2. 63: Luồng dữ liệu khái quát của kiến trúc stand – alone.

Mô tả sơ đồ: đặc điểm chính là ảnh được gởi từ server (2) để đọc tại máy trạm một cách tự động cùng với việc nạp lại ảnh (3,4); ảnh cũng có thể được truy vấn/ trích xuất (5,6). Với các bước được giải thích cụ thể như sau:

Ảnh từ một cuộc kiểm tra được yêu cầu gởi bởi các máy tạo ảnh được gởi đến server PACS.

Máy server PACS lưu trữ kiểm tra đó.



Những bản sao của ảnh được phân tán đến một số máy đầu cuối được chọn cho việc đọc và xem xét bệnh án. Server thực thi việc này một cách tự động.

Những kiểm tra về tiền sử bệnh được nạp lại từ server, và một bản sao ảnh được gởi đến máy trạm của đầu cuối được lựa chọn.

Adhoc yêu cầu là hiển lại những kiểm tra PACS được thực hiện bằng cách truy vấn hay trích xuất từ máy trạm ở đầu cuối người dùng. Thêm vào đó, nếu việc tự động nạp lại sai, máy trạm đầu cuối người dùng có thể truy vấn hay trích xuất kiểm tra từ máy server.

Máy trạm đầu cuối người dùng chứa một bộ nhớ cache lưu trữ cục bộ của một số kiểm tra PACS đã hoàn thành.

Thuận lợi Nếu server PACS bị hư, thiết bị tạo ảnh hoặc cổng thu nhận có thể linh động

gởi trực tiếp đến máy trạm đầu cuối người dùng để các chuyên gia x-quang có thể tiếp tục đọc những trường hợp mới.

Bởi vì nhiều bản sao của kiểm tra PACS được phân tán thông qua hệ thống, nên có ít rủi ro mất dữ liệu.

Những kiểm tra tiền sử PACS sẽ có sẵn ở máy trạm bởi vì chúng có thiết bị lưu trữ cục bộ.

Hệ thống ít có khả năng bị thay đổi hàng ngày trong khi thực thi mạng bởi vì những kiểm tra PACS được tải lại từ một nhớ lưu trữ cục bộ của máy trạm đầu cuối người dùng và có sẵn để hiển thị ngay lập tức.

Việc kiểm tra biến đổi tiêu đề DICOM cho việc điều khiển chất lượng có thể được tạo ra trước.

Khó khăn Những users cuối phải cần phải đáp lại đúng sự phân tán và nạp lại của kiểm tra

PACS mà không thể đồng thời cùng một lúc. Bởi vì ảnh được gởi đến những máy trạm được thiết kế nên mỗi máy trạm có

thể có danh sách công việc khác nhau và điều này có thể tạo nên sự bất tiện khi đọc hay xem lại tất cả những kiểm tra của bất kỳ máy trạm nào trong một lần thiết lập.

Người dùng đầu cuối dựa vào chức năng truy vấn, trích xuất để lấy những kiểm tra adhoc PACS từ máy chiếm giữ. Điều này có thể là một chức năng phức tạp so với kiến trúc client-server.

Các chuyên gia X-quang có thể đọc những kiểm tra PACS giống nhau tại cùng một thời điểm từ những máy trạm khác nhau bởi vì những kiểm tra này có thể được gởi từ nhiều máy trạm.

Client – Server ModelBa yếu tố chính Ảnh được lấy từ ngay trung tâm của server PACS. Từ một danh sách công việc đơn lẻ tại một máy trạm client, một đầu cuối người

dùng có thể chọn những ảnh theo máy server . Bởi vì máy trạm không có cache lưu trữ nên ảnh bị loại bỏ ngay sau khi đọcMô tả sơ đồ: luồng dữ liệu của kiến trúc client/server PACS được thể hiện như hình

dưới, theo các bước như sau:



Hình 2. 64: Luồng dữ liệu tổng quát của kiến trúc client-server.

Đặc điểm chính là hình ảnh được lấy vào trong server, những ảnh được yêu cầu từ server thông qua một danh sách công việc tại máy trạm, máy trạm không có cache lưu trữ,và ảnh bị hủy sau khi đọc. Xem kĩ các dòng mô tả các bước cho sơ đồ:

Ảnh từ hay một kiểm tra được yêu cầu bởi máy tạo ảnh được gởi đến máy server PACS

Máy server PACS lưu trữ kiểm tra Máy trạm đầu cuối người dùng hay máy trạm client có thể truy cập toàn bộ cơ

sở dữ liệu bệnh nhân hay tài liệu của máy server. Một kiểm tra nằm trong danh sách công việc được chọn, các ảnh từ kiểm tra

PACS được tải từ server một cách trực tiếp vào trong bộ nhớ của máy client cho việc hiển thị. Những kiểm tra tiền PACS được tải lại với cùng một thể thức.

Một đầu cuối người dùng đã hoàn thành việc đọc hay xem lại kiểm tra, dữ liệu ảnh được loại bỏ từ bộ nhớ, không để lại một dữ liệu ảnh nào trong bộ nhớ lưu trữ cục bộ của máy trạm client.

Thuận lợi Bất cứ kiểm tra PACS nào cũng đều có sẵn trong máy trạm đầu cuối người

dùng tại bất kỳ thời điểm nào. Điều nào tạo nên sự thuận tiện cho việc đọc và hiển thị dữ liệu.

Không cần phải phân tán việc nạp lại và học. Không có chức năng truy vấn/ trích xuất. Đầu cuối người dùng chỉ chọn những

kiểm tra từ danh sách công việc trong máy trạm client và các ảnh được tải một cách tự động.

Bởi vì bản sao chính của kiểm tra PACS được đặt trong server PACS và nó được chia sẻ bởi máy trạm client, những chuyên gia X-quang sẽ có thể gọi khi chúng được đọc những kiểm tra giống nhau tại cùng một thời điểm và vì vậy tránh được việc đọc trùng.

Khó khăn



Máy server PACS là một điểm hỏng hóc, nếu nó bị hư, thực thể PACS cũng sẽ gặp vấn đề. Trong trường hợp này, đầu cuối người dùng sẽ không thể xem bất cứ kiểm tra nào trên máy trạm client. Những kiểm tra yêu cầu mới phải được tổ chức lại cho đến khi server phục hồi.

Bởi vì không có nhiều giao tác dữ liệu trong kiến trúc client server, hệ thống sẽ nảy sinh nhiều lỗi giao tác, làm cho nó ít an toàn so với kiến trúc stand – alone.

Kiến trúc thì phụ thuộc rất nhiều vào việc thực thi mạng. Những thiết bị kiểm tra tiêu đề DICOM cho việc điều khiển chất lượng thì

không có sẵn trước khi chiếm giữ.Web-Based ModelMô hình PACS dựa vào web thì tương tự như mô hình client/server.Tuy nhiên, sự

khác biệt chủ yếu là phần mền client là một ứng dụng dựa vào Web. Thêm một vài thuận lợi khác so với mô hình client-server là:

Phần cứng máy trạm client có thể thực thi độc lập tùy thuộc vào sự hỗ trợ của trình duyệt.

Hệ thống là một cổng ứng dụng mà có thể được dùng trên cả site và tại nhà với kết nối Internet.

Tuy nhiên cũng tồn tại một khó khăn khác so với kiến trúc client/server là hệ thống có thể giới hạn số chức năng và sự thực thi bằng trình duyệt web

Kỹ thuật Web: Internet đươc phát triển bởi chính phủ Mỹ bắt nguồn từ những ứng dụng trong quân sự. Sau nhiều năm, nó đã được mở rộng cho nhiều ứng dụng khác. Mặt khác, Intranet là một mạng riêng mà chuyển tải thông tin của những thực thể quản lý thông qua một môi trường mạng bảo mật. World Wide Web là một tập các giao thức Internet mà cung cấp cho ta khả năng truy cập dễ dàng đến một lượng lớn dữ liệu thông qua kết nối Internet. Web dựa trên giao thức chuyển tải siêu văn bản (HTTP) mà nó hỗ trợ chuyển tải siêu văn bản từ tất các các máy tính cho phép truy cập trên thế giới thông qua Internet. Hai ngôn ngữ dành cho ứng dụng Web phổ biến nhất mà cho phép hiển thị những văn bản đa phương tiện và đã được định dạng là HTML và ngôn ngữ Java.Gần đây, XML cũng được mở rộng sử dụng. Hiện tại, các trình duyệt như IE hay Netcape Navigator thường hỗ trợ dạng ảnh JPEG và GIF. Trong thuật ngữ web, ta thường hay nói đến máy chủ web hay máy khách web. Website có thể truy cập thông tin trên máy chủ web thông qua giao thức HTTP. Trong suốt nhiều năm qua, những ứng dụng của kỹ thuật web đã mở rộng cho ứng dụng trong lĩnh vực chăm sóc sức khỏe. Một số website bây giờ đã hỗ trợ truy cập những thông tin dạng văn bản từ hệ thống ePR (một hệ thống ghi nhận bệnh nhân). Những hệ thống ePR dựa vào web có thể phân loại theo nhiều yếu tố của chúng như mức độ hoàn thiện và chi tiết của thông tin, chất lượng của dữ liệu và từ góc độ của khách hàng. Việc sử dụng máy chủ web như một phương tiện để truy cập đến ảnh và thông tin ở trong PACS đã được thực thi bởi cả những trung tâm hàn lâm và các nhà sản xuất.

Mô tả máy chủ web trongmôi trường PACS: cần xem xét đến một máy chủ chứa ảnh dựa vào web thì nó cần phải có những thành phần như sau:



Hình 2. 65: Máy chủ chứa ảnh dựa vào web

Hình trên là kiến trúc cơ bản của máy chủ web mà cho phép trình duyệt web truy vấn và lấy ảnh và dữ liệu ở trong PACS thông qua máy chủ dựa vào web. Trình biên dịch DICOM/HTTP là thành phần chính trong kiến trúc. Nhiệm vụ của nó là :

Hỗ trợ trình duyệt web kết nối Internet Giải thích những truy vấn từ trình duyệt được viết bằng HTML hoặc Java và

chuyển đổi những truy vấn sang chuẩn HL7 và DICOM Hỗ trợ truy cập đến DICOM SOP để truy vấn và lấy ảnh hoặc dữ liệu từ điều

khiển PACS. Cung cấp trình biên dịch để chuyển đổi ảnh DICOM và HL7 thành HTTP.Máy chủ web là một khái niệm tốt mà nó tận dụng tốt những kỹ thuật Internet có

sẵn trong bất cứ máy để bàn nào để truy cập ảnh và dữ liệu của PACS. Nó làm việc rất tốt trong môi trường Intranet bởi vì Intranet thường được thiết kế với tốc độ cao. Tuy nhiên,có nhiều trở ngại khi sử dụng Internet hiện hành cho những ứng dụng WAN vì 2 nguyên nhân. Đầu tiên, đáp ứng thời gian cho việc truyền ảnh từ Internet thì quá chậm. Vì lý do này mà nó chỉ hữu dụng khi ta cần truy xuất ảnh với số lượng và kính thước nhỏ. Thêm một vấn đề khác là, kỹ thuật web thì không được thiết kế dành cho việc hiển thị ảnh xám với độ phân giải cao. Trong trường hợp này, thời gian chờ cho việc hiển thị và thao tác ảnh sẽ trở nên quá lâu.

2.8.1.4. Các yêu cầu trong việc thiết kế hệ thống PACSKhi thiết kế mạng PACS chúng ta phải xem xét bốn yêu cầu sau. Tiêu chuẩn hoá hệ thống. Kiến trúc mở của hệ thống. Độ tin cậy của hệ thống. Tính bảo mật của hệ thống.Tiêu chuẩn hoá hệ thốngNguyên tắc đầu tiên trong việc thiết kế kiến trúc cho hệ thống PACS đó là viêc sử

dụng tối đa các chuẩn công nghiệp hiện tại để phù hợp với toàn bộ sơ đồ thiết kế của PACS, cũng có nghĩa là đối thiểu hoá việc thiết kế phần mềm cho người sử dụng. Hơn



nữa, việc sử dụng cả tiêu chuẩn phần cứng cũng như tiêu chuẩn phần mềm sẽ làm tăng khả năng nâng cấp thay đổi cho hệ thống.

Sử dụng tối đa các chuẩn công nghiệp đã có như là hệ điều hành Unix, Window, giao thức truyền thông TCP/IP, hệ quản trị cơ sở dữ liệu SQL, Orangcle, định dạng dữ liệu hình ảnh DICOM, địng dạng dữ liệu chữ viết HL7, ngôn ngữ lập trình Visual Basic.NET, C#.Net, C++.Net, java.Net…

Việc sử dụng các chuẩn để thực thi cho PACS sẽ đem lại nhiều thuận lợi như là việc thi hành các thành phần và các mônđun của PACS sẽ đơn giản hơn. Việc vận hành bảo dưỡng, tìm hiểu hệ thống cũng dễ dàng hơn. Hơn nữa, việc xác định hoạt động của PACS sẽ làm giảm thiểu sự mã hoá máy tính dư thừa, do đó dễ dàng hơn cho việc Debug và tìm kiếm thông tin.

Trong các chuẩn công nghiệp nêu trên thì chuẩn DICOM và HL7 là quan trọng nhất vì chúng cung cấp truyền thông giữa PACS và HIS/RIS, giữa các thiết bị của những nhà sản xuất khác nhau.

Kiến trúc mở của hệ thốngNếu hai module của hệ thống PACS trong cùng một bệnh viện không thể thông tin

được với nhau thì chúng trở thành hệ thống cách ly, từng module có thông tin của bệnh nhân là riêng biệt. Khi đó không thể xây dựng được hệ thống PACS mở và hệ thống bị giới hạn.

Do đó, kiến trúc mở là cần thiết đề cung cấp mộ phương pháp tiêu chuẩn cho việc trao đổi thông tin giữa các hệ thống khác nhau. Do công nghệ máy tính và truyền thông phát triển rất nhanh nên kiến trúc đóng sẽ là hạn chế việc nâng cấng cho hệ thống. Vì vậy, khi phát triển một hệ thống PACS dù là cỡ lớn hay cỡ nhỏ thì cũng luôn luôn đảm bảo đó là hệ thống mở.

Để một hệ thống PACS là hệ thống mở thì nó phải đảm bảo các yêu cầu sau: Có thể truyền dữ liệu từ module của PACS này đến module của PACS khác. Dạng dữ liệu và hình ảnh phải sử dụng đúng chuẩn. Giao thức máy tính cũng phải là giao thức chuẩn.Độ tin cậyĐộ tin cậy là một đặc điểm cần được chú ý vì hệ thống PACS có rất nhiều thiết bị

nên xác suất lỗi của hệ thống là rất cao. Hơn nữa do thông tin bệnh viện là thông tin cần tức thời và chính xác nên thời gian chết của hệ thống chỉ có thể nằm trong khoảng cho phép

Các biện pháp tăng độ tin cậy của hệ thống : Có chương trình phần mềm kiểm tra sữa lỗi phục hồi, sao lưu dữ liệu . Xây dựng hệ thống phần cứng dự phòngTính bảo mậtĐây là một nhân tố quan trọng của hệ thống, nó đảm bảo tính riêng tư về thông tin

của bệnh nhân. Hệ thống cơ sở dữ liệu phải hạn chế mức truy cập cho từng đối tượng cụ thể. Phần lớn các hệ thống quản trị cơ sỡ dữ liệu phức tạp đều có cơ chế bảo mật bằng account và password. Người thiết kế hệ thống phài đảm bảo cho người quản trị mạng có thể gắn các quyền truy nhập vào cơ sở dữ liệu PACS cho từng đối tượng người sử dụng.

Các vi phạm về về bảo mật dữ liệu chủ yếu tập trung ở các loại sau: Việc xâm phạm về vật lý liên quan đến sự bảo mật của phương tiện quản lý

thiết bị Các vi phạm về thái độ và sự lạm dụng có thể được giảm thiểu bằng điều khiển

và account.



2.8.2. Hệ thống MyFreePACS2.8.2.1. Giới thiệu

MyFreePACS được phát triển bời Pacssoft (http://www.pacssoft.com) và ứng dụng tại bệnh viện nhi Seattle. MyFreePACS là một hệ thống lưu trữ và truyền thông ảnh vói mục đích là cung cấp phương thức xem ảnh chuẩn DICOM một cách dễ dàng nhất từ mọi nơi trong bệnh viện, hoặc từ xa thông qua mạng.

2.8.2.2. Các tính năng chínhCác tính năng chính của MyFreePACS gồm có: Thu nhận ảnh từ các thiết bị như máy X-Quang, máy siêu âm, máy chụp cộng hưởng

từ,… Các thành phần quản trị hệ thống MyFreePACS và DICOM Server thông qua giao

diện Web. Có thể tìm kiếm ảnh theo tên bệnh nhân, mã số (ID) bệnh nhân hay thời gian. Cung cấp một số công cụ xử lý ảnh:

o Chỉnh độ sángo Di chuyểno Phóng to/thu nhỏo Đo khoảng cácho Lật ảnho Xoay ảnho Lấy âm bản.

2.8.2.3. Yêu cầu hệ thốngYêu cầu tối thiểu của hệ thống Hệ điều hành: Windows 2000, XP, 2003 Server, Linux Cơ sở dữ liệu: SQL Server 2000, SQL Server 2005 Express Edition, SQL Server 2005

hay MySQL PHP 4 trở lên Web Server: IIS (Internet Information Server) hay Apache Server

2.8.2.4. Lợi ích của hệ thốngLợi ích sau cài đặt hệ thống Cài đặt đơn giản, dể dàng Hệ thống hoàn toàn miễn phí, chi phí để cài đặt cũng không quá cao. Vì ngoại trừ phải

cài đặt hệ điều hành Windows, các thành phần khác như PHP, hay cơ sở dữ liệu đều có thể sử dụng miễn phí (SQL Server 2005 Express Edition, MySQL)

Hệ thống dựa trên nền web nên có thể truy cập dễ dàng từ bất kì nơi nào chỉ cần có kết nối internet, rất thuận tiện cho việc chẩn bệnh từ xa.

2.8.3. Chuẩn hình ảnh DICOM dùng trong y tế

2.8.3.1. Tổng quan về DICOMDICOM (The Digital Image and Communication in Medicine) là chuẩn định nghĩa

ra các qui tắc định dạng và trao đổi hình ảnh y tế cũng như thông tin liên quan. Hình ảnh y tế được nhận từ các thiết bị thu nhận hình ảnh số khác nhau như máy CT (compited Tomography), MR (Magnetic Resonance), US (UltraSound), NM (Nuclear Medicine). Nó tạo ra một ngôn ngữ chung cho phép giao tiếp hình ảnh và các thông tin y tế liên quan giữa các thiết bị và hệ thống trong mạng thông tin y tế.

Với sự ra đời của máy tạo ảnh chẩn đoán vào những năm 1970, cũng như việc sử dụng ngày càng nhiều hệ thống máy tính và ảnh số trong y tế với các định dạng khác


http://www.pacssoft.com/


nhau thì nhu cầu cần phải có một chuẩn chung cho quá trình truyền ảnh số và các thông tin liên quan ngày càng lớn.

Trước nhu cầu đó, American College of Radiology (ACR) và The National Electrical Manufacturers Association (NEMA) đã thiết lập thành một ủy ban chung vào năm 1983 để phát triển một chuẩn gọi là chuẩn ACR-NEMA.

Chuẩn ACR-NEMA (American College of Radiology và The National Electrical Manufacturers Association) ra đời nhằm mục đích để cho các thiết bị tạo ảnh của các nhà sản xuất khác nhau có thể trao đổi và chia sẻ thông tin trong môi trường thông tin ảnh y tế, đặc biệt là trong môi trường PACS. Chuẩn này trung vào trao đổi,kết nối và truyền thông giữa các hệ thống y tế. Phiên bản 1 của ACRNEMA ra đời năm 1985 xác định việc truyền bản tin điểm tới điểm,khuôn dạng dữ liệu và một số lệnh. Phiên bản thứ 2 ra đời năm 1988 định nghĩa phần cứng và giao thức phần mềm cũng như từ điển dữ liệu chuẩn. Nhưng vấn đề kết nối mạng chưa rõ ràng qua hai phiên bản này vì thế mà phiên bản thứ 3 ra đời và lấy tên là DICOM.

Vì sự ra đời của các chuẩn là khác nhau nên với các thiết bị không tuân theo tiêu chuẩn DICOM mà thực hiện theo tiêu chuẩn CR-NEMA hoặc tiêu chuẩn riêng của nhà sản xuất cần thì thích ứng sang DICOM. Để thích ứng với chuẩn ACR – NEMA thì cần một chuyển đổi từ ACR-NEMA sang DICOM, còn để thích ứng với các chuẩn riêng của nhà sản xuất thì cần phải chuyển đổi các đặc tính của nhà sản xuất sang ACR-NEMA hoặc DICOM. Để giải quyết các yêu cầu này cần tập hợp các mođun phần mềm tạo nên thư viện mã hóa. Thư viện mã hóa ưu việt cần có các đặc tính sau:

Sử dụng chung cho các thiết bị tạo ảnh của các nhà sản xuất khác nhau. Thích ứng với các nền phần cứng khác nhau. Kiến trúc phần mềm dựa theo hướng tiếp cận top – down. Ngôn ngữ lập trình chuẩn.

Hình 2. 66: Các thiết bị tạo,lưu trữ và truyền ảnh DICOM

DICOM hỗ trợ nhiều loại ảnh nén khác nhau để tối ưu cho việc lưu trữ và việc thuyền thônh ảnh DICOM trên mạng. Dưới đây là một số so sánh giữa các loại ảnh mà DICOM hỗ trợ.

Kiểu ảnh Kích thước (byte)

8-bit J2K Lossy Gray.dcm 24,8488-bit JPEG Lossless Gray.dcm 106,326 8-bit Uncompressed Gray.dcm 179,640



16-bit J2K Lossy Gray.dcm 305,85616-bit JPEG Lossless Gray.dcm 561,29216-bit Uncompressed Gray.dcm

610,394

24-bit J2K Lossy Color.dcm 100,34824-bit JPEG Lossless Color.dcm 6,830,92024-bit JPEG Lossy Color.dcm 1,620,03824-bit RunLength Color.dcm 14,040,71424-bit Uncompressed Color.dcm

18,875,660

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ợ

2.8.3.2. Phạm vi và lĩnh vực ứng dụng của DICOMChuẩn DICOM gắn liền với thông tin y tế. Với lĩnh vực này, nó định ra sự trao đổi

thông tin số giữa các thiết bị tạo ảnh và hệ thống mạng thông tin. Do các thiết bị tạo ảnh có thể hoạt động tương tác với các thiết bị y tế khác, phạm vi của chuẩn cần thiết phải chồng lên các khu vực khác trong thông tin y tế.

Chuẩn tăng cường khả năng hoạt động tương tác của các thiết bị tạo ảnh y tế bằng cách định ra:

Với việc truyền thông tin qua mạng, chuẩn đưa ra một bộ giao thức được tuân theo bởi các thiết bị thích nghi chuẩn.

Cú pháp và ngữ nghĩa của lệnh và các thông tin liên quan được trao đổi sử dụng các giao thức này.

Với việc truyền tin bằng phương tiện trung gian, chuẩn đưa ra một bộ các dịch vụ lưu trữ trung gian, cũng như khuôn dạng file và cấu trú thư mục y tế, tạo điều kiện cho việc truy nhập thông tin lưu trữ trên phương tiện trung gian.

Thông tin được sử dụng trong ứng dụng tuân theo chuẩn.

2.8.3.3. Thích nghi DICOMMột thành phần quan trọng của bất cú một chuẩn nào là phải định nghĩa tính thích

nghi với nó, hay nói cách khác là tính tuân thủ những điều mà chuẩn đề ra. Trong nhiều trường hợp khác như chuẩn DICOM chẳng hạn, sự thích nghi là hoàn toàn tự nguyện. Ủy ban của chuẩn DICOM không tạo ra bất cú sự áp đặt nào. Mặc dầu vậy, DICOM vẫn có một phần dành riêng để quy định sự thích nghi.

Mọi nhà sản xuất muốn chứng minh thiết bị hay phần mềm của họ thích nghi với chuẩn đều phải đưa ra một báo cáo thích nghi miêu tả một cách cụ thể sản phẩm của họ thích nghi với chuẩn như thế nào. Một báo cáo thích nghi được tham khảo với một khuôn dạng do DICOM đề ra, do vậy mà việc đối chiếu các trình bày về thích nghi trở nên đơn giản và khoa học. Người sử dụng và nhà sản xuất có thể xác định xem tài liệu hai thiết bị tuân theo DICOM có thể giao tiếp ăn khớp với nhau hay không bằng cách đối chiếu bản báo cáo thích nghi của hai thiết bị với nhau. Những người làm DICOM có thể xác định được chính xác khả năng đồng loạt hoạt động của hai ứng dụng.

Các nội dung cơ bản trong báo cáo thích nghi DICOM gồm: Mô hình thực thi ứng dụng: Mô hình thực thi (Implementation Model) của ứng

dụng là một lược đồ đơn giản thể hiện cách mà một ứng dụng liên kết với phạm vi cục bộ trong một thiết bị được đưa ra và từ xa thông qua giao diện DICOM.



Ví dụ, hoạt đông cục bộ có thể tao ra một đối tượng thông tin ảnh DICOM, còn hoạt động từ xa là hiển thị đối tượng đó.

Ngữ cảnh thể hiện được sử dụng: Bao gồm cú pháp trừu tượng và cú pháp chuyển đổi tương ứng. Thuật ngữ cú pháp trừu tượng được sử dụng trong phần này vì nó được định nghĩa trong một chuẩn quốc tế khác mà DICOM tham chiếu đến. Một bản báo cáo thích nghi.

DICOM sẽ liệt kê cả ngữ cảnh cả ngữ cảnh thể hiện mà ứng dụng đưa ra trong thỏa thuận cũng như khi đã được chấp thuận.

Cách liên kết thực hiện: Bản báo cáo thích nghi phải miêu tả sử thực hiện liên kết ( ví dụ như là khi nào tạo các liên kết và chấp nhận nhiều liên kết) cho từng hoạt động trong mô hình. Một số thiết bị như thiết bị lưu trữ trong hệ thống PACS phải được hổ trợ nhiều liên kết nếu chúng được chấp nhận.

2.8.3.4. Mục tiêu của ảnh DICOM Định ra ngữ nghĩa của lệnh và các dữ liệu liên quan, đưa ra các chuẩn cho các

thiết bị tương tác lệnh và dữ liệu với nhau. Định ra ngữ nghĩa của dịch vụ file, khuôn dạng file và các thư mục thông tin

cần thiết cho truyền tin ngoại tuyến. Định rõ các yêu cầu thích nghi của ứng dụng thực hiện chuẩn, cụ thể một bản

báo cáo thích nghi phải định ra đầy đủ thông tin để xác định các chức năng có thể đáp ứng.

Tạo thuận lợi cho hoạt động trong môi trường mạng thông tin. Có cấu trúc thuận lợi cho phép đáp ứng với các dịch vụ mới, vì thế có thể hỗ trợ

các ứng dụng hình ảnh y tế trong tương lai.

2.8.3.5. Cấu trúc của chuẩn DICOMCác thành phần của định dạng ảnh DICOM: Thích nghi: Định nghĩa các nguyên tắc thực thi chuẩn gồm các yêu cầu thích

nghi và báo cáo thích nghi CS (Conformance Statement) Định nghĩa đối tượng thông tin IOD (Information Object Definition) Định nghĩa lớp dịch vụ SC (Service Classes) Ngữ nghĩa và cấu trúc dữ liệu Từ điển dữ liệu Trao đổi bản tin Hỗ trợ truyền thông mạng cho việc trao đổi bản tin Khuôn dạng file và lưu trữ trung gian Sơ lược ứng dụng lưu trữ trung gian Chức năng lưu trữ và khuôn dạng trung gian cho trao đổi dữ liệu Chức năng hiển thị chuẩn mức xám Sơ lược an toàn Nguồn ánh xạ nội dung.



Hình 2. 68: DICOM và mô hình tham chiếu OSI

Định dạng file DICOM: bồm 2 phần là header, dữ liệu ảnh. Header:

o Tên và ID của bệnh nhân.o Loại ảnh y khoa ( CT,MR,Audio Recording,..)o Kích thước ảnh…

Ví dụ :

Hình 2. 69: Ví dụ về ảnh MRI

Hình trên chỉ ra rằng: 794 bytes đầu dùng để định dạng Header DICOM, mô tả kích thước ảnh và các thông tin ảnh. Kích thước của ảnh trên : 109x91x2 =19838 bytes.



Hình 2. 70: Ví dụ về một số trường của ảnh DICOM

Dữ liệu ảnh:o Ảnh nén (bitmap) hoặc ảnh chưa nén từ (jpeg, gif...)o Định nghĩa đối tượng thông tin IOD (Information Object Definition)o Định nghĩa lớp dịch vụ SC (Service Classes)o Ngữ nghĩa và cấu trúc dữ liệuo Từ điển dữ liệuo Trao đổi bản tino Hỗ trợ truyền thông mạng cho việc trao đổi bản tino Khuôn dạng file và lưu trữ trung giano Sơ lược ứng dụng lưu trữ trung giano Chức năng lưu trữ và khuôn dạng trung gian cho trao đổi dữ liệuo Chức năng hiển thị chuẩn mức xámo Sơ lược an toàno Nguồn ánh xạ nội dung

Các lớp đối tượng và dịch vụ trong DICOMDICOM có hai lớp thông tin là lớp đối tượng và lớp dịch vụ SOP (Service Object

Pair).



Hình 2. 71: Lớp dịch vụ và lớp đối tượng

Lớp đối tượng của DICOM định ra hai lớp nhỏ là lớp tiêu chuẩn và lớp tổ hợp. Mỗi lớp tiêu chuẩn bao gồm các đặc tính vốn có của thực thể hiện diện trong thế giới thực. Lớp tổ hợp là do ACR-NEMA định nghĩa từ các thông tin tổ hợp của các thiết bị ảnh tạo khác nhau.

Lớp đối tượng tiêu chuẩno Bệnh nhâno Xét nghiệmo Nguồn lưu trữo Chú giải ảnh

Lớp đối tượng tổ hợpo Ảnh CR (Computed Radiography)o Ảnh CT (Computed Tomography)o Ảnh số hóa film DF (Digital Fluorography)o Ảnh MR (Magnetic Resonance)o Ảnh y học hat nhân NM (Nuclear Medicine)o Ảnh siêu âm US (Ultrasound)o Đồ hoạo Đồ hình



Hình 2. 72: Minh họa đối tượng ảnh

Lớp dịch vụ của DICOM định nghĩa các dịch vụ như lưu trữ, in chất vấn và truy vấn… Mỗi lớp đều có một từ điển định nghĩa các thuộc tính để mã hoá dữ liệu một cách chính xác.

Hình 2. 73: Các dịch vụ của DICOM

Các dịch vụ DICOM được sử dụng để truyền đối tượng bên trong thiết bị và cho thiết bị thực hiện một dịch vụ cho đối tượng ví dụ như dịch vụ lưu trữ, dịch vụ hiển thị… Một lớp dịch vụ được xây dựng trên một tập các dịch vụ truyền thông DICOM được gọi là DIMSE (DICOM Message Sevice Elements). Các DIMSEs là các chương trình phần mềm thực hiện chức năng xác định. Có hai loại DIMSEs là một cho đối tượng tổ hợp và một cho đối tượng tiêu chuẩn. Một DIMSE tổ hợp được một cặp thiết bị gồm một thiết bị gồm thiết bị đưa ra yêu cầu và thiết bị nhận yêu cầu. Vì trong môi trường hướng đối tượng nên dịch vụ của DICOM được coi là một lớp dịch vụ. Nếu một thiết bị cung cấp dịch vụ thì được gọi là SCU (Service Class User). Chẳng hạn như đĩa từ là SCP để cho PACS controller lưu trữ dữ liệu còn CT scanner là SCU để cho đĩa từ trong PACS controller lưu ảnh. Tuy nhiên, có thể 1 thiết bị vừ là



SCP, vừa là SCU như PACS controller, nó gửi ảnh tới trạm hiển thị bằng các đưa ra các yêu cầu dịch vụ thì nó là SCU. Nếu nó nhận ảnh từ các thiết bị tạo ảnh bằng cách cung cấp dịch vụ lưu trữ thì nó lại là SCP.

Hình 2. 74: Các dịch vụ DIMSEs tiêu chuẩn

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

2.8.3.6. Khuôn dạng file DICOMThông tin đầu file: bao gồm các định danh bộ dữ liệu được đưa vào file. Nó bắt đầu

bởi 128 byte file Preamble (tất cả được đưa về 00H). Sau đó 4 byte kí tự “DICM”. Tiếp theo là các thành phần dữ liệu đầu file. Các thành phần dữ liệu đầu file này là bắt buộc đối với mọi file DICOM. Các thành phần dữ liệu đầu file này là bắt buộc đối với mọi file DICOM. Các thành phần dữ liệu này có nhãn dạng (0002, xxxx), được mã hóa theo cú pháp chuyển đổi VR ẩn và Little Endian.

Bộ dữ liệu: Mỗi file chỉ chứa một bộ dữ liệu thể hiện một SOP cụ thể và duy nhất liên quan đến một lớp SOP đơn và IOD tương ứng. Một file có thể chứa nhiều hình ảnh khi các IOD được xác định mang nhiều khung. Cú pháp chuyển đổi được sử dụng để mã hóa bộ dữ liệu được xác định duy nhất thông qua UID cú pháp chuyển đổi trong thông tin đầu file DICOM.

Thông tin quản lý file: Khuôn dạng file DICOM không bao gồm thông tin quản lí file để tránh sự trùng lặp với chức năng liên quan ở lớp khuôn dạng trung gian. Nếu cần thiết với một sơ lược ứng dụn DICOM cho trước, các thông tin sau sẽ được đưa ra bởi một lớp khuôn dạng trung gian:



Định danh sở hữu nội dung file Thông tin truy cập (ngày giờ tạo) Điều khiển truy cập file ứng dụng Điều khiển truy cập phương tiện trung gian vật lý (bảo vệ ghi…)Khuôn dạng file DICOM an toàn: Một file DICOM an toàn là một file

DICOM được mã hóa với một cú pháp bản tin mật mã được định nghĩa trongRFC2630. Phụ thuộc vào thuật toán mật mã sử dụng, một file DICOM an toàncó thể có các thuộc tính an toàn sau:

Bảo mật dữ liệu Xác nhận nguồn gốc dữ liệu Tính toàn vẹn dữ liệu

Hình 2. 76: Khuôn dạng file DICOM

2.8.4. DICOM Toolkit

2.8.4.1. DCMTKDCMTK – phiên bản mới nhất là DCMTK 3.5.4 – là một tập hợp các thư viện và

các ứng dụng hỗ trợ cho chuẩn DICOM. Bộ toolkit này bao gồm các module kiểm tra, xây dựng và chuyển đổi ảnh DICOM, xử lý dữ liệu offline, truyền và nhận ảnh trên mạng (có thể đáp ứng khả năng bảo mật cao thông qua kết nối SSL), DCMTK được viết bằng ngôn ngữ ANSI C, và C++.

DCMTK có thể hỗ trợ cho nhiều loại hệ điều hành như Windows, Linux, Solaris, QNX, IRIX, Free/Net/OpenBSD, và MacOS. Tất cả các thông tin cấu hình đều cho từng loại hệ điều hành đều được cung cấp đầy đủ.

Về tính năng bảo mật, DCMTK hỗ trợ nhiều tính năng bảo mật cho DICOM dưa trên toolkit OpenSSL về việc sử dụng các hàm mật mã và giao thức truyền tải dữ liệu bảo mật TLS được tin tưởng sử dụng ở các hệ thống lớn.

Một số gói cơ bản của DCMTK Config – chứa các tiện ích cấu hình cho DCMTK dcmdata – chứa các thư viện mã hoá/giải mã cho DCMTK dcmimage – cung cấp thêm các hỗ trợ ảnh màu dcmimgle – các thư viện và ứng dụng dùng cho việc xử lý ảnh. Dcmjpeg - các thư viện nén và giải nén ảnh jpeg. Dcmnet – các thư viện hỗ trợ cho việc truyền tải trên mạng Dcmqrdb – Server quản lý ảnh



Dcmsign – các thư viện dùng cho chữ kí số dcmtls – các thư viện mở rộng dành cho bảo mật dữ liệu khi truyền trên mạng.

2.8.4.2. DCM4CHEDCM4CHE là một bô công cụ mã nguồn mở để phục vụ cho việc xử lý ảnh

DICOM mở giống như DCMTK nhưng được viết bằng ngôn ngữ Java. Hiện tại dcm4che đang được phát triển tới phiên bản 2 với những cải tiến về hiện năng cũng như sử dụng bộ nhớ, và khả năng xử lý ảnh DICOM mạnh mẽ. Bộ công cụ dcm4che thiết kế để xử lý ảnh DICOM theo chuẩn DICOM 2006.

Môt số gói chính của DCM4CHE org.dcm4che2.audit.message: cung cấp các lớp cho việc tạo các thông điệp xác

thực theo định dạng XML tuân theo các đặc tả trong DICOM Supplement 95 org.dcm4che2.data: gói này chứa các lớp cho phép thao tác đọc ghi trên tập tin

DICOM org.dcm4che2.io: chứa các lớp đảm nhận vai trò nhập xuất tập tin theo chuẩn

DICOM. Ngoài ra còn có: org.dcm4che2.media, org.dcm4che2.net, org.dcm4che2.image,

org.dcm4che2.utilThao tác với ảnh DICOM với DCM4CHEĐọc ảnh DICOM: tập tin DICOM có thể được đọc thông qua đối tượng của Java

như java.io.InputStream và java.io.File. Tuy nhiên dcm4che đã thiết kế sẵn lớp chuyên dùng để đọc tập tin DICOM org.dcm4che2.io.DicomInputStream kế thừa lớp java.io.FilterInputStream. Tập tin DICOM sẽ được đọc ra thành các đối tượng org.dcm4che.data.DicomObject. Ví du:

DicomObject dcmObj;DicomInputStream din = null;try { din = new DicomInputStream(new File("image.dcm")); dcmObj = din.readDicomObject();}catch (IOException e) { e.printStackTrace(); return;}finally { try { din.close(); } catch (IOException ignore) { }}Khi đọc tập tin DICOM thì đối tượng DicomInputStream sẽ tự động nhận ra cú

pháp của tập tin DICOM tương ứng tuy nhiên cũng có thể chỉ rõ ra cú pháp này qua câu lệnh như sau:din = new DicomInputStream(new BufferedInputStream(new FileInputStream("image.dcm")), TransferSyntax.ImplicitVRLittleEndian);


http://www.dcm4che.org/docs/dcm4che2-apidocs/org/dcm4che2/util/package-summary.html

http://www.dcm4che.org/docs/dcm4che2-apidocs/org/dcm4che2/image/package-summary.html


Ghi tập tin DICOM: việc ghi thành tập tin theo chuẩn DICOM cũng được dễ dàng thực hiện thông qua lớp org.dcm4che2.io.DicomOutputStreamFile f = new File("newFile.dcm");FileOutputStream fos;try { fos = new FileOutputStream(f);}catch (FileNotFoundException e) { e.printStackTrace(); return;}BufferedOutputStream bos = new BufferedOutputStream(fos);DicomOutputStream dos = new DicomOutputStream(bos);try { dos.writeDicomFile(obj);}catch (IOException e) { e.printStackTrace(); return;}finally { try { dos.close(); } catch (IOException ignore) { }}Các tiện ích khác: dcm4che còn chứa một số các tiện ích có thể sử dụng theo

nhiều mục đích khác nhau thao tác trên tập tin DICOM theo kiểu chạy thông qua dòng lệnh.

dcm2txt – chuyển tập tin DICOM sang dạng text dcm2xml – chuyển tập tin DICOM sang dạng XML dcmdir – thao tác với một thư mục chứa ảnh DICOM. jpg2dcm – chuyển ảnh JPEG sang ảnh DICOM. pdf2dcm - chuyển ảnh tập tin PDF sang tập tin DICOM. rgb2ybr – chuyển dữ liệu màu trong tập tin DICOM từ hệ màu YBR sang hệ

màu RGB xml2dcm – chuyển một định dạng XML thành dạng DICOM.DCM4CHEEBên cạnh dcm4che, dcm4chee (dcm4che enterprise) là một hệ thống quản lý dữ

liệu bệnh viện được mở rộng từ dcm4che. dcm4chee được dùng với nhiều chức năng khác nhau. Tuy nhiên có 2 chức năng phổ biến là:

Lưu trữ và quản lý ảnh DICOM Cho phép làm việc với các chương trình xem ảnh DICOM thông dụng OsiriX,

K-PACS, ClearCanvas,…Dcm4chee cũng được viết trên Java và chỉ sử dụng một ít C/C++ cho việc tối ưu

việc nén ảnh. Dcm4chee sử dụng cơ sở dữ liệu để lưu thông tin đọc được trong header



của tập tin DICOM, thông tin về việc lưu trữ tập tin DICOM, và dữ liệu y tế. dcm4chee hỗ trợ 6 loại cơ sở dữ liệu thông dụng hiện nay như:

PostgreSQL MySQL Oracle SQL Server DB2 Firebird HSQL

Hình 2. 77 Mô hình hệ thống dcm4chee

Một số module của dcm4chee: Module Mô tảGiao diện Web Dcm4chee chứa một tập hợp các giao diện web dùng cho việc

quản lýDICOM Interface Hoạt động như một kho lưu trữ, thông qua module này

dcm4chee có thể lưu trữ, truy lục ảnh DICOM.HL7 Interface Một server tích hợp HL7 có thể hoạt động theo kiều thông điệp

ADT, ORM, và ORUWADO and RID Interfaces

Giao tiếp WADO và RID cho phéo truy cập vào nội dung đã được lưu trữ thông qua web

Media Creation Quản lý việc xuất ra CDBảng 2. 78: Một số tính năng của dcm4chee



2.9. Hệ thống thông tin y tế và chuẩn dữ liệu văn bản HL7

2.9.1. Hệ thống thông tin y tế

2.9.1.1. Giới thiệuHệ thống thông tin bệnh viện HIS (Hospital Information System) được phát triển từ

cuối những năm 1950 đầu 1960, ban đầu chỉ được dùng để làm công việc kế toán, lập hóa đơn, quản lí nhà kho như các phần mềm quản lí doanh nghiệp khác. Hiện nay, HIS đã được phát triển, mở rộng rất nhiều chức năng, trở thành một công cụ hữu ích cho các bệnh viện.

HIS là hệ thống quản lí các loại công việc trong môi trường bệnh viện: Hỗ trợ các hoạt động chẩn đoán và chăm sóc sức khỏe bệnh nhân trong bệnh

viện. Quản lí công việc kinh doanh hàng ngày của bệnh viện: tài chính, nhân sự, bảng

lương, viện phí… Đánh giá hiệu quả và chi phí của bệnh viện để từ đó đề ra kế hoạch phát triển

lâu dài cho bệnh viện.Hệ thống thông tin bệnh viện có thể chia thành nhiều loại: Hệ thống tập trung hay phân tán. Hệ thống hướng kinh doanh thuần túy hay là hướng đến bệnh nhân.Mục đích của bất kì một hệ thống HIS nào cũng là sử dụng hệ thống mạng các máy

tính để thu thập, xử lí và khôi phục lại thông tin quản lí và chăm sóc bệnh nhân từ các khoa trong toàn bệnh viện, thỏa mãn các chức năng cần thiết của tất cả người dùng. Nó cũng là một hệ thống hỗ trợ người điều hành bệnh viện đưa ra các quyết định về việc cải thiện các chế độ chăm sóc sức khỏe, tiết kiệm chi phí và nâng cao hiệu quả.

2.9.1.2. Kiến trúc hệ thốngKiến trúc của hệ thống thông tin bệnh viện đòi hỏi phải được thiết kế đảm bảo độ

mở rộng cả về phần cứng lẫn phần mềm. Khả năng nâng cấp các chức năng của hệ thống là chủ yếu tùy theo sự phát triển của công nghệ.

Kiến trúc phần cứng được đề xuất gồm có một máy chủ cơ sở dữ liệu trung tâm với tính năng kĩ thuật mới nhất nhằm giảm thiểu nguy cơ thất thoát dữ liệu, kết nối với các hệ thống đầu cuối được cấu hình cần thiết để hỗ trợ các công nghệ tiên tiến.

Hình 2. 79: Mô hình kiến trúc của hệ thống HIS



Tùy thuộc vào chức năng, quy mô của từng bệnh viện mà ta có thể tổ chức, sắp xếp hệ thống theo nhiều dạng khác nhau:

Hệ thống tập trung hoàn toàn.

Hình 2. 80: Hệ thống máy chủ tập trung

Hệ thống tập trung, truy xuất đến một hệ thống song song ở phòng xét nghiệm.

Hình 2. 81: Hệ thống tập trung + hệ thống song song ở phòng xét nghiệm

Hệ thống các chức năng ở máy trạm, cơ sở dữ liệu tập trung.

Hình 2. 82: Hệ thống hướng đến máy trạm với cơ sở dữ liệu tập trung



Hệ thống hoàn toàn phân tán

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.

2.9.1.3. Các nhiệm vụ của hệ thống HIS Quản lí hồ sơ bệnh nhân, bệnh án, trang thiết bị, thuốc, quản lí vật tư, tài chính,

đội ngũ y bác sĩ. Cho phép trao đổi thông tin, dữ liệu thống kê hai chiều giữa các phòng ban, các

khoa nhằm phục vụ cho người bệnh một cách tốt hơn. Giúp ban giám đốc của bệnh viện theo dõi kịp thời tình hình của bệnh viện về

công tác chữa bệnh, quản lí bệnh nhân, bệnh án… Hỗ trợ cho công tác đào tạo cũng như nghiên cứu khoa học tại bệnh viện Có khả năng liên kết với hệ thống thông tin của các cơ sở y tế khác như các

bệnh viện trong Bộ Y tế, các cơ sở y tế bên ngoài… Xây dựng các cơ sở dữ liệu về thông tin chuyên ngành y tế. Đánh giá hiệu qủa và chi phí của bệnh viện để từ đó đề ra kế hoạch phát triển

lâu dài cho bệnh viện.

2.9.2. Hệ thống FreeMEDFreeMED là một hệ thống mã nguồn mở quản lý hồ sơ bệnh án

điện tử có thể hoạt động như một HIS. FreeMED được phát triển dựa trên Linux, Apache, MySQL, và PHP (LAMP). Dự án FreeMED được chính thức khởi động 1999 bởi Jeffrey Buchbinder. FreeMED kế thừa từ AMOS (Automated Medical Office System), một chương trình được viết năm 1983 bằng Pascal với hệ thống quản lý cơ sở dữ liệu dBase, sau này FreeMED đã sửa lại sử dụng cơ sở dữ liệu quan hệ và lập trình hướng đối tượng. FreeMED được sử dụng tại các phòng mạch hoặc các bệnh viện. Dữ liệu bệnh nhân được bảo mật tránh các sự truy cập từ bên ngoài. Freemed đã trở thành ứng dụng tùy biến có thể mở rộng, nó thuận lợi cho việc điền mọi thông tin theo yêu cầu y khoa.

Một vài đặc điểm thuận lợi của Freemed Giao diện người dùng thân thiện Hồ sơ bệnh nhân được bảo mật



Quản lý được các phiên trao đổi trong hệ thống(Account Receivable) Quản lý được các yêu cầu truy cập và xem các thông tin chuyên sâu hơn Thao tác với dữ liệu của bệnh nhân dễ dàng, đồng thời có tích hợp REMITT 0.3

để hỗ trợ cho việc tính hóa đơn và báo cáo tình trạng của bệnh nhân. Kết nối với hệ thống Fax, máy in. Lập lịch cho bệnh nhân Hỗ trợ chuẩn HL7 v2.3…

2.9.3. Chuẩn dữ liệu văn bản HL7Thuật ngữ HL7 (Health Level Seven) được phát triển vào năm 1987, được dùng

riêng cho việc trao đổi thông tin y tế, giúp cho việc truyền thông trong y tế được thuận tiện và đơn giản hơn. Chuẩn HL7 được sử dụng phổ biến trong nhiều quốc gia: Úc, Phần Lan, Đức, Hà Lan, Nhật Bản, New Zealand, Áo, Hoa Kỳ…Tháng 6/1994, HL7 được ANSI (American National Standard Institute) xem xét, chấp nhận như là một chuẩn chính thức.

HL7 đã trải qua nhiều phiên bản. HL7 đưa ra phiên bản 2.2 vào tháng 12/1994, được ANSI chấp nhận vào ngày 8/2/1996, phiên bản 2.3 được đưa ra trên CD-ROM vào tháng 4/1997, được công nhận theo chuẩn của ANSI vào 13/5/1997. Chuẩn 2.3 hỗ trợ ADT (Administrator Discharge Transfer), văn bản quản trị bệnh nhân PAD (Patient Administrative Documentation), các yêu cầu, báo cáo kết quả, theo dõi y tế, quản lí báo cáo y tế MRM (Medical Record Management), sao chép, lập kế hoạch, báo cáo trắc nghiệm y tế CTR (Clinical Trials Reporting), báo cáo sự kiện có hại AER (Adverse Event Reporting), tình hình tài chính, các dịch vụ chăm sóc bệnh nhân…

Năm 2001, version 3.0 chính thức được triển khai, đi vào tiếp cận hướng đối tượng cho việc trao đổi dữ liệu y tế. Phiên bản 3.0 ra đời khắc phục một số nhược điểm của các phiên bản 2.x như: tiến trình tích hợp dữ liệu phức tạp, có sự hiểu lầm các đặc tính kĩ thuật, khó khăn trong việc đánh giá tiến trình thực hiện, việc mở rộng là tùy chọn, thiếu chức năng hỗ trợ cho việc bảo mật, thiếu các chức năng hỗ trợ cho công nghệ mới như XML, Web.

Hình 2. 84: Định dạng một file HL7



2.10. Giải pháp mở rộng

2.10.1. Giải pháp 1: sử dụng Cluster ServerCác Cluster Server chạy như những Server dịch vụ, và sử dụng cho việc mở rộng

một ứng dụng Java có thể chạy trên nhiều máy cùng một lúc, cùng đáp ứng những yêu cầu giống nhau.

Giải pháp này có nhiều lợi điểm: Tránh sự dư thừa dữ liệu, bao gồm cả RAID và quản lý nhập xuất Tránh sự dư thừa tài nguyên mạng Khắc phục sự cố Hệ thống có thể đáp ứng nhiều yêu cầu hơn và mạnh mẽ hơn.

Hình 2. 85: Mô hình cơ bản

Sau đây là mô hình khác cụ thể hơn dành riêng cho các ứng dụng Java



Hình 2. 86: Một mô hình cụ thể cho hệ thống Java

Nhược điểm của giải pháp này: Độ bảo mật không cao bởi vì mỗi máy phải mở thêm một cổng để liên lạc với

các máy tính khác. Có tính chất cục bộ về mặt địa lý: các máy tính dùng làm Cluster được đặt trong

mạng nội bộ. Nếu xảy ra sự cố (như mất điện chẳng hạn) thì tất cả các máy đều bị ảnh hưởng

2.10.2. Giải pháp 2: phát triển thêm tính năng mở rộng cho ServerVới đặc điểm của ứng dụng có tính tương tác, các Client cần phải được truyền dữ

liệu với nhau, cho nên trong giải pháp này khi cần mở rộng một Server thì ngoài việc yêu cầu Client mới kết nối đến một Server dự phòng thì Server ban đầu sẽ đóng vai trò như là một Client của một Server dự phòng để Client ở hai Server có thể liên lạc được với nhau.



Hình 2. 87: Cơ chế hoạt động của tính năng mở rộng

Khi cần mở rông Server, Server A và Server B sẽ đóng vai trò là các User của nhau. Sau đó các user mới sẽ kết nối tới Server B mà vẫn tương tác được với các User trong Server A vì Server B sẽ chuyển dữ liệu tới Server A và ngược lại.

Ưu điểm của giải pháp này: Các Server không cần nằm tập trung về mặt địa lý Dễ dàng bảo trì Server bị hư hỏng hay khắc phục các sự cố mất điện. Khi

Server A đang thực hiện nhiệm vụ của mình, tuy nhiên nó cần được ngưng hoạt động để bảo trì. Do đó nó cần phải chuyển hết User của mình cho Server khác rồi sau đó mới dừng hoạt động được. Trong quá trình di chuyển User như vậy thì chắc chắn sẽ có những ảnh hưởng nhất định tới User đang bị di chuyển, tuy nhiên hoạt động hay tương tác giữa các User khác không bị ảnh hưởng.

Hình 2. 88: Di chuyển User

Nhược điểm: Cần nhiều thời gian và điều kiện để nghiên cứu, phát triển. Hoạt động của User có thể bị ảnh hưởng.



2.10.3. Giải pháp 3: kết hợp giữa hai giải pháp 1 và 2Giải pháp này sử dụng Cluster để mở rộng Server. Dữ liệu nào cần tính thời gian

thực thì chuyền trực tiếp giữa 2 Server ứng dụng giống như giải pháp 2, còn ngược lại thì thông qua các Cluster Server để giảm áp lực lên Server ứng dụng.

Ưu điểm: tận dụng ưu điểm của cả hai giải pháp trên, giảm bớt nhược điểm về độ trễ của dữ liệu so với giải pháp 1.

Nhược điểm: các Server vẫn có tính cục bộ.


Báo cáo Đồ án tốt nghiệp CHƯƠNG III: THỰC HÀNH

CHƯƠNG III: THỰC HÀNH

Server được viết bằng ngôn ngữ Java và được đặt tên là WebF. Trong đó Client tương thích sẽ được viết bằng ngôn ngữ Action Script vì ngôn ngữ này đã được hỗ trợ giao thức RTMP khi giao tiếp với Server. Bất kì một ứng dụng nào khi viết trên Server WebF đã được hỗ trợ sẵn tính năng chuyển phát hình ảnh, âm thanh, Shared Object. Ngoài ra ứng dụng cũng được hỗ trợ cơ chế quản lý user, quản lý room, một số sự kiện phát sinh liên quan tới user như có user mới tham gia room, user thoát khỏi room,…

3.1. Tạo một ứng dụng chạy trên Server WebFMinh hoạ sau đây là tạo ra một ứng dụng chạy trên Server WebF với một hàm sayHello()

trả về một chuỗi “Hello World”. Client được viết bằng ngôn ngữ Action Script gọi hàm sayHello() của ứng dụng chạy trên Server và sau đó hiện lên kết quả trả về từ Server.

Bước 1: Tạo một dự án Java đặt tên là Hello, sau đó viết một lớp Application kế thừa lớp WebF.Manager.App.AppAdapter.package Hello;import WebF.Manager.App.AppAdapter;public class Application extends AppAdapter{ public String sayHello() //hàm này có thể được gọi từ Client { return "Hello World"; }}

Sau khi viết xong biên dịch thành tập tin Hello.jar đề sử dụng.Bước 2: Tạo một dự án Flex đặt tên là Hello, sau đó viết code như sau

<?xml version="1.0" encoding="utf-8"?><mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" themeColor="#00C6FF" width="294" height="154"><mx:Script>

<![CDATA[import mx.controls.Alert;private var nc:NetConnection; //đối tượng tạo một kết nối tới Serverprivate function onClick():void{

nc=new NetConnection(); // tạo mới đối tượng nc.objectEncoding=ObjectEncoding.AMF0; //sử dụng chuẩn AMF0 // Khai báo hàm thụ lý sự kiệnnc.addEventListener(NetStatusEvent.NET_STATUS,netStatusHandler);nc.connect(uri.text);

}function netStatusHandler(event:NetStatusEvent):void{

switch(event.info.code){

case "NetConnection.Connect.Success": //Gọi hàm “sayHello” trên Server

nc.call("sayHello",new Responder(callSuccess));break;



}}public function callSuccess(s:String):void{

Alert.show(s);}]]>

</mx:Script><mx:Button x="191" y="28" label="Call" id="call" click="onClick()"/><mx:TextInput x="23" y="28" id="uri" text="rtmp://localhost/Hello"/>

</mx:Application>Những dòng code như trên sẽ tạo ra trang Hello.html với một ô textbox chứa địa chỉ của

Server cần kết nối tới và một nút bấm để thực hiện lệnh kết nối tới Server, nếu thành công thì gọi hàm sayHello() trên Server. Kết quả như sau:

Hình 3. 1: Giao diên web của Client

Bước 3: Cấu hình cho Server biết có một ứng dụng mới Tạo một thư mục Hello trong thư mục WebFApp (đây là thư mục chứa các ứng dụng

của WebF) có sẵn. Thư mục này là thư mục gốc của ứng dụng. Sau này tất cả các dữ liệu của ứng dụng sẽ được lưu ở đây.

Tạo một thư mục conf nằm trong thư mục Hello đã tạo ở trên. Tiếp theo thực hiện các công việc sau trong thư mục conf

o Chép tập tin Hello.jar đã biên dịch ở trên vào thư mục confo Tạo một tập tin giống với tên của ứng dụng với phần mở rộng là “.conf” tức là

Hello.conf. Thêm vào tập tin một dòng chỉ lớp đã kế thừa lớp WebF.Manager.App.AppAdapter.

Nội dung của tập tin Hello.conf như sau:Hello.Application

Bước 4: Khởi động WebF bằng lệnh “java –jar WebF.jar”.



Hình 3. 2: Khởi động Server WebF

Khởi động Server thành công. Hiện tại Server có hai ứng dụng một là ứng dụng Hello, hai là ứng dụng iPath.

Bước 5: chạy trang web Hello.html và thu nhận kết quả

Hình 3. 3: Kết nối thành công

Thông báo trên màn hình hiện ra chứng tỏ Client đã kết nối thành công với Server và ứng dụng đã chạy được.

3.2. Tính năng chia sẻ và lưu trữ Video

3.2.1. Giới thiệuServer chuyển phát âm thanh và hình ảnh được thiết kế dựa trên giao thức RTMP.

Việc thiết kế dựa trên giao thức này nhận được nhiều sự thuận lợi bởi vì dữ liệu âm thanh và hình ảnh dùng trong giao thức này được tối ưu hoá bởi các giải thuật nén tiên tiến nhất hiện nay, và có thể đáp ứng được nhu cầu thực tế về truyền tải video thời gian thực.



3.2.2. Bắt tay trên giao thức RTMP Áp dụng cách bắt tay 3-hướng của TCP Bước 1:

o Sau khi hai máy client và server bắt tay nhau trên IP/TCP thì client gởi gói TCP đến port 1935 (port mặc định của giao thức RTMP)

o Dữ liệu của gói này đầu tiên là byte 0x03o Tiếp theo là 1536 byte có giá trị ngẫu nhiên

Hình 3. 4: Bắt tay RTMP giai đoạn một

Bước 2:o Sau khi server nhận được thông điệp yêu cầu kết nối của client, server

gửi gói TCP về client yêu cầu xác nhận kết nối.o Dữ liệu của gói này gồm 1+1536x2 byte bắt đầu bằng byte 0x03o Tiếp theo là 1536 byte được tạo ngẫu nhiên ở servero Cuối cùng là server gửi trả lại 1536 byte mà mà client đã gửi lên cho

server



Hình 3. 5: Bắt tay giai đoạn 2

Bước 3:o Giai đoạn cuối cùng trong quá trình bắt tay 3 hướng là client gửi gói xác

nhận lại yêu cầu kết nối của mình.o Dữ liệu của gói này gồm có 1+1536 byte, cũng bắt đầu bằng byte 0x03o Tiếp theo sau đó là 1536 byte của server đã gửi cho client để xác nhận

chính xác là client thực sự muốn kết nối tới server

Hình 3. 6: Bắt tay giai đoạn 3

3.2.3. Thực hiện kết nốiSau khi client và server thực hiện xong bắt tay, client gửi một thông điệp kết nối.

Trong thông điệp này client yêu cầu được kết nối vào một phòng có sẵn hoặc là tạo một phòng mới.



Trong thông điệp trả về của server, server sẽ trả về thông điệp kết nối thành công nếu client yêu cầu kết nối vào một phòng đã tồn tại, hoặc yêu cầu tạo một phòng mới chưa có trên server. Server sẽ gửi về thông điệp báo lỗi, nếu yêu cầu kết nối vào phòng chưa có sẵn hoặc tạo một phòng đã tồn tại trên server.

Hình 3. 7: Sơ đồ gửi, trả lời thông điệp kết nối giữa client và server.

3.2.4. Chia sẻ âm thanh, hình ảnh và lưu trữ tại ServerSau khi thực hiện xong việc kết nối, nếu client muốn yêu cầu server chuyển dữ liệu

video của nó đi tới các client khác để hiện thị thì client sẽ gửi thông điệp publish kèm theo tên của dữ liệu video đó.

Khi nhận được thông điệp publish, server sẽ kiểm tra xem tên gửi kèm với thông điệp publish đã được sử dụng chưa nếu chưa thì server gửi trả thông điệp thành công. Ngược lại thì server gửi trả thông điệp lỗi. Tên gửi kèm với thông điệp publish của client dùng để nhận diện các dữ liệu của từng client với nhau, tránh nhầm lẫn dữ liệu giữa các client.

Khi client bắt đầu nhận được thông điệp thành công gửi trả từ server, liền ngay sau đó client sẽ gửi dữ liệu video đến cho server. Server sẽ nhận dữ liệu video này rồi làm trạm trung gian cho các client khác.



Hình 3. 8: Sơ đồ gửi, trả lời thông điệp publish giữa client và server.

Một client muốn nhận dữ liệu video của một client nào đó, thì client này cần gửi thông điệp play kèm theo tên của dữ liệu video muốn hiển thị.

Khi nhận được thông điệp play, server sẽ kiểm tra xem tên gửi kèm với thông điệp này đã tồn tại hay chưa, nếu đã tồn tại server gửi trả thông điệp thành công rồi tiếp sau đó server sẽ chuyển dữ liệu video đã nhận được tương ứng với tên của client gửi lên về cho client hiển thị. Ngược lại thì server gửi trả thông điệp lỗi.

Hình 3. 9: Sơ đồ gửi, trả lời thông điệp play giữa client và server.

Như vậy, cuối cùng thì luồng dữ liệu giữa server và các client sẽ như sau



Hình 3. 10: Mô hình luồng dữ liệu giữa client và server khi chuyển dữ liệu video

Hình 3. 11: Kết quả thử nghiệm

Trong quá trình chia sẻ âm thanh, hình ảnh giữa các Client, Server còn có thể lưu trữ những dữ liệu này lại. Do đó người dùng có thể xem dưới dạng một đoạn Video có sẵn trên Server. Và lúc này Server hoạt động như một streaming Server.



3.3. Tính năng Shared ObjectShared Object là một tính năng khá hay, được hỗ trợ như là phần nền của hệ thống

cho nên rất mạnh và dễ dàng sử dụng.Để sử dụng Shared Object, đoạn mã bằng Action Script sau đây cần được xem qua

public var so:SharedObject;so = SharedObject.getRemote(“name”, “rtmp://localhost/iPath”, true);//trong đó đối số đầu tiên là tên của đối tượng Shared Object//đối số thứ 2 là địa chỉ của ứng dụng trên Server//đối số cuối cùng chỉ ra là đối tượng Shared Object có lưu trữ trên Server hay không?so.connect(nc); //kết nối đối tượng Shared Object tới Serverso.data[“thuộc tính”] = giá_trị; //thiết lập giá trịgiá_trị= so.data[“thuộc tính”]; //lấy giá trị của thuộc tính.

Tiếp theo sau đây là minh hoạ một chương trình có sử dụng Shared Object khi các bác sĩ đang thảo luận một hình ảnh mà một bác sĩ muốn báo cho những bác sĩ khác tập trung vào một điểm mình đang nói trên hình ảnh.

Đầu tiên mở một Client lên kết nối tới Server.

Hình 3. 12: Kết nối tới Server



Hình 3. 13: Kết nối thành công

Khi biểu tượng kết nối mở ra tức là kết nối thành công, tiếp theo một Client khác tiếp tục được mở ra.

Hình 3. 14: Tính năng Shared Object

Bác sĩ sẽ click vào mũi tên đỏ kéo đến chỗ khác để thông báo cho bác sĩ khác tập trung vào điểm mà mình muốn nói. Trong khi bác sĩ kéo mũi tên đỏ đi chỗ khác thì Client sẽ gửi thông báo đến sever rằng dữ liệu về toạ độ của mũi tên đã thay đổi.



Hình 3. 15: Thông điệp thiết lập dữ liệu của Shared Object được gửi về Server

Kết quả giữa hai Client sau khi bác sĩ kéo mũi tên đi chỗ khác.

Hình 3. 16: Sử dụng tính năng Shared Object

Rõ ràng với tính năng này, khả năng chia sẻ thông tin được nâng cao và cũng làm tăng hiệu quả truyên đạt thông tin giữa các ứng dụng, đồng thời cũng tạo ra cảm giác trực quan hơn giữa các người dùng đầu cuối.

3.4. Tính năng lấy thông tin của bệnh nhân trong FreeMEDThông tin của bệnh nhân được lấy dễ dàng khi bác sĩ gõ tên, ID hay ngày nhập viện của

bệnh nhân vào ô tìm kiếm.



Hình 3. 17: Tìm kiếm thông tin bệnh nhân

Trong khi bác sĩ gõ thông tin, chương trình sẽ đóng vai trò của Client sẽ tự động tìm kiếm thông tin phù hợp. Client sẽ gửi các thông điệp yêu cầu Server tìm kiếm thông tin về bệnh nhân gần đúng nhất so với những gì bác sĩ đang gõ trực tiếp vao ô tìm kiếm.

Hình 3. 18: Thông điệp “searchPatient” giúp tìm kiếm bệnh nhân

Sau khi bác sĩ đã gõ đầy đủ thông tin thì Client sẽ gửi thông điệp yêu cầu Server lấy thông tin của bệnh nhân trong FreeMED gửi về cho Client.



Hình 3. 19: Thông điệp “getFreemedInfo” lấy thông tin của bệnh nhân trong FreeMED

Kết quả như sau

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

3.5. Tính năng lấy ảnh trong MyFreePACS và chuyển thành ảnh JPEGSau khi lấy thông tin bệnh nhân trong FreeMED thì dựa vào id của bệnh nhân,

Client tiếp tục gửi yêu cầu Server lấy id ảnh của bệnh nhân gửi về cho Client. Sau khi nhận được id ảnh, nếu các bác sĩ nhấn nút xem ảnh thì một thông điệp yêu cầu Server lấy ảnh DICOM của bệnh nhân trong hệ thống MyFreePACS.



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

Khi Server có được ảnh DICOM, một module trên Server dùng thư viện dcm4che để tách ảnh DICOM ra thành ảnh JPEG, rồi cũng đọc thông tin của bệnh nhân chứa trong ảnh ra cùng lúc, nhằm tránh việc mở đọc ảnh DICOM nhiều lần.

Trong quá trình chuyển đổi ảnh, Server cũng tạo ảnh thumbnail của các ảnh đã tạo ra để Client lấy về hiện thị lên trước.

Hình 3. 22: Thông điệp lấy ảnh Thumbnail của ảnh DICOM tương ứng



Hình 3. 23: Ảnh thumbnail được hiện thị sau khi lấy về từ Server

Khi các bác sĩ click vào ảnh thumbnail nào thì ảnh thật tương ứng sẽ được gửi về và hiện lên

Hình 3. 24: Ảnh thật tương ứng với ảnh thumbnail được chọn.



Trong quá trình xem ảnh các bác sĩ có thể xem thông tin về ảnh khi click vào nút “Thông tin ảnh”.

Hình 3. 25: Thông điệp “getDICOMInformation” giúp lấy thông tin chứa trong ảnh DICOM

Hình 3. 26: Kết quả thông tin chứa trong ảnh DICOM sau khi được lấy về


Báo cáo Đồ án tốt nghiệp CHƯƠNG IV: THẢO LUẬN

CHƯƠNG IV: THẢO LUẬN

Trong khoảng thời gian làm luận án tốt nghiệp, tuy thời gian cũng khá khiêm tốn nhưng cùng với sự giúp đỡ của thầy hướng dẫn, bạn bè và nỗ lực cá nhân nên các mục tiêu đề ra đã dần dần được hoàn tất.

Tuy nhiên, một vấn đề đặt ra cho ứng dụng hội chẩn từ xa này là khả năng bảo mật thông tin của bệnh nhân bởi vì đây là những dữ liệu nhạy cảm. Nhưng việc đi sâu vào vấn đề bảo mật này cần rất nhiều thời gian nghiên cứu để làm sao vừa bảo đảm cho hệ thống truyền tải dữ liệu âm thanh, hình ảnh theo thời gian thực cũng như việc đảm bảo bí mật thông tin. Việc bảo mật thông tin này làm ảnh hưởng rất nhiều tới độ trễ của dữ liệu. Như vậy định hướng sau này của đề tài là sẽ được tiếp tục phát triển thêm những tính năng để mã hoá thông tin bênh nhân.

Ngoài ra, với bất cứ một ứng dụng nào cung cấp cho số đông các người dùng thì cũng đều phải áp dụng Cluster. Rõ ràng nếu hệ thống được sử dụng cho một bệnh viện nhỏ có khoảng vài chục người cùng tham gia một lúc thì sẽ không cần sử dụng Cluster. Nếu hệ thống này được sử dụng rộng rãi hơn thì vấn đề này bắt buộc phải xem xét. Do đó đây cũng là một hướng khác cho con đường phát triển tiếp theo của đề tài.

Mặt khác, hệ thống media Server này cũng có thể xây dựng để trở thành hệ thống elearning. Vì trong hệ thống elearning cần rất nhiều tương tác giữa người học và giảng viên. Giảng viên có thể chia sẻ bài giảng trực tuyến cũng như trực tiếp tương tác để chỉ rõ cho từng học viên đang theo dõi. Khi cần giảng viên có thể thao tác trực tiếp trên máy của mình để hướng dẫn một bài học nào đó và tất cả mọi học viên đều xem thấy được. Trong hệ thống elearning thông thường thì học viên chỉ có thể lắng nghe mà không thể đặt được câu hỏi cho người trình bày. Còn đối với hệ thống này, học viên không những có thể đặt câu hỏi trực tiếp cho giảng viên mà còn có thể thảo luận thành nhóm chung với các học viên khác nữa.

Không chỉ thế, media Server này còn có thể xây dựng thành Server chia sẻ video trực tuyến, hội thảo trực tuyến,…


Báo cáo Đồ án tốt nghiệp CHƯƠNG V: KẾT LUẬN

CHƯƠNG V: KẾT LUẬN

Về mặt lý thuyết:Luận văn đã đề ra vấn đề “xây dựng media Server ứng dụng trong hội chẩn từ xa”,

do đó luận văn tập trung nghiên cứu cơ sở lý thuyết để giải quyết cho được vấn đề trên, cụ thể như sau:

o Mô hình hệ thống Mô hình Peer to Peer Mô hình Client – Server

o Kiến trúc Servero Giao thức truyền tải dữ liệu thời gian thực

RTP (Realtime Transport Protocol) RTMP (Real Time Messaging Protocol)

o Chuẩn mã hoá dữ liệu AMF (Action Message Format) AMF0 AMF3

o Shared Objecto Chuẩn nén âm thanh HE-AACo Chuẩn nén hình ảnh MPEG4/H.264o Hệ thống lưu trữ và truyền tải hình ảnh (PACS)

Hệ thống MyFreePACS Chuẩn hình ảnh DICOM dùng trong y tế

o DICOM Toolkit DCMTK DCM4CHE

o Hệ thống thông tin y tế HIS Hệ thống FreeMED Chuẩn dữ liệu văn bản HL7

o Giải pháp mở rộng: Giải pháp là giải pháp sử dụng Cluster Server Giải pháp phát triển tính năng mở rộng của Server

Cơ bản luận văn đã giải quyết tương đối đầy đủ tất cả nội dung lý thuyết đã đề ra Về mặt thực hànhTừ phần cơ sở lý thuyết đã nghiên cứu, một media server ở mức cơ bản dùng trong

việc chia sẻ và lưu trữ âm thanh, hình ảnh, hỗ trợ tính năng Shared Object, cũng như tính năng tương tác với HIS, PACS để lấy ảnh và thông tin bệnh nhân đã được xây dựng. Media Server này cũng đã hoạt động tốt với một Client được xây dựng ở một đề tài khác, và hợp thành một bộ sản phẩm hỗ trợ các bác sĩ trong việc hội chẩn từ xa.


Báo cáo Đồ án tốt nghiệp TÀI LIỆU THAM KHẢO

TÀI LIỆU THAM KHẢO

1. Rafael C. Gonzalez, Richard E. Woods. Digital Image Processing (2nd Edition), Prentice Hall, 2002.

2. Akimichi Ogawa, Katsushi Kobayashi, Kazunori Sugiura, Osamu Nakamura, Jun Murai, "Design and Implementation of DV based video over RTP", May 2000, Packet Video Workshop 2000.

3. Adobe Systems Inc, "Action Message Format - AMF 0", June 2006.4. Adobe Systems Inc, "Action Message Format -- AMF 3", June 2006.5. David Salomon, “Data Compression The Complete Reference Fourth Edition”,

Springer-Verlag London Limited 2007.6. Gerald Moser, “MPEG-4 aacPlus - Audio coding for today’s digital media

world”, Coding Technologies, November 2005.7. Iain E. G. Richardson, “H.264 and MPEG-4 Video Compression Video Coding

for Next-generation Multimedia”, John Wiley & Sons Ltd, 2003.8. Nguyễn Đức Thuận , Vũ Duy Hải, Trần Anh Vũ, “Hệ thống thông tin y tế”,

Nhà xuất bản Bách Khoa Hà Nội, năm 2006.9. H.K.Huang, “PACS and Imaging Informatics”, JohnWiley & Son Inc.,

Hoboken, NewJersey, năm 2004.10. Nguyễn Quốc Cường, “Internetworking với TCP/IP”, Nhà Xuất Bản Giáo duc,

2001.11. Nguyễn Tấn Quy, Lưu Dương Minh Phương, “Tìm Hiểu Và Ứng Dụng

MyFreePacs Trong Việc Xây Dựng Hệ Thống Lưu Trữ Và Truyền Ảnh” (Picture Archive and Communication Systems – PACS ), 2008.

12. Đặng Thị Thanh Huyền, “Nghiên cứu một tích hợp dữ liệu giữa hai hệ thống HIS và PACS”, 2008.

13. Coding Technologies, http://www.codingtechnologies.com14. Gnash, http://wiki.gnashdev.org/RTMP15. Red5, http://osflash.org/red516. DICOM, http://dicom.offis.de


http://dicom.offis.de/

http://osflash.org/red5

http://wiki.gnashdev.org/RTMP

http://www.codingtechnologies.com/

http://www.sfc.wide.ad.jp/DVTS/pv2000/index.html

Documents

Media Server(DATN Pham Thai Bao)