多媒體串流封包格式定義

儘管 Zigbee 無線感測網路已為相當成熟的技術，但 Zigbee 網路的傳送速率 最高依舊僅有 250kbps，無法與其他通訊協定(如：WiFi、藍芽)的傳輸速率相提並 論，且經由不同的傳輸介面可能造成 Zigbee 傳送速率下降，如本論文所使用之

CC2530 與 BeagleBone 連結的 UART 介面，其 Baud Rate 最高設定為 230400，因 此最大傳輸速率將會限制於 184 kbps 內，然而本系統架構所使用的 CC2530

payload 最大僅 116Bytes ，由上述可得知選擇一個可靠的多媒體編碼器為最優先 的課題。

而經由第二章簡介所選擇的 Speex 語音壓縮技術以及 x264 影像壓縮技術，

語音方面儘管 Speex 具備良好的封包遺失處理能力，但 Speex 語音 Frame 若遭到

Zigbee 封包不規則的切割後傳送，在被切割的 Frame 出現封包遺失時會形成語音 僅剩一半的語音 Frame 無法順利解碼現象，連帶造成後方資訊皆無法解碼的嚴重 影響，因此在利用 Speex 編解碼器的同時設計一個健全的封包格式，以符合

CC2530 無線傳輸晶片中 116 Bytes 的 Payload 大小，使語音封包儘管於傳送過程 發生封包遺失狀況下，在接收端在使用 Speex 解碼器也不會造成語音 Frame 解碼 的錯誤。

在本論文中將採用 Speex 中的窄頻模式，使用其中 15Kbps、11Kbps、8Kbps、

6Kbps、4Kbps 五種不同壓縮率進行實驗，以窄頻 8Kbps 壓縮率為例，8Kbps 的壓

縮 Frame 大小是由 320Byte 的數位資訊進行壓縮所組成的一個 20Byte 的語音 Frame，可進行 20ms 時間長度播放的語音資訊，Speex 編碼格式如表 4 所示，

Speex Header 內可放置多種類別，能夠依據 Header 進行語音解碼型態的區分以及 動態調整解碼器，由於嵌入式平台運算能力有限在平台上僅運行一種語音壓縮技 術，且僅使用窄頻模式，因此能夠減少 Header 中的內容並於本論文中僅存放 4Byte 的 Speex frame size，由於 Header 夾帶資訊內容為不同 Bit-Rate 壓縮後的 Frame

Size，8Kbps 的 Frame Size 為 20 Byte 因此在 4 Byte 的 Header 中將會放入 4 個 16 進制內容依序 00、00、00、14，代表後面語音資料的大小，解碼器再依據 Speex

Header 的資訊進行不同編碼率的辨識進行解碼的動作。

表 4、Speex Header

Field Type Size

Speex_string Char[] 8

Speex_version Char[] 20

Speex_version_id int 4

Header_size int 4

Rate int 4

Mode int 4

Mode_bitstream_version int 4

Nb_channel int 4

Frame_size int 4

Vbr int 4

Frame_psr_packet int 4

Extra_headers int 4

Reserved1 int 4

Reserved1 int 4

圖 12、Speex 標準編碼格式

然而在 Speex 編碼格式如圖 12 所示，中每個 Frame 前都夾帶有 4 個 Bytes 紀 錄 Frame Size 的標頭檔，若一個封包中夾帶了 4 個 Frame 則需夾帶 4*4 Byte 的標 頭檔用於資料的記錄，由於相同編碼率下的標頭檔內容都是相同的，因此在標頭 檔上我們僅需保留一個並刪除多餘的，在有限的 payload 避免無謂的浪費，其本 論文所設計之 Speex 封包格式為圖 13 所示，以窄頻 8Kbps 為例可發現原始格式 僅能放入 4 個語音 Frame 相當於 80ms 的聲音，在去除掉多餘的標頭檔後可多放 入一個語音 Frame 相當於 100ms 的聲音。在高壓縮率的 Bitrate 下單一封包可以 攜帶的 Frame 個數即大於高品質的 Frame 個數，換言之在較低 Bitrate 下可將較 多的 Frame 數進行傳送。

圖 13、CC2530 語音封包格式

表 5 中為窄頻於一個 Zigbee 封包中所有編碼率所對應的 Frame size，經過本

Frame size (Byte)

Original frame number

Designed frame number