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 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 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 = 100Mbps. 75% của băng thông dành cho RTCP = 75%*100Kbps = 75Kbps được chia đều cho những người nhận, 25% còn lại = 25Kbps được giành cho người gửi. Phần 75% băng thông sẽ được chia đều cho những người nhận. Mỗi bên tham gia (nhận hay gửi) đều xác định được khoảng thời gian trung bình để truyền gói tin RTCP bằng cách lấy kích thước gói tin RTCP trung bình chia cho băng thông mà nó được cấp cho. Ví dụ số lượng bên nhận tham gia phiên ứng dụng là N, băng thông của phiên ứng dụng là R, kích thước trung bình gói tin
RTCP là S. Khi đó, thời gian trung bình mà mỗi người nhận truyền gói tin RTCP sẽ là: R S N T * 5 . 0 * 75 . 0 *
Thời gian trung bình mà phía gửi truyền gói tin RTCP sẽ là R S N T * 5 . 0 * 25 . 0 * 2.8. Kết luận
Như vậy, đối với các ứng dụng truyền thông đa phương tiện thời gian thực, như: Video Conference.... thì việc giảm tối thiểu độ trễ, giảm jitter và mất gói tin luôn được đặt lên hàng đầu và được các nhà sản xuất thiết bị truyền hình đặc biệt quan tâm giải quyết. Đến nay, đã có nhiều giải pháp cho giải quyết các vấn đề trên, giải pháp đường truyền, giải pháp tại thiết bị đầu cuối (khôi phục gói tin bị mất tại điểm nhận),.... Tuy nhiên, một trong những giải pháp quan trọng và quyết định đó là đường truyền.
Trong chương này luận văn đã trình bày một số giải pháp đảm bảo cho đường truyền tốt hơn, đó là: giải pháp giảm dữ liệu truyền trên mạng (nén video, nén audio) và giải pháp đưa ra các giao thức đặc biệt. Tuy nhiên, các giải pháp này chỉ giúp làm tăng chất lượng dịch vụ. Do vậy, các giải pháp này chưa đủ để đảm bảo cho chất lượng dịch vụ của Video Conference được tốt.
Để giải quyết vấn này, trong chương tới luận văn tiếp tục đưa ra một số giải pháp mạnh hơn, đó là các mô hình đảm bảo chất lượng vụ đang được sử dụng trên mạng hiện nay, mô hình dịch vụ tích hợp IntServ và mô hình dịch vụ phân biệt DiffServ và đưa ra mô hình đề xuất kết hợp mô hình IntServ với mô hình DiffServ sử dụng hàm ánh xạ.
Chƣơng 3
CÁC MÔ HÌNH ĐẢM BẢO CHẤT LƢỢNG DỊCH VỤ CHO TRUYỀN THÔNG ĐA PHƢƠNG TIỆN
Trong chương này, chúng tôi sẽ nghiên cứu và trình bày chi tiết từng mô hình IntServ và mô hình DiffServ. Đặc biệt, chúng tôi đưa ra một mô hình đề xuất đó là kết hợp hai mô hình IntServ và mô hình DiffServ với nhau bằng hàm ánh xạ. Các phần dưới đây là nội dung chi tiết mà chúng tôi muốn trình bày trong chương này.
3.1. Mô hình dịch vụ tích hợp IntServ (Intergrated Services)
3.1.1. Tổng quan
Trước những nhu cầu ngày càng tăng trong việc cung cấp các dịch vụ thời gian thực (thoại, video) và yêu cầu băng thông cao (các dịch vụ đa phương tiện), tổ chức IETF (Internet Engineering Task Force) đã đưa ra mô hình IntServ từ những năm đầu của thập kỷ 90 như một giải pháp hữu hiệu đảm bảo QoS IP [7].
Ý tưởng ban đầu của dịch vụ tích hợp IntServ là hỗ trợ việc dành trước tài nguyên cho các luồng lưu lượng, được thực hiện bởi việc thiết lập một tuyến dành trước tài nguyên trước khi gửi dữ liệu. Thực chất của mô hình intServ là các bộ định tuyến và thiết bị mạng phải dành trước nguồn tài nguyên của nó để cung cấp các mức chất lượng dịch vụ cụ thể cho các gói mang lưu lượng người dùng.
IntServ đã định nghĩa những yêu cầu cho các quá trình QoS để thỏa mãn hai mục đích: Phục vụ các ứng dụng thời gian thực và điều khiển việc chia sẻ băng thông giữa các cấp độ lưu lượng khác nhau.
Trong mô hình dịch vụ tích hợp, người ta đã đề xuất hai lớp dịch vụ bổ sung cho các dịch vụ IP truyền thống đó là: