2013-07-02 1 views
1

Я пытаюсь написать приложение для видеоконференции Android с помощью кодека openmax. Когда я справился с OpenMAX IL для декодирования avc, нашел большую задержку отправки пустой буферной команды для заполнения буфера выполненного обратного вызова. В моем случае речь идет об элементарном потоке 4-cif h.264 без B-Slices. Моя вызывающая последовательность omx:Как сократить латентность avc-декодера openmax?

  1. выделить узел openmax роли декодирования avc;
  2. переход состояния узла в режим ожидания;
  3. Конфигурирование определений портов;
  4. выделение буферов для входных и выходных портов;
  5. переводит состояние узла на выполнение;
  6. запустите один поток для пустых буферов и еще один поток для буферов заполнения;

В журнале результатов показывают, что существует 8-кадр задержки, из пустого буфера команды # 9 отправить сообщение FILL_BUFFER_DONE # 1 прибыл. У меня есть тест на samsung-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): [[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 мс после отправки каждой пустой команды пула, латентность сокращается до менее 4 кадров на SamSung Note2. Но я хочу найти способ управления IOMX без каких-либо задержек на фреймовой основе. – Zighouse

ответ

0

Я не забочусь относительную задержку, а измерения задержки в единицах времени, а затем попытаться определить, где генерируется задержка. Возможно, что (я видел такую ​​реализацию в каком-то коде поставщика платформы), есть некоторый порог в очереди выходных буферов, и FBD не отправляется немедленно. Это также может быть характеристикой внутренней реализации блока декодирования h264.

У меня нет кода Tegra (примечание), но реализация Exynos по умолчанию доступна из aosp. Предполагая, что вы можете создавать/загружать * .so, я бы начал с выполнения некоторых измерений в режиме декодирования I-кадра. В Exynos (как и в других случаях) он запускается в режиме эскизов, но имейте в виду, что довольно часто интеграторы устанавливают декодер google по умолчанию для создания миниатюр - в этом случае вы должны избавиться от этого или запустить создание миниатюр для высокого профиля (кодек google будет терпеть неудачу, поскольку он поддерживает основную и базовую ситуацию, а затем продолжит работу с поставщиком).

Вы также можете установить IFrameMode для обычного воспроизведения в режиме декодирования/omx Exynos для основной ветви для справки, то есть вам нужно отправить V4L2_CID_MPEG_MFC51_VIDEO_I_FRAME_DECODING в фазе конфигурации кодека.

Задержка IMHO для режима I-кадра будет какой-то асимптотой для регулярного декодирования (без некоторых дополнительных оптимизаций). На следующем шаге сделайте некоторые временные измерения в нижних слоях, включая ядро. Все результаты по сравнению с обычным декодированием дадут вам полную картину, если это возможно, где и как оптимизировать латентность.