Đồ án Nghiên cứu và phát triển hệ thống tạo luồng thời gian thực và giao thức thích ứng cho truyền thông đa phương tiện trong mạng Ad hoc

Lời Nói Đầu Trong những năm gần đây, cùng với sự phát triển mạnh mẽ của khoa học máy tính, đặc biệt là lĩnh vực máy tính nhúng, loài người người đã có những thay đổi to lớn về cách thức cũng như phương tiện giao tiếp. Với những tiến bộ trong truyền thông vô tuyến, kết hợp với sự bùng nổ của các phương tiện nhúng như điện thoại di động, PDA, và máy tính xách tay, thì một lĩnh vực công nghệ đầy tiềm năng đang dần được khai phá đó là “tính toán khắp nơi”(ubiquitous computing). Mạng Ad hoc ra đời như một tất yếu của quá trình phát triển này. Sau một thời gian làm việc rất cố gắng trên phòng Lab 411 Khoa Điện Tử - Viễn Thông dưới sự hướng dẫn tận tình của thầy giáo TS.Phạm Văn Tiến, cùng với sự hợp tác chặt chẽ của các thành viên trong phòng Lab, nhóm chúng em đã hoàn thành đồ án với đề tài “Nghiên cứu và phát triển hệ thống tạo luồng thời gian thực và giao thức thích ứng cho truyền thông đa phương tiện trong mạng ad hoc” Với những nỗ lực thực sự, đồ án của chúng em đã có được một số kết quả nhất định, mặc dù vậy do thời gian có hạn chúng em không thể tránh khỏi một số thiếu sót cũng như một số nhiệm vụ chưa hoàn thành được. Vì vậy, nhóm chúng em rất mong những ý kiến đóng góp của các thầy cô giáo và bạn bè. Tóm Tắt Đồ Án “Nghiên cứu và phát triển hệ thống tạo luồng thời gian thực và giao thức thích ứng cho truyền thông đa phương tiện trong mạng Ad hoc” Trong khi các mô hình mạng truyền thống sử dụng hạ tầng mạng cố định điều khiển trung tâm vẫn đang thống trị trong lĩnh vực truyền thông thì mạng ad hoc xuất hiện như một giải pháp đầy tiềm năng, với những đặc tính ưu việt về độ linh hoạt, chi phí vận hành, và khả năng thiết lập nhanh chóng. Thực tế, mạng ad hoc không phải quá mới, nhưng việc khai thác nguồn tài nguyên hạn chế của mạng ad-hoc sao cho hiệu quả lại là một thách thức rất lớn đối với giới truyền thông trên thế giới. Nhận thấy được tiềm năng này, nhóm chúng em, dưới sự hướng dẫn của TS. Phạn Văn Tiến đã nghiên cứu đề tài về truyền thông đa phương tiện thích ứng trên mạng ad hoc. Đồ án của chúng em trình bày về các vấn đề liên quan của đề tài nghiên cứu như cấu trúc mạng ad hoc, các giao thức thời gian thực( RTP/RTCP), chuẩn mã hóa H264 cho RTP, giao thức liên tầng thích ứng cross-layer design, phát triển giao diện người dùng. Từ đó xây dựng thành công hệ thống tạo luồng thời gian thực với giao thức truyền thích ứng cho mạng ad hoc. Cụ thể nội dung đồ án bao gồm 5 chương : Chương 1 Tổng quan hệ thống Trình bày tổng quan về mạng ad hoc và hệ thống được xây dựng trong đề tài. Chương 2 Giao thức thời gian thực và chuẩn mã hoá H.264 Trình bày về các giao thức thời gian thực và chuẩn nén H.264 được sử dụng cho hệ thống. Chương 3 Mô hình Cross-layer Trình bày mô hình Cross-layer design được thiết kế và xây dựng cho truyền thông đa phương tiện trên mạng adhoc Chương 4 Giao diện người dùng (GUI) Trình bày vấn đề thiết kế và thực thi giao diện người dùng được sử dụng cho truyền thông đa phương tiện trong mạng ad hoc. Chương 5 Kết quả thu được và hướng nghiên cứu tiếp theo Trình bày kết quả thực thi của nhóm nghiên cứu và đề ra hướng nghiên cứu cho các vấn đề liên quan trong đồ án.

