2013-07-02 63 views
1

我正在嘗試使用openmax編解碼器編寫android視頻會議應用程序。 當我利用OpenMAX IL進行avc解碼時, 發現發送空緩衝區命令到填充緩衝區 做過回調的時間很長。 我的情況是處理沒有B-切片的4-cif h.264基本流。 我的omx呼叫序列是:如何縮短openmax avc解碼器的延遲?

  1. 分配avc解碼角色的openmax節點;
  2. 將節點的狀態轉換爲空閒狀態;
  3. 配置端口定義;
  4. 爲輸入和輸出端口分配緩衝區;
  5. 將節點的狀態轉爲執行;
  6. 爲空緩衝區啓動一個線程,爲填充緩衝區啓動另一個線程;

日誌輸出表明存在8幀的等待時間, 來自空緩衝區#9命令發送到消息FILL_BUFFER_DONE#1到達。 我已經測試了三星note2和HTC-ONE-X和其他一些手機, 都有一個很大的解碼延遲。

對於視頻會議應用程序的接受程度來說,這個延遲很大。 任何人都可以幫助我縮短這種延遲?

日誌輸出雲:


I/java:TestKdavc(19867): video test started 
I/java:TestKdavc(19867): set video source: /sdcard/DCIM/vidrev.dat 
I/testkdavc/testkdavc.cpp(19867): [[email protected]] frame dimesion: 704 x 576 
I/OMXClient(19867): Using client-side OMX mux. 
D/avc/omxctrl.cpp(19867): [[email protected]] mComType = 1 
D/avc/omxctrl.cpp(19867): [[email protected]] tid = 1074982704 
D/avc/omxctrl.cpp(19867): [[email protected]] m_node = 4136a16c 
D/avc/omxctrl.cpp(19867): [getVideoPor[email protected]] nPorts = 2, iport = 0, oport = 1 
D/avc/omxctrl.cpp(19867): [[email protected]] mComType = 1, port = 0, info.nBufferCountActual = 5, info.nBufferSize = 50688, info.nBufferCountMin = 5 
D/avc/omxctrl.cpp(19867): [[email protected]] mComType = 1, port = 1, info.nBufferCountActual = 2, info.nBufferSize = 608256, info.nBufferCountMin = 2 
D/avc/omxctrl.cpp(19867): [[email protected]] mComType = 1, portIndex = 0, def.nBufferCountActual = 5, def.nBufferSize = 608256, def.nBufferCountMin = 5, buffersize = 608256 
D/avc/omxctrl.cpp(19867): [[email protected]] before useBuffer 
D/avc/omxctrl.cpp(19867): [[email protected]] before useBuffer 
D/avc/omxctrl.cpp(19867): [[email protected]] before useBuffer 
D/avc/omxctrl.cpp(19867): [[email protected]] before useBuffer 
D/avc/omxctrl.cpp(19867): [[email protected]] before useBuffer 
D/avc/omxctrl.cpp(19867): [[email protected]] mComType = 1, portIndex = 1, def.nBufferCountActual = 2, def.nBufferSize = 608256, def.nBufferCountMin = 2, buffersize = 608256 
D/avc/omxctrl.cpp(19867): [[email protected]] before allocateBufferWithBackup 
D/avc/omxctrl.cpp(19867): [[email protected]] before allocateBufferWithBackup 
D/avc/omxctrl.cpp(19867): [[email protected]] mComType: 1, OMX_CommandStateSet, state: 2 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: EVENT 
D/avc/omxctrl.cpp(19867): [[email protected]] mComType: 1, OMX_CommandStateSet, state: 3 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: EVENT 
D/avc/omxctrl.cpp(19867): [[email protected]] mComType = 1, m_vecOutputBuffers.size() = 2, err = 0 
I/testkdavc/testkdavc.cpp(19867): [[email protected]] found AVC/H264 decoder: OMX.SEC.AVC.Decoder, color format: OMX_COLOR_FormatYUV420Planar 
I/testkdavc/testkdavc.cpp(19867): [[email protected]] start feed 
I/avc/omxctrl.cpp(19867): [[email protected]] empty buffer #1 
I/avc/omxctrl.cpp(19867): [[email protected]] empty buffer #2 
I/avc/omxctrl.cpp(19867): [[email protected]] empty buffer #3 
I/avc/omxctrl.cpp(19867): [[email protected]] empty buffer #4 
I/avc/omxctrl.cpp(19867): [[email protected]] empty buffer #5 
I/avc/omxctrl.cpp(19867): [[email protected]] fill buffer #1 
I/avc/omxctrl.cpp(19867): [[email protected]] fill buffer #2 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: EMPTY_BUFFER_DONE #1 
I/avc/omxctrl.cpp(19867): [[email protected]] empty buffer #6 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: EMPTY_BUFFER_DONE #2 
I/avc/omxctrl.cpp(19867): [[email protected]] empty buffer #7 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: EMPTY_BUFFER_DONE #3 
I/avc/omxctrl.cpp(19867): [[email protected]] empty buffer #8 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: EMPTY_BUFFER_DONE #4 
I/avc/omxctrl.cpp(19867): [[email protected]] empty buffer #9 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: FILL_BUFFER_DONE #1 
I/testkdavc/testkdavc.cpp(19867): [[email protected]] get frame #1 of 704 x 576 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: EMPTY_BUFFER_DONE #5 
I/avc/omxctrl.cpp(19867): [[email protected]] fill buffer #3 
I/avc/omxctrl.cpp(19867): [[email protected]] empty buffer #10 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: FILL_BUFFER_DONE #2 
I/testkdavc/testkdavc.cpp(19867): [[email protected]] get frame #2 of 704 x 576 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: EMPTY_BUFFER_DONE #6 
I/testkdavc/testkdavc.cpp(19867): [[email protected]] retry put data 
I/avc/omxctrl.cpp(19867): [[email protected]] message type: FILL_BUFFER_DONE #3 
I/testkdavc/testkdavc.cpp(19867): [[email protected]] get frame #3 of 704 x 576 
+0

