[h264 @ 0x55abeda05080] error while decoding MB 0 14, bytestream 104435

為什麼一定要用多程序

• 一方面：如果采取pipeline的模式進行目辨別别，先讀取資料再識别，會有下面的報錯：

[h264 @ 0x55abeda05080] left block unavailable for requested intra mode
[h264 @ 0x55abeda05080] error while decoding MB 0 14, bytestream 104435
           

• 目前比較靠譜的一種解釋是“FFMPEG Lib does not support H264 videos in the rtsp protocol”。H264是當今流行的視訊壓縮格式；ffmpeg是一個開源庫，實作了對h264視訊檔案的解壓縮。
• 目前的opencv中的H264編碼實際上是向下調用ffmpeg的，ffmpeg中又調用了libx264，它執行的就是視訊流解碼的工作。是以報錯大機率也是從這個庫來的。然後我們進一步定位。

  

• 發現H264除了使用幀内壓縮之外，還使用了幀間壓縮；H264采用了獨特的I幀、P幀和B幀政策來實作，連續幀之間的壓縮。那麼也就是說在解碼的時候如果不能有H264壓縮時候需要的幀，就不能正确解碼。但是我們由于讀取圖檔和目标檢測是放在一起的，導緻傳輸堵塞。
• 解決方案是：讀取和識别分開進行。
• 另一方面，如果讀取速度低于視訊流的輸出速度，視窗顯示的圖檔是好幾秒鐘前的内容。一段時間過後，緩存區将會爆滿，程式報錯。
• 解決方案是：建立一個隊列，線程A從通過rtsp協定從視訊流中讀取出每一幀，并放入隊列中，線程B從隊列中将圖檔取出，處理後進行顯示。線程A如果發現隊列裡有兩張圖檔（證明線程B的讀取速度跟不上線程A），那麼線程A主動将隊列裡面的舊圖檔删掉，換上新圖檔。
• 由于程序間是獨立的，是以一個程序的崩潰不會影響其他程序。
• 同一個程序可以共享記憶體，程序間獨立，實作了資源隔離。/