DSM-CC
- 格式:pdf
- 大小:43.35 KB
- 文档页数:10
DSM-CC Message Header-Download 部 分
之前有篇文章对 DSM-CC Section 有了个介绍(DSMCC Section 是封装 DSM-CC Message 的),今天来总结一下 DSM-CC Message,就是在封装成 Section 之前的 数据,整个层次结构是这样的,我们先将下载数据(Download Data)和控制数 据(Download Control data)封装成 DSM-CC Message(如 DDB,DII,DSI), 然后再将 DSM-CC Message 封装成 DSM-CC Section,然后再封装成 TS packets, 这样就可以用 MPEG-2 的方式传输了,好了,下面就说说 DSM-CC Message 的 header 吧。 本文是对几个协议中的 DSM-CC Message Header 的一个总汇,大部分是翻译过来 的内容:
No. of bits Mnemonic
8
uimsbf
1
bslbf
1
bslbf
2
bslbf
2
bslbf
16
uimsbf
2
bslbf
5
uimsf
1
bslbf
8
uimsf
8
uimsf
}
else if (table_id==0×3D) {
DSMCC_descriptor_list()
}
else if (table_id==0×3E) {
table_id
DSMCC Section Type
0×00-0×37
ITU-T Rec.H.222.0|ISO/IEC 13818-1 所定义
0×38-0×39
ISO/IEC 13818-1 保留
0×3A
DSMCC-Section 包括了 multi-protocol 封装数据
0×3B
包括了 U-N Messages,除了 Download Data Msg 外(我们经常用 到的是 Download Control Msg)
CRC32:在 ISO/IEC 13818-1 附录 B 中定义。
checksum:
DSMCC Stream Types
DSMCC 定义了不同的 stream_type 值,PMT 的 es_info_loop 中有用到 stream_type 字段,dsmcc section 的 stream_type 描述如下:
table_id:占 8 位,标识了 DSMCC Section 净荷中的数据的类型,该字段定义了 table_id_extension,version_number,section_number 和 last_section_number 这些字段的编码规则。
下表包括 DSMCC table_id 的赋值。
0×0D
Dsmcc Sections(包括私有数据的任何类型)
0×0E-0×7F 保留
0×80-0xFF 用户私有
下面一些限制:
• 只有 table_id 为 0×3A 的 DSMCC Sections 包含 stream type 为 0×0A 的 packets
• 只有 table_id 为 0×3B 和 0×3C 的 DSMCC Section 包含 stream type 为 0×0B 的 TS Packets
下表包括了 DSMCC stream type 的赋值:
stream_type
Description
0×00-0×09 ITU-T Rec.H.220|ISO/IEC 13818-1 定义
0×0A
多协议封装
0×0B
DSMCC U-N Message
0×0C
DSMCC Strem Descriptors
将 DSM-CC 封装成 MPEG-2 Transport Stream(一)
本文为对 ISO-IEC 13818-6 中 9.2 节的翻译,因为里面有些经常用到的概念,为 了方便记忆以及留下痕迹,特写此博。
MPEG-2 Transport Stream 在协议栈(Protocol Stack)
中的角色
dsmcc_section_length:这个占位为 12bit 的字段指示了紧跟在该字段后面的 DSMCC Section 的剩余的字节数,该值不能超过 4093
table_id_extension:16 位的字段,如果 table_id 的值为 0×3B,该字段的值 为 dsmccMessageHeader 中 transaction_id 字段的低 2 个字节;如果 table_id 的值为 0×3C,该字段的值为 DownloadDataBlock 或 DownloadResponse 中的 moduleId 的值。如果既不是 0×3C 也不是 0×3B,则该值由用户所定义。
当 section_syntax_indicator 被设为 0(不用 CRC)并且 checksum 字段也被设 为 0,在其他层会提供一个错误检测,这种需求是强制的(请参考表 9-1 和 download transport protocol requirements)。
对于 MPEG2 传输流更多的与 private_section 相关的文法和语义,请参照 ISO/IEC 13818-1,第 2.4.4 节 Program Specific information,会包括设置 payload_unit_start_indicator,TS 流净荷中 point_field 的设置,以及 packet 中填充字段的用法。
0×3C
包括了 Download Data Messages
0×3D
包括了 Stream Descriptors
0×3E
包括了私有数据
0×3F
ISO/IEC 18318-1 保留
0×40-0xFE
用户私有
0xFF
forbidden
Multi-protocol encapsulated 数据也许包括 U-U RPCs
for (i ==0;i<dsmcc_section_length-9;i++){
private_data_byte
}
}
if (section_syntax_indicator==’0′) {
checksum
32
}
else {
CRC_32
32
}
}
uimsf uimsf
DSMCC Section 各字段的语义
section_syntax_indicator:占 1bit 的字段,当设为‘1’代表校验使用 CRC32 字段,当设为‘0’代表使用 checksum 字段。
private_indicator:占 1bit 的字段,将被设置为 section_syntax_indicator 的反码。
reservedБайду номын сангаас设为‘11’
Syntax DSMCC_section(){ table_id section_syntax_indicator private_indicator reserved dsmcc_section_length table_id_externsion reserved version_number current_next_indicator section_number last_section_number if (table_id==0×3A) { LLCSNAP() } else if (table_id==0×3B) { userNetworkMessage() } else if (table_id==0×3C) { downloadDataMessage()
在某写编码实现中,在 Private_section 中使用 CRC_32 是比较理想的。由于很 多系统对于 CRC_32 的计算很有难度,DSMCC_section 语法提供了 CRC_32 的一个 替代品。为了和 13818-1 一致,如果 section_syntax_indicator 被赋为 1,就 会使用 CRC_32 这种方式,但是如果 section_syntax_indicator 被赋为 0,除了 CRC32 字段被替代为 checksum 字段外,其他字段在和 section_syntax_indicator 被赋为 1 的情况没下没有任何差别。所以还是兼容 13818-1,因为紧跟着 section_length 字段后面的数据都被视为私有数据(private data)。
version_number:这是个 5bit 的字段,如果 table_id 的值为 0×3A 或 0×3B, 该字段设为 0;如果 table_id 为 0×3C 并且是 DownloadData Message,该字段 将会赋于 DDB Message 中 moduleVersion 字段的低 5 位的值;如果 table_id 的 值为 0×3C 并且是 DownloadData Response Message,该字段需被设为 0。如果 table_id 字段不是 0×3A 到 0×3C 中的值,该字段的值由用户所定义。
因为 section_syntax_indicator 字段可能会出错,private_indicator 字段必 须设置为 section_syntax_indicator 的反码,如果 section_syntax_indicator
为 0,那么 private_indicator 必须置为 1,如果不是这样,这个 section 就是 一个错误的 section。类似的,如果 section_syntax_indicator 为 1,则 private_indicator 为 0。