Mục lục
Chương 1. Mở đầu 1
1.1. Đặt vấn đề 1
1.2. Các hệ thống trên thế giới 1
1.3. Một số hệ thống ở Việt Nam 3
1.3.1. Hiện trạng phát triển của Việt Nam 3
1.3.2. Chính sách phát triển của Việt Nam trong tương lai 5
1.4 Nhu cầu và giải pháp 5
1.5 Cấu trúc của luận văn 6
Chương 2. Tổng quan về mạng và truyền thông dữ liệu 7
2.1. Các mô hình mạng 7
2.1.1. Mô hình mạng khách chủ (Client/Server). 7
2.1.2. Mô hình mạng ngang hàng (Peer to Peer). 8
2.2. Giao thức truyền thông trong mạng Internet 9
2.2.1. Giao thức điều khiển truyền thông TCP 9
2.2.2. Truyền thông User Datagram Protocol – UDP 10
2.2.3. Real Time Protocol – RTP 11
2.2.4. Real Time Streaming Protocol – RTSP 13
2.3 Truyền thông thời gian thực 14
2.3.1 Dữ liệu trong truyền thông thời gian thực 14
2.3.2 Truyền dòng dữ liệu 15
2.3.3 Các phương thức truyền dòng dữ liệu video 16
2.3.4 Vấn đề đồng bộ hoá Video và Audio 18
2.4 Nén/Giải nén Video 19
2.4.1 Các khái niệm cơ bản về nén video 19
2.4.2 Một số chuẩn nén video 20
2.5 Nén/Giải nén Audio 23
2.5.1 Một số khái niệm về nén Audio 23
2.5.2 Một số chuẩn nén audio 24
2.6. Một số khái niệm về tin học y sinh 25
2.6.1. Chuẩn đoán bệnh từ xa 25
2.6.2. Các loại dữ liệu trong tin học y sinh 26
Chương 3. Thiết kế hệ thống chuẩn đoán bệnh từ xa 27
3.1. Tìm hiểu về yêu cầu của hệ thống 27
3.2. Kiến trúc của hệ thống 28
3.2.1. Kiến trúc tổng thể của hệ thống 28
3.2.2. Kiến trúc của hệ thống phía bác sĩ: 29
3.2.3. Kiến trúc của hệ thống phía bên bệnh nhân: 30
3.3. Đặc tả các module xây dựng 32
Chương 4. Triển khai hệ thống 33
4.1 Giao diện hệ thống 33
4.1.1. Giao diện hệ thống bên Client 35
4.1.2. Giao diện hệ thống bên Server 38
4.2. Mô hình truyền dữ liệu của hệ thống 41
4.2.1. Mô hình 41
4.2.2. Mô tả mô hình truyền dữ liệu 41
4.3. Xây dựng Module Video Conference 42
4.3.1 Video streamming 42
4.3.2 Audio streamming 45
4.4. Tìm hiểu về Camera số có khả năng điều khiển 48
4.4.1 Giới thiệu về camera sử dụng trong hệ thống 48
4.4.2. Độ phân giải của camera 50
4.4.3. Tính nhạy sáng 50
4.4.4. Thấu kính và các tham số của thấu kính 50
4.4.5.Chức năng điều khiển của Camera 51
4.4.6 Lập trình điều khiển camera 51
Chương 5. Kết luận 54
5.1 Các kết quả thu được 54
5.2 Những lợi ích hệ thống đem lại 54
5.3 Hướng phát triển trong tương lai 55
Phụ lục 1: Bảng các thuật ngữ sử dụng 56
Tài liệu tham khảo 57
67 trang |
Chia sẻ: lethao | Lượt xem: 2964 | Lượt tải: 1
Bạn đang xem trước 20 trang tài liệu Khóa luận Xây dựng module Video Conference và kết nối camera có khả năng điều khiển, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
RTSP có thể sử dụng RTP nhưng hoạt động của RTSP không phụ thuộc vào cơ chế được sử dụng để truyền continuous media.
RTSP hỗ trợ các thao tác sau:
Lấy media từ media sever.
Mời một media sever vào conference.
Thêm media vào một presentation đã có sẵn.
2.2.4.2. Các đặc tính của giao thức RTSP
RTSP có các đặc tính nổi bật sau:
Có khả năng mở rộng: Các tham số và phương thức mới có thể được thêm vào RTSP một cách dễ dàng.
Bảo mật: RTSP sử dụng lại cơ chế bảo mật web
Transport – independent (độc lập truyền thông): RTSP có thể sử dụng giao thức truyền thông tin cậy như TCP, giao thức truyền thông không tin cậy như UDP hoặc các giao thức khác.
Phù hợp với các ứng dụng chuyên nghiệp.
Có khả năng có nhiều sever: Mỗi media stream trong một presentation có thể từ một sever khác nhau. Client sẽ tự động thiết lập nhiều phiên điều khiển đồng thời tới các media sever khác nhau
RTSP có thể dễ dàng được mở rộng, việc mở rộng có thể được thực hiện theo các cách sau:
o Những phương thức đã có sẵn có thể được mở rộng với các tham số mới.
o Có thể thêm vào các phương thức mới
o Có thể định nghĩa một phiên bản mới của giao thức.
Tổng kết các giao thức sử dụng trong quá trình truyền dữ liệu thời gian thực trên mạng ta có hình sau:
Hình 6 : Sơ đồ các giao thức dụng cho truyền thông thời gian thực
2.3 Truyền thông thời gian thực
2.3.1 Dữ liệu trong truyền thông thời gian thực
Đặc trưng quan trọng nhất đối với dữ liệu trong hệ tương tác trực tuyến thời gian thực là chúng phụ thuộc chặt chẽ với nhau trong quá trình truyền (qua mạng) và xử lý (xử lý trước và sau khi truyền). Khi luồng dữ liệu bắt đầu truyền, sẽ có một sự ràng buộc về mặt thời gian trong việc nhận và trình diễn dữ liệu. Chính vì lý do đó, mà dữ liệu đa phương tiện thời gian thực thường được gọi là các dòng dữ liệu đa phương tiện (điều này để nói rằng các gói dữ liệu được truyền đi dưới dạng các dòng một cách đều đều, không thay đổi, chúng phải được nhận và xử lý trong một khoảng thời gian giới hạn nào đó để có thể tạo ra một kết quả chấp nhận được).
Các hệ thống truyền thông đa phương tiện thời gian thực đều phải thực hiện quá trình thu bắt (capture), xử lý (process), truyền (transmission), nhận (receive) và trình diễn (presentation) dữ liệu đa phương tiện. Dưới đây là mô hình mô tả một hệ truyền thông đa phương tiện thời gian thực:
Capture Devices
Process
Session Manager
Stream
Data Source
Data Source
Session Manager
Data Source
Player
Stream
Device
Hình 7: Mô hình truyền dữ liệu thời gian thực
Với đặc thù của dữ liệu đa phương tiện (dung lượng lớn, và sự phụ thuộc về thời gian), nên các hệ thống truyền thông đa phương tiện thời gian thực đòi hỏi phải có hiệu năng cao cả về băng thông rộng, tốc độ truyền và khả năng xử lý linh hoạt, độ tin cậy (đảm bảo độ trung thực của âm thanh, hình ảnh) và cung cấp dịch vụ chấp nhận được. Các hệ thống truyền thông đa phương tiện đòi hỏi phải đáp ứng được sự tích hợp của nhiều loại dòng dữ liệu khác nhau, phải duy trì được mối quan hệ về mặt thời gian giữa các dòng dữ liệu khác nhau đó.
Sự phát triển của khoa học kỹ thuật trong lĩnh vực truyền thông đã cho phép chúng ta phát triển các ứng dụng đa phương tiện thời gian thực trong các mạng máy tính. Độ tin cậy, tốc độ truyền, băng thông của mạng ngày càng được cải thiện tốt hơn.
2.3.2 Truyền dòng dữ liệu
Khái niệm truyền dòng có thể hiểu là khi nội dung của audio hay video được truyền tới nơi nhận, nơi nhận có thể trình diễn được ngay trong quá trình truyền mà không cần phải đợi đến khi toàn bộ nội dung dữ liệu được truyền xong. Cơ chế này hoàn toàn khác với cơ chế download file của các giao thức HTTP hay FTP.
Truyền dòng cho phép chúng ta thể hiện các dòng video thời gian thực mà không phụ thuộc vào độ dài của video. Điều này rất có ý nghĩa khi truyền các file video có kích thước lớn hay các dòng video có độ dài không xác định. Khi đó, các giao thức khác như FTP hay HTTP sẽ không thể sử dụng được.
Chúng ta có thể bắt gặp rất nhiều trường hợp sử dụng cơ chế truyền dòng như các chương trình truyền hình trực tiếp, hội thảo qua mạng. Với khả năng truyền tải nội dung video, audio thông qua mạng, chúng ta có một phương pháp giao tiếp và truy nhập thông tin mới.
Với góc nhìn bao quát, truyền dòng là một phương pháp truyền thông tin liên tục, trong đó nội dung video được truyền đi theo trình tự thời gian. Bên nhận khi nhận dòng thông tin, nội dung video có thể trình diễn được ngay trên màn hình. Khả năng này rất có ý nghĩa đối với các loại dữ liệu phụ thuộc thời gian như video, audio, bởi vì để đảm bảo chất lượng cảm thụ video thì phải đảm bảo được mối quan hệ về mặt thời gian giữa các khung hình.
2.3.3 Các phương thức truyền dòng dữ liệu video
Có ba phương thức truyền dòng dữ liệu video như sau:
Truyền đơn hướng (Unicast)
Unicast là một phương thức đơn giản: các gói dữ liệu được truyền trực tiếp từ máy tính này tới máy tính khác. Unicast được sử dụng cho việc truyền dòng giữa hai máy tính (point-to-point). Một vấn đề đặt ra khi sử dụng phương thức truyền unicast, đó là băng thông của mạng (đường nối giữa hai máy tính). Dữ liệu đa phương tiện thời gian thực (audio, video) có dung lượng lớn, đòi hỏi tốc độ truyền cao (các dòng theo nén chuẩn MPEG1, MPEG2 đòi hỏi tốc độ truyền từ 3-9 Mbit/s). Do đó, nếu chúng ta chỉ truyền một dòng thì mạng Ethernet với tốc độ 10Mbit/s là đủ, tuy nhiên nếu chúng ta muốn truyền nhiều dòng cùng một lúc thì cần mạng có tốc độ truyền lớn hơn (các mạng Ethernet 100 Mbit/s, mạng ATM, mạng FDDI…). Một giải pháp khác là sử dụng các công nghệ nén hiện đại(H.263, H.264, MPEG-4) để nén dữ liệu Video và Audio, khi đó yêu cầu về băng thông của mạng sẽ không cao.
Truyền quảng bá (Broadcast)
Phương thức broadcast được dùng cho việc quảng bá. Khi một máy truyền theo kiểu broadcast, dòng dữ liệu đó sẽ được truyền tới tất cả các máy trong mạng con cùng một lúc. Nhược điểm của phương pháp này, đó là tất cả các máy trong mạng đều nhận được dòng dữ liệu đó cho dù nó không có nhu cầu nhận. Việc này sẽ chiếm dụng băng thông của mạng. Do đó, broadcast chỉ nên dùng trong trường hợp truyền thông cho các loại dữ liệu không cần đòi hỏi băng thông lớn, hay trong trường hợp thiết bị phần cứng của mạng không hỗ trợ phương thức multicast.
Truyền đa hướng (Multicast)
Khi sử dụng phương thức unicast hay broadcast, chúng ta có thể gặp phải một số vấn đề sau:
Với phương thức unicast, khi nhiều máy cùng muốn nhận dòng dữ liệu đa phương tiện đó, đòi hỏi máy tính truyền phải thực hiện nhiều kết nối đồng thời (mỗi kết nối sẽ truyền dòng dữ liệu đó cho máy tính tương ứng), điều này rất phức tạp và thông thường số lượng máy tính muốn nhận rất hạn chế.
Với phương thức broadcast, nhiều máy tính có thể nhận được đồng thời một dòng đi ra từ một máy tính, tuy nhiên ngay cả những máy tính không muốn nhận dòng dữ liệu đó cũng phải nhận, điều này gây nên tình trạng “rác” trong mạng, chiếm dụng băng thông của mạng, nên khi số lượng dòng truyền tăng có thể dẫn đến tắc nghẽn mạng.
Nhược điểm của hai phương thức đó được khắc phục trong phương thức multicast. Multicasting là một công nghệ mới cho phép dữ liệu được gửi đi từ một host và sau đó được nhân lên và gửi tới những host khác mà không gây ra tắc nghẽn mạng. Dữ liệu truyền theo cơ chế multicast chỉ được nhân lên chỉ khi các tiến trình chạy trên máy trạm thuộc mạng muốn lấy dữ liệu. Lưu ý là không phải tất cả các giao thức đều hỗ trợ “multicast” (trong Windows chỉ có hai giao thức có khả năng hỗ trợ “multicast” là giao thức IP và giao thức ATM). Ngoài ra, không phải lúc nào chúng ta cũng có thể sử dụng được địa chỉ multicast, chỉ những mạng mà thiết bị phần cứng (Hub, Switch, Router) của nó hỗ trợ thì phương thức multicast mới có thể sử dụng được [2].
Hệ thống do nhóm xây dựng, mô hình truyền dòng dữ liệu theo mô hình đơn hướng, tức là giao tiếp thực hiện chỉ giữa bác sĩ khám bệnh và bệnh nhân.
2.3.4 Vấn đề đồng bộ hoá Video và Audio
Việc duy trì mối quan hệ về mặt thời gian giữa các dòng dữ liệu khác nhau trong truyền thông đa phương tiện thời gian thực là hết sức quan trọng. Ví dụ như trong ứng dụng hội thảo trực tuyến thì dòng dữ liệu hình ảnh và âm thanh của một thành viên phải có quan hệ chặt chẽ với nhau về mặt thời gian. Ngay cả đối với một file video khi chúng ta tiến hành truyền đi trên mạng, chúng ta sẽ tách các dòng dữ liệu âm thanh và hình ảnh ra và truyền theo các dòng khác nhau, khi tới bên nhận các dòng dữ liệu sẽ lại được tích hợp lại, các dòng dữ liệu này cũng phải có quan hệ chặt chẽ với nhau về mặt thời gian. Quá trình duy trì mối quan hệ đó được gọi là sự đồng bộ hoá. Tuỳ thuộc vào đặc trưng về độ tin cậy của mạng chuyển mạch gói (độ trễ, tỉ lệ mất gói…) mà độ phức tạp của kỹ thuật động bộ có khác nhau.
Như vậy, thực chất nhiệm vụ của đồng bộ trong truyền thông đa phương tiện thời gian thực đó là: xác lập quan hệ thời gian thực của các dòng dữ liệu đa phương tiện. Về phương diện cảm thụ: đồng bộ đa phương tiện là quá trình làm “trơn” các hiệu ứng trễ và điều khiển, phối hợp thời gian trình diễn đồng thời các dòng dữ liệu đa phương tiện để thoả mãn độ cảm thụ của con người.
Các mô hình đồng bộ sử dụng trong truyền thông đa phương tiện thời gian thực bao gồm:
Mô hình dòng thời gian (Timeline): Các hành động được xác định bởi thời điểm bắt đầu, dựa trên các đặc trưng thực hiện đồng bộ bám theo thời gian tồn tại của đối tượng.
Mô hình điểm tham chiếu (Reference point): Các điểm tham chiếu hay điểm đồng bộ được xác định bên trong thời gian tồn tại của đối tượng đa phương tiện, tại thời điểm đó, ta thực hiện đồng bộ hóa các dòng dữ liệu đa phương tiện để trình diễn.
Mô hình phân cấp (Hierarchic): đồng bộ theo mức phân cấp.
Mô hình dựa trên sự kiện (Event based): Trong hệ thống hướng sự kiện, điểm bắt đầu hay kết thúc của một đối tượng được xử lý như sự kiện xẩy ra.
Đối với mỗi mô hình đồng bộ chúng ta có thể áp dụng một trong các phương pháp đồng bộ sau[2]:
Phương pháp dồn kênh (Multiplexing): Các dòng dữ liệu đa phương tiện (audio, video) được đồng bộ tích hợp lại tại nguồn phát trước khi được truyền đi.
Phương pháp dùng kênh riêng chứa thông tin đồng bộ.
Phương pháp đồng bộ tại nơi nhận dựa trên các nhãn thời gian được gói vào dữ liệu trước khi truyền đi.
2.4 Nén/Giải nén Video
2.4.1 Các khái niệm cơ bản về nén video
Việc phát triển các chuẩn nén rất cần thiết cho tương lai của ngành đa phương tiện. Video có nhu cầu nén cao nhất. Nếu không được nén, thì mỗi khung video sẽ chiếm một chỗ lưu trữ lên đến 7.4 Mb. Vì vậy, khi hình video hiển thị toàn bộ màn hình khoảng 22 giây thì hình video chuyển động toàn phần (FSFM) có thể chiếm không gian lưu trữ trên đĩa quang 600 Mb. Nếu với tốc độ hiển thị 30frame/s, để phát lại video đó đòi hỏi phải có tốc độ truyền 222 Mb/giây, vượt quá tốc độ hiện nay là 1,5 Mb/s. Vì vậy nén là yếu tố quan trọng trong việc giải quyết vấn đề này, ngoài ra, nó còn đòi hỏi phải cần có tốc độ xử lý phát triển cao hơn để thực hiện thuật toán giải nén tinh vi.
Việc mã hóa video theo thời gian thực được thực hiện theo một loạt các bước sau[2]:
Đầu tiên bộ nén/giải nén tạo một khung gồm hàng ngàn pixel bằng cách lấy mẫu tín hiệu tương tự từ bộ ghi hình.
Bộ nén/giải nén sẽ chia khung thành nhiều khối với độ sáng là 16 x 16 pixel và mỗi cặp mầu là 8 x 8 pixel.
Sau đó nó sẽ phân tích các khối để xác định dữ liệu nào cần phải được gửi đi để tránh tình trạng gửi những dữ liệu chưa được chuyển đổi từ khung trước.
Nếu có thay đổi nào nghiêm trọng thì nó sẽ sử dụng mã hóa nội khung để gửi toàn bộ dữ liệu mới.
Nếu chỉ là những thay đổi nhỏ không đáng kể thì nó sẽ sử dụng mã hóa giữa khung để bổ sung vào những thông tin đã có sẵn.
Nếu không có thay đổi nào thì nó sẽ quét mầu lại cho khối đó.
Nếu như khối hoàn chỉnh được gửi đi gần vị trí ban đầu của nó trong khung trước, thì bộ nén/giải nén sẽ sử dụng phép bù động để di chuyển toàn bộ khối.
Sau đó, nó sử dụng thuật toán DCT(Discrete Cosin Transform: Biến đổi Cosin rời rạc) để tổ chức lại thông tin pixel trong phạm vi mỗi khối thành một dạng dày đặc hơn bằng cách tạo ra một loạt các hệ số toán học tượng trưng cho một số tổ hợp các giá trị pixel.
Nó sử dụng phép lượng tử hóa để co dãn và làm tròn các hệ số nhằm tạo ra những hệ số xấp xỉ nhất mà có thể được gửi đi với số lượng bit ít hơn.
Cuối cùng, nó sử dụng mã hóa hai chiều và mã hóa thời gian chạy để giảm bớt các chuỗi số không rất dài do phép lượng tử hóa sinh ra.
2.4.2 Một số chuẩn nén video
Do sự phát triển nhanh của truyền thống đa phương tiện, các máy camera số, máy ảnh số, các phương tiện giải trí số… vì vậy có rất nhiều chuẩn nén đã được đưa ra. Hiện nay trên thế giới có 2 tổ chức chính thức đưa ra các chuẩn video được áp dụng rộng rãi trên thế giới: MPEG(Motion Picture Expert Group) và ITU(International Telecommunication Union). MPEG đưa ra các chuẩn MPEG-x, còn ITU đưa ra các chuẩn H.26x. Sau đây mô tả một số các chuẩn đó:
MPEG-1
Chuẩn cho giai đoạn đầu (MPEG-1) xác định một dòng truyền bit cho video và âm thanh nén được tối ưu hóa để phù hợp với băng thông 1,5 Mb/giây – tốc độ truyền dữ liệu của các thiết bị như CD-ROM, băng âm thanh số (DAT), các đĩa WORM (ghi một lần đọc nhiều lần), đĩa MO (đĩa từ quang) và các kênh truyền thông như ISDN và LAN. Chuẩn này bao gồm 5 phần:
Phần hệ thống (11172-1) liên quan đến đồng bộ hóa và ghép bội thông tin nghe nhìn.
Phần video (11172-2) đề cập đến kỹ thuật nén video.
Phần audio (11172-3) đề cập đến kỹ thuật nén âm thanh.
Thử nghiệm tương hợp (11172-4) được thiết kế nhằm tạo nền tảng cho các phương pháp luận để thử nghiệm các dòng truyền bit và tạo nền tảng cho các bộ giải mã để tương hợp được các phần 1, 2 và 3.
Mã hóa phần mềm (11172-5) là phần đáp ứng cho khả năng xử lý ngày càng phát triển của máy tính giúp phần mềm có khả năng thực hiện được với 3 phần đầu của bộ chuẩn.
Thông số kỹ thuật cho phép ảnh đạt đến kích thước 4095 x 4095 với tần số độ phân giải 60 fps và tốc độ bit lên đến 100 Mb. Chất lượng hình ảnh Video đưa ra tốt, xấp xỉ với hình thức ghi video dưới dạng băng từ.
MPEG-2
Giai đoạn 2 (MPEG-2) hiện đang được phát triển. Chuẩn này bao gồm 3 phần và các định nghĩa của 3 phần này đã được hoàn tất năm 1993. Mỗi phần sẽ do một tiểu ban xử lý:
Phần hệ thống (13818-1) xác định dạng mã hóa cho âm thanh và video đa kênh gộp và cho các dữ liệu khác để thành một dạng phù hợp để truyền hoặc lưu trữ.
Phần video (13818-2) là một phần tốt của MPEG-1 xác định dòng bit mã hóa cho video số chất lượng cao.
Phần âm thanh (13818-3) xác định mã hòa âm thanh đa kênh tốc độ chậm.
Chuẩn các hệ thống MPEG-2 xác định 2 dạng dòng dữ liệu: dòng lưu thông và dòng chương trình. Dòng lưu thông có thể đồng thời mang được nhiều chương trình và dòng này được tối ưu hóa để sử dụng trong các ứng dụng nơi mà có thể xảy ra tình trạng mất dữ liệu. Dòng chương trình được tối ưu hóa cho các ứng dụng truyền thông đa phương tiện, cho việc xử lý các hệ thống hoạt động trong phần mềm, và cho khả năng tương thích được với MPEG-1. Cả hai dòng này được thiết kế với ý định hỗ trợ rất nhiều các ứng dụng. Dòng lưu thông được thiết kế để truyền tín hiệu truyền hình số và hệ thống điện thoại hình qua vệ tinh, cáp quang, ISDN, ATM,… đồng thời, dòng này cũng được thiết kế để lưu trữ được trên băng video số và trên các thiết bị khác.
MPEG-2 hỗ trợ độ các độ phân giải 720x480 và 1280x720 , tốc độ hiển thị 60 frame/s, âm thanh chất lượng tốt. Nó gần như tương thích với tất cả các chuẩn TV(NTSC, HDTV,…). MPEG-2 sử dụng trong lưu trữ dữ liệu video trên DVD-ROM, nó có thể nén 2 tiếng video với chỉ một vài Gigabytes. Tuy nhiên quá trình nén dữ liệu cần tài nguyên tính toán đủ mạnh, trong khi giải nén có thể chỉ cần khả năng xử lý không lớn lắm.
MPEG-4
Công việc nghiên cứu về chuẩn MPEG mới dùng để mã hóa các chương trình nghe nhìn với tốc độ bit rất thấp đã chính thức bắt đầu vào tháng 9/1993. Chuẩn này được biết đến với tên MPEG-4, chủ yếu về truyền hình độ rõ nét cao. MPEG-4 bao gồm các chức năng mã hóa các chương trình để truyền qua các kênh với tốc độ rất thấp (176 x 144 x 10 Hz với tốc độ bit lên tới 64 kb/giây) hay để lưu trữ được trong phạm vi dung lượng rút gọn. Thuật toán nén MPEG-4 dựa trên thuật toán nén dữ liệu trong các chuẩn MPEG-1, MPEG-2, và Apple Quicktime. Chuẩn được đưa ra vào tháng 10-1998, trong tài liệu ISO/IEC-14496.
H.261
H.261 là chuẩn nén/giải nén dữ liệu do tổ chức ITU đưa ra vào năm 1990 [9], thiết kế để nén và truyền dữ liệu video trên mạng ISDN với datarate là bội số 64kbps. Thuật toán nén dữ liệu được thiết kế cho phép đưa ra dữ liệu nén với tốc độ datarate từ 40kbps đến 2Mbps. Chuẩn hỗ trợ 2 chế độ phân giải CIF và QCIF.
H.263
H.263 là một chuẩn nén/giải nén dữ liệu Video do tổ chức ITU đưa ra đầu tiên vào năm 1995 [9]. Được phát triển từ chuẩn H.261, nó được thiết kế cho các ứng dụng video có tốc độ bitrate thấp, và với độ lớn dữ liệu nén đưa ra nhỏ(dưới 64kbps). Tuy nhiên giới hạn đó đang dần được thay thế với khả năng nén ngày càng được nâng cao, đồng thời cho phép hoạt động trên nhiều một miền lớn bitrate khác nhau.
H.263 là chuẩn được phát triển tiếp từ chuẩn H.261 đã được đưa ra trước đó, với những cải tiến mới làm tăng hiệu suất hoạt động và khả năng khắc phục lỗi.
H.263 hỗ trợ 5 chế độ phân giải: SQCIF, QCIF, CIF, 4CIF, 16CIF.
Format
NTSC-based
PAL-based
SQCIF
128 x 96
QCIF
176 x 120
176 x 144
CIF
352 x 240
352 x 288
4CIF
704 x 480
704 x 576
16CIF
1408 x 960
1408 x 1152
Bảng 1: Các chế độ phân giải
Với khả năng hỗ trợ cho độ phân giải 4CIF, 16CIF, H.263 đã có thể thích ứng với các ứng dụng có chỉ sổ bitrate cao.
Dưới đây là đồ thị thể hiện tương quan giữa độ nén(bit rate) và chất lượng hình ảnh(PSNR) khi áp dụng nén theo chuẩn H.263 [17] :
Hình 8: Biểu đồ thể hiện tương quan tỉ lệ nén và chất lượng hình ảnh
Hình trên thể hiện tương quan giữa bitrate và chất lượng hình ảnh của video được nén. Thí nghiệm thực hiện nén 3 đoạn Video khác nhau. Với mỗi đoạn video được quay với 2 tốc độ 10 frame/ s và 30 frame /s.
Chuẩn nén video sử dụng trong hệ thống xây dựng
Với yêu cầu có thể hoạt động trên mạng có băng thông không cao và truyền video theo phương thức trực tiếp(máy camera quay hình, sau đó nén hình và truyền ngay lập tức), vì vậy chuẩn nén video được sử dụng trong hệ thống nhóm xây dựng là chuẩn H.263
2.5 Nén/Giải nén Audio
2.5.1 Một số khái niệm về nén Audio
Các file âm thanh stereo chưa được nén yêu cầu khoảng 150KB của đĩa cứng cho mỗi giây. Kích cỡ của file phụ thuộc vào tốc độ lấy mẫu, số bit trong một mẫu, và âm thanh đó là mono hay stereo. Ví dụ: với tốc độ lấy mẫu 22kHz, 16-bit/1 mẫu, âm thanh mono, thì tốc độ dữ liệu sinh ra là 2.65MB/1 phút. Chính vì vậy mà việc nén file âm thanh sử dụng audio codec là phương pháp thích hợp để lưu trữ âm thanh trong đĩa cứng hoặc có thể sử dụng audio Streamming qua một mạng có băng thông giới hạn
Audio codec được sử dụng cho các mục đích khác nhau. Một số các codec sử dụng chỉ với mục đích là chỉ có thể nghe rõ để tiếp nhận thông tin được, yêu cầu quan trọng là độ nén cao(DSP Group TrueSpeech hoặc Microsoft Groupe Spécial Mobile [GSM] 6.10)-ví dụ như ứng dụng telephone(voice oriented audio codec). Một số khác thì sử dụng với yêu cầu đảm bảo chất lượng âm thanh trung thực(Fraunhofer Institut Integrierte Schaltungen IIS [FhG] MPEG Layer-3 hoặc Voxware MetaSound)-ví dụ như nghe nhạc(music oriented audio codec), tuy nhiên khi đó dữ liệu nén sẽ lớn và yêu cầu đường truyền mạng có băng thông lớn
2.5.2 Một số chuẩn nén audio
Một số chuẩn nén hiện đang được sử dụng [18] :
Audio Codec
Mô tả
Frequency/Sampling Rate
CCITT A-Law
CCITT A-Law codec tương thích với chuẩn Telephony Application Programming Interface(TAPI) dùng trong cộng đồng châu Âu. Có tên khác là G.711, codec này được hỗ trợ bởi nhiều các thiết bị phần cứng, và có tỉ lệ nén là 2:1
8.000 kHz, 8-bit, Stereo, 15 kbps11.025 kHz, 8-bit, Stereo, 21 kbps22.050 kHz, 8-bit, Mono, 21 kbps22.050 kHz, 8-bit, Stereo, 43 kbps44.100 kHz, 8-bit, Mono, 43 kbps
CCITT u-Law
Tương tự như CCITT A-Law codec, nhưng tương thích với chuẩn TAPI sử dụng ở Mỹ
Tương tự như CCITT A-Law codec.
DSP Group TrueSpeech
Nén tốt cho những âm thanh không yêu cầu chất lượng cao, và được thiết kế cho chỉ số bitrate thấp đến trung bình. Có datarate thấp hơn GSM 6.10. Nó không có tốc độ nén đáp ứng thời gian thực tuy nhiên có tốc độ giải nén đáp ứng thời gian thực.
8.000 kHz, 1-bit, Mono, 1 kbps
GSM 6.10
Có hiệu quả nén tốt và tốt nhất với bitrate từ trung bình đến cao. Tỉ lệ nén là 2:1, nén thời gian thực. GSM tương thích với chuẩn European Telecommunications Standards Institute recommendation 6.10
8.000 kHz, Mono, 1 kbps11.025 kHz, Mono, 2 kbps22.050 kHz, Mono, 4 kbps44.100 kHz, Mono, 8 kbps
Microsoft ADPCM
Có tỉ lệ nén cao 4:1và đảm bảo yêu cầu thời gian thực. Thích hợp cho stream audio kết hợp với video có bit rate cao.
8.000 kHz, 4-bit, Mono, 4 kbps8.000 kHz, 4-bit, Stereo, 8 kbps11.025 kHz, 4-bit, Stereo, 11 kbps
Microsoft G.723.1
Dùng để tạo ra các file ASF, sử dụng để stream audio thông qua mạng Internet. Thích hợp với mạng có băng thông thấp 14.4 đến 28.8 kbps.
8.000 kHz, Mono, 6400 bit/s 0 kbps8.000 kHz, Mono, 5333 bit/s 0 kbps
MPEG Layer-3
Sử dụng với những file âm nhạc có chất lượng tốt và có bit rate trong khoảng từ thấp đến trung bình. Sử dụng trên mạng Intranet hoặc mạng Internet. Có khả năng nén cao cho rất nhiều loại file âm thanh vì vậy có bit rate thấp và cần ít tài nguyên CPU.
8 kbps, 8.000 kHz, Mono, 0 kbps16 kbps, 8.000 kHz, Mono, 1 kbps8 kbps, 11.025 kHz, Mono, 0 kbps16 kbps, 11.025 kHz, Mono, 1 kbps18 kbps, 11.025 kHz, Mono, 2 kbps20 kbps, 11.025 kHz, Mono, 2 kbps
PCM
Tạo ra các dữ liệu âm thanh chưa được nén với bit rate cao.
8.000 kHz, 8-bit, Stereo, 15 kbps11.025 kHz, 8-bit, Mono, 10 kbps44.100 kHz, 8-bit, Mono, 43 kbps48.000 kHz, 8-bit, Mono, 46 kbps
Bảng 2: Các codec đang được sử dụng
Chuẩn nén được nhóm sử dung:
Sau khi tìm hiểu về hạ tầng cơ sở mạng về đường truyền, băng thông, tốc độ truyền thống. Trên cơ sở yêu cầu của hệ thống là cần chất lượng âm thanh không cao, và sử dụng băng thông ít, vì vậy hệ thống xây dựng sử dụng chuẩn GSM 6.10
2.6. Một số khái niệm về tin học y sinh
2.6.1. Chuẩn đoán bệnh từ xa
Telemedicine là một từ ghép bắt nguồn từ “tele” trong tiếng Hy Lạp có nghĩa là “từ xa” và “medicine” trong tiếng Latin là “mederi” nghĩa là “điều trị”. Năm 1970, lần đầu tiên khái niệm Telemedicine được dùng nhằm mô tả cung cấp dịch vụ chăm sóc sức khỏe cho các bệnh nhân từ xa thông qua việc sử dụng công nghệ thông tin. Dịch vụ chăm sóc sức khỏe ở đây có thể bao gồm cả chẩn đoán và điều trị, cung cấp thuốc men, tư vấn, dự phòng và phục hồi, bảo hiểm y tế, giảng dạy, nghiên cứu...
Ví dụ, một bác sĩ đang ngồi trong phòng làm việc của mình khám cho một bệnh nhân cách đó hàng ngàn cây số. Chỉ cần nháy chuột là bác sĩ đã có trong tay đầy đủ thông tin về bệnh sử, thông tin kết quả thăm khám như: xét nghiệm (xét nghiệm huyết học, sinh hóa, vi sinh, tế bào...), thông tin về chẩn đoán chức năng (điện tim, điện não, hô hấp...), thông tin về hình ảnh (Xquang, siêu âm,...). Đó chính là một ứng dụng của telemedicine.
2.6.2. Các loại dữ liệu trong tin học y sinh
2.6.2.1. Điện tâm đồ
Điện tâm đồ là đồ thị ghi những thay đổi của dòng điện trong tim. Quả tim co bóp theo nhịp do điều khiển của một hệ thống dẫn điện nằm trong cơ tim. Những dòng điện tuy rất nhỏ, khoảng 1 phần nghìn volt, nhưng có thể dò thấy được từ các cực điện đặt trên tay, chân và ngực bệnh nhân và chuyển đến máy ghi. Máy ghi điện khuếch đại lên và ghi lại trên điện tâm đồ. Điện tâm đồ được xử dụng trong y học để xét nghiệm bệnh về tim như rối loạn nhịp tim, đau tim, nhồi máu cơ tim v.v...
2.6.2.2 Điện não đồ
Điện não đồ EEG (Electroencephalography) là phương pháp đo dòng điện chạy qua các điện cực đặt trên da đầu, đôi khi đặt trục tiếp trên vỏ não. Từ các biến đổi của dòng điện ghi được, có thể suy đoán nhiều hoạt động, tình trạng của não. Với các thông số đó sẽ giúp cho các bác sĩ trong quá trình chuẩn đoán bệnh.
Về cơ chế đo Điện Tâm Đồ và cách thu và xử lý dữ liêu từ máy Điện Tâm Đồ cũng như cơ chế, cách thu và xử lý với dữ liệu Điện Não Đồ đã được trình bầy kĩ trong Khoá Luận Tốt Nghiệp của Vũ Văn Tiệp, làm cùng trong đề tài nghiên cứu.
Chương 3. Thiết kế hệ thống chuẩn đoán bệnh từ xa
3.1. Tìm hiểu về yêu cầu của hệ thống
Thông qua việc tìm hiểu một số yêu cầu của bác sĩ, cũng như phía bệnh nhân trong quá trình khám, chữa bệnh của mình, đồng thời tìm hiểu các hệ thống đã được xây dựng và phát triển ta thấy có những yêu cầu cần phải phát triển cho hệ thống hỗ trợ chuẩn đoán bệnh từ xa bao gồm các chức năng chính sau đây:
Phía bác sĩ mong muốn cho thể nhìn thấy bệnh nhân một cách trực quan nhất trong quá trình khám bệnh của mình. Trong quá trình khám bệnh bác sĩ mong muốn có được hình ảnh của bệnh nhân một cách nhanh và chính xác nhất. Nhất là việc khám và chữa bệnh trực tiếp đòi hỏi hình ảnh có thể phóng to, hay thu nhỏ tùy theo thời điểm, đồng thời cũng có thể thay đổi góc nhìn của hình ảnh sao cho thuận lợi nhất để có thể quan sát kỹ hơn mà không phải làm ph
Các file đính kèm theo tài liệu này:
- Công cụ hỗ trợ chuẩn đáo bệnh từ xa.doc