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

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI Viện Công nghệ thông tin truyền thông Xử lý liệu đa phương tiện ĐỀ TÀI: Các kỹ thuật đồng Audio – Video thời gian thực dùng giao thức RTP Nhóm sinh viên thực hiện: Nguyễn Đức Hậu 20124977 Hà Văn Cầu 20124970 Trần Quang Đạt 20124974 Lưu Việt Tùng 20159550 Giảng viên hướng dẫn: PGS.TS Nguyễn Thị Hoàng Lan Các kỹ thuật đồng Audio – Video thời gian thực Hà Nội, 5-2016 Phân công công việc Page | Các kỹ thuật đồng Audio – Video thời gian thực MỤC LỤC Page | 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 (Real-time Transport Control Protocol) Page | 10 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 | 11 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 Page | 12 Các kỹ thuật đồng Audio – Video thời gian thực mã hoá khác so sánh trực tiếp chúng với Để giải 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 | 13 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 Nhận gói tin RTP Đọc nhãn thời gian Thực tính diff=ts_RTP – ref_ts Page | 14 Các kỹ thuật đồng Audio – Video thời gian thực Thay ref_ts mớibằng ts_RTP Chuyển diff thành giây micro giây Tăng giá trị đồng hồ tuyệt đối Thay giá trị tham chiếu cũ nhãn thời gian RTCP Sender Report ts_RTP > ref_ts Bộ giải mã làm việc frame Gói tin RTCP N Y Y N 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à: 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 Page | 15 Các kỹ thuật đồng Audio – Video thời gian thực ∆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 Để đư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: Page | 16 Các kỹ thuật đồng Audio – Video thời gian thực • 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 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 Page | 17 Các kỹ thuật đồng Audio – Video thời gian thực 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 IV Xây dựng ứng dụng thử nghiệm Bài toán đặt cho trình thử nghiệm - Bài toán : Gọi video call từ máy 201 sang máy 202, bắt phân tích gói tin - Yêu cầu đặt :Bắt phân tích gói tin, gói tin tìm phân tích trường thể tính giúp đồng audio –video truyền tải thời gian thực Công cụ sử dụng - Máy chủ Asterisk cài Centos6.7 - Máy có cài cấu hình Xlite - Phần mềm yahoo phục vụ cho trình gọi audio video - WIRESHARK bắt phân tích gói tin Thực nghiệm asterisk Page | 18 Các kỹ thuật đồng Audio – Video thời gian thực Mô hình đặt : Thực nghiệm: Máy cài Xlite kết nối qua tổng đài asterisk thực gọi audio video Kết bắt phân tích gói tin: Ở nhằm mục đích đồng ta quan tâm đến trường : - Time stamp (nhãn thời gian, 32 bits): (của gói tin RTP )Phản ánh thời điểm lấy mẫu octet gói RTP Thời điểm lấy từ đồng hồ tăng đặn tuyến tính theo thời gian phép việc đồng tính toán độ jitter Tần số đồng hồ không cố định, tuỳ thuộc vào loại tải trọng Giá trị khởi đầu chọn ngẫu nhiên “Tem thời gian” thành phần thông tin quan trọng ứng dụng thời gian thực Người gửi thiết lập “tem thời gian” thời điểm octet gói lấy mẫu “Tem thời gian” tăng dần theo thời gian gói Sau nhận gói liệu, bên thu sử dụng “tem thời gian” nhằm khôi phục thời gian gốc để chạy liệu với tốc độ thích hợp Ngoài ra, sử dụng để đồng dòng liệu khác (chẳng hạn hình tiếng) Page | 19 Các kỹ thuật đồng Audio – Video thời gian thực - Gói tin SR ( sender report ) RTCP : Mục đích thông báo người gửi, tạo người gửi, chứa thông tin nhằm đồng gói tin: Trong gói tin SR ta quan tâm đến trường sau: NTP time stamp Nhãn thời gian Giao thức thời gian mạng máy tính NTP(Network Time Protocol timestamp), có độ dài 64 bít, thời gian tuyệt đối thông báo gửi RTP Time stamp tương ứng thời điểm NTP time stamp Page | 20 Các kỹ thuật đồng Audio – Video thời gian thực Ngoài giúp việc đồng nguồn khác nhau, ta quan tâm đến định danh Cname, SSRC Synchronization Source Identifier (SSRC, 32 bits): nguồn đồng gói RTP, số chọn ngẫu nhiên Trong phiên RTP có nhiều nguồn đồng Mỗi nguồn phát luồng RTP Bên thu nhóm gói nguồn đồng lại với để phát lại tín hiệu thời gian thực Page | 21 Các kỹ thuật đồng Audio – Video thời gian thực RTCP mang thông tin định danh lớp vận chuyển gọi CNAME (canonical name) Thông tin giúp ta định danh nguồn phát RTP(tương ứng với thành viên tham gia hội thảo) Trong phiên truyền RTP, giá trị SSRC Page | 22 Các kỹ thuật đồng Audio – Video thời gian thực phía phát thay đổi gây xung đột đòi hỏi thiết lập lại kết nối Do phía nhận cần sử dụng CNAME để trì kết nối tới thành viên Ngoài ra, việc CNAME xác định thành viên, giúp cho bên nhận phân chia luồng tin nhận thành tập tương ứng với người gởi Ví dụ, xác định cặp tín hiệu video/audieo người gởi (vì luồng có định danh SSRC khác nhau) Điều giúp cho việc đồng tín hiệu audio với tín hiệu video RTCP cung cấp thông tin nhận dạng nguồn cụ thể dạng văn Nó bao gồm tên người sử dụng, số điện thoại, địa e-mail thông tin khác V Kết luận Trong báo cáo nhóm thực nêu tổng quan mô hình đồng vấn đề xử lý đa phương tiện Đồng thời nhóm tìm hiểu, trình bày số phương pháp đồng audio-video thời gian thực phương pháp đồng dựa việc xây dựng thời gian tham chiếu tuyệt đối phương pháp đồng thích nghi Và cuối nhóm khảo sát, so sánh số ứng dụng đồng audio-video thời gian thực môi trường Asterisk Trong trình tìm hiểu nhóm chúng em gặp nhiều khó khăn nguồn tài liệu nghiên cứu nên chắn không tránh khỏi thiếu sót, hạn chế Vì chúng em mong nhận xét, đóng góp ý kiến cô Cuối chúng em xin chân thành cảm ơn PGS.TS Nguyễn Thị Hoàng Lan tận tình giúp đỡ chúng em để nhóm hoàn thành nghiên cứu thú vị Page | 23 Các kỹ thuật đồng Audio – Video thời gian thực VI Tài liệu tham khảo Slide xử lý liệu đa phương tiện – PSG.TS Nguyễn Thị Hoàng Lan, ĐHBKHN http://en.wikipedia.org/wiki/Real-time_Transport_Protocol http://www.ietf.org/rfc/rfc3550.txt A Realtime Software Solution for Resynchronizing Filtered MPEG2 Transport Stream - Bin Yu, Klara Nahrstedt, Department of Computer Science, University of Illinois at Urbana-Champaign A Guide to MPEG Fundamentals and Protocol Analysis – Tektronix Company The MPEG Representation of Digital Media – Editor Leonardo Chiariglione, CEDEO, Via Borgionera103, 10040 Villar Dora, Italy Page | 24 [...].. .Các kỹ thuật đồng bộ Audio – Video thời gian thực II Đồng bộ Audio – Video theo dòng Audio tại nơi nhận Trong kỹ thuật truyền video, âm thanh hình ảnh được truyền theo 2 dòng khác nhau(tốc độ 2 dòng dữ liệu có bản chất và yêu cầu hoàn toàn khác nhau), cần phải xác lập đồng bộ audio- video tại nơi nhận để đảm bảo thời gian thực Hiện nay có 2 kỹ thuật đồng bộ audio- video thời gian thực đó là: Đồng bộ. .. 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 Page | 12 Các kỹ thuật đồng bộ Audio – Video thời gian thự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à... +160 ms và -160 ms đến -80 ms Nguyên tắc đồng bộ theo dòng Audio Page | 11 Các kỹ thuật đồng bộ Audio – Video thời gian thực - III Độ trễ biến thiên “jilter” là sự khác nhau tức thời về thời gian trễ các dòng audio – video Độ lệch “skew” là độ lệch về thời gian giữa 2 dòng audio và video Độ trễ điểm đầu cuối “end-to-end delay” được định nghĩa là toàn bộ thời gian trễ từ khi âm thanh, hình ảnh được hình... tham chiếu Đồng bộ thích nghi - Cả 2 phương pháp trên đều đồng bộ dòng Audio tại nơi nhận, chúng ta cùng tìm hiểu về cách thức đồng bộ tại nơi nhận Giải pháp đồng bộ loại bỏ frame: Dòng dữ liệu audio có vai trò là chủ, dòng video được đồng bộ theo dòng audio Tại các điểm đồng bộ: Nhãn thời gian của gói tin của dòng video được so sánh với nhãn thời gian của gói tin dòng audio Nếu một frame video bị trễ... quan tâm đến các trường cơ bản như sau: NTP time stamp Nhãn thời gian của Giao thức thời gian mạng máy tính NTP(Network Time Protocol timestamp), có độ dài 64 bít, chỉ ra thời gian tuyệt đối khi thông báo được gửi RTP Time stamp tương ứng thời điểm NTP time stamp Page | 20 Các kỹ thuật đồng bộ Audio – Video thời gian thực Ngoài ra giúp việc đồng bộ giữa các nguồn khác nhau, ta quan tâm đến các định danh... hai Page | 17 Các kỹ thuật đồng bộ Audio – Video thời gian thực 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 giải... 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, ... Page | 14 Các kỹ thuật đồng bộ Audio – Video thời gian thực Thay thế ref_ts mớibằ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. .. Synchronization Source Identifier (SSRC, 32 bits): chỉ ra nguồn đồng bộ của gói RTP, số này được chọn ngẫu nhiên Trong 1 phiên RTP có thể có nhiều hơn một nguồn đồng bộ Mỗi một nguồn phát ra một luồng RTP Bên thu nhóm các gói của cùng một nguồn đồng bộ lại với nhau để phát lại tín hiệu thời gian thực Page | 21 Các kỹ thuật đồng bộ Audio – Video thời gian thực RTCP mang một thông tin định danh ở lớp vận chuyển... trong các gói tin tìm và phân tích các trường thể hiện được tính năng giúp đồng bộ audio video truyền tải thời gian thực 2 Công cụ sử dụng - Máy chủ Asterisk được cài trên Centos6.7 - 2 Máy có cài và cấu hình Xlite - Phần mềm yahoo phục vụ cho quá trình gọi audio và video - WIRESHARK bắt và phân tích gói tin 3 Thực nghiệm trên asterisk Page | 18 Các kỹ thuật đồng bộ Audio – Video thời gian thực Mô