Truyền tải IPTV
Chúng ta quan tâm truyền video qua bộ giao thức. Đầu tiên chúng ta sẽ thảo luận về hai phương thức phát chính được IPTV sử dụng. Tiếp theo chúng ta sẽ nói về các chuẩn khác nhau sử dụng để mã hóa và phát video. Do chuẩn MPEG-2 là phương thức thông dụng nhất sử dụng để phát video qua mạng IP. Thêm đó do RTP (giao thức truyền tải thời gian thực) thì rất cần thiết cho phát video, đồng thời cũng khảo sát việc sử dụng nó.
đầu
Phương thức phát
Có ba phương thức truyền cơ bản mà video truyền qua mạng IP. Phương pháp đó gồm phát chuyển file nhưng hạn chế xem thời gian thực, quảng bá và truyền hình theo yêu cầu (VoD). Hai phương pháp sau được sử dụng cho xem phim thời gian thực, buổi truyền hình, buổi hòa nhạc, hoặc một số hình thức khác. Do chuyển file của video, mặc dù miêu tả việc chuyển file qua mạng IP, nó sử dụng phát lại và không xem ngay tức thì, việc chuyển file có thể xảy ra qua FTP hay qua sử dụng ứng dụng Bit Torrent đã được nói ở phần trước. Do đó, trong phần này chúng ta nhấn mạnh vào việc sử dụng công nghệ quảng bá và truyền hình theo yêu cầu để cung cấp khả năng IPTV.
Khi video quảng bá, mỗi đường truyền được cung cấp một số lượng kênh duy nhất cho phép STB lựa chọn đường truyền, người xem điều khiển hộp muốn xem. Trong thực tế, khi một người xem sử dụng STB để lựa chọn kênh thì hộp sẽ thiết lập kết nối multicast tới kênh quảng bá, loại trừ nhu cầu về các kênh được số hóa đưa vào nhà thuê bao, chúng thực hiện khi sử dụng truyền hình cáp.
Quảng bá
Phần đầu trong hình 2.9 minh họa việc phát video qua kênh quảng bá. Nguồn quảng bá có thể là phim ảnh được lưu giữ từ trước trên server cũng như đường truyền trực tiếp từ một trạm truyền hình không gian chiếu trận chung kết bóng rổ Olympic mùa hè, hát opera hoặc các chương trình khác. Mỗi nguồn là đầu vào bộ mã hóa truyền dẫn mà nó đóng gói luồng video, gồm cả sắp đặt kênh và nhóm địa chỉ multicast tới STB thì sẽ nối liền người xem chọn một kênh sử dụng hộp bất cứ lúc nào.
Hệ thống truyền dẫn được xem là một dãy server truyền thông mà nó quản lý số lượng luồng truyền dẫn. Server truyền thông hỗ trợ việc phát cả multicast và unicast, với unicast được sử dụng cho VoD. Do quảng cáo về dịch vụ mô tả bề mặt quan trọng của hoạt động IPTV, hệ thống quản lý thuê bao sử dụng để thực hiện chức năng đó. Thêm đó để quảng cáo tới thuê bao, hệ thống quản lý thuê bao bình thường sẽ cung cấp chức năng bổ sung như là quảng bá một hướng dẫn chương trình điện tử và hỗ trợ tương tác các đặc tính của STB, như cung cấp nội dung được chọn lựa tới thuê bao ví như VoD.
đầu
Hình 2.9. IPTV được phát truyền dẫn quảng bá và truyền hình theo yêu cầu unicast Truyền hình theo yêu cầu
Phần dưới của hình 2.9 minh họa sự tích hợp VoD vào hệ thống truyền thông IPTV. Do VoD trả lời yêu cầu được tạo ra bởi thuê bao qua STB hay PC, trả lời truyền một chuỗi datagram unicast tới địa chỉ IP của STB hoặc máy tính cá nhân. Điển hình, trạm quản lý thuê bao sẽ hiện thị danh sách chương trình VoD từ đó một thuê bao có thể chọn một chương trình. Tuy nhiên, hoạt động của nó cũng có thể chèn thêm một thẻ với hóa đơn hàng tháng của thuê bao, mà có thể liệt kê hàng trăm chương trình, chi phí xem và một mã truy nhập để tìm chương trình lựa chọn. Với phương thức này, truyền luồng datagram IP sẽ mô tả truyền dẫn unicast tới STB hay máy tính cá nhân của thuê bao.
Các chuẩn phát truyền hình
Một số chuẩn có thể được sử dụng cho hệ thống phát truyền hình IPTV. Hai chuẩn thông dụng nhất là MPEG-1 và MPEG-2, với MPEG-2 mô tả sự chuyển đổi chuẩn trước kia mà thường được sử dụng trong STB cáp nhờ đó mà nó có khả năng nén dữ liệu.
Chuẩn MPEG mới là MEG-4, nó được hoàn thành vào năm 1998 và trở thành chuẩn quốc tế vào năm 2000. MPEG-4 được thiết kế cho việc phát truyền hình chất lượng DVD tương tự với MPEG-2 nhưng tốc độ dữ liệu thấp hơn. Trên thực tế,
đầu
MPEG-4 tỉ lệ với phương tiện truyền dẫn tại bất kì tốc độ nào, từ quay số tốc độ thấp tới kết nối quang về nhà thuê bao băng tần cao. Vào năm 2000 Apple Computer thêm chức năng hỗ trợ MPEG-4 với công nghệ QuickTime và hoạt động với các công ty hàng đầu như Cisco, IBM, Philips, Sun Microsystems và 20 công ty khác hợp thành Internet Streaming Media Alliance (ISMA) đảm bảo luồng phương tiện MPEG-4 được tạo ra với một sản phẩm của nhà cung cấp sẽ chạy được trên chương trình của nhà cung cấp.
Phiên bản quốc tế MPEG-4 tốt hơn biết đến như là chuẩn H.264 và tương đương với MPEG-4 bộ phận chuẩn 16. Mặc dù cả MPEG-4 và H.264 cung cấp nâng cao đáng kể so với MPEG-2, chúng tập trung vào máy tính nhiều hơn. Điều này có nghĩa đối với các nhà cung cấp cáp hiện tại mà có cơ sở cài đặt nhiều STB MPEG-2, nâng cấp lên thiết bị tương thích MPEG-4 hoặc H.264 có thể gặp khó khăn. Khi so sánh với các nhà cung cấp IPTV mới nổi lên mà có lượng khách hàng đang dùng STB mới hoặc sử dụng bộ xử lý Pentium 4 hoặc lõi kép (dual core) để xem truyền hình thì họ rất sẵn sàng phục vụ với công nghệ mới nhất. Trên thực tế, một số truyền hình vệ tinh như truyền hình trực tiếp, đã dùng MPEG-4 để phát truyền hình số nhờ đó mà chất lượng ảnh ở tốc độ thấp hơn, cho phép nhiều kênh hơn khi phát trong phổ tần được phép sử dụng
Sử dụng MPEG-2
Một trong những phương thức thông dụng sử dụng để phát IPTV qua việc đóng gói MPEG-2 sử dụng UDP tại tầng vận chuyển. Khi việc đóng gói xảy ra, UDP có thể tùy ý sử dụng RTP để cung cấp khung mức ứng dụng nhận ra tải trọng được truyền và cung cấp số thứ tự chuỗi cho mỗi gói dữ liệu RTP, mà cho phép phát hiện tổn hao gói.
UDP/RAW và UDP/RTP
Hình 2.10 minh họa sử dụng RTP cho việc truyền IPTV dựa vào MPEG-2, chú ý là video cũng có thể truyền trực tiếp trong gói UDP mà không sử dụng RTP. Khi tình huống này xảy ra, luồng truyền dẫn sẽ liên quan đến UDP/RAW. Khi sử dụng UDP/RAW, có thể phát hiện một số lỗi và điều kiện thông tin gồm:
• Người gửi thay đổi
• Thiếu byte đồng bộ
• Kích cỡ gói không đúng
• Hết thời gian
• Jitter quá mức
đầu
Hình 2.10. Phát MPEG-2 qua IP
Khi sử dụng RTP với UDP như trên hình 2.10, gói có thể được lấy mẫu theo thời gian và nhận dạng qua sử dụng số thứ tự chuỗi. Số thứ tự này cho phép phát hiện lỗi thêm vào thêm nữa có thể phát hiện lỗi khi sử dụng UDP/RAW. Lỗi có thể phát hiện khi sử dụng UDP/RTP gồm:
• Xác định gói nhận được không hợp lệ
• Phát hiện gói sao
• Xác định gói bị mất
• Xác định gói có kích cỡ không đúng
Mặc dù cả UDP/RAW và UDP/RTP có thể sử dụng truyền tải video, cái sau cung cấp khả năng bù nếu có tình trạng lỗi ở gói thu được không hợp lệ, gói không đúng kích cỡ hoặc gói nhân bản. Do UDP/RTP cho phép đầu thu xác định mất gói, nó cũng cho phép đầu thu bù lỗi khi có sự cố mất gói. Tùy thuộc vào phần mềm sử dụng tại đầu thu, nó có thể chẳng làm gì, theo thời gian màn hình hiện lên các khoảng trống hoặc lặp lại khung thu ở giai đoạn trước.
Nhãn thời gian cho phép đầu thu thực hiện đồng bộ cũng như giải quyết jitter do trễ gói khi đi qua mạng. Hình 2.10 minh họa quá trình đóng gói sử dụng MPEG-2 để phát qua datagram IP. Do RTP là một phần tích hợp của quá trình phát cho phép gói truyền có thể được khôi phục lại, chúng ta chuyển sang xem xét giao thức này. Đầu tiên chúng ta khảo sát mào đầu kết hợp với việc sử dụng giao thức này. Sau đó chúng ta nghiên cứu chi tiết.
Overhead RTP
Trong quá trình đóng gói luồng dữ liệu MPEG-2 như trong hình 2.10, để ý đến mào đầu của giao thức tại lớp mạng. Phần đầu IP, UDP và RTP trong 40 byte mào đầu trong khi 1316 byte video truyền tải qua MPEG-2. Do đó, mào đầu tại lớp mạng là 40/1316 xấp xỉ 3%. Nếu datagram IP truyền trên mạng Ethernet có 26 byte đầu và 4
đầu
byte đuôi, kết quả mào đầu là 70/1316 xấp xỉ khoảng 5,3%.
Khi sử dụng UDP/RAW, loại ra phần đầu RTP. Mào đầu tại tầng mạng là 28/1316 hoặc xấp xỉ 2,1 %. Khi UDP/RAW trong một datagram IP truyền trên mạng Ethernet, kết quả mào đầu là 58/1316, xấp xỉ 4,4%.
Bảng 2.2. So sánh mào đầu của UDP/RAW và UDP/RTP
Giao thức Tầng mạng
(%) Tầng liên kết dữ liệu (%)
UDP/RTP 3,0 5,3
UDP/RAW 2,1 4,4
Bảng 2.2 so sánh mào đầu kết hợp với sử dụng UDP/RAW và UDP/RTP. Chú ý rằng cả hai lớp mạng và liên kết dữ liệu khác nhau trong mào đầu giữa UDP/RTP và UDP/RAW thì ít hơn 1%.
Giao thức truyền tải thời gian thực (RTP)
RTP được nhận dạng trong phần đầu UDP với số thứ tự cổng (port number) 5004 trường vận chuyển. Như đề cập ở trước, RTP cung cấp chức năng vận chuyển mạng từ đầu cuối tới đầu cuối, tiện ích là phát dữ liệu thời gian thực như âm thanh, hình ảnh và dữ liệu mô phỏng qua dịch vụ mạng multicast và unicast. Mặc dù RTP cung cấp chuỗi và nhãn thời gian của dữ liệu, nó không đánh địa chỉ dành riêng của tài nguyên cũng không đảm bảo chất lượng dữ liệu dịch vụ QoS đối với dữ liệu thời gian thực. Do đó, nó hoạt động hiện thời trên mạng mục đích cấu hình hàng đợi để ưu tiên lưu lượng xác định trước cho phép video thời gian thực đưa tới đích với trễ nhỏ nhất.
Mào đầu RTP
Hình 2.11 minh họa phần đầu phiên bản 2 RTP. Phiên bản 1 RTP thì hiện tại tỏ ra bị hạn chế, và tất cả ứng dụng hiện tại đều viết cho phiên bản 2, nó không đối nghịch với phiên bản 1. Phần đầu phiên bản 2 RTP gồm 10 trường, chúng ta nói ngắn gọn về chúng.
Trường phiên bản (Ver)
Hai bit đầu tiên trong phần đầu biểu diễn trường phiên bản. Đối với RTP phiên bản 2 (IPv4), trường này luôn thiết lập lên nhị phân 10 hay thập phân là 2.
Trường đệm (P)
Trường đệm có chiều dài 1 bit. Trường này thiết lập lên nhị phân là 1 khi một hay nhiều byte đệm thêm vào, nếu chúng không ở trong tải trọng thì được thêm vào gói. Byte cuối của trường đệm tính toán số lượng byte thêm vào. Do đó, đầu thu sử dụng giá trị này để xác định số lượng byte bổ sung để loại ra.
đầu
Trường này có 1 bit được thiết lập nếu mào đầu cố định truyền theo một mở rộng mào đầu. Nếu không, giá trị của trường này thường là 0.
Hình 2.11. Phần đầu RTP phiên bản 2 Trường tính toán CSRC (CC)
Đây là trường 4 bit chỉ ra số lượng của bộ nhận dạng nguồn phát (CSRC) truyền mào đầu cố định. Có thể lên tới 15 nguồn phát.
Trường đánh dấu (M)
Đây là trường 1 bit, khi thiết lập được thông dịch bởi hiện trạng. Ví dụ, thiết lập bit này cho phép đường biên khung được đánh dấu trong luồng gói.
Trường kiểu tải trọng (PT)
Mục đích của trường 7 bit này là nhận dạng khung của tải trọng RTP vì vậy nó có thể thông dịch đúng bởi ứng dụng. Ví dụ, H.261 video được nhận dạng bởi giá trị trường PT là 31 trong khi H.263 video là 34.
Trường số thứ tự chuỗi (Sequence Number)
Trường số thứ tự chuỗi 16 bit có một giá trị được lựa chọn ban đầu ngẫu nhiên. Sau đó, số thứ tự chuỗi tăng lên một đối với mỗi gói dữ liệu RTP được truyền. Mục đích cơ bản của trường số thứ tự chuỗi là phát hiện mất gói. Đối với video, một khung có thể bị chia vào một số gói RTP, vì vậy các gói đó có thể có nhãn thời gian giống nhau. Do đó, số thứ tự chuỗi có thể được để đảm bảo nhiều khung video lắp lại đúng tại đầu thu.
Trường nhãn thời gian (Timestamp)
Trường nhãn thời gian 32 bit sử dụng để đưa gói âm thanh và hình ảnh theo thứ tự thời gian đúng. Giá trị của trường nhãn thời gian phản ánh nhãn của byte đầu tiên trong gói dữ liệu, điều đó giải thích tại sao khung cần truyền bởi một chuỗi gói RTP sẽ có nhãn thời gian giống nhau trong mỗi phần đầu của gói RTP.
đầu
Trường nguồn đồng bộ (SSRC)
Đây là trường 32 bit nhận dạng nguồn đồng bộ. Giá trị cho trường này được lựa chọn ngẫu nhiên vì vậy hai nguồn đồng bộ trong phiên RTP giống nhau có xác suất giá trị giống nhau rất thấp. Như vậy tất cả thành phần bổ sung RTP phải có khả năng phát hiện và giải quyết xung đột
Trường nguồn phát (CSRC)
Đây là trường 32 bit biểu diễn một mảng từ 0 đến 15 yếu tố CSRC. Có thể gồm tới 16 yếu tố CSRC và nhận dạng nguồn phát đối với nội dung tải trọng trong gói. Bộ nhận dạng CSRC được chèn bởi bộ trộn, sử dụng bộ nhận dạng SSRC của nguồn phát, như bộ nhận dạng của tất cả nguồn trộn vào tạo ra gói âm thanh. Bộ trộn là một thiết bị tiếp sóng mức RTP cho phép nhiều băng tần được sử dụng dành cho nghe hoặc xem một kênh thông thường. Bộ trộn đặt gần vùng băng tần thấp và gói tái đồng bộ để duy trì khoảng cách được tạo ra bởi người khởi tạo và nó phiên dịch, ví dụ mã hóa âm thanh sử dụng trên kết nối băng tần cao tới phương thức mã hóa phù hợp hơn đối với kết nối băng tần thấp hơn. Trong môi trường hình ảnh, bộ trộn được thiết kế chia tỉ lệ hình ảnh riêng rẽ trong luồng video độc lập vào luồng ghép lại để mô phỏng một khung cảnh. Ví dụ khác bộ trộn hình ảnh gồm thiết bị phiên dịch luồng video từ IP/UDP vào giao thức khác nhau hoặc phiên dịch luồng từ nguồn từ các nguồn độc lập không thực hiện tái đồng bộ hay trộn.
Ước tính nhãn thời gian
Đối với video, nhãn thời gian phụ thuộc vào khả năng của ứng dụng để xác định số thứ tự khung. Ví dụ, nếu ứng dụng truyền khung tại tốc độ khung cố định, nhãn thời gian ảnh hưởng bởi tốc độ khung. Tại tốc độ khung thường truyền 30 khung trên một giây (fps), nhãn thời gian tăng lên 3000 đối với mỗi khung; trái lại tại tốc độ khung là 25fps, nhãn thời gian tăng lên 3600 với mỗi khung. Như ghi chú ở trên, khi một khung truyền như một chuỗi gói RTP, giá trị nhãn thời gian trong mỗi phần đầu sẽ giống nhau. Đối với tình huống mà số thứ tự khung không được xác định, giá trị khóa hệ thống sẽ được sử dụng để tính toán nhãn thời gian.
Sử dụng số thứ tự cổng
Theo đặc tính kĩ thuật RTP, dữ liệu RTP được truyền trên một số thứ tự cổng UDP chẵn, trái lại giao thức điều khiển truyền tải thời gian thực (RTCP) gói truyền trên số thứ tự cổng lẻ tiếp theo cao hơn. Mặc dù ứng dụng có thể sử dụng bất kì đôi cổng UDP nào, số thứ tự cổng 5004 và 5005 biểu diễn cổng đăng kí cho ứng dụng lựa chọn chúng như cổng mặc định.
RTCP
Giao thức điều khiển truyền tải thời gian thực cung cấp thông tin về người tham gia trong một phiên cuộc gọi cũng như kĩ thuật giám sát chất lượng dịch vụ. Thông tin
đầu
về người tham gia trong một phiên có thể thay đổi từ hoàn cảnh mà không có điều