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 RTP

MỤC LỤC


Các kỹ thuật đồng bộ Audio – Video thời gian thự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.

Page | 2


Các kỹ thuật đồng bộ Audio – Video thời gian thực
Đồ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ộ
Page | 3


Các kỹ thuật đồng bộ Audio – Video thời gian thực
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).

Page | 4


Các kỹ thuật đồng bộ Audio – Video thời gian thực

Đ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.
Page | 5


Các kỹ thuật đồng bộ Audio – Video thời gian thực

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
 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ó duy trì
Tích hợp các dữ liệu phụ thuộc phải sử dụng thêm timers
Khó sử dụng hệ thống phân cấp

3. Các vấn đề xử lý thời gian thực

Đa phương tiện thời gian thực được dùng để chỉ các ứng dụng trong đó dữ
liệu đa phương tiện được gửi đi và tái tạo lại trong thời gian thực.Nó có thể chia
Page | 6

Các kỹ thuật đồng bộ Audio – Video thời gian thực
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
Page | 7


Các kỹ thuật đồng bộ Audio – Video thời gian thực
triển.Các giao thức đó là:RTP (Real-time Transport Protocol) và RTCP (Realtime Transport Control Protocol)

Page | 8


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ộ 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
Page | 9

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

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
Page | 10


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

Page | 12


Các kỹ thuật đồng bộ Audio – Video thời gian thực

Nhận được gói tin RTP
Đọc 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 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à:
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 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 +

∆ts1
Tc

(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

t2 = t0 +

∆ts1 ∆ts 2
+
TC
TC

(3.1.4)

(3.1.5)

Khi gói tin dữ liệu thứ N nhận được
∆tsj – ts_RTPj – ts_RTPj-1
N

∆ts j

j =2

Tc

∑
tN = t1 +

(3.1.6)

(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.
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 tác với nhau như thế nào. Nói cách khác, ứng nào sẽ điều khiển
quá trình đồng bộ. Ta có các mô hình sau đây:
• Mô hình đối xứng (symetric model): trong đó ứng dụng video và audio có độ ưu

tiên như nhau đối với kết quả đồng bộ. Mô hình này đòi hỏi phải có một trọng
tài (referee) để điều khiển hai ứng dụng đó, tránh xung đột.
• Mô hình chủ tớ (1) được điều khiển bởi ứng dụng audio. Trong trường hợp này,

ứng dụng audio sẽ gửi thông điệp đồng bộ đến ứng dụng video và nó sẽ phải
căn cứ vào thông tin trong thông điệp này để điều chỉnh, phục hồi lại sự đồng
bộ như ở phía gửi. Trong mô hình này, tiến trình điều khiển đồng bộ được tích
hợp trong ứng dụng “tớ” (slave) và được điều khiển bởi ứng dụng “chủ”
(master) do đó làm độ phức tạp tăng lên, đặc biệt là ở ứng dụng tớ.

• Mô hình chủ tớ (2): tương tự như mô hình ở trên song được điều khiển bởi ứng

dụng video.
Việc lựa chọn mô hình sử dụng trong ba mô hình trên dựa trên kết quả quan
sát đơn giản. Trong môi trường hội nghị đa phương tiện , phần quan trọng nhất
của thông điệp là chứa trong dòng audio (lời nói) trong khi dòng video chr có ý
nghĩa cho thấy hình ảnh của thành viên đang nói trong hội nghị mà thôi. Vì
vậy, các lỗi trong dòng audio sẽ gây cảm giác khó chịu đối với người sử dụng
hơn.Hơn thê nữa, hình ảnh tĩnh của thành viên đang nói có thể được sử dụng
trong trường hợp dòng video bị ngắt quãng mà không ảnh hưởng nhiều lắm
đến nội dung của hội nghị. Do đó, mô hình chủ tớ (3) thường được sử dụng
hơn.

Cơ chế đồng bộ
Như vậy, bằng thuật toán xây dựng thời gian tham chiếu tuyệt đối, ta đã
khôi phục được thời gian gửi gói tin ở phía nhận. Tại các điểm đồng bộ, thời
gian này của hai dòng audio và video sẽ được so sánh với nhau. Chức năng này
thường được thực hiện bởi một thành phần riêng, 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 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 giải mã bình thường trong khi bộ quản lí
đồng bộ sẽ dừng ứng dụng video lại trong khoảng thời gian bằng với độ lệch
để phục hồi đồng bộ. Nói cách khác bộ giải mã video phải đợi audio. Trong
trường hợp ứng dụng video là chủ, audio phải tăng tốc độ giải mã để bắt kip
với tốc độ video.
• Giá trị tuyệt đối của độ lệch lớn hơn Neg_Threshold: audio đến trước video.

Như trong trường hợp trước, nếu ứng dụng audio là chủ, nó sẽ giải mã bình
thường trog khi ứng dụng video sẽ phải tăng tốc của nó lên. Trong trường hợp
ứng dụng video là chủ, bộ giải mã audio sẽ phải đợi video.
Trong phương pháp đồng bộ này, việc chon giá trị ngưỡng thích hợp là hết
sức quan trọng.

Page | 16