Các kỹ thuật đồng bộ audio video thời gian thực dùng giao thức RTP

ĐỀ TÀI: Các kỹ thuật đồng bộ Audio – Video thời gian thực dùng giao thức RTPMỤC LỤCI.Tổng quan về mô hình đồng bộ và các vấn đề xử lý thời gian thực41.Tổng quan về đồng bộ đa phương tiện42.Các mô hình đồng bộ62.1.Mô hình dòng thời gian (Timeline) :62.2.Mô hình điểm tham chiếu (Reference Point)62.3.Mô hình dựa trên sự kiện (Event Based)8II.Đồng bộ Audio – Video theo dòng Audio tại nơi nhận.11III.Thuật toán đồng bộ Audio –Video theo điểm tham chiếu121.Vấn đề đồng bộ122.Thuật toán xây dựng lại thời gian133.Phục hồi đồng bộ17IV.Xây dựng ứng dụng và thử nghiệm181.Bài toán đặt ra cho quá trình thử nghiệm182.Công cụ sử dụng193.Thực nghiệm trên asterisk19V.Kết luận23VI.Tài liệu tham khảo24 I.Tổng quan về mô hình đồng bộ và các vấn đề xử lý thời gian thực1.Tổng quan về đồng bộ đa phương tiện Dữ liệu đa phương tiện cần được hiểu là nhiều loại dữ liệu sẽ được thu thập, gửi đi và hiển thị một cách đồng thời. Có rất nhiều loại dữ liệu: đơn giản nhất là dữ liệu văn bản và các dạng dữ liệu khác như ảnh đồ họa, âm thanh, video . . . Nguồn dữ liệu đa phương tiện gồm 2 loại là : •Nguồn thông tin trực tiếp : Các tín hiệu vật lý được thu nhận,số hóa và truyền đi ngay tới nơi nhận mà không qua lưu trữ trung gian.•Nguồn thông tin được tái tạo hay tổng hợp : Các đối tượng media khác nhau được tổng hợp vốn được lưu ở các thiết bị lưu trữ.Chúng có thể có nguồn gốc “tự nhiên” do capture như ở trên, cũng có thể hoàn toàn là dạng nhân tạo như hoạt hình. Dựa vào đặc điểm của các loại dữ liệu mà có các dạng đồng bộ:Đồng bộ liên tục: là đồng bộ bám liên tục theo thời gian.Đồng bộ đa phương tiện: thiết lập lại quan hệ thời gian giữa các gói dữ liệu audio – video để trình diễn liên tục ,cảm thụ trung thực tại nơi nhận so với nguồn.Đồng bộ điểm: đồng bộ các khối dữ liệu tại các thời điểmĐồng bộ trong một dòng dữ liệu phương tiện (Intramedia Synchronization): xác lập lại quan hệ thời gian giữa các sự kiện trong một dòng dữ liệu của phương tiện, đơn luồng.

