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

 Đồ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

Viện Công nghệ thông tin và truyền thông

Xử lý dữ liệu đa phương tiện

ĐỀ TÀI: Các kỹ thuật đồng bộ Audio – Video thời gian

thực dùng giao thức RTP

Nhóm sinh viên thực hiện:

1 Nguyễn Đức Hậu 20124977

2 Hà Văn Cầu 20124970

3 Trần Quang Đạt 20124974

4 Lưu Việt Tùng 20159550

Giảng viên hướng dẫn: PGS.TS Nguyễn Thị Hoàng Lan

Hà Nội, 5-2016

Phân công công việc

MỤC LỤC

I. Tổng quan về mô hình đồng bộ và các vấn đề xử lý thời gian thực

1. 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

 Đồng bộ giữa các dòng (Intermedia Synchronization): xác lập lại mối quan hệ thời gian giữa các dòng dữ liệu phương tiện

Đồng bộ hóa được hỗ trợ bởi nhiều thành phần hệ thống như hệ thống tính toán,

hệ thống truyền thông, cơ sở dữ liệu, documents … Do đó, đồng bộ hóa phải được xem xét ở nhiều mức trong hệ thống đa phương tiện

Hệ thống tính toán và các tầng truyền thông thấp hơn xử lý các đối tượng tránh

độ trễ rung (jitter) trong một dòng phương tiện trong suốt quá trình trình diễn của các đơn vị của một dòng phương tiện

Đồng bộ hóa các dòng đa phương tiện được hỗ trợ run-time để hạn chế độ lệch

về thời gian giữa các dòng phương tiện (skew) và hỗ trợ cho đồng bộ hóa giữa các

dữ liệu phụ thuộc thời gian với dữ liệu không phụ thuộc thời gian để xử lý tốt các tương tác người dùng Mục tiêu là để bắt đầu hoặc ngừng dòng dữ liệu không phụ thuộc thời gian trong khoảng thời gian chấp nhận được, nếu đạt tới một điểm nào

đó trong quá trình trình diễn của dữ liệu không phụ thuộc thời gian

2. Các mô hình đồng bộ

Vấn đề của sự trình diễn các dữ liệu đồng bộ, tương tác người dùng, và các thiết bị vật lý để thiết lập lại quan hệ thời gian thỏa mãn dưới ràng buộc thời gian thực Dưới đây là các mô hình để trình diễn đồng bộ hóa đa phương tiện.

2.1. Mô hình dòng thời gian (Timeline) :

Các hành động được xác định bởi thời điểm bắt đầu, thực hiện đồng bộ bám theo thời gian tồn tại của đối tượng

Sử dụng 1 dòng thời gian tổng thể.Đồng bộ bám liên tục theo dòng thời gian nên yêu cầu càn phải có đồng bộ đồng hồ

Ưu điểm :

 Cho chất lượng cao

 Dễ dàng để duy trì vì các đối tượng độc lập với nhau

 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 bộ được xác định bên trong thời gian tồn tại của đối tượng đa phương tiện, tại thời điểm đó thực hiện đồng bộ thời gian giữa các dòng dữ liệu đa phương tiện để trình diễn (player)

Dùng nhãn thời gian đánh dấu bên trong các đối tượng tại các thời điểm cần đồng bộ

Các dữ liệu phụ thuộc thời gian trong một phương tiện được xem như là chuỗi các LDU (Logic Data Unit)

Điểm tham chiếu: là thời điểm bắt đầu, thời điểm kết thúc của quá trình trình diễn của dữ liệu hoặc các thời điểm bắt đầu của các đơn vị con của dữ liệu phụ thuộc thời gian.

Điểm đồng bộ là tập các điểm tham chiếu kết nối, xác định đồng bộ giữa các dòng dữ 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 các LDU mở

 Dễ tích hợp các dữ liệu phụ thuộc thời gian

 Trục thời gian là trường hợp đặc biệt của mô hình điểm tham chiếu

Nhược điểm :

o Đôi khi phân cấp phức tạp

2.3. Mô hình dựa trên sự kiện (Event Based)

Đồng bộ dựa trên các sự kiện :

- Bắt đầu của 1 đối tượng

- Kết thúc của 1 đối tượng

Việc bắt đầu hay kết thúc 1 sự kiện sẽ kích hoạt hành động tiếp theo

Ưu điểm :

 Dễ tích hợp các đối tượng tương tác

 Dễ dàng mở rộng bởi các sự kiện mới

thành 2 loại là đa phương tiện tương tác và đa phương tiện truyền thông trực tuyến.

