Странное исполнение avcodec_decode_video2

Question

Я разрабатываю Android-плеер для Android. Я использую ffmpeg в собственном коде для декодирования видеофрагмента. В родном коде, у меня есть нить под названием decode_thread, который вызывает avcodec_decode_video2()

int decode_thread(void *arg) { 
    avcodec_decode_video2(codecCtx, pFrame, &frameFinished,pkt); 
} 

У меня есть еще один поток, называемый display_thread, который использует aNativeWindow для отображения декодированного кадра на SurfaceView.

Проблема в том, что если я разрешаю decode_thread работать непрерывно без задержки. Это значительно снижает производительность avcodec_decode_video2(). Иногда для декодирования кадра требуется около 0,1 секунды. Однако, если я положил задержку на decode_thread. Что-то это нравится.

int decode_thread(void *arg) { 
    avcodec_decode_video2(codecCtx, pFrame, &frameFinished,pkt); 
    usleep(20*1000); 
} 

Производительность avcodec_decode_video2() действительно хорошо, приблизительно 0,001 секунды. Однако откладывание задержки на decode_thread не является хорошим решением, поскольку оно влияет на воспроизведение. Может ли кто-нибудь объяснить поведение avcodec_decode_video2() и предложить мне решение?

Answer 1

Похоже, что производительность функции декодирования видео улучшится только потому, что ваш поток спит. Скорее всего, поток декодирования видео вытесняется другим потоком, и, следовательно, вы получаете увеличенное время (следовательно, ваш поток не работает). Когда вы добавляете вызов к usleep, это переключает контекст в другой поток. Поэтому, когда ваш поток декодирования снова запланирован в следующий раз, он начинается с полного фрагмента процессора и больше не прерывается в функции decode_ video2.

Что вы должны сделать? Вы, конечно же, хотите немного расшифровать пакеты, чем вы их показываете, - производительность avcodec_decode_video2, конечно же, не постоянна, и если вы попытаетесь остановиться всего на один кадр вперед, у вас может не хватить времени для декодирования одного из фреймов.

Я создал бы очередь производителей-потребителей с декодированными кадрами с верхним лимитом. Поток декодера является производителем, и он должен работать до тех пор, пока он не заполнит очередь, а затем он должен ждать, пока есть место для другого кадра. Поток отображения является потребителем, он будет принимать кадры из этой очереди и отображать их.