ĐỀ TÀI: Các kỹ thuật đồng Audio – Video thời gian thực dùng giao thức RTP MỤC LỤC Các kỹ thuật đồng Audio – Video thời gian thực I Tổng quan mô hình đồng vấn đề xử lý thời gian thực Tổng quan đồng đa phương tiện Dữ liệu đa phương tiện cần hiểu nhiều loại liệu thu thập, gửi hiển thị cách đồng thời Có nhiều loại liệu: đơn giản liệu văn dạng liệu khác ảnh đồ họa, âm thanh, video Nguồn liệu đa phương tiện gồm loại : Nguồn thông tin trực tiếp : Các tín hiệu vật lý thu nhận,số hóa truyền tới nơi nhận mà không qua lưu trữ trung gian • Nguồn thông tin tái tạo hay tổng hợp : Các đối tượng media khác tổng hợp vốn lưu thiết bị lưu trữ.Chúng có nguồn gốc “tự nhiên” capture trên, hoàn toàn dạng nhân tạo hoạt hình • Dựa vào đặc điểm loại liệu mà có dạng đồng bộ:  Đồng liên tục: đồng bám liên tục theo thời gian  Đồng đa phương tiện: thiết lập lại quan hệ thời gian gói liệu audio – video để trình diễn liên tục ,cảm thụ trung thực nơi nhận so với nguồn  Đồng điểm: đồng khối liệu thời điểm  Đồng dòng liệu phương tiện (Intramedia Synchronization): xác lập lại quan hệ thời gian kiện dòng liệu phương tiện, đơn luồng  Đồng dòng (Intermedia Synchronization): xác lập lại mối quan hệ thời gian dòng liệu phương tiện Page | Các kỹ thuật đồng Audio – Video thời gian thực Đồng hóa hỗ trợ nhiều thành phần hệ thống hệ thống tính toán, hệ thống truyền thông, sở liệu, documents … Do đó, đồng hóa phải xem xét nhiều mức hệ thống đa phương tiện Hệ thống tính toán tầng truyền thông thấp xử lý đối tượng tránh độ trễ rung (jitter) dòng phương tiện suốt trình trình diễn đơn vị dòng phương tiện Đồng hóa dòng đa phương tiện hỗ trợ run-time để hạn chế độ lệch thời gian dòng phương tiện (skew) hỗ trợ cho đồng hóa liệu phụ thuộc thời gian với liệu không phụ thuộc thời gian để xử lý tốt tương tác người dùng Mục tiêu để bắt đầu ngừng dòng liệu không phụ thuộc thời gian khoảng thời gian chấp nhận được, đạt tới điểm trình trình diễn liệu không phụ thuộc thời gian Các mô hình đồng Page | Các kỹ thuật đồng Audio – Video thời gian thực Vấn đề trình diễn liệu đồng bộ, tương tác người dùng, thiết bị vật lý để thiết lập lại quan hệ thời gian thỏa mãn ràng buộc thời gian thực Dưới mô hình để trình diễn đồng hóa đa phương tiện 2.1 Mô hình dòng thời gian (Timeline) : Các hành động xác định thời điểm bắt đầu, thực đồng bám theo thời gian tồn đối tượng Sử dụng dòng thời gian tổng thể.Đồng bám liên tục theo dòng thời gian nên yêu cầu càn phải có đồng đồng hồ Ưu điểm :  Cho chất lượng cao  Dễ dàng để trì đối tượng độc lập với  Dễ hiểu Nhược điểm :  Yêu cầu chi phí cao 2.2 Mô hình điểm tham chiếu (Reference Point) Các thời điểm tham chiếu hay điểm đồng xác định bên thời gian tồn đối tượng đa phương tiện, thời điểm thực đồng thời gian dòng liệu đa phương tiện để trình diễn (player) Dùng nhãn thời gian đánh dấu bên đối tượng thời điểm cần đồng Các liệu phụ thuộc thời gian phương tiện xem chuỗi LDU (Logic Data Unit) Page | Các kỹ thuật đồng Audio – Video thời gian thực Điểm tham chiếu: thời điểm bắt đầu, thời điểm kết thúc trình trình diễn liệu thời điểm bắt đầu đơn vị liệu phụ thuộc thời gian Điểm đồng tập điểm tham chiếu kết nối, xác định đồng dòng liệu đa phương tiện để trình diễn Ưu điểm :      Dễ hiểu Mô tả tự nhiên quan hệ thời gian Dễ tích hợp LDU mở Dễ tích hợp liệu phụ thuộc thời gian Trục thời gian trường hợp đặc biệt mô hình điểm tham chiếu Nhược điểm : o Đôi phân cấp phức tạp Page | Các kỹ thuật đồng Audio – Video thời gian thực 2.3 Mô hình dựa kiện (Event Based) Đồng dựa kiện : - Bắt đầu đối tượng - Kết thúc đối tượng Việc bắt đầu hay kết thúc kiện kích hoạt hành động Ưu điểm :  Dễ tích hợp đối tượng tương tác  Dễ dàng mở rộng kiện  Linh hoạt Nhược điểm : o o o o o Không dễ dàng xử lý Đặc điểm kỹ thuật phức tạp Khó trì Tích hợp liệu phụ thuộc phải sử dụng thêm timers Khó sử dụng hệ thống phân cấp Các vấn đề xử lý thời gian thực Đa phương tiện thời gian thực dùng để ứng dụng liệu đa phương tiện gửi tái tạo lại thời gian thực.Nó chia Page | Các kỹ thuật đồng Audio – Video thời gian thực thành loại đa phương tiện tương tác đa phương tiện truyền thông trực tuyến Ngày với tiến phương tiện truyền thông kỹ thuật số công nghệ mạng, đa phương tiện trở thành tính thiếu Internet Hoạt hình, âm video clip ngày phổ biến.Dữ liệu đa phương tiện, không giống liệu truyền thống,nó có đặc trưng riêng Trước tiên, ứng dụng đa phương tiện thường đòi hỏi băng thông cao nhiều so với ứng dụng truyền thống văn bản.Khoảng 25 giây clip với độ phân giải 320*240 2,3 MB,tương đương với khoảng 1000 hình liệu dạng văn bản.Thứ hai,hầu hết ứng dụng đa phương tiện có quy định nghiêm ngặt chậm trễ.Thứ ba,các dòng liệu dễ bị phân đoạn đường truyền.Đối với ứng dụng đa phương tiện,người nhận có đệm giới hạn.Khi liệu đến nhanh, đệm bị tràn số gói liệu bị mất, kết chất lượng kém.Khi liệu đến chậm,bộ đệm tràn dưới,bộ đệm đủ liệu để tái tạo lại….Do đảm bảo thời gian thực ứng dụng khác khác nhau.Sẽ có cân chậm trễ chất lượng tùy theo dịch vụ(QoS) Trong đa phương tiện tương tác,sự chậm trễ nghiêm ngặt để đạt tính tương tác.Ví dụ, điện thoại Internet, người chịu độ trễ khoảng 250 mili giây Điều đặt vấn đề khó khăn cho ứng dụng đa phương tiện tương tác qua Internet.Giải pháp đưa cố gắng cung cấp dịch vụ tốt (best- effort) Đa phương tiện truyền thông trực tuyến coi dòng thời gian thực liên tục.Dữ liệu truyền ứng dụng máy chủ tái tạo lại thời gian thực ứng dụng client Các ứng dụng client bắt đầu phát lại âm video đủ liệu nhận lưu trữ đệm máy thu.Sự chậm trễ lên đến vài giây, nghĩa chậm trễ sever bắt đầu truyền liệu client bắt đầu phát lại Để hỗ trợ vấn đề xử lý thời gian thực cho loại đa phương tiện tương tác truyền thông trực tuyến giao thức real-time đời phát Page | Các kỹ thuật đồng Audio – Video thời gian thực triển.Các giao thức là:RTP (Real-time Transport Protocol) RTCP (Realtime Transport Control Protocol) Page | Các kỹ thuật đồng Audio – Video thời gian thực II Đồng Audio – Video theo dòng Audio nơi nhận Trong kỹ thuật truyền video, âm hình ảnh truyền theo dòng khác nhau(tốc độ dòng liệu có chất yêu cầu hoàn toàn khác nhau), cần phải xác lập đồng audio-video nơi nhận để đảm bảo thời gian thực Hiện có kỹ thuật đồng audio-video thời gian thực là: Đồng theo dòng aidio điểm tham chiếu Đồng thích nghi - Cả phương pháp đồng dòng Audio nơi nhận, tìm hiểu cách thức đồng nơi nhận Giải pháp đồng loại bỏ frame: Dòng liệu audio có vai trò chủ, dòng video đồng theo dòng audio Tại điểm đồng bộ: Nhãn thời gian gói tin dòng video so sánh với nhãn thời gian gói tin dòng audio Nếu frame video bị trễ giới hạn bị loại bỏ Dòng liệu audio có vai trò chủ (principle jet), dòng video (slave jet) đồng theo dòng audio Nguyên nhân dòng audio chọn làm dòng chủ dựa vào nghiên cứu sinh học đôi tai mắt người Đôi tai người nhạy cảm với thay đổi nhỏ âm Trong mắt lại nhạy cảm hơn, điển hình tượng lưu ảnh võng mạc Do vậy, dòng audio chọn làm dòng chủ dòng audio có tốc độ thấp nhiều so với dòng video - Không thể so sánh nhãn trực tiếp  giải pháp khôi phục đồng hồ nơi gửi nơi nhận dựa nhãn thời gian  thực tính toán điểm tham chiếu - -     Cảm thụ độ lệch audio video: Vùng đồng (in synchronization): độ lệch cho phép từ -80 ms đến +80 ms Vùng đồng (out synchronization): độ lệch từ -160 ms đến +160 ms Vùng trung gian (transient): độ lệch khoảng +80 ms đến +160 ms -160 ms đến -80 ms Nguyên tắc đồng theo dòng Audio Page | Các kỹ thuật đồng Audio – Video thời gian thực - III Độ trễ biến thiên “jilter” khác tức thời thời gian trễ dòng audio – video Độ lệch “skew” độ lệch thời gian dòng audio video Độ trễ điểm đầu cuối “end-to-end delay” định nghĩa toàn thời gian trễ từ âm thanh, hình ảnh hình thành điểm nguồn, truyền qua mạng đến điểm đích thể Thuật toán đồng Audio –Video theo điểm tham chiếu Vấn đề đồng Ta thấy giao thức truyền thông thời gian thực cho phép loại liệu tải truyền thời điểm Do nguồn liệu sinh kết nối RTP cho riêng Trong môi trường truyền thông đa phương tiện, ta xét cụ thể audio video, điều dẫn đến dòng video audio phải truyền hai kênh khác ( ví dụ qua hai cổng UDP khác nhau) điều khiển hai ứng dụng hoàn toàn riêng biệt Vấn đề nảy sinh ta muốn quan hệ thời gian dòng phía nhận giống phía gửi (giả sử dòng đồng phía gửi) Do audio video truyền hai loại gói tin RTP khác nhau, thao tác giải mã thực hai ứng dụng khác nên gây lỗi đồng intermedia Trong phần ta đưa mô hình đồng dựa điểm tham chiếu Ý tưởng cách định kì so sánh nhãn thời gian gói tin audio video nhận điểm định nghĩa trước (gọi điểm đồng - sync point) Vấn đề nhãn thời gian audio video mã hoá khác so sánh trực tiếp chúng với Để giải Page | 10 Các kỹ thuật đồng Audio – Video thời gian thực vấn đề này, ta dùng thuật toán kết hợp nhãn thời gian gói tin RTP RTCP để khôi phục lại thời gian phía gửi phía nhận Nhờ ta có thời gian tuyệt đối để so sánh độ lệch thời gian video audio Tại điểm đồng bộ, độ lệch so sánh với ngưỡng dùng để điều khiển trình đồng Thuật toán xây dựng lại thời gian Ở để đơn giản việc mô tả thuật toán, ta đặt số hạn chế sau đây: liệu truyền video (trường hợp phức tạp so với audio gói tin RTP thuộc khung hình có giá trị nhãn thời gian) truyền unicast hai máy Ý tưởng thuật toán khôi phục thời gian phía gửi từ gói tin RTCP thường xuyên cập nhật giá trị thông tin lấy từ gói tin RTP Nó dùng hai thời gian tham chiếu, cho đồng hồ tuyệt đối hai 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 từ phía gửi Sau ta phân tích hai giá trị nhãn thời gian gói tin Giá trị thời gian tuyệt đối nhãn thời gian NTP chuyển sang giây micro giây dùng để khởi động đồng hồ thời gian tuyệt đối, nhãn thời gian RTP tương ứng dùng để khởi động thời gian tham chiếu RTP Mỗi nhận gói tin RTP mới, nhãn thời gian đọc lưu vào nhớ Sau so sánh với thời gian tham chiếu RTP, nhãn thời gian lớn giá trị tham chiếu, ta tính chênh lệch chúng Lúc này, nhãn thời gian cuối nhận trở thành thời gian tham chiếu RTP (thay cho giá trị trước đó) bước sử dụng để tính độ lệch nhận gói tin RTP Có hai lí để làm vậy: • Phần giá trị khởi đầu ngẫu nhiên loại bỏ thao tác gói tin Vì việc biết trước giá trị khởi đầu trước truyền không cần thiết (Lưu ý nhãn thời gian gói tin liệu RTP nhãn thời gian RTP gói tin RTCP có giá trị khởi đầu) • Nó cho phép thao tác chuyển đổi thực giá trị tương đối nhỏ (ở độ lệch) gảm lỗi lượng tử hoá trình chuyển đổi Giá trị chênh lệch phải đổi sang micro giây với 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 Page | 11 Các kỹ thuật đồng Audio – Video thời gian thực thực sinh lỗi, giá trị chuyển đổi nhỏ nên sai số nhỏ Độ lệch (tính theo micro giây) cộng vào giá trị tham chiếu thời gian tuyệt đối để cập nhật trạng thái ứng dụng Các giá trị nhãn thời gian sử dụng thuật toán phải tăng dần để bước tính độ chênh lệch nhãn thời gian cũ đồng thời thay cho giá trị tham chiếu RTP cũ Nếu nhãn thời gian gói tin RTP nhận nhỏ giá trị tham chiếu RTP, gói tin bị vứt bỏ giá trị tham chiếu RTP giữ nguyên cũ Quá trình tiếp tục trên, đồng hồ tuyệt đối liên tục cập nhật có gói tin liệu RTP nhận cho ta “hình ảnh“ đồng hồ phía gửi Mỗi bước xử lí tạo sai số đó, thời gian dài lỗi lớn Chính đây, RTCP đóng vai trò quan trọng dùng để định kì đồng lại cho thuật toán Khi nhận đựơc RTCP Sender Report, nhãn thời gian NTP gói tin dùng để thay cho giá trị thời gian tham chiếu tuyệt đối cũ xác, gần với đồng hồ phía gửi Nhờ có bước xử lí này, sai số tích luỹ trước loại bỏ nhận gói tin RTCP Đồng thời, thời gian tham chiếu RTP thay giá trị nhãn thời gian RTP Sender Report Vì việc truyền gói tin RTP RTCP không đồng bộ, nên xảy trường hợp gói tin RTCP nhận giải mã giải mã gói tin RTP khung hình Như ta biết, gói tin liệu RTP thuộc khung hình có nhãn thời gian giống Do để tránh gây lỗi trình diễn, việc thay giá trị tham chiếu thời gian NTP, RTP xảy trình giải mã khung hình kết thúc Đây trường hợp xảy việc truyền video mà không xảy liệu audio Bằng cách ta xây dựng, mô thời gian phía gửi phía nhận mà không phụ thuộc vào kiểu liệu tải Page | 12 Các kỹ thuật đồng Audio – Video thời gian thực Nhận gói tin RTP Đọc nhãn thời gian Thay giá trị tham chiếu cũ nhãn thời gian RTCP Sende N Y ts_RTP > ref_ts Thực tính diff=ts_RTP – ref_ts Thay ref_ts mớibằng ts_RTP Bộ giải mã làm việc frame N Chuyển diff thành giây micro giây Y Tăng giá trị đồng hồ tuyệt đối Gói tin RTCP N Hình 3.3: Thuật toán xây dựng lại thời gian Hình mô tả bước thuật toán xây dựng thời gian phía gửi sau bước khởi đầu (nhận gói tin RTCP đầu tiên) Giá trị ref_ts thời gian tham chiếu RTP (nó nhãn thời gian gói tin liệu RTP RTCP tuỳ thuộc vào thời điểm xét), ts_RTP nhãn thời gian gói tin liệu RTP Sơ đồ cho trường hợp phức tạp, liệu truyền video Nếu liệu audio ta không cần xem xét đến thời điểm thay giá trị tham chiếu Gọi thời gian tuyệt đối lấy từ gói tin RTCP (đã biến đổi cách thích hợp) ts_NTP giá trị tương ứng định dạng RTP media_ts ts_RTPi nhãn thời gian gói tin liệu thứ i Sau trình khởi đầu , thời gian tuyệt đối là: Page | 13 Các kỹ thuật đồng Audio – Video thời gian thực t0 = ts_NTP (3.1.1) Độ lệch tính dùng nhãn thời gian RTP gói tin RTCP để làm tham chiếu ∆ts1 = ts_RTP1 – media_ts (3.1.2) Đồng hồ tuyệt đối sau gói tin liệu RTP nhận là: t1 = t0 + ∆ts1 Tc (3.1.3) Tc thời gian lấy mẫu cho kiểu liệu tải gói tin RTP Khi gói tin RTP nhận được, thời gian tham chiếu RTP cũ thay ts_RTP1 thời gian tuyệt đối là: ∆ts2 = ts_RTP2 – ts_RTP1 t2 = t0 + ∆ts1 ∆ts + TC TC (3.1.4) (3.1.5) Khi gói tin liệu thứ N nhận ∆tsj – ts_RTPj – ts_RTPj-1 N ∆ts j j =2 Tc ∑ tN = t1 + (3.1.6) (3.1.7) Quá trình tiếp tục nhận gói tin điều khiển RTCP mới.Lúc này, nhãn thời gian (ts_NTP media_ts) dùng để khởi động lại giá trị tham chiếu thuật toán xây dựng lại thời gian tuyệt đối lại bắt đầu lại Có thể thấy việc khôi phục thời gian tuyệt đối không phụ thuộc vào trễ jitter mạng đơn giản đọc nhãn thời gian từ gói tin nhận mà Thuật toán không nhạy cảm với việc gói Trong trường hợp gói, ảnh hưởng tồn cho tời nhận gói tin RTCP Phục hồi đồng Mô hình đồng Page | 14 Các kỹ thuật đồng Audio – Video thời gian thực Để đưa thủ tục đồng hoàn chỉnh, ta cần phải xem ứng dụng tương tác với Nói cách khác, ứng điều khiển trình đồng Ta có mô hình sau đây: • Mô hình đối xứng (symetric model): ứng dụng video audio có độ ưu tiên kết đồng Mô hình đòi hỏi phải có trọng tài (referee) để điều khiển hai ứng dụng đó, tránh xung đột • Mô hình chủ tớ (1) điều khiển ứng dụng audio Trong trường hợp này, ứng dụng audio gửi thông điệp đồng đến ứng dụng video phải vào thông tin thông điệp để điều chỉnh, phục hồi lại đồng phía gửi Trong mô hình này, tiến trình điều khiển đồng tích hợp ứng dụng “tớ” (slave) điều khiển ứng dụng “chủ” (master) làm độ phức tạp tăng lên, đặc biệt ứng dụng tớ • Mô hình chủ tớ (2): tương tự mô hình song điều khiển ứng dụng video Việc lựa chọn mô hình sử dụng ba mô hình dựa kết quan sát đơn giản Trong môi trường hội nghị đa phương tiện , phần quan trọng thông điệp chứa dòng audio (lời nói) dòng video chr có ý nghĩa cho thấy hình ảnh thành viên nói hội nghị mà Vì vậy, lỗi dòng audio gây cảm giác khó chịu người sử dụng hơn.Hơn thê nữa, hình ảnh tĩnh thành viên nói sử dụng trường hợp dòng video bị ngắt quãng mà không ảnh hưởng nhiều đến nội dung hội nghị Do đó, mô hình chủ tớ (3) thường sử dụng Cơ chế đồng Như vậy, thuật toán xây dựng thời gian tham chiếu tuyệt đối, ta khôi phục thời gian gửi gói tin phía nhận Tại điểm đồng bộ, thời gian hai dòng audio video so sánh với Chức thường thực thành phần riêng, gọi quản lí đồng (sync manager) Trong thành phần này, điều quan trọng phải thiết lập Page | 15 Các kỹ thuật đồng Audio – Video thời gian thực giá trị ngưỡng (threshold) thích hợp Trong trường hợp có audio video ta cần hai giá trị Neg_Threshold cho trường hợp audio đến trước video Pos_Threshold cho trường hợp video đến trước audio, hai giá trị khác Bộ quản lí đồng so sánh độ lệch thời gian tuyệt đối hai dòng thời điểm đồng với giá trị ngưỡng vào có thao tác thích hợp • Nếu độ lệch nằm ngưỡng: hai dòng xem đồng Trong trường hợp này, không cần thực thêm thao tác • Nếu độ lệch lớn Pos_Threshold: video đến trước audio Nếu ứng dụng audio chủ, gói tin audio giải mã bình thường quản lí đồng dừng ứng dụng video lại khoảng thời gian với độ lệch để phục hồi đồng Nói cách khác giải mã video phải đợi audio Trong trường hợp ứng dụng video chủ, audio phải tăng tốc độ giải mã để bắt kip với tốc độ video • Giá trị tuyệt đối độ lệch lớn Neg_Threshold: audio đến trước video Như trường hợp trước, ứng dụng audio chủ, giải mã bình thường trog ứng dụng video phải tăng tốc lên Trong trường hợp ứng dụng video chủ, giải mã audio phải đợi video Trong phương pháp đồng này, việc chon giá trị ngưỡng thích hợp quan trọng Page | 16 [...].. .Các kỹ thuật đồng bộ Audio – Video thời gian thực 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ộ 2 Thuật. .. 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à: Page | 13 Các kỹ thuật đồng bộ Audio – Video thời gian thực 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... 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 3 Phục hồi đồng bộ Mô hình đồng bộ Page | 14 Các kỹ thuật đồng bộ Audio – Video thời gian thực Để có thể đưa ra thủ tục đồng bộ hoàn chỉnh, ta cũng cần phải xem các ứng dụng tương... 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... gọi là bộ quản lí đồng bộ (sync manager) Trong thành phần này, điều quan trọng là phải thiết lập được Page | 15 Các kỹ thuật đồng bộ Audio – Video thời gian thực các giá trị ngưỡng (threshold) thích hợp Trong trường hợp chỉ có audio và video ta cần hai giá trị Neg_Threshold cho trường hợp audio đến trước video và Pos_Threshold cho trường hợp video đến trước audio, hai giá trị này có thể khác nhau Bộ quản... 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 Page | 12 Các kỹ thuật đồng bộ Audio – Video thời gian thực Nhận được gói tin RTP. .. đượ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... nhãn thời gian Thay thế các giá trị tham chiếu cũ bằng các nhãn thời gian trong RTCP Sende N Y ts _RTP > ref_ts Thực hiện tính diff=ts _RTP – ref_ts Thay thế ref_ts mớibằng ts _RTP Bộ giải mã đang làm việc trên một frame N Chuyển diff thành giây và micro giây Y Tăng giá trị đồng hồ tuyệt đối Gói tin RTCP mới 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. .. hợp (ví dụ với video ta phải chia 90kHz cho tốc độ khung hình ) Mỗi bước Page | 11 Các kỹ thuật đồng bộ Audio – Video thời gian thự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... Bộ quản lí đồng bộ sẽ so sánh độ lệch thời gian tuyệt đối giữa hai dòng tại các thời điểm đồng bộ với các giá trị ngưỡng và căn cứ vào đó có những thao tác thích hợp • Nếu độ lệch nằm giữa các ngưỡng: hai dòng được xem như là đồng bộ Trong trường hợp này, không cần thực hiện thêm thao tác gì • Nếu độ lệch lớn hơn Pos_Threshold: video đến trước audio Nếu ứng dụng audio là chủ, các gói tin audio được