Ngày nay với sự tiến bộ của phương tiện truyền thông kỹ thuật số và công nghệ mạng, đa phương tiện đã trở thành một tính năng không thể thiếu trên Internet Hoạt hình, âm thanh và video clip ngày càng phổ biến.Dữ liệu đa phương tiện, không giống như các dữ liệu truyền thống,nó có các đặc trưng riêng Trước tiên, các ứng dụng đa phương tiện thường đòi hỏi băng thông cao hơn nhiều so với các ứng dụng truyền thống như văn bản.Khoảng 25 giây clip với độ phân giải 320*240 có thể mất 2,3 MB,tương đương với khoảng 1000 màn hình dữ liệu dạng văn bản.Thứ hai,hầu hết các ứng dụng đa phương tiện có quy định nghiêm ngặt về sự chậm trễ.Thứ ba,các dòng dữ liệu dễ bị phân đoạn trên đường truyền.Đối với các ứng dụng đa phương tiện,người nhận có 1 bộ đệm giới hạn.Khi dữ liệu đến quá nhanh, các bộ đệm sẽ bị tràn và một số gói dữ liệu sẽ bị mất, kết quả là chất lượng kém.Khi dữ liệu đến quá chậm,bộ đệm sẽ tràn dưới,bộ đệm sẽ không có đủ dữ liệu để tái tạo lại….Do đó sự đảm bảo thời gian thực trong các ứng dụng khác nhau là khác nhau.Sẽ có sự cân bằng trong sự chậm trễ

và 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ễ là rất nghiêm ngặt để đạt được tính tương tác.Ví dụ, trong điện thoại Internet, con người chỉ có thể chịu được một độ trễ của khoảng 250 mili giây Điều này đặt ra một vấn đề cực kỳ khó khăn cho các ứng dụng đa phương tiện tương tác qua Internet.Giải pháp được đưa ra là

cố gắng cung cấp dịch vụ tốt nhất có thể (best- effort)

Đa phương tiện truyền thông trực tuyến được coi như 1 dòng thời gian thực liên tục.Dữ liệu được truyền bởi một ứng dụng máy chủ và được tái tạo lại trong thời gian thực bởi các ứng dụng client Các ứng dụng trên client có thể bắt đầu phát lại âm thanh và video ngay khi đủ dữ liệu đã được nhận và được lưu trữ trong bộ đệm của máy thu.Sự chậm trễ có thể lên đến vài giây, nghĩa là sự chậm trễ khi sever bắt đầu truyền dữ liệu và khi client bắt đầu phát lại

Để hỗ trợ về vấn đề xử lý thời gian thực cho cả 2 loại đa phương tiện tương tác và truyền thông trực tuyến các giao thức real-time đã được ra đời và phát

triển.Các giao thức đó là:RTP (Real-time Transport Protocol) và RTCP (Real-time Transport Control Protocol)

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ộ theo dòng aidio tại điểm 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ễ quá giới hạn sẽ bị loại bỏ

- Dòng dữ liệu audio có vai trò là chủ (principle jet), dòng video (slave jet) được đồng bộ theo dòng audio Nguyên nhân dòng audio được chọn làm dòng chủ dựa vào nghiên cứu sinh học về đôi tai và mắt của con người Đôi tai của con người rất nhạy cảm với sự thay đổi nhỏ của âm thanh Trong khi mắt lại kém nhạy cảm hơn, điển hình là hiện tượng lưu ảnh võng mạc Do vậy, dòng audio được chọn làm dòng chủ mặc dù dòng audio có tốc độ thấp hơn nhiều so với dòng video

- Không thể so sánh 2 nhãn này trực tiếp  giải pháp khôi phục đồng hồ nơi gửi tại nơi nhận dựa trên các nhãn thời gian  thực hiện tính toán điểm tham chiếu

 Cảm thụ độ lệch giữa audio và video:

 Vùng đồng bộ (in synchronization): độ lệch cho phép từ -80 ms đến +80 ms

 Vùng mất đồng bộ (out synchronization): độ lệch từ -160 ms đến +160 ms

 Vùng trung gian (transient): độ lệch khoảng +80 ms đến +160 ms và -160 ms đến -80 ms

Nguyên tắc đồng bộ theo dòng Audio

- Độ 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 thành ở điểm nguồn, được truyền qua mạng đến điểm đích thể hiện

III. Thuật toán đồng bộ Audio –Video theo điểm tham chiếu

1. Vấn đề đồng bộ

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ộ

2. 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

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ớ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

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