PCM (Pulse Code Modulation)
Tín hiệu tương tự được lấy mẫu ở tần số cố định, ví dụ: 8000 mẫu/giây. Giá trị của mỗi mẫu là một số thực.
Mỗi mẫu được làm tròn tới một số trong tập các giá trị định trước. Thao tác này được gọi là lượng tử hóa. Số lượng các số trong tập các giá trị hữu hạn gọi là các giá trị lượng tử, thường là lũy thừa của 2, ví dụ: 256 (2^8).
Mỗi giá trị lượng tử được biểu diễn bằng một số lượng cố định các bít. Mỗi giá trị mẫu được chuyển thành dãy bít (1 byte nếu có 256 giá trị lượng tử). Các biểu diễn bít này được chuyển thành dạng biểu diễn số của tín hiệu và được truyền đi.
Bình thường, quá trình lượng tử hóa gồm 2 bước: Lượng tử hóa tuyến tính 13 hay 14 bít, rồi nén theo logarit xuống 8 bít.
Nén 13 bít xuống 8 bít là biến đổi A-Law được sử dụng ở Châu Âu, nén 14 bít xuống 8 bít là biến đổi M-Law được sử dụng ở Bắc Mỹ và Nhật Bản.
Chúng ta xét một ví dụ: Nếu một tín hiệu audio tương tự được lấy mẫu ở tần số 8000 mẫu/giây, mỗi mẫu được lượng tử và được biểu diễn bởi 8 bít. Khi đó tín hiệu số sẽ có tốc độ bít là 64000 bít/giây. Tín hiệu số này có thể được chuyển trở lại thành tín hiệu tương tự để chạy. Tuy nhiên, tín hiệu analog được khôi phục từ tín hiệu số thường khác với tín hiệu ban đầu. Bằng cách tăng tần số lấy mẫu và số lượng các giá trị lượng tử, có thể làm cho tín hiệu được giải mã giống tín hiệu tương tự ban đầu hơn (thậm chí giống hệt - ở một mức nào đó). Do vậy, rõ ràng có một sự tương ứng giữa chất lượng của tín hiệu được giải mã với yêu cầu bộ nhớ lưu trữ và băng thông để truyền tín hiệu số. Mã hóa tiếng nói thường dùng PCM, với tốc độ lấy mẫu khoảng 8000 mẫu/giây, và 8 bít/mẫu cho ta tốc độ là 64Kbps. Đĩa CD audio cũng dùng phương pháp PCM với tốc độ lấy mẫu 44100 mẫu/giây và 16 bít/mẫu cho tốc độ 705.6Kbps ứng với âm thanh mono và 1.411Mbps ứng với âm thành stereo.
DPCM (Differential PCM)
Theo phương pháp này, các mẫu được so sánh với nhau, sau đó không mã hóa toàn bộ mẫu mà chỉ mã hóa sự khác nhau giữa các mẫu.
Sử dụng cơ chế đoán dựa trên các mẫu trước để giảm tốc độ bít (mã hóa sự khác nhau giữa mẫu đoán và mẫu thực tế - 4 bít/mẫu).
Theo phương pháp này, khi thời gian tăng lên, tỉ lệ lỗi giữa tín hiệu giải mã và tín hiệu mã hóa sẽ tăng, do đó theo định kì, một mẫu đầy đủ sẽ được mã hóa.
ADPCM (Adaptive DPCM)
Dùng chiến lược đoán sự khác nhau giữa các xung theo kiểu thích nghi.
Cung cấp chất lượng âm thanh như PCM, tốc độ bít là 32Bbps.
LPC (Linear Predictive Coding)
Cho âm thanh chất lượng tốt, tốc độ bít là 1.2-2.4Kbps. LPC mô hình hóa tiếng nói như một nguồn được truyền qua bộ lọc.
CELP (Code Excited Linear Predictor)
Sử dụng mô hình như LPC, nhưng có thêm nhiều thông tin về nguồn âm thanh.
Một bảng mã các vector nguồn có tại phía gửi và phía nhận
Nguồn phát sẽ tìm từ bảng mã trên phần phù hợp nhất với âm thanh vào và gửi đi.
GSM
Sử dụng mô hình tương tự LPC, chi phí tính toán thấp hơn CELP và thích hợp cho hệ thống điện thoại di động.
Tốc độ bít là 13Kbps.
MP3
Tốc độ bít là 128Kbps hoặc 112Kbps. Cho âm thanh chất lượng CD.
Chuẩn nén rất phức tạp, sử dụng cơ chế giảm thiểu sự dư thừa…
Lƣợc đồ mã hóa Băng thông (Kbps)
Chất lƣợng âm thanh
PCM 64 Âm thanh chất lượng điện thoại
ADPCM 32 Âm thanh chất lượng điện thoại
GSM 13 Âm thanh chất lượng điện thoại
CELP 4-9 Âm thanh chất lượng điện thoại
LPC 2 Âm thanh chất lượng rô bốt
MP3 128 Âm thanh chất lượng CD
Bảng 2.1. So sánh các lược đồ mã hóa âm thanh 2.5.2. Nén video
Video là một dãy tuần tự các hình ảnh, mỗi hình ảnh được hiển thị với tốc độ không đổi ví dụ 24 hoặc 30 hình/giây. Một ảnh không được nén gồm một mảng các pixel, mỗi pixel được mã hóa thành một số bít để biểu diễn màu và độ sáng. Có 2 kiểu dư thừa thông tin trong hình ảnh video, các cơ chế nén video đều dựa trên những điều này. Dư thừa về mặt không gian là dư thừa trong một ảnh cụ thể. Ví dụ: Một ảnh gồm hầu hết khoảng trống có thể được nén một cách hiệu quả. Dư thừa về mặt thời gian là sự lặp lại ảnh trong ảnh tiếp theo. Ví dụ: Một ảnh và ảnh tiếp theo giống nhau, không có lý do gì để mã hóa lại hình ảnh tiếp theo đó. Sau đây sẽ là giới thiệu ngắn gọn về chuẩn nén video MPEG [19].
MPEG (Motion Picture Engineering Group) là một chuẩn công nghiệp cho việc nén và truyền audio/video. Hiện tại có 3 chuẩn đã được công bố liên quan tới nén video là: MPEG1, MPEG2, MPEG4. Chuẩn mới nhất là MPEG4 đang ở phiên bản 2 và đang được tiếp tục phát triển. Có 2 chuẩn khác là MPEG7 (mô tả nội dung đa phương tiện, metadata) và MPEG21 (mô tả framework cho
đa phương tiện) không đóng vai trò quan trọng trong ứng dụng Video Conference. Bảng sau đây tổng kết các định dạng và đặc điểm của MPEG.
MPEG1 MPEG2 MPEG4
Độ phân giải 352x240 720x480 720x480
Băng thông chuẩn 1.5Mbps 5Mbps 2Mbps
Băng thông cực đại 2.5Mbps 15Mbps 4Mbps Bảng 2.2. Bảng so sánh các chuẩn MPEG
Ban đầu, MPEG1 là một chuẩn được thiết kế để nén khoảng 30 phút audio/video vào trong một đĩa CD. Nó nén và giải nén khá nhanh nhưng chất lượng video thì không được tốt. Tốc độ mã hóa từ 1Mbps tới 1.5Mbps. Chuẩn H.263 được sử dụng trong các hệ thống H.323 cung cấp chất lượng hình ảnh tốt hơn với băng thông thấp hơn. MPEG1 không được sử dụng trong các hệ thống Video Conference.
MPEG2 là lược đồ nén video được sử dụng phổ biến. Rất nhiều sản phẩm sử dụng chuẩn này, cung cấp hình ảnh chất lượng tốt. Chuẩn này được phát triển cho ứng dụng quảng cáo đồng thời cũng được sử dụng trong các môi trường tương tác như Video Confernce. MPEG2 là chuẩn rất phức tạp gồm nhiều độ phân giải và định dạng khác nhau.
Vào năm 1999, MPEG4 là một chuẩn mới ra đời. Giống như MPEG2, nó cung cấp một miền tốc độ từ tốc độ thấp (sử dụng trong truyền thông không dây) cho tới tốc độ cao. Với t ốc độ thấp nó có thể thay thế MPEG2 (nén tốt hơn nhưng chất lượng không đổi). MPEG1 cho chất lượng video CDROM (1.5Mbps), MPEG2 cho chất lượng video DVD (3-6Mbps) và MPEG4 cho nén video hướng đối tượng.
2.6. Giao thức RTP (Real-Time Trasport Protocol)
2.6.1. Giới thiệu về RTP
RTP là giao thức giao vận thời gian thực chạy trên UDP. RTP được sử dụng trong các ứng dụng truyền thông đa phương tiện thời gian thực để truyền dữ liệu đa phương tiện. Các đoạn audio/video được tạo bởi phía gửi của ứng dụng đa phương tiện, được phía gửi chèn header vào và được đóng gói trong gói tin RTP. Các trường quan trọng trong header như: Kiểu mã hóa, trường số thứ tự, trường nhãn thời gian và các trường khác. Mỗi gói RTP lại được đóng gói vào trong gói UDP và được truyền đi. RTP cung cấp dịch vụ cho các ứng dụng đa phương tiện, nó được xem như là lớp con của tầng giao vận [2].
Hình 2.6. RTP có thể được xem như là một thành phần của tầng giao vận Trên cách nhìn của người phát triển ứng dụng, RTP không phải là phần của tầng giao vận mà là của tầng ứng dụng, đó là vì người phát triển phải tích hợp RTP vào ứng dụng. Tại phía gửi của ứng dụng, nhà phát triển phải viết code để đóng gói tin RTP, rồi gửi nó tới giao diện socket UDP. Tương tự phía nhận, gói tin RTP khi qua giao diện socket UDP, người phát triển viết code để đọc các đoạn dữ liệu đa phương tiện từ gói tin RTP.
Hình 2.7. RTP cũng có thể được xem như là một phần của tầng ứng dụng Chúng ta cần lưu ý rằng, RTP không cung cấp các cơ chế đảm bảo phân phối gói tin đúng thời gian hay cơ chế đảm bảo chất lượng dịch vụ khác. Các dịch vụ mà RTP cung cấp là đóng gói gói tin RTP trong header của gói tin có các trường quan trọng như: Kiểu mã hóa, số thứ tự, nhãn thời gian để từ đó các ứng dụng bên trên có các cơ chế làm tăng chất lượng dịch vụ của ứng dụng. Việc đóng gói RTP được thực hiện ở các hệ thống cuối, không phải ở các router trung gian. Router không phân biệt được gói tin IP chứa gói RTP và gói tin IP không chứa gói RTP.
Trong một phiên Video Conference giữa 2 người, 4 luồng RTP được mở: 2 luồng cho truyền âm thanh (theo 2 hướng, mỗi hướng một luồng), 2 luồng truyền video (theo 2 hướng, mỗi hướng một luồng). Nếu kết hợp cả audio và video vào 1 luồng (như chuẩn MPEG1, MPEG2) thì chỉ cần 2 luồng RTP (mỗi hướng một luồng).
Gói tin RTP không chỉ được truyền unicast, nó có thể được gửi theo cơ chế multicast theo kiểu một-nhiều, nhiều-nhiều.
2.6.2. Các trường trong header của gói RTP
Hình 2.8. Các trường trong header của gói tin RTP
Trƣờng Playload Type
Dài 7 bít, xác định kiểu mã hóa audio/video được sử dụng trong phiên RTP. Do đó RTP hỗ trợ 128 kiểu mã hóa. Với luồng audio, trường playload type dùng để xác định kiểu mã hóa audio (chẳng hạn: PCM, GSM,…) được sử dụng. Nếu phía gửi quyết định thay đổi kiểu mã hóa trong một phiên, phía gửi có thể thông báo cho phía nhận sự thay đổi qua trường này. Phía gửi muốn thay đổi kiểu mã hóa để tăng chất lượng audio hoặc để giảm tốc độ bít của luồng gói tin RTP. Sau đây là một số kiểu mã hóa được dùng trong RTP để mã hóa audio.
Mã payload type
Kiểu mã hóa audio
Tần số lấy mẫu Băng thông
0 PCM mu-law 8KHz 64Kbps 1 1016 8KHz 4.8Kbps 3 GSM 8KHz 13Kbps 7 LPC 8KHz 2.4Kbps 9 G.722 8KHz 48-64Kbps 14 MPEG Audio 90KHz - 15 G.728 8KHz 16Kbps
Bảng 3.3. Một số kiểu mã hóa audio được RTP hỗ trợ
Các giá trị của trường “Payload type” chỉ kiểu mã hóa dữ liệu video được dùng để xác định kiểu mã hóa video (chẳng hạn: JPEG, MPEG1, MPEG2, H231). Phía gửi cũng có thể thay đổi kiểu mã hóa trong một phiên.
Mã payload type Kiểu mã hóa video
26 Motion JPEG
31 H.261
32 MPEG1 Video
33 MPEG2 Video
Bảng 2.4. Một số kiểu mã hóa video trong RTP
Trƣờng số thứ tự
Trường này có độ dài 16 bit. Số thứ tự tăng lên 1 sau khi mỗi gói RTP được gửi đi, nó có thể được phía nhận dùng để phát hiện mất gói tin và khôi phục lại gói tin. Ví dụ: Nếu phía nhận nhận được các gói RTP có khoảng trống giữa số 86 và 89 thì sẽ biết được rằng gói thứ 87, 88 bị mất và nó cố gắng khôi phục lại dữ liệu mất.
Trƣờng nhãn thời gian
Dài 32 bít. Nó xác định thời điểm lấy mẫu của byte đầu tiên trong dữ liệu gói RTP. Phía nhận dùng nhãn thời gian để loại bỏ jitter. Nhãn thời gian được lấy từ đồng hồ lấy mẫu ở phía gửi. Ví dụ: Nhãn thời gian tăng lên 1 sau mỗi chu kì lấy mẫu.
Trƣờng số định danh nguồn phát SSRC
Trường này dài 32 bit. Nó xác định nguồn của luồng RTP. Mỗi luồng trong một phiên RTP có một số SSRC phân biệt. SSRC không phải là địa chỉ IP của phía gửi mà là một số mà phía nguồn gán ngẫu nhiên khi một luồng mới bắt đầu. Khả năng 2 luồng được gán cùng số SSRC là rất nhỏ.
2.7. RTCP-Giao thức điều khiển RTP (RTP Control Protocol)
RTCP được dùng cùng với RTP, đặc biệt khi truyền muilticast từ một hoặc nhiều người gửi tới nhiều người nhận. Gói RTCP được truyền trong một phiên RTP từ một người tới tất cả những người khác trong phiên đó. Gói RTCP được truyền tới tất cả những người tham gia dùng địa chỉ IP multicast. Với một phiên RTP, có một địa chỉ multicast và tất cả các gói RTP, RTCP dùng địa chỉ này. Các gói RTP và RTCP được gửi qua các số cổng khác nhau [2].
Hình 2.9. Sử dụng RTCP cùng RTP
RTCP không đóng gói các đoạn audio/video. Nó được gửi theo định kì và chứa các báo cáo về phía gửi, hoặc phía nhận cho biết những số liệu thống kê trạng thái của phía gửi hoặc phía nhận. Những số liệu thống kê này gồm: Số gói tin được gửi, số gói tin mất, jitter,… Đặc tả RTP không cho biết ứng dụng làm gì với những thông tin này. Người phát triển ứng dụng có thể quyết định việc xử lý các thông tin này. Phía gửi có thể dùng thông tin này để thay đổi tốc độ truyền,… Sau đây là các loại gói tin trong giao thức RTCP.
Gói tin mô tả việc nhận
Với mỗi luồng RTP mà phía nhận nhận được, phía nhận sẽ tạo ra một báo cáo. Phía nhận sẽ gộp các báo cáo này vào một gói RTCP. Gói tin này được gửi multicast tới tất cả mọi bên tham gia phiên RTP. Các báo cáo được tạo ra gồm các trường, trong đó có các trường quan trọng gồm:
Số SSRC của luồng RTP mà báo cáo được tạo ra
Tỉ lệ gói tin bị mất trong luồng RTP. Phía nhận sẽ tính số gói tin RTP bị mất chia cho số gói tin được gửi. Nếu phía gửi nhận được báo cáo cho biết phía nhận chỉ nhận được một phần nhỏ của các gói tin được truyền, nó sẽ chuyển sang tốc độ mã hóa thấp hơn chẳng hạn.
Số thứ tự cuối cùng nhận được trong luồng gói tin RTP.
Thời gian lệch trung bình giữa các gói tin được nhận thành công tại phía nhận.
Gói tin mô tả phía gửi
Với mỗi trường RTP truyền đi, phía gửi tạo các gói tin mô tả phía gửi. Các gói tin này chứa các thông tin về luồng RTP bao gồm:
Số SSRC của luồng RTP.
Nhãn thời gian và thời gian thực của gói RTP cuối cùng được tạo trong luồng gói tin.
Số byte đã được gửi trong luồng gói tin.
Các gói tin mô tả phía gửi được sử dụng để đồng bộ hóa các luồng dữ liệu đa phương tiện khác nhau trong cùng một phiên RTP. Xét một ví dụ: Một ứng dụng Video Conference trong đó bên gửi tạo ra 2 luồng gói tin RTP độc lập: Một luồng audio, một luồng video. Các nhãn thời gian trong các gói RTP được tính theo đồng hồ lấy mẫu chứ không theo thời gian thực tế. Mỗi gói tin RTP kiểu gói tin mô tả phía gửi được gán nhãn thời gian và thời gian thực của gói tin gần nhất được tạo ra ở phía gửi. Do đó các gói tin mô tả phía gửi sẽ tạo ra một liên hệ giữa thời gian lấy mấu với thời gian thực. Phía nhận có thể dùng các thông số này để đồng bộ việc thực hiện chạy audio và video.
Gói tin mô tả nguồn
Với mỗi luồng gói tin RTP mà phía gửi truyền đi, phía gửi cũng tạo và truyền đi các gói mô tả nguồn. Những gói này chứa thông tin về nguồn gửi như: Địa chỉ email của phía gửi, tên người gửi và ứng dụng tạo ra luồng gói tin RTP, số SSRC của luồng RTP. Những gói tin này cung cấp một ánh xạ giữa định danh nguồn với tên người dùng hoặc tên máy chạy ứng dụng.
Chia sẻ băng thông trong RTCP
Xét ví dụ một phiên RTP gồm có 1 bên gửi và một số lượng lớn bên nhận. Nếu mỗi người nhận theo định kì tạo các gói RTCP, thì băng thông tổng hợp của các gói tin RTCP có thể lớn hơn nhiều so với băng thông của các gói RTP gửi bởi bên gửi. Lưu lượng RTP được gửi multicast, không thay đổi khi lượng người nhận tăng trong khi lưu lượng truyền RTCP tăng tuyến tính với số người nhận. Do đó cần phải giới hạn băng thông cho các gói tin RTCP.
Các gói tin RTCP bị hạn chế băng thông, chỉ được phép chiếm tới khoảng 5% băng thông của phiên ứng dụng. Ví dụ: Giả sử có một bên gửi, gửi video với tốc độ 2Mbps. RTCP sẽ giới hạn băng thông dành cho mình tối đa là 5%*2Mbps