在PushData線程中添加一些睡眠模擬實際情況後,例如在發送每個空緩衝區命令之後睡眠40毫秒後,SamSung Note2上的延遲縮短到小於4幀。但我想要的是找到一種方法來控制IOMX,而不會在幀的基礎上延遲。 – Zighouse

回答

0

我不會在意相對延遲,而是測量時間單位的延遲,然後試圖找出產生的延遲,。可能是這樣的(我在某些平臺供應商代碼中看到了這樣的實現)輸出緩衝隊列中存在一些閾值,並且不立即發送FBD。它也可能是內部h264解碼單元實現的一個特徵。

我沒有Tegra(note)的代碼,但Exynos實現默認情況下可從aosp獲得。假設你能夠構建/上傳* .so,我將從I幀解碼模式開始做一些測量。在Exynos中(和其他情況一樣),它是通過縮略圖模式觸發的,但請注意,經常集成商將谷歌解碼器設置爲默認縮略圖創建 - 在這種情況下,您必須擺脫這種情況或運行縮略圖創建高調(谷歌的編解碼器將失敗,因爲它支持主要和基線afair,然後將繼續供應商的一個)。

您也可以爲常規回放設置IFrameMode查看主分支的decode/omx Exynos實現以供參考,即您需要在編解碼器配置階段發送V4L2_CID_MPEG_MFC51_VIDEO_I_FRAME_DECODING。

對於I幀模式的恕我直言延遲將是某種常規解碼的漸近線(沒有一些高級優化)。在下一步中,在包括內核在內的較低層進行一些時序測量。所有與常規解碼相比較的結果將爲您提供完整的圖片,如果可能的話,在何處以及如何優化延遲。