Bảng 4.4: Cấu trúc thông tin bổ sung của transport_protocol_label (truyền qua OC)[8]
Số bit | Giải thích | |
remote_connection | 1 | |
reserved | 7 | |
If(remote_connection=1) { origial_network_id ts_id service_id } | 16 16 16 | Tùy chọn, tham chiếu đến dòng thành phần mang OC từ mạng/dòng truyền/kênh khác. |
component_tag | 8 | Tham chiếu đến dòng thành phần thông qua nhãn nhận diện được gán trong mô tả stream_identifier trong PMT của dòng thành phần mang OC. |
Có thể bạn quan tâm!
- Nghiên cứu mô hình truyền hình lai ghép HbbTV và xây dựng ứng dụng minh họa - 5
- Mô Hình Tiêu Chuẩn Hbbtv Phiên Bản 1.5
- Vòng Đời Của Một Ứng Dụng Liên Quan Tới Quảng Bá
- Tìm Hiểu Môi Trường Triển Khai Và Xây Dựng Ứng Dụng Minh Họa Hbbtv
- Nghiên cứu mô hình truyền hình lai ghép HbbTV và xây dựng ứng dụng minh họa - 10
- Nghiên cứu mô hình truyền hình lai ghép HbbTV và xây dựng ứng dụng minh họa - 11
Xem toàn bộ 89 trang tài liệu này.
Bảng 4.5: Cấu trúc thông tin bổ sung của transport_protocol_label (truyền qua băng rộng)[8]
Số bit | Giải thích | |
For (i=0;i<N;i++) { | ||
url_base_length url_base_bytes() | 8 8 | Địa chỉ gốc của ứng dụng, có dạng “http://” và kết thúc bằng “/”. |
For (j=0;j<M, j++) { | Các địa chỉ mở rộng của ứng dụng | |
url_extension_length | 8 | |
url_extension_bytes() | ||
} | ||
} |
Chú ý: Nhiều khai báo giao thức truyền băng rộng có thể gán cùng nhãn để xác định nhiều địa chỉ URL hơn cho ứng dụng.
Khai báo giao thức truyền:
Mỗi ứng dụng phải tham chiếu ít nhất một mô tả giao thức thông qua nhãn nhận diện để xác định giao thức truyền thực sự. Tùy vào đầu thu hỗ trợ, một ứng
dụng có thể sử dụng kết hợp nhiều giao thức. Trường hợp này xem như phương án dự phòng và thứ tự giao thức tham chiếu chính là thứ tự ưu tiên. Đầu thu sẽ chọn giao thức dựa vào các yếu tố khác nhau. Có thể do thiết lập người dùng trong đầu thu, hay dựa vào chất lượng truyền của mỗi giao thức tại từng thời điểm.
Việc xác định giao thức truyền cho mỗi ứng dụng được thực hiện trong bộ mô tả application_descriptor đặt trong vòng lặp trong của từng ứng dụng. Mô tả có cấu trúc như trong bảng 4.6 sau:
Bảng 4.6: Cấu trúc bộ mô tả application_descriptor[8]
Số bit | Giải thích | |
application_descriptor { | ||
descriptor_tag | 8 | Nhận diện loại mô tả, có trị 0x0 |
descriptor_length | 8 | Chiều dài phần phía sau (byte) |
application_profile_length | 8 | Vòng lặp mô tả các profile của chuẩn cần để thực thi ứng dụng. Ứng dụng cần profile cơ bản có bộ giá trị (0,1,1,1). |
for( i=0;i<N;i++) { | ||
application_profile Version.major Version.minor Version.micro | 16 8 8 8 | |
} | ||
service_bound_flag | 1 | Cho biết ứng dụng có liên hệ với kênh chương trình hay không. |
Visibility | 2 | Ứng dụng được nhìn thấy đối với các hàm API truy xuất danh sách ứng dụng không. |
Reserved | 5 | |
application_priority | 8 | Mức ưu tiên ứng dụng, giá trị lớn hơn cho mức ưu tiên cao hơn. Trường hợp có nhiều ứng dụng có cùng application_id trong kênh, ứng dụng có độ ưu tiên cao hơn sẽ được chọn thực thi. Hoặc trong trường hợp tài nguyên hệ thống giới hạn, đầu thu sẽ ưu |
tiên ứng dụng có mức ưu tiên cao hơn. | ||
for( i=0;i<N;i++) { transport_protocol_label } | 8 | Xác định phương thức truyền ứng dụng thông qua nhãn giao thức đã được gán trong bộ mô tả transport_protocol_descriptor. |
Xác định điểm (trang) bắt đầu ứng dụng:
Sử dụng bộ mô tả simple_application_location_descriptor, đặt trong vòng lặp mô tả trong của mỗi ứng dụng. Cú pháp được thể hiện trong bảng số bảng 4.7 như sau:
Bảng 4.7: Cấu trúc bộ mô tả simple_application_location_descriptor[8]
Số bit | Giải thích | |
simple_application_location_descriptor { | ||
descriptor_tag | 8 | Nhận diện loại mô tả , có trị 0x15 |
descriptor_length | 8 | Chiều dài phần phía sau (byte) |
initial_path_bytes() | Đường dẫn chỉ đến trang khởi tạo ứng dụng | |
} |
Giả sử ứng dụng được tổ chức thành 2 thư mục con main và image. Trang khởi tạo là index.html lưu trong thư mục main. Như vậy, nếu ứng dụng truyền qua OC bắt đầu tại thư mục gốc của ứng dụng, thì initial_path_bytes sẽ có trị “main/index.html”. Còn nếu truyền qua kênh ngược, url_base_bytes có trị “http://<domain>/địa chỉ gốc của ứng dụng” và initial_path_bytes sẽ có trị “main/index.html”. Nếu đặt toàn bộ ứng dụng trong thư mục con khác có tên “application” chẳng hạn, thì initial_path_bytes sẽ là “application/main/index.html”. Báo hiệu ứng dụng qua kết nối băng rộng:
Thông tin báo hiệu ứng dụng thường được truyền trong dòng quảng bá trong các section AIT như mô tả chi tiết ở trên. Bên cạnh đó, HbbTV cũng cho phép cung cấp thông tin báo hiệu ứng dụng thông qua kết nối băng rộng. Báo hiệu theo cách này chỉ dùng cho các ứng dụng độc lập quảng bá.
Một nhóm các ứng dụng độc lập quảng bá được liệt kê trong file có định dạng
*.xml ait, cũng gồm những thông tin báo hiệu tương tự trong AIT. Trong trường hợp này, một số thông tin chỉ có giá trị giới hạn như dùng giao thức truyền HTTP (protocol_id = 0x3), thông tin kiểm soát trạng thái ứng dụng là AUTOSTART hoặc PRESENT. Việc xác định địa chỉ tham chiếu đến file báo hiệu được thực thiện thông qua thủ tục tạo ứng dụng (application.createApplication) trong một ứng dụng liên quan quảng bá đang chạy.
4.4.2 Khai báo dòng con AIT
Không giống một số bảng SI truyền trong các gói có mã nhận diện PID cố định, AIT và OC được truyền trong dòng thành phần riêng và phải được khai báo trong PMT như các dòng thành phần khác của kênh. Khai báo bổ sung dòng thành phần trong PMT là công việc bắt buộc giúp đầu thu kiểm soát toàn bộ cấu trúc dòng truyền. Mỗi khai báo mang các thông tin quan trọng như loại dữ liệu trong dòng (stream_type), mã nhận diện các gói thuộc dòng (elementary_PID) và một số thông tin chi tiết khác ứng với từng loại dòng được đặt trong vòng lặp mô tả theo sau. Dòng mang AIT: có stream_type = 0x05, sử dụng mô tả application_signalling gồm hai thông tin chính: loại ứng dụng AIT khai báo (application_type) và phiên bản AIT (AIT_version_number). Khi phát hiện có phiên bản mới, đầu thu sẽ truy xuất AIT theo phiên bản mới này, cú pháp mô tả như sau:
Bảng 4.8: Cấu trúc bộ mô tả application_signalling_descripor [8]
Số bit | Giải thích | |
application_signalling_descriptor { | ||
descriptor_tag | 8 | Nhận diện loại mô tả , có trị 0x6F |
descriptor_length | 8 | Chiều dài phần phía sau (byte) |
For( i =0;i<N;i++) { | ||
reserved | 1 | |
application_type | 15 | Xác định loại ứng dụng được báo hiệu trong AIT, ứng dụng HbbTV có trị 0x10 |
reserved | 3 | |
AIT_version_number | 5 | Phiên bản AIT hiện tại |
} | ||
} |
Dòng mang OC: có stream_type = 0xB, sử dụng các mô tả gồm:
Cú Pháp | Số bit | Giải thích |
data_broadcast_id_descriptor { | ||
descriptor_tag | 8 | Nhận diện loại mô tả , có trị 0x66 |
descriptor_length | 8 | Chiều dài phần phía sau (byte) |
data_broadcast_id | 8 | Nhận diện loại dữ liệu trong OC, có trị 0x123 cho OC mang ứng dụng HbbTV. |
} |
Data_broadcast_id_descriptor: xác định loại ứng dụng trong dòng mang OC Bảng 4.9: Cấu trúc bộ mô tả data_broadcast_id_descriptor [8]
Stream_identifier_descriptor: gán nhãn nhận diện dòng thành phần, dùng để tham chiếu trong OC
Bảng 4.10: Cấu trúc bộ mô tả stream_identifier_descriptor [8]
Số bit | Giải thích | |
stream_identifier_descriptor { | ||
descriptor_tag | 8 | Nhận diện loại mô tả, có trị 0x52 |
descriptor_length | 8 | Chiều dài phần phía sau (byte) |
component_tag | 8 | Gán nhãn nhận diện dòng thành phần |
} |
Carousel_identifier_descriptor: định danh carousel mang ứng dụng
Bảng 4.11: Cấu trúc bộ mô tả carousel_identifier_descriptor [8]
Số bit | Giải thích | |
carousel_identifer_descriptor{ | ||
descriptor_tag | 8 | Nhận diện loại mô tả, có trị 0x13 |
descriptor_length | 8 | Chiều dài (byte) phần phía sau |
carousel_id | 8 | Mã nhận diện carousel |
} |
4.4.3 Truyền ứng dụng
Ứng dụng lai ghép sẽ được truyền đến đầu thu theo giao thức truyền được khai báo trong trong AIT. Ứng dụng có thể sử dụng cả hai phương thức. Nếu truyền qua dòng truyền MPEG2, ứng dụng được đóng gói theo giao thức OC. Đây là một giao thức phức tạp, không được đề cập trong báo cáo này.
Trong trường hợp ứng dụng có sử dụng dòng thông tin đồng bộ, bắt buộc phần thông tin này phải truyền qua dòng MPEG2.
4.5 Đồng bộ ứng dụng HbbTV
4.5.1 Định nghĩa sự kiện
Khái niệm sự kiện (event) được DSM - CC đưa ra để dùng trong trường hợp cần đồng bộ giữa chương trình quảng bá và ứng dụng tương tác. Có thể xem sự kiện là một tín hiệu đặc biệt được đưa vào dòng truyền quảng bá để báo cho đầu thu thực hiện một số tác vụ cụ thể tại thời điểm xác định. Các báo hiệu được mang trong dòng thành phần riêng, và không nhất thiết phải truyền liên tục. Mỗi sự kiện khi báo hiệu có thể bao gồm dữ liệu kèm theo. Có thể tạo nhiều tín hiệu khác nhau cho từng mục đích khác nhau. Nhiều sự kiện có thể truyền song song trong dòng truyền, giữa chúng được phân biệt bằng mã nhận diện riêng.
Đối tượng streamevent trong OC:
Về cơ bản, DSM-CC OC đóng gói file, thư mục ứng dụng và truyền chúng theo cơ chế lặp mà đầu thu có thể dễ dàng nhận được từng thành phần dữ liệu riêng. OC bao gồm 3 đối tượng chính: ServiceGatewayMessage (cấu trúc thư mục gốc), DirectoryMessage (cấu trúc các thư mục con) và FileMessage (dữ liệu file). Ngoài ra, OC còn hỗ trợ đối tượng StreamEventMessage. Đây là đối tượng đặc biệt không lưu bất kỳ dữ liệu nào thuộc ứng dụng. Nó dùng để định nghĩa các sự kiện có trong dòng truyền, cũng như cách tham chiếu đến dòng thành phần tương ứng mang thông tin kích hoạt sự kiện. Thông tin mô tả cho mỗi sự kiện bao gồm mã nhận diện, tên sự kiện và tham chiếu dòng con được mô trả trong hình 4.3.
Hình 4.3: Mô hình phát lặp dữ liệu theo giao thức OC
Chuẩn DSMCC OC vốn rất phức tạp, bao gồm các cấu trúc dữ liệu đan xen, nhiều cấu trúc quan trọng trong chuẩn đã được đề cập chi tiết trong đề tài trước đây. Cấu trúc chi tiết của đối tượng StreamEventMessage được mô tả sau đây:
Bảng 4.12: Cấu trúc đối tượng BIOP::StreamEventMessage [8]
Số byte | Diễn giải | |
BIOP::StreamEventMessage(){ | ||
Magic | 4 | Báo hiệu bắt đầu đối tượng, có trị “BIOP” |
Biop::version | 2 | Phiên bản đối tượng, trị “1.0” |
Byte_order | 1 | Thứ tự mã hóa byte, mặc định 0 |
message_type | 1 | Loại đối tượng, trị 0 (đối tượng tải) |
message_size | 4 | Kích thước đối tượng (từ sau trường này) |
objectKey_length | 1 | Chiều dài objectKey_data, tối đa 4 byte |
objectKey_data | Chỉ danh đối tượng | |
objectKind_length | 1 | Chiều dài objectKind_data, tối đa 4 byte |
objectKind_data | 4 | Loại đối tượng StreamEvent, có trị “ste ” |
objectInfo_length | 2 | Thông tin thêm |
DSM::Event_EventList_T(){ |
Liệt kê tên của những sự kiện dòng | ||
for (eventNames_count) { | ||
eventName_len | ||
eventName_data | ||
} | ||
} | ||
messageBody_len | Tham chiếu các dòng con mang thông tin kích hoạt sự kiện | |
taps_count | ||
for (taps_count) { | ||
id | Nhận diện loại tham chiếu dòng con, trị 0 | |
use | 1 | Mục đích sử dụng dòng con được tham chiếu. Trường hợp này sẽ tham chiếu đến dòng kích hoạt sự kiện (xem phần sau) có trị 0xD (STR_EVENT_USE) |
association_tag | Nhãn nhận diện dòng con (được gán trong PMT) | |
selector_len | 2 | Thông tin thêm, không được dùng |
} | ||
eventIds_count | 2 | Danh sách mã sự kiện, đồng nhất với danh sách tên sự kiện trong EventList |
for (eventIds_count) { | 1 | |
eventId | ||
} | ||
} |
File định dạng xml
Như vậy nếu ứng dụng được truyền qua băng rộng nhưng có định nghĩa sự kiện, thì dòng truyền phải gồm các cấu trúc dữ liên quan cho một OC chứa định nghĩa này. Tuy nhiên, ứng dụng truyền qua băng rộng cũng có thể tải kèm file định nghĩa ở dạng *.xml. File gồm những thông tin tương đương với đối tượng StreamEventMessage trong OC, file xml được định nghĩa theo lược đồ sau:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!--W3C Schema generated by XMLSpy v2006 sp2 U (http://www.altova.com)-->
<xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchemaxmlns:dsmcc="urn:dvb:mis:dsmcc:2009"