openmax avc 디코더의 대기 시간을 단축하는 방법은 무엇입니까?

나는 openmax의 코덱을 사용하여 안드로이드 화상 회의 응용 프로그램을 작성하려고합니다. avc 디코딩을 위해 OpenMAX IL을 사용했을 때 빈 버퍼 명령을 보내면 버퍼가 채워지는 대기 시간이 커졌습니다. 완료 콜백. 제 경우는 B-Slices가없는 4-cif h.264 기본 스트림을 다루고 있습니다. omx의 호출 순서는 다음과 같습니다.openmax avc 디코더의 대기 시간을 단축하는 방법은 무엇입니까?

avc 디코딩 역할의 openmax 노드를 할당합니다.
중계 노드 상태를 유휴 상태로 전환합니다.
포트 정의를 구성합니다.
입력 및 출력 포트에 버퍼를 할당합니다.
transit 노드가 실행 중임을 나타냅니다.
빈 버퍼 용으로 하나의 스레드를 시작하고 채우기 버퍼 용으로 다른 스레드를 시작하십시오.

로그 출력 도착 메시지 FILL_BUFFER_DONE # 1에 송신되는 빈 버퍼 # 9 명령 8 프레임 대기 시간 있다는 것을 나타낸다. 나는 삼성 전자 -not2와 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

출처

2013-07-02 Zighouse

실제 상황을 모방하기 위해 일부 Sleep을 PushData 스레드에 추가 한 후 (예 : 각 비어있는 버퍼 명령을 보낸 후 40ms를 대기) SamSung Note2에서 대기 시간이 4 프레임 미만으로 단축됩니다. 하지만 내가 원하는 것은 프레임 기반의 지연없이 IOMX를 제어하는 방법을 찾는 것입니다. – Zighouse

. 그것은 (일부 플랫폼 공급 업체 코드에서 그러한 구현을 보았습니다) 출력 버퍼 대기열에 약간의 임계 값이 있으며 FBD가 즉시 전송되지 않을 수도 있습니다. 또한 내부 h264 디코딩 유닛 구현의 특성 일 수도 있습니다.

나는 Tegra (주) 코드가 없지만 Exynos 구현은 기본적으로 aosp에서 사용할 수 있습니다. 당신이 빌드/업로드 * .so 수 있다고 가정하면 I- 프레임 디코딩 모드에서 일부 측정을 시작합니다. Exynos에서는 (다른 경우와 마찬가지로) 썸네일 모드에 의해 트리거되지만 꽤 자주 통합자가 썸네일 생성을위한 기본값으로 Google의 디코더를 설정한다는 것을 알고 있어야합니다.이 경우 제거해야하거나 높은 프로필 (Google 코덱 그것이 기본 및 기준선을 뒷받침하고 있기 때문에 실패 할 것이고 그 다음에는 공급 업체의 것을 계속할 것입니다).

표준 재생을 위해 IFrameMode를 설정할 수도 있습니다. 참고로 마스터 분기에 대한 decode/omx Exynos 구현을 살펴보십시오. 즉, 코덱 구성 단계에서 V4L2_CID_MPEG_MFC51_VIDEO_I_FRAME_DECODING을 보내야합니다.

I 프레임 모드의 IMHO 대기 시간은 일부 고급 최적화가없는 일반 디코딩에 대한 일종의 점근 현상입니다. 다음 단계에서는 커널을 포함하여 하위 계층에서 타이밍 측정을 수행합니다. 정기적 인 디코딩과 비교하여 모든 결과는 가능한 경우 전체 그림을 제공하고 대기 시간을 최적화하는 방법과 방법을 제공합니다.

출처

2013-12-19 14:42:22

openmax avc 디코더의 대기 시간을 단축하는 방법은 무엇입니까?

답변

관련 문제