首先,這是乙個典型的sample table box:
一、stbl box中常見的子box:
stts:decoding time to sample box時間戳和sample對映表。通過這個box可以實現時間到sample number的對映。
stsd:sample description,主要描述當前track有關的編碼資訊，以及用於初始化解碼的附加資訊。
stsz,stz2:sample size boxes每個sample大小的表。
stsc:sample to chunk的對映表。
stco,co64:chunk位置偏移表。
stss：關鍵幀index。
二、對主要的子box進行解析:
(2)解析stsz box 可以獲得乙個sample size的表。
filed name
type
size(bits)
fullbox header
------
sample_size
uint32
32sample_count
uint32
32entry_size
uint32
varies
sample_size中表示sample長度，如果是0表示每個sample長度不定，會記錄在entry_size中；否則每個sample長度一樣，並且entry_size域不存在。
'stz2' box中的entry_size是compact的，長度由特定字段指定。
(3)解析stsc還原sample 與chunk的對映表,記錄了每個chunk中包含多少sample，其結構定義如下：
filed name
type
size(bits)
fullbox header
------
entry_cout
uint32
32chunk_entry
uint32[3]
varies
chunk_entry包含三個字段：
first_chunk: uint32
samples_per_chunk: uint32
sample_description_index: uint32
每個entry表示從first_chunk開始的每個chunk都包含samples_per_chunk個samples，這些sample都可以用使用sample_description_index資訊解碼。通過這個box，可以構建出當前track的chunk結構，及其包含的sample。
sample 是儲存的最基本單元，mp4把sample 存在chunk中。chunk的長度、chunk的大小、chunk中sample的數量及大小都是不定的。通過解析這部分box來還原這個對映表。
(4) 「stco」這個box記錄了chunk對應的offset，只是包含字段乙個是32為（'stco'），乙個是64位（'co64'）。
chunk offset box中記錄都是相對檔案的偏移量，可以直接通過這些資訊讀取。
三、小結
由於'mdat' box中的多**資料是沒有結構的，只能參考moov的trak box解析。反過頭來。我們看一下針對單個track中的media資訊儲存應該是下面的結構
|chunk #0| chunk#1| ... | chunk #n|
每個chunk的構成是下面的結構：
|sample #0|sample #1| ... | sample #n|
從trak box中的minf中可以看出，每個chunk的長度不定，其所包含的sample數目不同，每個sample的長度也不完全相同。
編譯sample遇到的錯誤
無論是編譯sdk的sample，還是nokiacv附帶的例子，常常遇到莫名其妙的錯誤。更莫名其妙的是，有時候沒改過什麼，錯誤就沒了。摸索了兩天，覺得編譯乙個project的流程大致如下，假設project已經匯入或者建立，carbide.c v2.0.2 1，build configuration ...
切片分析報告格式 端子切片分析報告
mm 線材導體根數 若為編織，此項填na 導體壓接高 度cch 0.76 上公差0.05 下公差0.05 導體壓接寬度 ccw1.45 上公差0.05 下公差0.05 a.檢查項 1 壓接高度 crimp height ch 2 壓接寬度 crimp width cw 3 芯線導體根數 count ...
Android HAL分析報告
1 hal簡介 android 的 hal hardware abstract layer硬體抽象層 是google因應廠商 希望不公開原始碼 的要求下，所推出的新觀念，其架構如下圖。雖然 hal 現在的 抽象程度 還不足，現階段實作還不是全面符合 hal的架構規劃，不過也確實給了我們很好的思考空間...