151 Số byte Type [Giá trị] Mô tả 1 1 2 U8 2 U16 dạng thông điệp độn số lượng các mã hóa theo sau là các số lượng các mã hóa gởi lặp đi lặp lại : Số byte Type [Giá trị] Mô tả 4 U32 0 1 2 4 5 16 0xffffff11 0xffffff21 dạng mã hóa mã hóa thô (raw) mã hóa CopyRect mã hóa RRE mã hóa CoRRE mã hóa Hextile mã hóa ZRLE mã hóa giả Cursor mã hóa giả DesktopSize 6,7,8 0xffffff00 tới 0xffffff10 0xffffff12 tới 0xffffff20 0xffffff22 tới 0xffffffff Những mã hóa được đăng kí khác zlib, tight, zlibhex các tùy chọn của tight 4.1.6.3.4 FrameBufferUpdateRequest Báo cho server biết client quan tâm đến một khu vực trong vùng đệm khung xác định bằng x-position, y-position, width và height. Server thường hồi đáp FrameBufferUpdateRequest bằng cách gởi một FramebufferUpdate. Chú ý rằng tuy 152 là như thế một FramebufferUpdate có thể gởi để hồi đáp nhiều FramebuferUpdateRequest. Server ngầm định rằng client giữ một bản sao của mọt phần trong vùng đệm khung mà nó quan tâm. Điều này có nghĩa là server thông thường chỉ cần gởi các cập nhật tăng dần cho client. Tuy thế, nếu vì vài nguyên nhân nào đó client đã mất nội dung khu vực nó cần, thì client có thể gởi một FramebufferUpdateRequest với incremental đặ t bằng 0 (sai). Việc này yêu cầu server gởi cả nội dung của cả khu vực càng sớm càng tốt. Khu vực sẽ không cập nhật khi dùng mã hóa CopyRect. Nếu client đã không mất nội dung khu vực nó quan tâm, thì nó sẽ gởi một FramebufferRequest với incremental đặt khác 0 (đúng). Nếu và khi có bất kì sự thay đổi tới khu vực xác định của vùng đệm khung, server sẽ gởi một FramebufferUpdate. Chú ý rằng có một chu kỳ bất giữa việc gở i và nhận các FramebufferUpdateRequest và FramebufferUpdate. Trong trường hợp là một client nhanh (cấu hình mạnh), client có thể muốn điều chỉnh tần suất gởi các FramebufferUpdateRequest tăng dần để tránh lấn chiếm đường mạng. Số byte Type [Giá trị] Mô tả 1 1 2 2 2 2 U8 U8 U16 U16 U16 U16 dạng thông điệp incremental x-position y-position width height 4.1.6.3.5 Sự kiện phím 153 là khi một phím nhấn hoặc thả. Cờ down là khác 0 (đúng) nếu phím đang được nhấn, 0 (sai) nếu phím đang thả. Phím tự nó cũng được dùng để xác định giá trị “keysym” định nghĩa bởi Hệ thống X Windows. Số byte Type [Giá trị] Mô tả 1 1 2 4 U8 4 U8 U32 dạng thông điệp cờ down độn phím Dành cho hầu hết các phím, “keysym” giống với giá trị ASCII tương ứng. Để biết chi tiết, xem The Xlib Reference Manual, phát hành bởi O’Reilly & Associates, hay xem file tiêu đề <X11/keysymdef.h> từ bất kỳ một cài đặt của hệ hống X Windows. Một số phím thông dụng khác: 154 Tên phím Giá trị keysym BackSpace Tab Return hay Enter Escape Insert Delete Home End Page Up Page Down Left Up Right Down 0xff08 0xff09 0xff0d 0xff1b 0xff63 0xffff 0xff50 0xff57 0xff55 0xff56 0xff51 0xff52 0xff53 0xff54 Tên phím Giá trị keysym F1 F2 F3 F4 … F12 Shift (trái) Shift (phải) Control (trái) Control (phải) Meta (trái) Meta (phải) Alt (trái) Alt (phải) 0xffbe 0xffbf 0xffc0 0xffc1 … 0xffc9 0xffe1 0xffe2 0xffe3 0xffe4 0xffe7 0xffe8 0xffe9 0xffea 155 Việc thông dịch keysym khá phức tạp. Nhằm để hoạt độn phối hợp rộng rãi càng nhiều càng tốt, cần tuân theo các chỉ dẫn sau: • “Shift state” (i.e. khi các phím shift được nhấn) chỉ nên dùng như một hướng dẫn khi biên dịch một keysym. Chẳng hạn, trên một bàng phím US ký tự ‘#’ được nhấn kèm theo shift mới được, còn bàn phím UK thì không. Một server với một bàn phím US nhận một ký tự ‘#’ từ một client với một bàn phím UK sẽ không được g ởi với bất kỳ phím shift nhấn nào cả. Trong trường hợp đó, server có thể cần “giả” nhấn shift trên hệ thống cục bộ của nó, nhằm để lấy ký tự có hay không shift, ví dụ, một ký tự ‘3’. • Việc phân biệt ký tự chữ hoa chữ thường là rất quan trọng. Điều này không đúng với một số bàn phím trong các Hệ thống X Windows xử lý giống nhau với cả chữ hoa chữ thườ ng. Chẳng hạn, server nhận được một keysym ‘A’ hoa mà không kèm theo nhấn shift thì nên thông dịch là một ký tự ‘A’ hoa. Một lần nữa, điều này cũng có thể cần làm “giả” cục bộ nhấn shift. • Server nên bỏ qua việc “khóa” các keysym chẳng hạn CapsLock và NumLock khi có thể. Thay vào đó chúng nên được thông dịch mỗi keysym dựa vào ký tự tùy theo trường hợp của nó. • Không giống Shift, trạng thái của các phím tinh chỉnh như Control và Alt cần phải lấy để chỉ nh sửa việc thông dịch các keysym khác. Chú ý rằng sẽ không có những keysym cho ký tự điều khiển ASCII ví dụ như ctrl-a – các tổ hợp phím này được phát sinh qua khung nhìn bằng cách gởi một nhấn Control và một nhấn ‘a’. • Trên khung nhìn khi các phím tinh chỉnh như Control và Alt có thể cũng được dùng để phát sinh các keysym dựa trên ký tự, các khung nhìn có thể cần gởi thêm các sự kiện “thả” nhằm để keysym được thông dịch chính xác. Chẳng hạn, trên một bàn phím PC Đức, ctrl-alt-q sẽ tạo ra ký tự ‘@’. Trong trường hợp này, khung nhìn cần gởi các sự kiện thả “giả” cho Control và Alt 156 nhằm để ký tự ‘@’ thông dịch đúng (ctrl-alt-q có thể có nghĩa gì đó hoàn toàn khác đối với server). • Không có chuẩn chung cho “tab lùi” trong Hệ thống X Windows. Trên một số hệ thống shift-tab cho keysym “ISO_Left_Tab”, trên số khác nó cho ra keysym “BackTab” dùng riêng và trên số còn lại nó cho “Tab” và các ứng dụng lấy từ tình trạng phím shift để biết nó là tab lùi hay tab tiến. Trong nghi thức RFB cách tiếp cận sau được ưa chuộng hơn. Khung có thể phát sinh một Tab kèm shift nhấn hơn là một ISO_Left_Tab. Tuy thế, để tương thích với m ột số khung nhìn có sẵn, server cần nhận ra ISO_Left_Tab như là một Tab kèm shift nhấn. 4.1.6.3.6 Sự kiện trỏ cho biết con trỏ có di chuyển hoặc nút trỏ được nhấn hoặc thả. Con trỏ đang ở vị trí (x-position, y-position), và trạng thái của các nút 1 đến 8 tính theo thứ tự từ bit 0 đến 7 của button-mask, giá trị bit 0 là thả, giá trị bit 1 là nhấn Trên một mouse chuẩn, các nút 1, 2 và 3 tương ứng cho các nút trái, giữa và phải trên mouse. Trên mouse có wheel (bộ phận scroll), m ỗi bước quay wheel lên tương ứng với việc nhấn và thả nút 4, và mỗi bước quay wheel xuống tương úng với việc nhấn và thả nút 5. Số byte Type [Giá trị] Mô tả 1 1 2 2 U8 5 U8 U16 U16 dạng thông điệp button-mask x-position y-position 4.1.6.3.7 ClientCutText 157 Client có dạng văn bản mới ISO 8859-1 (Latin-1) trong vùng cắt văn bản của nó. Hết mỗi dòng biểu thị bởi ký tự đơn linefeed / newline (sang dòng mới, giá trị 10), không cần giá trị carriage-return (trở về đầu dòng, giá trị 13). Hiện tại chưa có cách chuyển đổi văn bản ngoài bộ ký tự Latin-1. Số byte Type [Giá trị] Mô tả 1 3 4 Độ dài chuỗi U8 6 U32 mảng U8 dạng thông điệp độn độ dài chuỗi văn bản 4.1.6.4 Các thông điệp từ server đến client 4.1.6.4.1 FramebufferUpdate Một cập nhật vùng đệm khung gồm một tuần tự các chữ nhật dữ liệu điểm ảnh client phải vẽ lên vùng đệm khung của nó. Thông điệp được gởi hồi đáp cho một FramebufferUpdateRequest từ client. Chú ý rằng có một quá trình bất tận việc gởi và nhận các FramebufferUpdateRequest và FramebufferUpdate. Số byte Type [Giá trị] Mô tả 1 1 2 U8 0 U16 dạng thông điệp độn số các chữ nhật 158 đi kèm theo là số các chữ nhật dữ liệu điểm ảnh. Mỗi hình chữ nhật bao gồm: Số byte Type [Giá trị] Mô tả 2 2 2 2 4 U16 U16 U16 U16 U32 0 1 2 4 5 16 0xffffff11 0xffffff21 x-position y-position width height dạng mã hóa mã hóa thô (raw) mã hóa CopyRect mã hóa RRE mã hóa CoRRE mã hóa Hexile mã hóa ZRLE mã hóa giả Cursor mã hóa giả DesktopSize 6, 7, 8 0xffffff00 đến 0xffffff10 0xffffff12 đến 0xffffff20 0xffffff22 đến 0xffffffff Các mã hóa khác zlib, tight, zlibhex các tùy chọn của tight 159 tiếp theo là các dữ liệu điểm ảnh trong dạng mã hóa đã xác định. Xem phần 4.3.6.5 cho định dạng dữ liệu cho mỗi mã hóa và xem phần 4.3.6.6 cho định nghĩa của mã hóa giả. 4.1.6.4.2 SetColourMapEntries Khi định dạng điểm ảnh dùng “bản đồ ảnh”, thông điệp này báo cho client biết những giá trị điểm ảnh xác định trước cần ánh xạ vào các cường độ RGB. Số byte Type [Giá trị] Mô tả 1 1 2 2 U8 1 U16 U16 dạng thông điệp độn màu đầu tiên số lượng màu tiếp theo là lặp đi lặp lại số lượng màu các dữ liệu như sau Số byte Type [Giá trị] Mô tả 2 2 2 U16 U16 U16 đỏ xanh lá xanh dương 4.1.6.4.3 Bell Bật loa chuông nếu client có. Số byte Type [Giá trị] Mô tả 1 U8 2 dạng thông điệp 4.1.6.4.4 ServerCutText Client có dạng văn bản mới ISO 8859-1 (Latin-1) trong vùng cắt văn bản của nó. Hết mỗi dòng biểu thị bởi ký tự đơn linefeed / newline (sang dòng mới, giá trị 10), 160 không cần giá trị carriage-return (trở về đầu dòng, giá trị 13). Hiện tại chưa có cách chuyển đổi văn bản ngoài bộ ký tự Latin-1. Số byte Type [Giá trị] Mô tả 1 3 4 Độ dài chuỗi U8 6 U32 mảng U8 dạng thông điệp độn độ dài chuỗi văn bản 4.1.6.5 Các mã hóa 4.1.6.5.1 Mã hóa thô Mã hóa đơn giản nhất là dữ liệu điểm ảnh thô. Trong trường hợp này, dữ liệu chứa width x height các giá trị điểm ảnh (với width và height là chiều dài và chiều rộng của hình chữ nhật). Các giá trị chỉ đơn giản biểu thị các điểm ảnh theo thứ tự đường quét từ trái sang phải. Mọi client RFB đều phải bắt buộc hiểu dữ liệu điểm ảnh dưới dạng mã hóa thô, và các server chỉ gởi dạng mã hóa thô nếu client không chỉ rõ dạng mã hóa. Số byte Type [Giá trị] Mô tả width x height x bytesPerPixel mảng PIXEL các điểm ảnh 4.1.6.5.2 Mã hóa CopyRect Mã hóa CopyRect (sao chép hình chữ nhật) là dạng mã hóa rất đơn giản và hiệu quả được dùng khi client đã có sẵn dữ liệu điểm ảnh như thế trong vùng đệm khung của nó. Mã hóa trên đường truyền chỉ đơn giản gồm 2 tọa độ X, Y. Hai tọa độ này cho biết vị trí trong vùng đệm khung mà client sẽ sao chép hình chữ nhật dữ liệu điểm ảnh vào. Điều này được ứng dụng trong nhiề u tình huống, hiển nhiên nhất là việc người [...]... con 1 U8 x-and-y-position 165 Mô tả width-and-height Nếu không đặt, mọi hình chữ nhật con có cùng màu, màu mặt tiền; nếu bit ForegroundSpecified không được đặt thì mặt tiền sẽ giống với lát cuối Một hình chữ nhật con là: Số byte Type [Giá trị] Mô tả 1 U8 x-and-y-position 1 U8 width-and-height Vị trí và kích thước của mỗi hình chữ nhật con xác định trong hai byte, x-and-y-position và width-and-height... việc vẽ văn bản hay lặp lại các mẫu Một server thông minh sẽ có thể gởi tường minh một mẫu chỉ một lần, và biết vị trí trước đó của mẫu trong vùng đệm khung, gởi từ từ các xuất hiện của mẫu sử dụng mã hóa CopyRect Số byte Type [Giá Mô tả trị] 2 U16 src-x-position 2 U16 src-y-position 4.1.6.5.3 Mã hóa RRE RRE viết tắt của rise- and-run-length encoding (mã hóa chiều dài tăng trưởng và chạy) và như tên ngầm... nhiều điểm mà không đòi hỏi một thiết bị điều khiển đa điểm Khả năng này được bao gồm trong các thành phần của H.323 4.2.2.6 Quản lý băng thông: Luồng âm thanh và hình ảnh thì tốn băng thông và có thể làm cản trở sự hoạt động của mạng H.323 giải quyết vấn đề này bằng cách cung cấp cách quản lý băng thông Nhà quản lý mạng có thể hạn chế số kết nối H.323 đồng thời trong mạng của họ hay lượng băng thông... trường 4 bit được dùng Các trường bit đóng gói trong các byte, các bit quan trọng nhất biểu diễn các điểm ảnh cực trái (i.e big endian) Cho các lát không rộng bằng bội số 8, 4 hay 2 điểm ảnh, các bit độn sẽ dùng để canh lề mỗi dòng cho chính xác số lượng byte Số byte Type [Giá Mô tả trị] paletteSize x bytesPerCPixel mảng CPIXEL bảng màu m mảng U8 các điểm ảnh đóng gói 17 đến 1 27 – không dùng (không... chiều Các hình chữ nhật mã hóa RRE đến client trong dạng mà có thể dựng hình ngay lập tức và hiệu quả bởi các engine đồ họa đơn giản nhất RRE không thích hợp với các máy desktop phức tạp, nhưng có thể hữu dụng trong một số trường hợp Ý tưởng căn bản đằng sau RRE là phân vùng một hình chữ nhật dữ liệu điểm ảnh thành các vùng hình chữ nhật con (các hình chữ nhật phụ), mỗi cái trong chúng chứa các điểm... nhật 2 U16 con 2 U16 x-position 2 U16 y-position 2 U16 width height 4.1.6.5.4 Mã hóa CoRRE Chú thích: mã hóa CoRRE đã bị bỏ - Hextile là mã hóa tốt hơn dùng cùng ý tưởng CoRRE (Compact RRE) là một biến thể của RRE, với việc chúng ta sẽ bảo đảm hình chữ nhật lớn nhất được gởi không quá 255x255 điểm ảnh Một server muốn gởi một điểm ảnh lớn hơn thế chỉ đơn giản là cắt nhỏ ra và gởi các hình chữ nhật RFB... giữa các điểm nhận Ngoài việc đảm bảo rằng các điểm nhận sẽ giải mã được thông tin, H.323 thiết lập phương thức cho người dùng ở nơi nhận có thể giao tiếp đúng với người gởi Chuẩn này cũng thiết lập cách thiết lập cuộc gọi và những nghi thức điều khiển 4.2.2.3 Độc lập với mạng: H.323 được thiết kế để chạy bên trên kiến trúc mạng thông thường Khi kỹ thuật mạng phát triển, và khi kỹ thuật quản lý băng... ảnh nền Đi kèm là số lượng hình chữ nhật con các instance (hiển thị) của cấu trúc: Số byte Type [Giá trị] Mô tả số byte mỗi điểm ảnh PIXEL giá trị điểm ảnh hình chữ nhật 2 U16 con 2 U16 x-position 2 U16 y-position 2 U16 width height 4.1.6.5.5 Mã hóa Hextile Hextile là một biến đổi của ý tưởng CoRRE Các hình chữ nhật được cắt ra các tile (lát) 16x16, cho phép các chiều hình chữ nhật xác định bằng mỗi 4... thanh: G .71 1 : Mã hóa và giải mã âm thanh PCM 56/64 kpbs G .72 2 : Mã hóa và giải mã âm thanh cho 7Khz ở 48/56/64kbps G .72 3.1 : Mã hóa và giải mã tiếng nói cho 5.3 và 6.3 kbps G .72 8 : Mã hóa và giải mã tiếng nói cho 16 kbps G .72 9 : Mã hóa và giải mã tiếng nói cho 8/16 kbps 4.2.3.3 Mã hóa và giải mã hình ảnh: H.261: Mã hóa và giải mã hình ảnh >=64kbps 173 H.263: Mã hóa và giải mã hình ảnh . U8 x-and-y-position width-and-height Vị trí và kích thước của mỗi hình chữ nhật con xác định trong hai byte, x-and-y-position và width-and-height. Bốn bit quan trọng nhất của x-and-y-position. trị] Mô tả 2 2 U16 U16 src-x-position src-y-position 4.1.6.5.3 Mã hóa RRE RRE viết tắt của rise- and-run-length encoding (mã hóa chiều dài tăng trưởng và chạy) và như tên ngầm định. điệp button-mask x-position y-position 4.1.6.3 .7 ClientCutText 1 57 Client có dạng văn bản mới ISO 885 9-1 (Latin-1) trong vùng cắt văn bản của nó. Hết mỗi dòng biểu thị bởi ký tự đơn