doc132 trang | Chia sẻ: lvcdongnoi | Lượt xem: 2372 | Lượt tải: 3download
Bạn đang xem trước 20 trang tài liệu Đồ án Nghiên cứu và phát triển hệ thống tạo luồng thời gian thực và giao thức thích ứng cho truyền thông đa phương tiện trong mạng Ad hoc, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
tỉ lệ mất gói tại tầng trasport ( lossrate ) , sẽ cho ta một bức tranh trung thực về chất lượng đường truyền hiện thời và từ đó sẽ có những điều tốc độ mã hoá của bộ Encoder một cách hợp lí, sao cho thích ứng với chất lượng hiện tại của môt trường truyền dẫn. Bên cạnh việc điều khiển tốc độ của bộ mã hóa , việc truyền lại gói cũng vô cùng cần thiết để đảm bảo tỉ lệ truyền gói là thành công, đặc biệt là gói NAL chứa dữ liệu của ảnh I, SPS, PPS. Để đảm bảo việc truyền lại không tiêu tốn nhiều tài nguyên của hệ thống , tầng transport cần phải biết được giá trị etx , thông qua etx ,chúng ta sẽ biết được sô gói cần truyền lại để đảm bảo truyền gói thành công Cơ chế giao tiếp Khi olsrd cập nhập thông số mới về chất lượng đường truyền,tầng routing sẽ gửi một thông báo lến tầng transport, đề thông báo cho tầng transport biết chất lượng của đường truyền đã thay đổi. Khi tầng transport cập nhập thông số được đưa lên từ tầng routing, thông số này được dùng để điều chỉnh tôc độ của bộ mã hóa, và xác định số gói cần truyền lại để đảm bảo tỷ lệ truyền gói là cao nhất Mô hình giao tiếp liên tầng Hình 3. 6: Mô hình giao tiêp liên tầng Giao tiếp liên tầng giữa vlc và olsrd sử dụng cơ chế giao tiếp giữa các tiến trình sử dụng vùng nhớ ngoài ,Nội dung của vùng nhớ ngoài như sau Olsrd_pid, chỉ số tiến trình của olsrd Vlc_pid , chỉ số tiến trình của olsrd Etx_value, giá trị được chuyển từ tầng routing (olsrd) lến tầng trasport Cơ chế giao tiếp được thực hiện tuần tự qua các bước sau Olsrd update giá trị trị etx_value lên vùng nhớ chung Olsrd gửi tín hiệu thông báo lên tầng transport (vlc ), thông qua tín hiệu Vlc khi nhận được tín hiệu thông báo, sẽ truy cập vùng nhớ chung và lấy về giá trị etx_value Thiết kế hệ thống Trong vlc xây dựng một tuyến ( thread ) giao tiếp với olsrd, thông qua vùng nhớ chung, tuyên này chỉ thức dậy khi được đánh thức bởi một tín hiệu đồng bộ tuyên từ hàm signal_catch(), hàm signal_catch(), là hàm được xây dựng để bắt tín hiệu thông báo của olsrd. Giao tiếp liên tầng Transport - Application điều khiển tốc độ mã hóa Mục tiêu của thiết kế là điều khiển tốc độ mã hóa theo chất lượng đường truyền, Khi chất lượng kênh truyền tốt tương ứng với tỉ lệ truyền gói thành công cao, ta tăng tốc độ luồng bit đầu ra của bộ mã hóa. Khi chất lượng kênh truyền tồi, tương ứng với tỉ lệ mất gói cao, ta cần giảm tôc độ đầu ra của bộ mã hóa, Tốc độ của luồng bit đầu ra của bộ mã hóa được điều chỉnh thông qua tham số QP hoặc CRF. Do vậy giá trị QP (hoặc CRF ) mới sẽ được update thường xuyên theo điều kiện môi trường truyền dẫn, do vậy quá trình truyền video sẽ thích ứng với môi trường truyền dẫn, do vậy cải thiện được chất lượng video bên thu. Mô hình thiết kế Hình 3. 7: Mô hình thiết kế Quá trình điều khiển tốc độ Cập nhập thông số lossrate, và etx Tính toán giá trị QP mới , 2 tham số đầu vào của hàm calQPCRF() Update gia trị QP mới cho bộ Encoder Yêu cầu hệ thống Đảm bảo đồng bộ giữa các tiến trình Quá trình tính toán không diến ra quá lâu Thiết kế truyền bản tin instance message Phân tích yêu cầu Quá trình truyền video và audio sẽ trở nên vô cung khó khăn khi môi trường truyền dẫn xảy ra những đột biến không thể lường trước, do vậy để đảm bảo thông tin liên lạc giữa các hope với nhau, thì giải pháp truyền text là một giải pháp hợp lý.Nội dung text bao giờ cũng có dung lượng nhỏ, và có thể truyền tải tốt trong môi trường có tài nguyên hạn hẹp. quá trình trao đổi thông tin được diễn ra trên giao diện GUI, thân thiện với người sử dụng Yêu cầu đối với giao diện GUI cửa sổ hiện thị video Cửa sổ hiện thị text Cửa sổ nhập dữ liệu text từ bàn phím Listbox chứa các địa chỉ IP Các nút bấm điều khiển truyền text Hình 3. 8: Yêu cầu với giao diện GUI Mô hình hệ thống Hình 3. 9: Mô hình hệ thống Hình 3. 10: Mô hình truyền text Hoạt động của giao diện GUI Dữ liệu text được lấy từ bàn phím,sau đó được lưu trong một mảng ký tự .Dữ liệu text sau đó được truyền đi sang node Receiver khi Button Send được bấm. bên Receiver hiển thị nội dung text lên cửa sổ hiển thị giao diện khi nhận được nội dung text. Và giao diện bên Sender cũng có chức năng tương tự List box chứa danh sách địa chỉ IP của các node mạng, danh sách này sẽ được update thường xuyên, thông qua danh sách này người sử dụng sẽ biết được node nào đang kết nối trong mạng và node nào đã rời khỏi mạng Nút bấm điều khiển âm lượng của audio Thiết kế và thực hiện Vì qua trình truyền và nhận độc lập với nhau, do vậy tại Sender và Receiver cần tạo 2 tuyến, một tuyến đảm nhận chức năng lấy dữ liệu từ bàn phím hiển thị nên giao diện GUI và truyền đi.Một tuyến khác nhận dữ liệu được gửi trên mạng và hiển thị lên giao diện GUI. Ta thực hiện thiết kế này như sau: Tuyến thực hiện giao diện và hiển thị text nhận được từ giao diện GUI void * doChat(void *data) { char msgR[50]; int len, res = 0; struct sockaddr_in address; int result; int client_fd; ///tao Socket sockfd = socket(PF_INET, SOCK_STREAM, 0); ///dat ten va gan dia chi ket noi cho socket client_fd = sockfd; address.sin_family = AF_INET; address.sin_port = htons(9995); printf("dia chi cua server:%s\n", psz_Server); address.sin_addr.s_addr = inet_addr(psz_Server); memset(&(address.sin_zero), '\0', 8); //zero rest of struct len = sizeof(struct sockaddr); thực hiện kết nối result = connect(sockfd,(struct sockaddr *)&address, len); nếu kết nối không thành công, thực hiện thông báo lỗi và thoát khỏi chương trình if(result == -1){ perror(" ket noi khong thanh cong, ChatText \n"); exit(1); } Quá trinh nhận gói tin được diễn ra liên tục trong vòng lặp while while(1){ nhận gói tin res = recv(sockfd, &msgR, sizeof(msgR), 0); kiểm tra nhận có thành công không if(res < 0) { perror("recv error"); } else{ Nếu thành công, hiển thị bản tin instance message lên màn hinh giao diện XDrawString(display, win_display, gc_display, xd_offset, yd_offset, msgR, strlen(msgR)); yd_offset += 10; } } } Tuyến thư 2, thực hiện lấy dữ liệu từ bàn phím, hiển thị lên giao diện text, và gửi dữ liệu ra ngoài mạng void * chatInterface(void) { Quá trình diễn ra liên tục trong vòng lặp while while (1) { kiểm tra sự kiện trên giao diện: XNextEvent(display, &report); Kiểm tra loại sự kiện switch (report.type) { case Expose: if(report.xexpose.window = winButton) { Vẽ các thành phần của giao diện , khi Giao diện được hiển thị XDrawString(display, winButton, gcBt, 5, 20, pz_WinBtName, len); } if (report.xexpose.count != 0) break; if (window_size == TOO_SMALL) TooSmall(win, gc, font_info); else { } break; khi sự kiện là nút bấm Send được gửi, dữ liệu text được gửi đi case ButtonPress: kiểm tra đúng là nút Send được bấm if(report.xbutton.window == winButton) { Hiển thị lên màn hình giao diện XDrawString(display, winDis, gcChild, xd_offset, yd_offset, msa,strlen(msa)); Gửi dữ liệu ra ngoài mạng int i_byteSent = send(revfd, &msa, sizeof(msa), 0); } Trường hợp khi bàn phím được gõ case KeyPress: Đọc dữ liệu vào bộ đệm XLookupString(&report, buffer, i_bufsize, &keysym, NULL); Nếu ký tự nằm thuộc loại hiển thị được, thêm ký tự vào thông điệp cần hiển thị if((keysym >= XK_space )&&(keysym <= XK_ydiaeresis )) { strcat(msa, buffer); } } Chương 4: Thiết Kế Giao Diện Một chương trình muốn áp dụng vào thực tế, nó không chỉ có tính khoa học và nó phải hướng tới người dùng, tức là có giao diện thân thiện với người dùng, có những hướng dẫn sử dụng đơn giản. Do vậy, với phần mềm truyền đa phương tiện qua mạng ad-hoc, dù ứng dụng trên cả cho board hệ nhúng, cần có giao diện sử dụng cho người dùng cũng như thực hiện chức năng truyền thông đa phương tiện. Yêu cầu đối với giao diện Mục đích của sản phẩm phần mềm là cung cấp chức năng truyền thông đa phương tiện: Video, Audio và Text. Do vậy, chương trình phải có giao diện gồm có các thành phần: Cửa sổ hiện thị Video. Cửa sổ hiện thị Text. Cửa sổ gõ Text. Cửa sổ hiện thị dòng Text nhận được. Nút để thực hiện chức năng gửi Text( Hoặc nhấn Enter). Cửa sổ chứa danh sách các thành viên trên mạng. Các Nút thực hiện các chức năng điểu khiển Video, Audio .... Hướng tới chương trình sẽ có giao diện: Hình 4. 1: Yêu cầu giao diện Hướng tiếp cận Thiết kế cửa sổ giao diện như trên chúng ta có 2 hướng tiếp cận: Tạo một giao diện mới tách biệt với nền tảng sẵn có và tích hợp khung Video vào giao diện. Thiết kế giao diện theo cấu trúc nền sẵn có( tức dùng các chức năng sẵn có của chương trình). Ta thấy rằng với phương pháp tạo mới giao diện sẽ dễ dàng cho việc thực hiện thiết kế giao diện. Ta có thể sẽ dễ tìm kiếm các công cụ phục vụ cho thiết kế giao diện như Qt Designer. Giao diện dễ thiết kế và lại đẹp, dễ dàng cho việc xử lí các sự kiện như nhấn nút, gõ text, font chữ, hiện thị…Nhưng nếu đi theo hướng thứ nhất chúng ta sẽ gặp những bất lợi vô cùng to lớn. Đó là việc tích hợp luồng Video lên giao diện được tạo, sẽ rất khó cho việc xử lí đó. Khó khăn khác chúng ta phải đối diện với đó là nếu dùng chương trình thiết kế mang tính chất kéo thả - dễ thực hiện. Nhưng số lượng thư viện yêu cầu lại lớn, yêu cầu tài nguyên lớn cho việc sử dụng chương trình. Đó là điểm vô cùng bất lợi cho việc thiết kế chương trình dùng cho các thiết bị nhúng, vốn đã rất hạn hẹp về tài nguyên như bộ nhớ, Ram, tốc độ xử lí… Nếu chúng ta tiếp cận theo hướng thứ 2, thiết kế giao diện theo cấu trúc nền sẵn có. Khó khăn gặp phải đầu tiên đó là phải tìm hiểu cấu trúc, chức năng thư viện mà chương trình đã dùng để tạo cửa sổ video cũng như giao diện ban đầu. Có nghĩa là chúng ta phải tìm hiểu code của chương trình, thêm các chức năng theo ý muốn của mình dựa vào các thư viện sẵn có của chương trình. Một điểm yếu nữa là dùng những chức năng nền của chương trình thì giao diện tạo ra sẽ không đẹp bằng làm theo cách thứ nhất. Nhưng một ưu điểm lớn nhất mà làm khiến chúng ta nên đi theo hướng này đó là không phải lo tích hợp luồng video vào giao diện, chương trình nhẹ dễ dàng chạy trên các board mạch nhúng mà không cầm phải thêm nhiều thư viện. Vì mục đích hướng đến là chạy hiệu quả trên các board mạch nhúng nên việc tạo ra chương trình ít sử dụng các thư viện ngoài, yêu cầu sử dụng ít tài nguyên là một yêu cầu rất quan trọng. Thêm vào đó việc chạy chương trình trên board mạch nhúng, có khả năng di động cao nên màn hình hiển thị cũng sẽ đơn giản, nhỏ gọn. Do đó mà việc thiết kế giao diện không yêu cầu phải quá cầu kỳ, nó chỉ cần đáp ứng đầy đủ yêu cầu về chức năng soạn thảo cũng như truyền text và hiện thị một cách rõ ràng có khả năng đọc được là đáp ứng được yêu cầu. Do vậy việc tiếp cận theo hướng thứ 2 trong trường hợp này sẽ thích hợp nhất. Giới thiệu về cơ chế hoạt động của XWindow() X là một hệ thống để thực thi giao diện người ( các cửa sổ window) dựa vào việc hiển thị bằng các bitmap. Nó cũng là một đặc tính cho một giao thức giao tiếp mức cao được sử dụng giữa hai chương trình. Một chương trình được gọi là “ Server” và chương trình còn lại là “ Client”. Server thực sự vẽ lên màn hình và nhận các tín hiệu đầu vào từ bàn phím và chuột. Còn Client là nơi mà các chương trình tiện ích thực thi. Những chương trình này có thể ở trên một máy khác, hoặc chúng có thể trên cùng máy tính với server. Một điều quan trọng cần chú ý là việc xác định “Server” và “ Client” ở đây khác với khái niệm server/client thông thường. Nó thường gây nhầm lẫn cho những người mới bắt đầu tiếp xúc với X. Ví dụ, bạn có một máy trạm Sun và bạn đang chạy chương trình mô phỏng/hay CAD trên một máy tính khác ở đâu đó và hiển thị trên màn hình của máy Sun. Khi đó máy Sun sẽ là Server( nó giao tiếp với bàn phím, chuột và đồ họa phần cứng). Chương trình CAD trên máy tính kia sẽ là Client. Client yêu cầu việc thực thi đồ họa và Server cung cấp các dịch vụ này. Đặc tính của giao thức X định nghĩa sự tương tác giữa các chương trình. Giao thức X thường xuyên được thực thi như là lớp trên lớp TCP/IP. Những đặc tính của X không đặc tả giao diện người dùng trông như thế nào, trình quản lý window sẽ làm gì, hoặc ứng dụng sẽ hoạt động ra sao? X đơn giản chỉ là một phương thức mức thấp nhằm tạo ra những cửa sổ window, nhận đầu vào người dùng( những hiện tượng nhấn phím và chuột), hiện thị chuỗi, vẽ đường thẳng, đường cong và bitmap. Giao thức X Server cung cấp một tập hợp các dịch vụ mức thấp rất rõ ràng được sử dụng bởi Client để thực thi bất kỳ công việc gì từ giao diện người dùng. Những dịch vụ cơ bản như sau: Xử lý đầu vào Server nhận tín hiệu đầu vào từ bàn phím và chuột. Những tín hiệu này được coi như là những sự kiện từ chương trình client thích hợp. Phương thức được sử dụng để xác định window nào sẽ nhận tín hiệu đầu vào phụ thuộc vào trình quản lý window( Nó thực sự là một client khác). Những hiện tượng điển hình là nhấn phím, sự di chuyển của chuột và sự nhấn hoặc nhả chuột. Những dịch vụ cửa sổ window phân cấp Những dịch vụ này cho phép client yêu cầu server tạo ra hay hủy một window( một hình chữ nhật trên màn hình). Window cũng có thể được đặt trong một cửa sổ window khác. Rất nhiều chức năng có thể được thực thi trên những cửa sổ window này( thiết lập hoặc truy vấn kích cỡ và vị trí). Những thực thi về đồ họa Client có thể yêu cầu server vẽ đường thẳng, hình chữ nhật, hình tròn, dấu chấm hoặc hình đa giác. Màu sắc, độ dày và kiểu được đặc tả bởi client. X11 cũng hỗ trợ rất nhiều chức năng về bitmap được thực thi trên window. Những chức năng về text và font Client có thể yêu cầu chuỗi text được vẽ vào cửa sổ window tại một vị trí nhất định sử dụng đặc tính font. Trước khi làm được điều này, client phải nói cho server để load font để sử dụng. Client có thể yêu cầu thông tin về những loại font sẵn có cũng như kích cỡ và các thông số của việc tải font chữ. Giao thức X không biết gì về radio buttons, scroll bars, sliders, text entry fields hoặc menu bars. Những thứ đó tất cả được thực thi trên client. Giao diện Client/Server Giao thức X định nghĩa những thông tin chuyển qua, chuyển lại giữa client và server. Thông tin truyền giữa client và server được đóng và các gói ở mức độ giao thức X( khác với với những gói Ethernet hoặc TCP/IP). Có 4 thể loại của gói: Request Một gói request( yêu cầu) được gửi bởi client tới server để yêu cầu server thực thi một vài hành động hoặc trả về thông tin. Event Một gói Event( sự kiện) được gửi bởi server tới client để thông báo với server về đầu vào người dùng hoặc một vài thông tin về những thứ đang xảy ra.( ví dụ như một cửa sổ window thay đổi kích thước). Error Một gói Error( lỗi) được gửi bởi server tới client để thông báo với nó rằng một yêu cầu không hợp lệ. Vì những yêu cầu được xếp trong hàng đợi, một lỗi có thể không được phát hiện đến khi sau nhiều yêu cầu được chứa bởi client. Chương trình Window cơ bản Theo lý thuyết thì có khả năng viết một chương trình client sử dụng những hàm chuẩn của thư viện C. Client này phải mở một kết nối socket tới server, tạo yêu cầu và viết chúng tới socket và biên dịch những gói phản hồi, sự kiện, và gói thông báo lỗi. Mặc dù có thể, nhưng những cái này không cần thiết vì những thư viện sắn có chứa những hàm giao tiếp với X server sử dụng giao thức X. Thư viện phổ biến nhất là “ Xlib” và được gọi từ ngôn ngữ lập trình C. Mọi chương trình Xlib có cùng một cấu trúc chung: Kết nối tới một X server với XOpenDisplay() Tạo ra một window với XCreateSimpleWindow() Thiết lập những thuộc tính chuẩn cho trình quản lý cửa sổ Lựa chọn loại sự kiện nó cần nhận Load font Tạo ra Graphics context để điều khiển việc vẽ Hiển thị cửa sổ với XMapWindow() Lặp để xử lí sự kiện Để thực hiện các hàm trên phải khai báo các file thư viện , , . Trong đó file chứa những khai báo về loại cấu trúc được sử dụng trong các hàm Xlib. File thiết lập nhiều hằng được định nghĩa. File chứa nhiều sự định nghĩa cấu trúc và những hằng định nghĩa cho những nhóm chức năng của Xlib. Cuối cùng là file có gắng làm cho chương trình có tính di động bằng việc gộp những file phụ thuộc vào hệ điều hành cho chương trình biên dịch. Window : Một số định dạng( ID) được trả về bởi XCreateWindow() hoặc XCreateWindow() và sau đó được sử dụng như là tham chiếu đến cửa sổ được tạo ra. Display: Một cấu trúc chứa đựng thông tin về server và màn hình hiện thị của nó. Cấu trúc này sẽ được điền đầy sau khi chương trình gọi hàm XOpenDisplay(). Pixmap: Một số tư nhiên được sử dụng để cung cấp cho trình quản lý window thông tin về kích cỡ của cửa sổ. XEvent: Chứa thông tin về một sự kiện. Nó có thể được biên dịch như là một trong nhiều cấu trúc riêng biệt phụ thuộc vào loại của sự kiện. Kết nối tới X Server Client muốn server thực hiện bất kỳ một yêu cầu gì thì trước hết chúng phải kết nối đến server. Để kết nối đến server chúng ta sửa dụng hàm XOpenDisplay() - kết nối một chương trình Xlib tới server. char *display_name = NULL; Display *display; int screen_num; Screen *screen_ptr;    . progname = argv[0]; /* Kết nối tới X server */ if ( (display=XOpenDisplay(display_name)) == NULL ) {    (void) fprintf( stderr, "%s: cannot connect to X server %s\n",                progname, XDisplayName(display_name));    exit( -1 ); } screen_num = DefaultScreen(display); screen_ptr = DefaultScreenOfDisplay(display); Thông số display_name của XOpenDisplay() đặc tả server. Cái này có thể là bất kỳ server nào trên mạng và cũng có thể đặc tả trong câu lệnh. Khi display_name không được đặc tả bởi dùng dùng, nó sẽ được thiết lập tới NULL, khi đó XOpenDisplay() sẽ kết nối đến server được đặc tả trong biến môi trường DISPLAY. Cả biến môi truờng DISPLAY và thông số display_name của XOpenDisplay() có cùng kiểu định dạng. Định dạng đó là host:server:screen, trong đó host ám chỉ tới tên của máy đang chạy server, server, số hiệu của server trên máy; và screen, số hiệu màn hình trên server. Số hiệu server được nghĩ như là số của người dùng trên một host riêng. Số hiệu server thường là 0 trên máy trạm đơn người dùng và cũng có thể khác 0 khi host có bàn phím, màn hình riêng. Hàm XOpenDisplay() trả về một con trỏ tới cấu trúc của loại Display. Nếu kết nối thành công, cấu trúc này sẽ bị điền đầy với những thông tin về server và màn hình của nó. Nếu không kết nối được, XOpenDisplay sẽ trả về NULL. Trong chương trình trên hàm DefaultScreen() trả về số hiệu nhận dạng trên server. Hầu hết các client muốn biết về kích cỡ của màn hình để thiết kế việc hiện thị đầu ra. Việc lấy các thông tin về màn hình server có 2 cách : Truy cập vào thông tin thành phần của cấu trúc Display để có thông tin về cửa sổ root window. Sử dụng các hàm XGetGeometry() hoặc XGetWindowAttributes() để có chiều dài và rộng của cửa sổ root window. Cách thứ nhất chỉ có được thông tin về về root window nhưng hiệu quả hơn. Cách thứ 2 có thể lấy được thông tin của bất kỳ cửa sổ nào. Với cách thứ 1, để có thông tin về các chiều của màn hình, bạn có thể sử dụng các macro DisplayWidth() và DisplayHeight(), trả về thông tin tính theo đơn vị pixel. Nếu muốn biết thông tin dưới dạng millimeter bạn sử dụng macro DisplayWidthMM() và DisplayHeightMM(). Với cách thứ 2, để có được thông tin hình học của cửa sổ sử dụng XGetGeometry() hoặc để có tất cả những đặc tính của cửa sổ sử dụng XGetWindowAttributes(). Hàm XGetWindowAttributes() trả về nhiều thông tin việc gọi hàm XGetgeometry(). Những phương thức này có sự bất tiện là chúng lấy thông tin từ server, nên có thời gian trễ phụ thuộc vào mạng. Code cho việc lấy thông tin về màn hình – sử dụng macro Display *display; int screen_num; unsigned int display_width, display_height;    . screen_num = DefaultScreen(display);    . /* Kích thước hiện thị là một phần của cấu trúc Display */ display_width = DisplayWidth(display, screen_num); display_height = DisplayHeight(display, screen_num); Một cách khác để có thông tin về kích cỡ cửa sổ - sử dụng macro XGetGeometry() Display *display; int screen_num; Window root; int x, y; unsigned int width, height; unsigned int border_width; unsigned int depth;    . /* Tạo Display */    . /* Lấy thông tin về cửa sổ root window */ if (XGetGeometry(display, RootWindow(display, screen_num), &root,       &x, &y, &width, &height, &border_width, &depth) == False)    {    fprintf(stderr, "%s: can't get root window geometry\n",          progname);    exit(-1);    } display_width = width; display_height = height; Tạo cửa sổ Window Để tạo cửa sổ window. Thực ra là mối quan hệ vị trí với cửa sổ cha của nó được xác định khi cửa sổ được tạo ra. Mỗi màn hình có cửa sổ root window của chính nó. Để tạo ra những cửa sổ ứng dụng cho chương trình của bạn trên màn hình, chúng ta sẽ sử dụng cửa sửa root trên màn hình đó như là cửa sổ cha. ID của cửa sổ root window được trả về bởi macro RootWindow(). Trước khi ánh xạ cửa sổ, một chương trình phải thiết lập những thuộc tính chuẩn để nói cho trình quản lý biết ít nhất là một vài thông tin cần thiết về ứng dụng. Rất nhiều hàm cung cấp cách thiết lập các thuộc tính này. Hàm được thiết kế để thiết lập tất cả các thuộc tính quan trọng cho những ứng dụng thông thường là XSetWMProperties(). Tập hợp những thuộc tính nên được thiết lập đó là: Tên của cửa sổ Tên Icon Icon pixmap Kích thước cửa sổ Chế độ focus Xử lí sự kiện Trong một chương trình Xlib, mọi thứ được điều khiển bằng sự kiện. Sự kiện vẽ trong màn hình thỉnh thoảng được thực hiện như là đáp ứng cho một sự kiện – sự kiện ‘expose’. Nếu một phần của cửa sổ bị ẩn, khi cửa sổ được hiện thị trên các cửa sổ khác, một sự kiện ‘expose’ được gửi đi để báo cho chương trình biết. Nó sẽ vẽ lại phần đó của cửa sổ.Chương trình của chúng ta có thể nhận biết 3 loại sự kiện : Vẽ lại Tính toán lại nội dung của nó khi nó thay đổi kích cỡ Nhận tín hiệu từ bàn phím Sau khi một chương trình tạo ra a cửa sổ( hoặc nhiều cửa sổ), nó nên nói cho X server biết loại sự kiện nào mà nó muốn nhận cho cửa sổ đó.Trong Xlib, chúng ta sử dụng XSelectInput() để đăng ký cho sự kiện. Hàm này có 3 thông số - cấu trúc Display, ID của cửa sổ, và loại của sự kiện. Thông số ID cho phép chúng ta đăng ký nhận những sự kiện khác nhau trên những cửa sổ window khác nhau. XSelectInput(display, win, ExposureMask | KeyPressMask |    ButtonPressMask | StructureNotifyMask); Thông số thiết yếu của XSelectInput() là định danh của sự kiện. Mỗi ký hiệu được sử dụng ở đây lựa chọn 1 trong nhiều loại sử kiện. ExposureMask lựa chọn những sự kiện Expose, những sự kiện xảy ra khi cửa sổ được hiển thị lần đầu tiên và bất cứ khi nào chúng xuất hiện lại khi bị làm mờ đi. Những sự kiện Expose báo hiệu rằng ứng dụng nên vẽ lại chính nó. X cung cấp những sự kiện riêng biệt cho việc ấn và thả bàn phím hoặc chuột. KeyPressMask lựa chọn duy nhất KeyPress, và ButtonPressMask lựa chọn duy nhất những sự kiện ButtonPress. Những sự kiện ButtonRelease và KeyRelease cũng được lựa chọn với ButtonReleaseMask và KeyReleaseMask. StructureNotifyMask lựa chọn số các loại sự kiện, CirculateNotify, ConfigureNotify, DestroyNotify… Trong đó ConfigureNotify thường được sử dụng để thông báo cho ứng dụng biết kích cỡ mới của cửa sổ khi nó được thay đổi lại kích cỡ. XSelectInput() thực sự thiết lập đặc tính event_mask của cửa sổ window. Sau khi tạo được cửa sổ window lựa chọn được sự kiện mong muốn, chúng ta sẽ tạo ra Server resource. Server resource là tập hợp các thông tin được quản lý bởi server và được tham chiếu tới ứng dụng bằng ID number. Các Item với các loại Colormap, Cusor, Font, GC, Pixmap và Window là các server resource. Nên tạo ra chúng một lần hơn là tạo ra và hủy đi thuyền xuyên bằng các gọi các hàm con. Đó là lý do tại sao chúng được tạo ra trong hàm main hoặc trong hàm con được gọi chỉ một lần từ main. Tạo Graphic Context Khi chúng ta thực hiện các chức năng vẽ( đồ họa, text ..) chúng ta có thể đặc tả những tùy chọn cho việc điều khiển dữ liệu sẽ được vẽ thế nào – màu gì được sử dụng cho nền, cho viền; những cạnh sẽ được kết nối với nhau như thế nào; font chữ nào sẽ được sử dụng để vẽ text … Để tránh việc cần cung cấp lượng vô cùng lớn các thông số cho mỗi chức năng vẽ, một cấu trúc graphical context, viết là GC được sử dụng. Chúng ta thiết lập những tùy chọn trong cấu trúc này, và sau đó đưa con trỏ trỏ vào cấu trúc này tới bất kỳ hàm thực hiện chức năng vẽ nào. Chúng cần thiết để thực hiện nhiều yêu cầu vẽ với nhiều tùy chọn như nhau. Do đó, chúng ta khởi tạo một GC, thiết lập chọn lựa mong muốn, và đưa cấu trúc GC này tới tất cả các hàm thực hiện chức năng vẽ. Trước khi vẽ vào một cửa sổ, chúng ta cần phải định nghĩa những thông số tổng quát cho việc vẽ - độ dày của đường được sử dụng, vẽ với màu gì… Chúng được thực hiện với Graphical Context( GC). Một GC định nghĩa nhiều thuộc tính được sử dụng với nhiều hàm thực hiện chức năng vẽ. Với việc định nghĩa một GC, chúng ta có thể sử dụng nhiều hơn một GC cho một cửa sổ đơn, để vẽ nhiều thể loại khác nhau( màu sắc khác nhau, độ dày đường thẳng khác nhau…). Để tạo một GC, ta sử dụng hàm XCreateGC(). Giả sử display là con trỏ trỏ tới cấu trúc Display, và win là ID của cửa sổ được tạo ra trước đó. /* Biến này sẽ chứa những xử lí mà GC trả về. */ GC gc; /* Những biến này được sử dụng để đặc tả những đặc tính. */ /* Khởi tạo giá trị cho GC. */ XGCValues values = CapButt | JoinBevel; unsigned long valuemask = GCCapStyle | GCJoinStyle; /* Tạo ra một GC mới. */ gc = XCreateGC(display, win, valuemask, &values); if (gc < 0) { fprintf(stderr, "XCreateGC: \n"); } Khi chúng ta tạo ra GC, chúng ta có thể sử dụng nó trong các hàm thực hiện chức năng vẽ. Chúng ta cũng có thề điều chỉnh những thông số của nó. /* Thay đổi màu viền của GC sang màu trắng. */ XSetForeground(display, gc, WhitePixel(display, screen_num)); /* Thay đổi màu nền của GC sang màu đen. */ XSetBackground(display, gc, BlackPixel(display, screen_num)); /* Thay đổi kiểu điền đầy của GC tới ‘solid’. */ XSetFillStyle(display, gc, FillSolid); Sau khi chúng ta tạo ra GC, chúng ta có thể vẽ đường thẳng, đường tròn, text … XDrawLine( display, win, gc, 20, 20, 40, 100); Tải font chữ Bên cạnh việc vẽ đồ họa trên cửa sổ, chúng ta cũng muốn vẽ text lên đó. Text phải có 2 đặc tính – ký tự được viết, và font chữ của nó. Để vẽ text, trước hết chúng ta cần tải font chữ. Sau đó chúng ta gán tới một GC, và cuối cùng chúng ta vẽ text trên của sổ window, sử dụng GC đó. Để hỗ trợ những font chữ một các linh động, một cấu trúc font được định nghĩa là XFontStruct.Cấu trúc này được sử dụng để chứa thông tin về font, và được đưa tới nhiều hàm chức xử lí font và vẽ text. Tải một Font Chúng ta sử dụng hàm XLoadQueryFont() để tải font. Hàm này yêu cầu X server tải dữ liệu định nghĩa một font với tên của nó. /* con trỏ này sẽ trỏ vào kết quả trả về cho cấu trúc. */ XFontStruct* font_info; /* Tải font. */ char* font_name = "*-helvetica-*-12-*"; font_info = XLoadQueryFont(display, fond_name); if (!font_info) { fprintf(stderr, "XLoadQueryFont: failed loading font '%s'\n", font_name); } Gán một font tới một GC Sau khi chúng ta tải font, chúng ta cần gán nó tới một GC mà chúng ta tạo ra ở trên. XSetFont(display, gc, font_info->fid); Trường ‘fid’ của cấu trúc XFontStruct là một định danh được sử dụng để xác định font với các yêu cầu khác. Vẽ text lên một cửa sổ Khi chúng ta đã có font mong muốn và gán tới GC, chúng ta có thể vẽ text lên cửa sổ của chúng ta, sử dụng hàm XDrawString(). Hàm này sẽ vẽ text tại vị trí được xác định. int x, y; /* Vẽ dòng “hello world” lên góc trái của cửa sổ. */ x = 0; y = 0; XDrawString(display, win, gc, x, y, "hello world", strlen("hello world")); Chúng ta cũng có thể dùng XTextWidth() để đoán độ dày của dòng text. Hoặc có thể thiết lập hai thông số “ascent” và “descent” đặc tả chiều cao của font chữ. Window Mapping Để hiển thị cửa sổ window ta dùng câu lệnh /* Hiện thị cửa sổ */ XMapWindow(display, win); Để một window có thể nhìn thấy được, nó phải thoải mãn 5 điều kiện. Cửa sổ phải được ánh xạ với XMapWindow() Tất cả lớp trên của nó phải được ánh xạ. Cửa sổ này không bị làm mờ đi bởi các cửa sổ mức ngang hàng hoặc lớp trên của nó. – Nó phụ thuộc vào trật tự stack. Khi ánh xạ đầu tiên, một cửa sổ xuất hiện trên đỉnh của so với những cửa sổ ngang hàng với nó. Yêu cầu bộ đệm phải được đẩy ra. Với nhiều nguyên nhân phức tạp, một ứng dụng phải đợi đến sự kiện Expose trước khi giả sử rằng cửa sổ của nó được hiển thị và vẽ lên nó. XMapWindow() là nguyên nhân giao thức X yêu cầu server hiển thị cửa sổ trên màn hình. Giống như tất cả các giao thức X khác, yêu cầu này cũng được đưa vào hàng đợi cho đến tận khi việc đọc sự kiện được thực thi, XNextEvent(), một hàm XFlush() hoặc XSync() được gọi. Tạo vòng lặp xử lí sự kiện Những chương trình X là sự điều khiển sự kiện, nó có nghĩa là sau khi thiết lập tất cả server resource và window manager hints, chương trình thực thi tất cả những hành động đáp lại sự kiện. Vòng lặp bắt sự kiện là một cách chuẩn để đáp ứng sự kiện, việc thực thi những hành động tương ứng phụ thuộc vào loại sự kiện và thông tin được chứa trong cấu trúc sự kiện. Vòng lặp sự kiện thông thường là vòng lặp đóng, một loại sự kiện với nội dụng cụ thể được định nghĩa bởi ứng dụng chỉ rõ rằng người sử dụng muốn thoát. Vòng lặp sự kiện phải đảm bảo xử lí chính xác mọi sự kiện đầu vào. Có rất nhiều cách để tạo vòng lặp, nhưng về cơ bản nó sẽ giống như sau: /* Cấu trúc này sẽ chứa dữ liệu của sự kiện, một nó nhận được sự kiện. */ XEvent an_event; /* Vòng lặp vô hạn. */ while (1) { XNextEvent(display, &an_event); switch (an_event.type) { case Expose: /* xử lí sự kiện... */ . . break; default: /* xử lí sự kiện mặc định. */ break; } } Hàm XNextEvent() gọi sự kiện tiếp theo đến từ X server. Nó không có sự kiện nào đang đợi, nó sẽ khóa cho đến khi nhận được một sự kiện. Khi nó trả lại, dữ liệu của sự kiện được đặt vào biến XEvent – thông số thứ hai của hàm. Chúng ta có thể bắt rất nhiều loại sự kiện như : gõ bàn phím, nhấn hay nhả chuột, thay đổi kích thước cửa sổ… Thực thi thiết kế Tạo cửa sổ giao diện Để tạo giao diện hiển thị khi chương trình chạy, chúng ta phải biết chúng được gọi ra từ đâu. Khi đã tìm ra được file tạo khung chứa video. Ta sẽ tạo ra một cửa sổ, có lớp cha chính là cửa sổ để chứa video, để phục vụ cho việc gõ text, nền của các cửa sổ đều là trắng, viền đen. Mỗi cửa sổ có ví trí bắt đầu( tọa độ bắt đầu) , độ dài và rộng. win_send=XCreateSimpleWindow(p_vout>p_sys>p_display,p_win->base_window, 230, 320, 40, 30, 2, BlackPixel(p_vout->p_sys->p_display, p_vout->p_sys->i_screen),WhitePixel(p_vout->p_sys->p_display, p_vout->p_sys->i_screen)); win_text = XCreateSimpleWindow(p_vout->p_sys->p_display, p_win->base_window, 20, 320, 200, 40, 2, BlackPixel(p_vout->p_sys->p_display,p_vout->p_sys->i_screen),WhitePixel(p_vout->p_sys->p_display,p_vout->p_sys->i_screen)); Tạo GC Để thực thi các chức năng vẽ đồ họa, text ta sẽ tạo các GC tương ứng cho mỗi cửa sổ. gc_send = XCreateGC(p_vout->p_sys->p_display, win_send, 0, NIL); XSetForeground(p_vout->p_sys->p_display, &gc_send, WhitePixel(p_vout->p_sys->p_display,p_vout->p_sys->i_screen)); gc_text = XCreateGC(p_vout->p_sys->p_display, win_text_1, 0, NIL); XSetForeground(p_vout->p_sys->p_display, &gc_text, WhitePixel(p_vout->p_sys->p_display,p_vout->p_sys->i_screen)); Hiển thị cửa sổ Sau khi khai báo cửa sổ window, chúng ta sẽ phải ánh xạ để hiện thị cửa sổ lên màn hình. XMapWindow( p_vout->p_sys->p_display, win_send); XMapWindow( p_vout->p_sys->p_display, win_text); Sau khi thực thi đoạn code giao diện của chương trình sẽ có dạng sau: Hình 4. 2: Giao diện bên nhận( Receiver) Giao diện bên thu gồm các cửa sổ gõ text, cửa sổ hiện thị text vừa gõ cũng như hiển thị text nhận được từ bên phía phát. Ở đây có cả nút bấm để thực hiện việc gửi text tới bên phát. Để thiết kế cửa sổ bên phát ta cũng sẽ tạo ra các cửa sổ có các chức năng tương tư. Việc xử lí sự kiện ở đây, ngoài việc bắt sự kiện nhấn nút Send, thì người dùng có thể gõ text rồi nhấn enter để thực hiện chức năng gửi giữ liệu. Hình 4. 3: Giao diện bên phát Xử lí sự kiện while( XCheckWindowEvent( p_vout->p_sys->p_display, win_text, ButtonPressMask | KeyPressMask | StructureNotifyMask, &xevent ) == True ) { if(xevent.type == KeyPress) { // Xu ly su kien go ban phim, phim Enter, phim SpaceBack charcount = XLookupString(&xevent, buffer, bufsize, &key, &compose); if( key == XK_Return) { if(yd_offset >= 100) { XClearWindow( p_vout->p_sys->p_display, win_display); yd_offset = 10; }; XDrawString(p_vout->p_sys->p_display, win_display, gc_display, xd_offset, yd_offset, text, strlen(text)); XClearWindow(p_vout->p_sys->p_display, win_text_1); yd_offset += 10; xd_offset = 10; pthread_cond_signal(&x_request); } else { if( key == XK_BackSpace) { text[strlen(text)-1] = '\0'; XClearWindow(p_vout->p_sys->p_display, win_text_1); XDrawString(p_vout->p_sys->p_display, win_text_1 , gc_text, 10, 10, text, strlen(text)); } else { strcat(text,buffer); XDrawString(p_vout->p_sys->p_display, win_text_1, gc_text, 10, 10, text, strlen(text)); } } } } Hàm trên xử lí trên cửa sổ gõ text, chúng ta có thể gõ text, nhấn enter hoặc click vào nút SEND để gửi text đến bên nhận. Nếu chúng ta gõ sai text, chúng ta dễ dàng có thể sử lại bằng việc sử dụng phím BackSpace, giống như chát trên yahoo. Trên đây chỉ là đoạn code xử lí sự kiện trên cửa sổ gõ text. Cửa sổ này cần xử lí nhiều sự kiện nhất, còn các cửa sổ SEND và hiện thị các sự kiện cần xử lí không nhiều. Hình 4. 4: Khi bên nhận gửi text đến bên phát Để phân biệt đoạn text nào là đoạn text mình gửi đi, đoạn nào là đoạn mình nhận được, chúng sẽ được phân biệt bởi địa chỉ ip. Đoạn text mà có địa chỉ ip đằng trước là đoạn text nhận được, còn đoạn text mà không có địa chỉ ip đằng trước chính là đoạn text mình đã gửi đi. Ở đây chúng ta không sử dụng việc hiển thị 2 địa chỉ ip, với đoạn text nhận được thì có địa chỉ ip của máy gửi và với đoạn text của mình thì sẽ có địa chỉ ip của máy mình, vì nó sẽ là lẫn lộn giữa các đoạn text. Người sử dụng nhiều khi quên cả địa chỉ ip của chính mình. Do vậy, để phân biệt ta chỉ cần một thông số địa chỉ ip của bên gửi đoạn text đó. Như hình bên dưới: Hình 4. 5: Phân biệt text ( bên nhận) Hình 4. 6: Phân biệt text ( bên phát) Vì Xlib chỉ cung cấp cho chúng ta những chức năng cơ bản nhất, nên mọi sự kiện đều do chúng ta xử lí. Như là khi truyền text, cửa sổ để hiện thị text đầy, nếu tiếp tục thì những thông tin khác sẽ không được hiện thị lên cửa sổ. Do đó chúng ta phải kiểm tra cửa sổ, nếu cửa sổ đã điền đầy text thì chúng ta sẽ phải xóa nội dụng cũ trên cửa sổ đi. Trong một trường hợp, nhất là nội dụng quan trọng, người sử dụng muốn lấy lại những thông tin về nội dung text mình đã gõ. Do vậy, chúng ta phải lưu những thông tin này vào bộ đệm. Tất nhiên số lượng không nhiều, vì nếu không nó sẽ góp phần vào việc chiếm đoạt tài nguyên thiết bị. Hình 5-7 bên dưới là việc xóa cửa sổ khi đầy nội dung text. Hình 4. 7: Xóa cửa sổ khi tràn Khi cửa sổ đầy text, thì chúng ta gõ text vào, cửa sổ sẽ được xóa và hiển thị nội dung text vừa gõ vào. Hoặc khi cửa sổ đang đầy text mà nhận được text từ bên phát cửa sổ cũng sẽ được xóa và nội thị nội dung mới nhận được. Hình 5-8 và hình 5-9 Hình 4. 8: Tự động xóa nội dung text khi tràn Hướng phát triển Sau quá trình nghiên cứu và thực thi nhóm đã thực hiện được việc tạo ra giao diện người dùng khá than thiện. Cụ thể, bên phát có chức năng gửi và nhận text tới và từ phía thu. Bên nhận có chức năng hiển thị video, có audio và có giao diện cho việc truyền text cũng như có các chức năng cơ bản hỗ khác. Tuy đã phát triển được giao diện có được khá nhiều chức năng, nhưng trong tương lại giao diện sẽ cần có thêm các chức năng khác như hiện thị được những thiết bị đang trên mạng. Có giao diện điều khiển audio và video. Chương 5 : Kết quả thực nghiệm và hướng nghiên cứu Test case 1: Thực nghiệm truyền text Mục đích Thực thi việc truyền text cùng với video và audio thông qua mang ad-hoc. Điều kiện thực nghiệm Hardware: 3 PC chạy linux( fedora core 7) địa chỉ IP lần lượt là 192.168.11.165, 192.168.11.14 ; 192.168.11.164 1 Webcam Labtek Software: Streaming server chạy trên PC 1( vlc-0.8.6c) – 192.168.11.5 với bộ mã hóa h264( X264) lấy dữ liệu từ webcam Labtec. Client chạy trên PC 2 – 192.168.11.165 nhận dữ liệu từ streaming server. Phần mềm olsr – định tuyến. Được cài đặt trên tất cả các máy làm nhiệm vụ chuyển phát gói tin. PC 3 – 192.168.11.164 làm nhiệm vụ chuyển phát gói tin. Tiến hành thí nghiệm PC 1 – 192.168.11.5 dùng để lấy dự liệu từ webcam và truyền tới PC thu đặt tại phòng lab 411. PC 2 – 192.168.11.165 dùng để thu video từ bên thu đặt tại đường đôi gần thư viện điện tử. PC 3 – 192.168.11.164 dùng để chuyển phát gói dư liệu đặt tại tầng 1 khu nhà C9. PC 1 sẽ lấy dự liệu từ webcam Labtec và truyền, truyền audio và text đến PC 2 – 192.168.11.5 Kết quả thu được Thực hiện được truyền video, audio và text thông qua PC trung gian trong mạng ad-hoc. Hình 5. 1: Cửa sổ giao diện bên server Hình 5. 2: Bảng liệt kê IP trên mạng Hình 5. 3: Giao diện bên thu Trong cửa sổ giao diện của PC 1 – 192.168.11.5 nhận được đoạn text truyền từ PC 3 – 192.168.11.165. Trên giao diện của máy PC 3 ( máy thu) hiển thị được video và audio cũng như truyền được text cho PC 1( máy phát). Giao diện PC 1 hiển thị được địa chỉ của PC 3 trên khung nhận text. PC 2 thông báo trên mạng có 3 thiết bị với các địa chỉ IP là 192.168.11.5, 192.168.11.165 và 192.168.11.164. Giá trị đáng giá đường truyền là ETX = 2.753. Thực hiện được các chức năng thiết kế giao diện như hiển thị địa chỉ IP, xóa text khi cửa sổ text đầy. Test Case 2: Thực nghiệm kết quả truyền lại (feedback) Mục dích Thực thi chức năng truyền lại (feedback) của giao thức thích ứng. Thông qua đó, lấy số liệu truyền lại từ phía sender gửi về phía receiver. Điều kiện thực nghiệm Hardware: 3 PC chạy linux( fedora core 7), fit-pc chạy Genius địa chỉ IP lần lượt là 192.168.12.165, 192.168.12.126 ; 192.168.12.5; 192.168.12.100. Chế độ chạy là Mode Ad-hoc. 1 Webcam Labtek Các bộ đàm để thực hiện liên lạc giữa bốn nút mạng Software: Sender là PC 1( vlc-0.8.6c) – 192.168.12.165 với bộ mã hóa h264( X264) lấy dữ liệu từ webcam Labtec. Receiver là PC 2 – 192.168.12.126 nhận dữ liệu từ sender. Phần mềm olsr – định tuyến. Được cài đặt trên tất cả các máy làm nhiệm vụ chuyển phát gói tin. PC 3 – 192.168.12.5 và fit-pc làm nhiệm vụ định tuyến cho các gói tin (các nút trung gian). Tiến hành thí nghiệm PC 1 – 192.168.12.165 dùng để lấy dự liệu từ webcam và truyền tới PC thu , nút này được đặt tại phòng lab 411. PC 2 – 192.168.12.126 dùng để thu video từ bên thu đặt tại đường đôi gần thư viện điện tử. PC 3 – 192.168.12.5 dùng để trung chuyển dư liệu đặt tại tầng 1 khu nhà C9. Fit-pc đặt tại phòng 411 PC 1 sẽ lấy dự liệu từ webcam Labtec và truyền, truyền audio và text đến PC 2 – 192.168.12.126 Kết quả thu được Giá trị thu được của bản tin feedback được hiển thị lên cửa sổ console ở bên Sender: Hình 5. 4: Bản tin feedback Các thông số mà bản tin feedback gửi về bao gồ số gói mất, và danh sách gói mất. Ở đây chính là timestamp của gói bị mất. Dựa vào đây ta sẽ thực hiện việc truyền lại các gói mất. Test Case 3: Thu thập số liệu về tổn hao CPU khi thực hiện giao thức truyền thích ứng sử dụng bộ codec H 264 Mục đích Đo đạc độ chiếm dụng CPU của hệ thống streaming sử dụng giao thức thích ứng và bộ codec H264 so với CPU chạy ở chế độ thông thường khi không sử dụng hệ thống streaming. Điều kiện thực nghiệm Điều kiện thí nghiệm của thí nghiệm này tương tự như với trường hợp thí nghiệm Test Case 2 Tiến hành thí nghiệm Các bước chuẩn bị và tiến hành thí nghiệm ta thực hiện như trường hợp Test Case 2 Sau đó chụp ảnh màn hình System Monitor để kiểm tra độ chiếm dụng CPU của hệ thống tạo luồng thời gian thực trên mạng adhoc Chụp ảnh màn hình System Monitor để kiểm tra độ chiếm dụng CPU của máy tính khi không chạy hệ thống. Kết quả thu được Bên Receiver. Trạng thái CPU của máy trước khi chạy hệ thống: Hình 5. 5: CPU bên nhận( khi không truyền) Độ chiếm dụng CPU khi chạy một chương trình VLC thông thường: Hình 5. 6: CPU bên nhận( khi chạy vlc thông thường) Độ chiếm dụng CPU của hệ thống streaming: Hình 5. 7: CPU bện nhận( khi truyền) Như vậy ta thấy rằng, độ chiếm dụng CPU của một hệ thống streaming thời gian thực sử dụng giao thức thích ứng tăng nhẹ so với độ chiếm dụng CPU của một chương trình VLC thông thường (22.3% so với 16.2% CPU1) và chiếm dụng một lượng CPU không phải quá lớn so với khi không chạy chương trình nào (6.0% CPU1). Điều này chứng tỏ tiêu hao năng lượng của giao thức thích ứng thời gian thực là không nhiều và có thể chấp nhận được đối với bên thu. Bên Sender Trạng thái CPU của máy trước khi chạy hệ thống: Hình 5. 8: CPU bên phát( khi không truyền) Độ chiếm dụng CPU khi chạy một chương trình VLC thông thường: Hình 5. 9: CPU bên phát( khi chạy vlc thông thường) Độ chiếm dụng CPU của hệ thống streaming: Hình 5. 10: CPU bên phát ( khi truyền) Như vậy ta thấy rằng, bên Sender độ chiếm dụng CPU của một hệ thống streaming thời gian thực sử dụng giao thức thích ứng cũng tương đương như đối với bên Receiver (Hai máy có cùng cấu hình) và chỉ tăng nhẹ so với độ chiếm dụng CPU của một chương trình VLC thông thường (26.0% so với 15.3% CPU1) và chiếm dụng một lượng CPU không phải quá lớn so với khi không chạy chương trình nào (6.1% CPU1). Điều này chứng tỏ tiêu hao năng lượng của giao thức thích ứng thời gian thực là không nhiều và có thể chấp nhận được đối với bên phát. Kết Luận Đồ án đã thực hiện hoàn chỉnh các nhiệm vụ sau: Xây dựng thành công giao thức liên tầng (cross-layer design) với việc sử dụng kỹ thuật trao đổi thông tin đa luồng và đa tiến trình IPC (Inter-process Communications). Truyền video thời gian thực sử dụng bộ mã hóa H264 Truyền audio đồng bộ với video Truyền văn bản đồng thời với luồng video và audio Điều khiển tốc độ (giá trị QP) thích ứng với đường truyền dựa trên bản tin feed back và thông tin lấy được từ tầng định tuyến theo mô hình liên tầng. Thực hiện truyền dữ liệu đa chặng trong mạng ad hoc không dây với khoảng cách lớn. Xây dựng được giao tiếp người máy cơ bản cho các chức năng truyền và hiển thị dữ liệu. Vấn đề tồn tại của đồ án: Chưa thực hiện được truyền hai chiều đồng thời tại một tiến trình. Chưa xây dựng được cơ chế truyền lại thông minh (lựa chọn gói tin cần truyền lại). Chưa xây dựng được giao diện hoàn chỉnh và thân thiện cho người sử dụng. Mới chỉ chạy được trên một dòng hệ nhúng là Fit-pc còn các nút đa phần là Laptop. Hướng Nghiên Cứu Tiếp Theo Do đồ án còn một số vấn đề tồn tại chưa giải quyết được nên hướng phát triển tiếp theo của đồ án thực hiện các mục tiêu sau đây: Xây dựng cơ chế truyền dữ liệu (video/audio/text) hai chiều đồng thời trong một phiên truyền. Xây dựng thuật toán lựa chọn gói truyền lại thích ứng Tiếp tục xây dựng hoàn chỉnh giao tiếp người máy, giao diện đồ họa người dùng. Tối ưu mã nguồn và tải chạy trên các dòng hệ nhúng khác nhau như Fox, Armadillo… Tài Liệu Tham Khảo Iain E. G. Richardson , “H.264 and MPEG-4 Video Compression Video Coding for Next-generation Multimedia “, John Willey & Son 2003 Tien Pham Van, “Proactive ad hoc devices for relaying real-time video packets”, Doctor of Philosophy Dissertation 2007 ITU-T Recommendation H.264 Advanced video coding for generic audiovisual services: Advanced video coding for generic audiovisual services 2006 Colin Perkin, “RTP: Audio and Video for the Internet”, Addison Wesley 2003 S. Wenger M.M. Hannuksela, T. Stockhammer , Request for Comments 3984: RTP Payload Format for H.264 Video,2005 David Austerberry, “The Technology of Video and Audio Streaming”, Focal press 2005 Victor Ramamoorthy ,”A ρ-domain Rate Control Algorithm for the H.264 Encoder “,CA 94566 2004 László Czúni, Gergely Császár, Attila Licsár,”Estimating the Optima Quantization Parameter in H.264”, Pannon University, Veszprém, Hungary 2006 M. Mahdi Ghandi and Mohammed Ghanbari ,”A lagrangian optimized rate control algorithm for the h.264/avc encoder”,Department of Electronic Systems Engineering, University of Essex 2007 Thomas Wiegand et al, .Overview of the H.264/AVC video coding standard,. IEEE Trans. on circuits and systems for video technology, Vol. 13, No. 7, pp. 560-576, July 2003 Thomas Wiegand et al, .Rate-Constrained Coder Control and Comparison of Video Coding Standards,.IEEE Trans. on circuits and systems for video technology,Vol. 13, No. 7, pp. 688-703, July 2003 Thomas schierl and Thomas wiegand.“H.264/avc rate adaptation for Z. Li et al., "Proposed Draft of Adaptive Rate Control," JVT-H017, 8th Meeting: Geneva, May 2003 PHỤ LỤC: Hồ sơ sinh viên Họ và tên: Từ Văn Hiếu Giới tính: Nam Ngày sinh: 06/05/1986 Quê quán: Thường Tín – Hà Nội Lớp: Điện tử 4 Điểm TB giai đoạn 2: Địa chỉ : Phòng 403- Nhà A3 – 128C Đại La E-mail : hieu_tv1986@yahoo.com Điện thoại : 0983617586 Tên đồ án: Nghiên cứu và phát triển hệ thống tạo luồng thời gian thực và giao thức thích ứng cho truyền thông đa phương tiện trong mạng ad hoc Mô tả nội dung Đồ án: Lĩnh vực có liên quan ( từ khóa) : Giảng viên hướng dẫn : TS. Phạm Văn Tiến Mục tiêu nghề nghiệp: ( đi học tiếp, nghiên cứu, DN nhà nước, DN tư nhân): Kỹ năng Kỹ năng Thời gian sử dụng Trình độ(1_Bắt đầu, 5_Thành thạo) 1.Ngôn ngữ lập trình VC, C/C++ 1 2 3 4 5 Java 1 2 3 4 5 .Net 1 2 3 4 5 2. Lập trình Web ASP, JSP, PHP , .v.v. 1 2 3 4 5 3. Lập trình Database MS SQL, MySQL, SQL .v.v. 1 2 3 4 5 4. Phát triển Oracle 1 2 3 4 5 5. Networking Administration 1 2 3 4 5 Programming 1 2 3 4 5 6. Quản trị nhóm Analysis & Design 1 2 3 4 5 7. Kỹ năng viễn thông Mobile programming 1 2 3 4 5 CDMA/GSM 1 2 3 4 5 Webservice 1 2 3 4 5 R&D tools cho hệ tổng đài, viễn thông 1 2 3 4 5 8. Kỹ năng điện tử Ngôn ngữ mô tả phần cứng Verilog/VHDL 1 2 3 4 5 Phần mềm thiết kế mạch Orcad/Protel.. 1 2 3 4 5 Thiết kế dùng vi điều khiển, PSoC, FPGA. 1 2 3 4 5 9.Chứng chỉ nghề Chứng chỉ MS, SUN, IBM, CISCO , CNTT Japan ...... 10. Chứng chỉ cuộc thi HS giỏi, NC Khoa học 11. Chứng chỉ/ giải thưởng khác Ngoại ngữ Ngoại ngữ (Anh, Pháp, Nhật .v.v.) Trình độ, khả năng Tiếng: 1 2 3 4 5 Tiếng: 1 2 3 4 5 Kỹ năng khác (làm việc theo nhóm, làm việc độc lập, quản lý…) Công việc có thể làm (lập trình, thiết kế, quản trị…): Công việc khác: Kinh nghiệm/ Nơi thực tập, làm việc Tên công ty, địa điểm đã thực tập Công việc tham gia Hồ sơ sinh viên Họ và tên: Trần hải Long Giới tính: Nam Ngày sinh: 16/04/1986 Quê quán: Từ Sơn – Bắc Ninh Lớp: ĐT4 – K49 Điểm TB giai đoạn 2: Địa chỉ : Nhà 28 ngách 24/83 Kim Đồng – Hoàng Mai – Hà Nội E-mail : hlong1604@gmail.com Điện thoại : 0973 989887 Tên đồ án: Nghiên cứu và phát triển hệ thống tạo luồng thời gian thực và giao thức thích ứng cho truyền thông đa phương tiện trong mạng ad hoc Mô tả nội dung Đồ án: Lĩnh vực có liên quan ( từ khóa) : Mạng thông tin Giảng viên hướng dẫn : TS. Phạm Văn Tiến Mục tiêu nghề nghiệp: ( đi học tiếp, nghiên cứu, DN nhà nước, DN tư nhân): Đi làm cho doanh nghiệp tư nhân hoặc doanh nghiệp nước ngoài Kỹ năng Kỹ năng Thời gian sử dụng Trình độ(1_Bắt đầu, 5_Thành thạo) 1.Ngôn ngữ lập trình VC, C/C++ 4 Java 1 .Net 2 2. Lập trình Web ASP, JSP, PHP , .v.v. 1 3. Lập trình Database MS SQL, MySQL, SQL .v.v. 2 4. Phát triển Oracle 1 5. Networking Administration 2 Programming 2 6. Quản trị nhóm Analysis & Design 3 7. Kỹ năng viễn thông Mobile programming 1 CDMA/GSM 1 Webservice 1 R&D tools cho hệ tổng đài, viễn thông 1 8. Kỹ năng điện tử Ngôn ngữ mô tả phần cứng Verilog/VHDL 2 Phần mềm thiết kế mạch Orcad/Protel.. 1 Thiết kế dùng vi điều khiển, PSoC, FPGA. 2 9.Chứng chỉ nghề Chứng chỉ MS, SUN, IBM, CISCO , CNTT Japan ...... 10. Chứng chỉ cuộc thi HS giỏi, NC Khoa học 11. Chứng chỉ/ giải thưởng khác Giải khuyến khích Ngoại ngữ Ngoại ngữ (Anh, Pháp, Nhật .v.v.) Trình độ, khả năng Tiếng: Anh 3 Kỹ năng khác (làm việc theo nhóm, làm việc độc lập, quản lý…) Tốt Công việc có thể làm (lập trình, thiết kế, quản trị…): Lập trình và quản trị Công việc khác: Kinh nghiệm/ Nơi thực tập, làm việc Tên công ty, địa điểm đã thực tập Công việc tham gia Lab 411 Khoa điện tử viễn thông Lập trình Hồ sơ sinh viên Họ và tên: Phùng Đình Vinh Giới tính: Nam Ngày sinh:12/06/1986 Quê quán:Thuận Thành Bắc Ninh Lớp:ĐT 4 – K 49 Điểm TB giai đoạn 2: Địa chỉ : 1B – Q39 – Ngõ 160 – Nguyễn An Ninh – Hà Nội E-mail : vinhphungdinh@gmail.com Điện thoại : 0914598378 Tên đồ án: Nghiên cứu và phát triển hệ thống tạo luồng thời gian thực và giao thức thích ứng cho truyền thông đa phương tiện trong mạng ad hoc Mô tả nội dung Đồ án: Lĩnh vực có liên quan ( từ khóa) : Giảng viên hướng dẫn : TS. Phạm Văn Tiến Mục tiêu nghề nghiệp: DN Tư nhân hoặc DN nước ngoài Kỹ năng Kỹ năng Thời gian sử dụng Trình độ(1_Bắt đầu, 5_Thành thạo) 1.Ngôn ngữ lập trình VC, C/C++ 4 Java 4 .Net 3 2. Lập trình Web ASP, JSP, PHP , .v.v. 3 3. Lập trình Database MS SQL, MySQL, SQL .v.v. 4 4. Phát triển Oracle 1 5. Networking Administration 3 Programming 4 6. Quản trị nhóm Analysis & Design 4 7. Kỹ năng viễn thông Mobile programming 2 CDMA/GSM 4 Webservice 4 R&D tools cho hệ tổng đài, viễn thông 2 8. Kỹ năng điện tử Ngôn ngữ mô tả phần cứng Verilog/VHDL 2 Phần mềm thiết kế mạch Orcad/Protel.. 3 Thiết kế dùng vi điều khiển, PSoC, FPGA. 2 9.Chứng chỉ nghề Chứng chỉ MS, SUN, IBM, CISCO , CNTT Japan ...... 10. Chứng chỉ cuộc thi HS giỏi, NC Khoa học 11. Chứng chỉ/ giải thưởng khác Chứng nhận SVNCKH Ngoại ngữ Ngoại ngữ (Anh, Pháp, Nhật .v.v.) Trình độ, khả năng Tiếng: Anh 5 Tiếng: Kỹ năng khác (làm việc theo nhóm, làm việc độc lập, quản lý…) Công việc có thể làm (lập trình, thiết kế, quản trị…): Công việc khác: Kinh nghiệm/ Nơi thực tập, làm việc Tên công ty, địa điểm đã thực tập Công việc tham gia

Các file đính kèm theo tài liệu này:

  • docStreaming Group Thesis - Final Version.doc
  • docHeader.doc