Đề tài Mô hình hội nghị đa phương tiện và ứng dụng trong hệ đào tạo điện tử

i xem cảm nhận được sự mất đồng bộ và bắt đầu thấy không thoải mái trừ phi người nói nói chậm đi hoặc di chuyển con trỏ chậm lại. Nếu xét từ quan điểm giao diện người dùng , thì lỗi đồng bộ này là không chấp nhận được. Sẽ là rất vô lí nếu trong thực tế ta trỏ vào một đối tượng trong khi lại tác động vào một đối tượng khác. Các loại đồng bộ khác Việc kết hợp giữa audio và các hình ảnh động (animation) thường không đòi hỏi quan hệ về thời gian chặt chẽ như trong đồng bộ môi. Bằng cách tận dụng khả năng tương tác, các chuỗi ảnh động có thể được trình diễn lặp đi lặp lại nhiều lần. Trình diễn đồng bộ audio và văn bản thường được biết đến như là sự chú thích bằng lời cho các tài liệu. Đối với loại đồng bộ phương tiện này, độ lệch chấp nhận được có thể suy ra từ thời gian phát âm của một từ ngắn, vì vậy nó có thể được lấy bằng 250ms. Việc đồng bộ giữa video và văn bản hay ảnh tĩnh diễn ra dưới hai dạng sau: Chế độ overlay: văn bản thường là mô tả thêm cho chuỗi hình ảnh đang được trình diễn. Chế độ non-overlay: trong chế độ này ràng buộc thời gian là kém chặt chẽ hơn. Với những ứng dụng thuộc loại này, độ lệch đồng bộ khoảng 500ms giữa video và văn bản hoặc ảnh tĩnh là chấp nhận được. Mô hình tham chiếu cho đồng bộ đa phương tiện Để có thể phân tích và hiểu rõ các yêu cầu đối với đồng bộ đa phương tiện ta đưa ra ở đây một mô hình tham chiếu cụ thể. Mỗi một lớp trong mô hình thực thi một cơ chế đồng bộ thông qua việc cung cấp cá giao diện thích hợp. Giao diện này có thể được sử dụng bởi bản thân ứng dụng của lớp đó hoặc bởi các lớp cao hơn. Sự trừu tượng về lập trình và chất lượng dịch vụ ở các lớp trên là cao hơn so với các lớp dưới. Hình 2.5: Mô hình tham chiếu cho đồng bộ đa phương tiện Lớp phương tiện (Media Layer) Ở mức phương tiện, ứng dụng chỉ thao tác hoặc động trên một dòng phương tiện liên tục. Dòng này có thể xem như là một chuỗi các đơn vị dữ liệu logic (Logical Data Unit-LDU) vì vậy nó cung cấp cho ta một giao diện độc lập với thiết bị. Mỗi một LDU sẽ có môt giá trị nhãn thời gian xác định. Ngay khi dữ liệu sẵn sàng, tiến trình thuộc lớp này sẽ đọc và ghi các LDU trong một vòng lặp bằng các thao tác như đọc read(devicehandle, LDU), ghi write(devicehandle, LDU) và hệ điều hành sẽ tiến hành lập lịch cho các tiến trình tương ứng theo thời gian thực để chúng có thể đồng bộ với nhau. Lớp dòng (Stream Layer) Lớp này hoạt động chủ yếu với các dòng phương tiện liên tục hoặc một nhóm các dòng phương tiện. Ở mức này, các dòng dữ liệu là các luồng liên tục với các tham số thời gian. Lúc này, ta không còn xét đến các LDU riêng lẻ nữa. Các thao tác cơ bản bao gồm start(stream), stop(stream), created_group(list_of_streams), start(group) và stop(group). Ứng dụng sử dụng lớp dòng được thực thi trong môi trường không phải là thời gian thực. Việc tạo ra các đối tượng phương tiện, tương tác với ngưòi dùng cũng như bắt đầu, kết thúc các dòng là do ứng dụng đảm nhận. Thông thường thuật toán “chủ-tớ” thường được dùng để đồng bộ các dòng với nhau hoặc đồng bộ giữa các dòng trong cùng một nhóm. Ở đây, dòng “chủ” sẽ đìều khiển một hoặc nhiều dòng “tớ”. Lớp đối tượng (Object Layer) Lớp này hoạt đông trên mọi loại phương tiện, không kể liên tục hay rời rạc. Nó nhận ở đầu vào là đặc tả đồng bộ và chịu trách nhiệm lập lịch trình diễn cho toàn hệ thống một cách hợp lí. Các chức năng trong lớp này phải hỗ trợ việc tính toán và thực thi các lịch trình diễn đó, bao gồm cả việc trình diễn các phương tiện không liên tục, đồng thời nó cũng phải hỗ trợ việc gọi tới các chức năng của lớp phương tiện (media layer). Lớp đặc tả (Specification Layer) Đây là một lớp mở, nó không đưa ra một giao diện cụ thể nào cả. Lớp này bao gồm các ứng dụng, công cụ cho phép tạo ra, thực hiện các kĩ thuật đồng bộ. Các công cụ đó có thể là bộ soạn đồng bộ (synchronization editor), các hệ thống sáng tác (authoring system)… Nhiệm vụ của lớp đặc tả là ánh xạ các yêu cầu chất lượng dịch vụ QoS của người dùng vào các định nghĩa chất lượng đặt ra ở giao diện của lớp đối tượng hoặc các lớp thấp hơn. Các phương pháp đặc tả có thể là: Dựa trên nhịp thời gian (interval-based): cho phép chỉ ra các đặc tính, mối liên hệ về thời gian và quá trình trình diễn của các đối tượng phương tiện. Dựa trên điều khiển luồng (control flow-based): các luồng dữ liệu sẽ được tiến hành đồng bộ tại các điểm đồng bộ định nghĩa trước. Dựa trên trục (axes-based): gắn các sự kiện trình diễn với một trục tham chiếu chung được chia sẽ bởi nhiều đối tượng phương tiện khác nhau. Chất lượng dịch vụ trong truyền thông đa phương tiện Thực thi một thuật toán đồng bộ cho một ứng dụng xác định đòi hỏi phải xác định chất lượng dịch vụ (QoS) cho truyền thông đa phương tiện. Chất lượng dịch vụ là một tập các tham số bao gồm tỉ số tốc độ (speed ratio), tỉ số sử dụng (utilization ratio), trễ trung bình (average delay), jitter, tỉ số bit lỗi (bit error rate) và tỉ số gói tin lỗi (packet error rate). Hình (2.6) minh hoạ cho ta việc tính toán các một số tham số này. normal jitter skew Skew correction TIME Stream B (Video) Stream A (Audio) t0 t11 t21 Hình 2.6: Các tham số chất lượng dịch vụ Tỉ số tốc độ bằng tốc độ trình diễn thật sự (actual presentation rate) chia cho tốc độ trình diễn danh nghĩa (nominal presentation rate). Theo hình (2.6), trong khoảng (t0,t1) tỉ số tốc độ là 6:6 hay 1, trong khoảng (t1,t2) tỉ số tốc độ bằng 4:6 hay 0,67. Tỉ số sử dụng bằng tốc độ trình diễn thật sự chia cho tốc độ phân phát (delivery rate). Trường hợp lí tưởng là cả tỉ số tốc độ và tỉ số sử dụng đều bằng 1. Việc truyền lặp lại các frame sẽ làm cho tỉ số sử dụng lớn hơn 1 trong khi việc mất mát dữ liệu sẽ làm tỉ lệ này nhỏ hơn 1. Jitter là chênh lệch tức thời giữa hai dòng được đồng bộ. Độ lệch (skew) là chênh lệch trung bình trong thời gian trình diễn giữa hai đối tượng được đồng bộ trên n điểm đồng bộ. Truyền lặp lại các frame (duplication) sẽ làm cho các dòng bị kéo dài về thời gian (stream lag) trong khi kết quả của việc thất lạc dữ liệu là làm rút ngắn các dòng lại (stream lead). Trên hình ****, trong khoảng (t1,t2) độ lệch là 4:6. Hình (2.6) cũng minh hoạ cho chúng ta thấy cách hiệu chỉnh độ lệch bằng phương pháp loại bỏ các frame. Trên hình (2.6) các frame màu đậm đã được vứt bỏ để phục hồi lại sự đồng bộ giữa hai dòng. Ngoài ra còn hai tham số chất lượng dịch vụ nữa, đó là tỉ lệ bit lỗi (bit error rate-BER) và tỉ lệ gói tin lỗi (packet error rate-PER). Bảng dưới minh hoạ cho ta các tham số dịch vụ cụ thể của hai ứng dụng: điện thoại video (video telephony) và truyền dòng video JPEG. Điện thoại video Truyền dòng video JPEG Tỉ số tốc độ 1.0 1.0 Tỉ số sử dụng 1.0 1.0 Trễ trung bình 0,25 s 0,2 s Jitter nhỏ nhất 10 ms 5ms Tỉ lệ bit lỗi lớn nhất 0,01 0,1 Tỉ lệ gói tin lỗi lớn nhất 0,001 0,01 Bảng 1: Các tham số dịch vụ của hai ứng dụng điện thoại video và truyền video JPEG Chương 3 Một số giải pháp đồng bộ audio-video thời gian thực Thuật toán đồng bộ dựa trên việc xây dựng thời gian tham chiếu tuyệt đối Để có thể trình bày phương pháp đồng bộ này, trước hết ta cần xem xét các giao thức truyền thông thời gian thực là RTP và RTCP và các đặc tính của nó khi áp dụng cho các nguồn dữ liệu đa phương tiện cơ bản là audio và video. Truyền thông thời gian thực RTP (Real-time Transport Protocol) Giao thức truyền thông thời gian thực là giao thức nằm ở tầng ứng dụng được thiết kế bởi tổ chức IETF và nó đã trở thành chuẩn cho tất cả các ứng dụng dựa trên kiến trúc H323. Mặc dù được gọi là giao thức “truyền thông” song RTP sử dụng các giao thức phía dưới cho các chức năng trộn và truyền. RTP là hoàn toàn độc lập với kiến trúc mạng. Trong mạng TCP/IP, nó hoạt động trên tầng UDP trong khi trong môi trường ATM nó hoạt động trên AAL5. Tương tự như UDP, RTP không có cơ chế đảm bảo các gói tin được nhận đúng thời điểm và theo đúng thứ tự phía gửi. RTP chỉ đơn giản cho phép truyền nhận dữ liệu theo thời gian thực, đồng thời thêm vào các thông tin về thời gian, số thực tự và định danh nguồn cho phần dữ liệu trong gói tin… cho phép phía nhận sắp xếp lại các gói tin nhận được theo đúng thứ tự. Các đặc tả RTP bao gồm hai phần, phần dữ liệu (RTP) và phần điều khiển (RTCP). Phần điều khiển chủ yếu được dùng để theo dõi chất lương dịch vụ trong các ứng dụng hội nghị đa phương tiện, nhưng cũng có khi được dùng để truyền thông tin về những người tham gia hội nghị. RTP và RTCP là các chuẩn độc lập với ứng dụng do đó ta cần định nghĩa thêm các đặc tả để có thể sử dụng được chúng vào những ứng dụng cụ thể (audio hoặc video) một cách đúng đắn. RTP được xác định hoàn toàn bởi chuẩn và tài liệu mô tả đặc tính kĩ thuật (profile specification documents). Tài liệu đặc tả này cung cấp các yêu cầu thêm vào đối với từng ứng dụng cũng như định dạng dữ liệu tải (payload format specification document) trong gói tin RTP của ứng dụng đó. Sau đây ta sẽ xem xét một số trường quan trọng trong header của gói tin RTP Hình 3.1: Định dạng phần header của RTP Version (V) : 2 bits. Phiên bản của RTP mới nhất là 2. Padding (P) : 1 bit. Nếu trường này được thiểt lập thì gói sẽ chứa một hay nhiều các byte thêm tại cuối header của gói mà không phải là thành phần của dữ liệu của gói. Byte cuối cùng của phần thêm này chứa số đếm các byte được thêm vào. Các byte được thêm vào để một vài thuật toán mã hoá với kích thước khối cố định hoặc để mang một vài gói RTP trong một đơn vị dữ liệu ở giao thức ở tầng thấp hơn. eXtension (X) : 1 bit. Nếu trường này được đặt thì một header cố định theo sau bởi một header mở rộng. CSRC count (CC) : 4 bits. Số định danh CSRC theo sau bởi header. Số này nhiều hơn một nếu dữ liệu trong gói RTP chứa dữ liệu đến từ nhiều nguồn. Marker (M) : 1 bit. Xác định bởi profile, điểm đánh dấu để cho phép các sự kiện điển hình như biên của frame được đánh dấu trong luồng gói dữ liệu. Payload Type: kiểu dữ liệu tải. Trường này chỉ ra kiểu dữ liệu trong phần dữ liệu tải (payload) của gói tin RTP như dữ liệu video mã hoá theo chuẩn H261 hoặc dữ liệu audio PCM. Người ta đã định nghĩa trước một tập các giá trị PT. Mỗi gói tin RTP chỉ có thể mạng một loại dữ liệu mà thôi. Sequence Number: 16 bits. Tăng một khi mỗi gói dữ liệu RTP được gửi đi, được nơi nhận dùng để phát hiện mất mát gói và khôi phục thứ tự các gói. Giá trị ban đầu của Sequence Number được chọn một cách ngẫu nhiên. Timestamp: đây là mộ trường 32 bit chỉ ra thời điểm lấy mẫu của byte đầu tiên trong phần dữ liệu tải. Giá trị này được tính từ một đồng hồ tăng tuyến tính, đơn trị theo thời gian. Tần số của đồng hồ này phụ thuộc vào kiểu dữ liệu trong gói tin và được xác định cho mọi loại tải (PT) trong các tài liệu đặc tả định dạng thích hợp. Giá trị khởi đầu của đồng hồ cũng được lấy một cách ngẫu nhiên cho mỗi kết nối RTP như đối với trường sequence number. Nhờ đó mà các nhãn thời gian của các kết nối RTP khác nhau là không tương thích với nhau thậm chí ngay cả khi chúng sinh ra từ cùng một nguồn. Nói cách khác, không tồn tại một mối liên kết tương đối nào về thời gian hoặc thứ tự nào trong mô hình đồng bộ mà ta sẽ trình bày ở phần sau. Synchronization Source (SSRC): nguồn đồng bộ. Là một số 32 bit chỉ ra nguồn dữ liệu trong hội thảo. Nguồn dữ liệu ở đây là một thiết bị phần cứng, ví dụ như máy thu video hoặc microphone. Giá trị này được sinh ra một cách ngẫu nhiên và phải là duy nhất trong một phiên RTP. Nếu hai nguồn dữ liệu có cùng SSRC , chúng sẽ tự đồng thoát ra khỏi phiên đó sau đó lại đăng nhập vào phiên để sinh ra một số SSRC khác. Chú ý rằng, đối với các phiên sinh ra từ cùng một nguồn, giá trị SSRC là khác nhau. RTCP (RTP Control) Giao thức điều khiển RTP (RTCP) chủ yếu được dùng để cung cấp phản hồi về chất lượng dịch vụ cho việc theo dõi hội nghị, vì nó mang thông tin về các gói tin nhận được. Nó cũng đồng thời mang thông tin về các thành viên tham gia hội nghị giúp nhận dạng, kiểm soát phiên. Ngoài ra, giao thức này đóng một vai trò quan trọng trong quá trình đồng bộ vì những lí do sau đây: Mọi gói tin RTCP đều có hai trường nhãn thời gian, cả hai trường này đều rất cần thiết cho việc xây dựng lại thời gian gói tin được gửi ở phía nhận. RTCP mang một định danh, gọi là “canonical name” (CNAME) xác định duy nhất một thành viên trong hội nghị. Vì vậy, các kết nối RTP khác nhau xuất phát từ cùng một người tham gia sẽ có giá trị SSRC khác nhau nhưng lại cùng CNAME. Điều này cho phép hai dòng audio và video từ cùng một thành viên của hội nghị được liên kết với nhau, đạt được sự đồng bộ. Các gói tin RTP và RTCP hoạt động trên cùng một giao thức ở tầng giao vận (ví dụ UDP…) nhưng thông thường chúng được truyền trên hai kênh riêng biệt (ví dụ hai cổng UDP khác nhau). Các gói tin RTCP được multicast một cách định kì tới tất cả các thành viên tham gia hội nghị. Vì vậy tất cả các thành viên đều có thể điều khiển trạng thái hội nghị. Đặc tả RTCP đã định nghĩa sẵn một vài kiểu gói tin, tuỳ thuộc vào thông tin chứa trong nó. Mọi nguồn nhận dữ liệu (source) trong hội nghị đều sinh ra các gói tin Receive Report (Báo cáo nhận) mang thông tin về tất cả các thành viên gửi mà nó nhận được từ Receive Report trước. Những thông tin này bao gồm tổng số gói tin bị mất và jitter. Nguồn gửi trong hội nghị cũng sẽ sinh ra một gói tin Sender Report giống như Receive Report nhưng thêm vào 20 byte thông tin về nguồn gửi đó. Đặc biệt các gói tin này đều mang các nhãn thời gian giúp xây dựng lại thời gian tham chiếu tuyệt đối sẽ được nói đến trong phần sau. Một loại khác của gói tin RTCP gọi là SDESC (Source Description) mang các thông tin về một thành viên xác định trong hội nghị như CNAME, tên thật, địa chỉ e-mail của thành viên đó… Cuối cùng, một nguồn khi muốn rời khỏi hội nghị phải gửi đi một gói tin RTCP đặc biệt, gói tin BYE. Sau đây là cấu trúc 20 byte đầu tiên của gói tin Sender Report  0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| RC | PT=SR=200 | length | header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | NTP timestamp, most significant word | sender +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hình 3.2: Phần thông tin người gửi trong Sender Report Nhãn thời gian đầu tiên là một số 64 bit, tuân theo giao thức NTP (Network Time Protocol) chỉ ra khoảng thời gian từ 0h00 ngày 1/1/1900 cho đến thời điểm hiện tại. Trong trường hợp này, 32 bit cao là khoảng thời gian đó tình theo giây, trong khi 32 bit thấp là phần micro giây còn lại đã được chuyển sang dạng số 32 bit. Để có thể sử dụng nó để làm tham chiếu cho thời gian tuyệt đối, giá trị này phải được chuyển sang dạng micro giây bằng cách chia nó cho 232/106. Thao tác này thường được thực hiện bằng phép dịch bit nhị phân để làm giảm độ phức tạp tính toán. Rõ ràng, cách tính này dẫn đên sai số, nhưng ở mức chấp nhận được (nhỏ hơn 0.1%). Nhãn thời gian thứ hai biểu diễn cùng một giá trị nhưng được định dạng theo kiểu nhãn thời gian của gói tin dữ liệu RTP. Cụ thể là nó được tính (từ nhãn thời gian NTP) với cùng giá trị khởi đầu, tần số đồng hồ như trong nhãn thời gian gói tin RTP. Các giá trị này cho phép đồng bộ các dòng audio và video từ cùng một người gửi vì chúng có đồng hồ tham chiếu giống nhau. Các nguồn mã hoá (Audio và Video) Giao thức RTP hỗ trợ hầu hết các định dạng nén đa phương tiện cơ bản. Đồng thời nó cũng có thể được mở rộng cho các định dạng mới bằng cách định nghĩa các mô tả thích hợp. Đối với mỗi một định dạng nén, mô tả này định nghĩa ý nghĩa các trường header, cách tổ chức dữ liệu tải, đặc biệt nó còn định nghĩa tần số đồng hồ và cách tính nhãn thời gian. Đối với: Mã hoá audio: tần số đồng hồ được dùng để sinh ra nhãn thời gian là độc lập với số kênh audio (môn hay stereo) và kiểu nén. Nó bằng tần số lấy mẫu. Ví dụ với mã hóa PCM, tần số lấy mẫu là 8kHz vì vậy nhãn thời gian RTP (không tính đến giá trị khởi đầu) có được bằng cách nhân thời điểm lấy mẫu của mẫu audio đầu tiên trong gói với 8000. Đối với mã hoá video: tần số đồng hồ dùng để tính toán nhãn thời gian được đặt bằng 90kHz. Giá trị này được chọn là do nó thích hợp với các chuẩn đã được dùng phổ biến như PAL, HDTV và NTSC., đồng thời nó cũng cung cấp độ phân giải cần thiết khi so sánh nhãn thời gian RTP với nhãn thời gian NTP trong gói tin Sender Report. Tần số đồng hồ này cũng được đề nghị dùng cho các chuẩn mã hoá trong tương lai thậm chí nếu các chuẩn đó có tốc độ khung hình khác. Các nhãn thời gian trong mã hoá video sẽ có bước nhảy bằng tần số đồng hồ chia cho tốc độ khung hình mong muốn. Trong mã hoá video, tần số đồng hồ được lấy cố định và luôn bằng 90kHz. Từ đó ta có nếu video được truyền với tốc độ khung hình là 30fps thì bước nhảy nhãn thời gian là 3000 cho mỗi khung hình. Vì tốc độ khung hình thay đổi trong quá trình truyền nên nhãn thời gian cũng phải thay đổi theo. Khôi phục tham chiếu thời gian tuyệt đối Vấn đề đồng bộ Như vậy, ta thấy giao thức truyền thông thời gian thực chỉ cho phép một loại dữ liệu tải được truyền đi tại một thời điểm. Do đó mỗi một nguồn dữ liệu sẽ sinh ra một kết nối RTP cho riêng nó. Trong môi trường truyền thông đa phương tiện, ở đây ta xét cụ thể là audio và video, điều này dẫn đến là các dòng video và audio phải truyền trên hai kênh khác nhau ( ví dụ qua hai cổng UDP khác nhau) và được điều khiển bởi hai ứng dụng hoàn toàn riêng biệt. Vấn đề nảy sinh khi ta muốn quan hệ về thời gian giữa các dòng tại phía nhận giống như tại phía gửi (giả sử các dòng đã được đồng bộ tại phía gửi). Do audio và video được truyền bởi hai loại gói tin RTP khác nhau, thao tác giải mã được thực hiện ở hai ứng dụng khác nhau nên sẽ gây ra lỗi đồng bộ intermedia. Trong phần này ta sẽ đưa ra mô hình đồng bộ dựa trên các điểm tham chiếu. Ý tưởng cơ bản của nó là một cách định kì sẽ so sánh nhãn thời gian của các gói tin audio video nhận được tại các điểm được định nghĩa trước (gọi là điểm đồng bộ - sync point). Vấn đề ở đây là các nhãn thời gian của audio và video được mã hoá khác nhau do đó không thể so sánh trực tiếp chúng với nhau. Để giải quyết vấn đề này, ta sẽ dùng một thuật toán kết hợp nhãn thời gian của cả gói tin RTP và RTCP để khôi phục lại thời gian phía gửi ở phía nhận. Nhờ vậy ta sẽ có một thời gian tuyệt đối để có thể so sánh độ lệch về thời gian giữa video và audio. Tại các điểm đồng bộ, độ lệch này sẽ được so sánh với một ngưỡng và dùng để điều khiển quá trình đồng bộ. Thuật toán xây dựng lại thời gian Ở đây để đơn giản trong việc mô tả thuật toán, ta đặt ra một số hạn chế sau đây: dữ liệu truyền là video (trường hợp này là phức tạp hơn so với audio vì các gói tin RTP thuộc cùng một khung hình có cùng giá trị nhãn thời gian) và chỉ truyền unicast giữa hai máy. Ý tưởng của thuật toán là khôi phục thời gian phía gửi từ các gói tin RTCP và thường xuyên cập nhật giá trị này bằng thông tin lấy từ các gói tin RTP. Nó dùng hai thời gian tham chiếu, một là cho đồng hồ tuyệt đối và hai là cho tham chiếu RTP. Để khởi động tiến trình, phía nhận phải chờ gói tin RTCP Sender Report đầu tiên từ phía gửi. Sau đó ta sẽ phân tích hai giá trị nhãn thời gian trong gói tin này. Giá trị thời gian tuyệt đối trong nhãn thời gian NTP được chuyển sang giây và micro giây và được dùng để khởi động đồng hồ thời gian tuyệt đối, trong khi nhãn thời gian RTP tương ứng được dùng để khởi động thời gian tham chiếu RTP. Mỗi khi nhận được một gói tin RTP mới, nhãn thời gian của nó sẽ được đọc và lưu vào bộ nhớ. Sau đó nó được so sánh với thời gian tham chiếu RTP, nếu nhãn thời gian mới này lớn hơn giá trị tham chiếu, ta sẽ tính chênh lệch giữa chúng. Lúc này, nhãn thời gian cuối cùng nhận được trở thành thời gian tham chiếu RTP mới (thay cho giá trị trước đó) và trong bước tiếp theo nó sẽ được sử dụng để tính độ lệch mới khi nhận được gói tin RTP tiếp theo. Có hai lí do để làm như vậy: Phần giá trị khởi đầu ngẫu nhiên được loại bỏ bởi các thao tác giữa các gói tin kế tiếp. Vì vậy việc biết trước giá trị khởi đầu này trước khi truyền là không cần thiết. (Lưu ý rằng nhãn thời gian trong gói tin dữ liệu RTP và nhãn thời gian RTP trong gói tin RTCP có cùng giá trị khởi đầu). Nó cho phép các thao tác chuyển đổi được thực hiện trên những giá trị tương đối nhỏ (ở đây là độ lệch) do đó gảm lỗi lượng tử hoá trong quá trình chuyển đổi. Giá trị chênh lệch này phải đổi sang micro giây với những tham số thích hợp (ví dụ với video ta phải chia 90kHz cho tốc độ khung hình ). Mỗi bước thực hiện đều sinh ra lỗi, nhưng do giá trị được chuyển đổi nhỏ nên sai số cũng là rất nhỏ. Độ lệch này (tính theo micro giây) được cộng vào giá trị tham chiếu thời gian tuyệt đối để cập nhật trạng thái của ứng dụng. Các giá trị nhãn thời gian sử dụng trong thuật toán phải tăng dần để ở bước tiếp theo có thể tính được độ chênh lệch giữa nhãn thời gian cũ và mới đồng thời thay thế cho giá trị tham chiếu RTP cũ. Nếu nhãn thời gian của gói tin RTP nhận được nhỏ hơn giá trị tham chiếu RTP, gói tin đó sẽ bị vứt bỏ và giá trị tham chiếu RTP được giữ nguyên như cũ. Quá trình cứ tiếp tục như trên, đồng hồ tuyệt đối liên tục được cập nhật mỗi khi có một gói tin dữ liệu RTP nhận được và do đó cho ta “hình ảnh“ của đồng hồ phía gửi. Mỗi bước xử lí như trên đều tạo ra một sai số nào đó, thời gian càng dài thì lỗi càng lớn. Chính tại đây, RTCP đóng một vai trò rất quan trọng vì nó được dùng để định kì đồng bộ lại cho thuật toán. Khi nhận đựơc một RTCP Sender Report, nhãn thời gian NTP trong gói tin đó sẽ được dùng để thay cho giá trị thời gian tham chiếu tuyệt đối cũ vì nó chính xác, gần với đồng hồ phía gửi hơn. Nhờ có bước xử lí này, các sai số tích luỹ trước đó được loại bỏ mỗi khi nhận được một gói tin RTCP. Đồng thời, thời gian tham chiếu RTP cũng được thay thế bằng giá trị nhãn thời gian RTP trong Sender Report. Vì việc truyền các gói tin RTP và RTCP là không đồng bộ, nên sẽ xảy ra trường hợp gói tin RTCP được nhận trong khi bộ giải mã đang giải mã các gói tin RTP của một khung hình. Như ta đã biết, các gói tin dữ liệu RTP thuộc cùng một khung hình sẽ có nhãn thời gian giống nhau. Do đó để tránh gây ra lỗi trình diễn, việc thay thế các giá trị tham chiếu thời gian NTP, RTP chỉ xảy ra khi quá trình giải mã khung hình kết thúc. Đây là trường hợp chỉ xảy ra đối với việc truyền video mà không bao giờ xảy ra đối với dữ liệu audio. Bằng cách này ta có thể xây dựng, mô phỏng được thời gian phía gửi ở phía nhận mà không phụ thuộc vào kiểu dữ liệu tải. Nhận được gói tin RTP Đọc nhãn thời gian Thực hiện tính diff=ts_RTP – ref_ts Thay thế ref_ts mới bằng ts_RTP Chuyển diff thành giây và micro giây Tăng giá trị đồng hồ tuyệt đối Thay thế các giá trị tham chiếu cũ bằng các nhãn thời gian trong RTCP Sender Report ts_RTP > ref_ts Bộ giải mã đang làm việc trên một frame Gói tin RTCP mới N Y Y N N Hình 3.3: Thuật toán xây dựng lại thời gian Hình trên mô tả các bước của thuật toán xây dựng thời gian phía gửi sau bước khởi đầu (nhận được gói tin RTCP đầu tiên). Giá trị ref_ts là thời gian tham chiếu RTP (nó có thể là nhãn thời gian của gói tin dữ liệu RTP hoặc RTCP tuỳ thuộc vào thời điểm xét), trong khi ts_RTP là nhãn thời gian của gói tin dữ liệu RTP. Sơ đồ này là cho trường hợp phức tạp, dữ liệu truyền là video. Nếu dữ liệu là audio ta không cần xem xét đến thời điểm thay thế các giá trị tham chiếu. Gọi thời gian tuyệt đối lấy từ gói tin RTCP (đã được biến đổi một cách thích hợp) là ts_NTP trong khi giá trị tương ứng ở định dạng RTP của nó là media_ts. ts_RTPi là nhãn thời gian của gói tin dữ liệu thứ i. Sau quá trình khởi đầu , thời gian tuyệt đối là: t0 = ts_NTP (3.1.1) Độ lệch đầu tiên được tính dùng nhãn thời gian RTP trong gói tin RTCP để làm tham chiếu ∆ts1 = ts_RTP1 – media_ts (3.1.2) Đồng hồ tuyệt đối sau khi gói tin dữ liệu RTP đầu tiên nhận được là: t1 = t0 + (3.1.3) Tc là thời gian lấy mẫu cho kiểu dữ liệu tải trong gói tin RTP đó. Khi gói tin RTP tiếp theo nhận được, thời gian tham chiếu RTP cũ được thay thế bằng ts_RTP1 và thời gian tuyệt đối là: ∆ts2 = ts_RTP2 – ts_RTP1 (3.1.4) t2 = t0 + (3.1.5) Khi gói tin dữ liệu thứ N nhận được ∆tsj – ts_RTPj – ts_RTPj-1 (3.1.6) tN = t1 + (3.1.7) Quá trình này cứ tiếp tục cho đến khi nhận được một gói tin điều khiển RTCP mới.Lúc này, các nhãn thời gian của nó (ts_NTP và media_ts) sẽ được dùng để khởi động lại các giá trị tham chiếu và thuật toán xây dựng lại thời gian tuyệt đối lại bắt đầu lại như trên. Có thể thấy rằng việc khôi phục thời gian tuyệt đối không phụ thuộc vào trễ jitter của mạng vì nó chỉ đơn giản là đọc các nhãn thời gian từ các gói tin nhận được mà thôi. Thuật toán này cũng không nhạy cảm với việc mất gói. Trong trường hợp mất gói, ảnh hưởng của nó sẽ tồn tại cho tời khi nhận được gói tin RTCP tiếp theo. Phục hồi đồng bộ Với thuật toán trên, ta có thể so sánh được các thời gian tham chiếu gi