CODEWITHSUNDEEP
androidperformanceffmpegdelaydecode
Kelvin Tan
Kelvin Tan

Reputation: 992

Strange performance of avcodec_decode_video2

I am developing an Android video player. I use ffmpeg in native code to decode video frame. In the native code, I have a thread called decode_thread that calls avcodec_decode_video2() 

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

I have another thread called display_thread that uses aNativeWindow to display a decoded frame on a SurfaceView.

The problem is that if I let the decode_thread run continuously without a delay. It significantly reduces the performance of avcodec_decode_video2(). Sometimes it takes about 0.1 seconds to decode a frame. However if I put a delay on the decode_thread. Something likes this. 

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

The performance of avcodec_decode_video2() is really good, about 0.001 seconds. However putting a delay on the decode_thread is not a good solution because it affects the playback. Could anyone explain the behavior of avcodec_decode_video2() and suggest me a solution?

Upvotes: 0

Views: 1012

Answers (1)

George Y.
George Y.

Reputation: 11799

It looks impossible that the performance of video decoding function would improve just because your thread sleeps. Most likely the video decoding thread gets preempted by another thread, and hence you get the increased timing (hence your thread did not work). When you add a call to usleep, this does the context switch to another thread. So when your decoding thread is scheduled again the next time, it starts with the full CPU slice, and is not interrupted in the decode_ video2 function anymore.

What should you do? You surely want to decode packets a little bit ahead than you show them - the performance of avcodec_decode_video2 certainly isn't constant, and if you try to stay just one frame ahead, you might not have enough time to decode one of the frames.

I'd create a producer-consumer queue with the decoded frames, with the top limit. The decoder thread is a producer, and it should run until it fills up the queue, and then it should wait until there's room for another frame. The display thread is a consumer, it would take frames from this queue and display them.

Upvotes: 1

Related Questions