背景： 我使用ffmpeg編碼了一個原始h264文件。我正在嘗試創建自己的容器，如Smooth Streaming如何與碎片化的mp4容器一起使用。我對平穩流的安全性並不滿意，但任何人都可以通過適當的身份驗證從IIS中完全擷取文件。如何獲得給定h264流（Silverlight）的精確持續時間？
問題 反正我有我的原H264碼流播放「還挺」 Silverlight中使用媒體流與啓用了SSL的工作，但我不能讓我爲我是從服務器端發送到媒體流夾頭時間戳權在silverlight客戶端內。在sp2 Nals解析的h264數據塊之間存在延遲。我看到this question獲得持續時間。想知道是否有一種簡單的方法來計算h264流中的幀並獲取持續時間，以便我可以將準確的時間戳傳遞給MediaSampleSource。如果有人可以A：指向我的開源框架計數器的方向，或給我一些僞解析幀的代碼（也許一些十六進制解析提示）。或者，也許有人對這個確實很好的問題有一些經驗。任何幫助將不勝感激。提前致謝。
我通過ISO 14496-10文檔挖掘並發現了一些十六進制字符串在原始h264碼流尋找框：
0x00000141， 0x00000101， 0x00000165
如果你通過你的流並計數這些十六進制字符串和您的編碼與ffmpeg和libx264這應該讓你一個非常穩固的幀數。 （如果我錯了，請有人糾正我）。因此，如果您擁有h264視頻的總持續時間，並且您擁有應該可以從ffmpeg輕鬆獲得的FPS，那麼您可以使用在傳遞給MediaStreamSource的任何給定數據塊中計算的幀數，以獲得爲您提供非常準確的TimeStamp MediaSampleSource。希望這可以幫助某人，因爲前幾天我的回放震動時，真的讓我很沮喪。
編輯
正如我已經測試DirectShow中我的播放功能我已經注意到，這不是完美的，僅適用於使用的ffmpeg簡單地編碼H264流。 h264具有可變的幀率和比特率。雖然視頻運行非常順暢，但眼光敏銳的人可以看到，在視頻中更復雜的序列中，時序有點尷尬。我認爲對於一個粗糙的視頻流播放器來說，這是一個很好的方法，特別是如果經常使用關鍵幀。我認爲在我點擊回答之前添加此內容是公平的。
這實際上是一個兔子洞的位。從ISO 14496第10部分開始，並轉到7.3節的語法。
第一個近似值是使用vui_parameters（num_units_in_tick/time_scale）中的字段速率和slice_header（）的數量。
這打破了，如果你）■處理高清內容和您的編碼器使用多個slice_header（每張照片（然後你必須檢查first_mb_in_slice == 0）。
您必須注意frame_mbs_only_flag和field_pic_flag。
另一個毛球是表D-1，它解釋了pic_timing SEI消息的pic_struct字段。這包括場重複（TBT或BTB），幀倍增和幀三倍等。
如果您有傳輸流，您可以通過檢查PES標頭（ISO 13818第1部分）上的第一個和最後一個訪問單元的DTS值來結束運行。