4

I have a project based off of https://ikaruga2.wordpress.com/2011/06/15/video-live-wallpaper-part-1/, which uses an older copy of the ffmpeg libraries from http://bambuser.com/opensource. Within the C++ code in this project we have the following lines of code:

        unsigned long long current = GetCurrentTimeInNanoseconds();
        avcodec_decode_video(pCodecCtx, pFrame, &frameFinished, packet.data, packet.size);
        __android_log_print(ANDROID_LOG_DEBUG, "getFrame>>>>", "decode video time: %llu", (GetCurrentTimeInNanoseconds() - current)/1000000);

This code continually reports between 60 and 90 ms to decode each frame on an Xperia Ion, using a 1280x720 h264 source video file. Other processing to get the frame out to the screen takes an average of 30ms more with very little variation. This leads to frame rates of 10-11fps.

Ignoring that other processing, a decode that takes an average of 75ms would result in 13fps. However, when I browse my SD card and click on that mp4 file to open it in the native viewer, it shows at a full 30fps. Further, when I open a 1920x1080 version of the same mp4 in the native viewer it also runs at a full 30fps without stutter or lag. This implies (to my novice eye) that something is very very wrong, as the hardware is obviously capable of decoding many times faster.

What flags or options can be passed to avcode_decode_video to optimize decode speed to match that of the native viewer? Can optimizations be made elsewhere to optimize speed further? Is there a reason that the native viewer can decode almost an order of magnitude faster (taking into account the 1920x1080 source results)?

EDIT

The answer below is very helpful, but is not practical for me at this time. In the mean time I have managed to decrease decoding time by 70% with some optimal encoding flags found through many many hours of trial and error. Here are the ffmpeg arguments I'm using for encoding in case it helps anyone else who stumbles across this post:

        ffmpeg.exe -i "#inputFilePath#" -c:v libx264 -preset veryslow -g 2 -y -s 910x512 -b 5000k -minrate 2000k -maxrate 8000k -pix_fmt yuv420p -tune fastdecode -coder 0 -flags -loop -profile:v main -x264-params subme=5:ref=4 "#ouputFilePath#"

With these settings ffmpeg is decoding frames in 20-25 seconds, though with the sws_scale and then writing out to the texture I'm still hovering at ~22 FPS on an Xperia Ion at a lower resolution than I'd like.

Nicholas
  • 1,734
  • 3
  • 19
  • 42

1 Answers1

1

The native viewer uses hardware h264 decoder, while ffmpeg is usually compiled software-only. You must build ffmpeg with libstagefright.

libstagefright option has been pulled

Alex Cohn
  • 52,705
  • 8
  • 94
  • 269
  • Thank you. Would you be able to provide a link to instructions on how to do that or a download location to get compiled libraries? The latter is relevant as the last time I tried to compile ffmpeg (steps 3-8 at the link I provided) it proved impossible as I have Windows, don't have access to a Linux machine, and CygWin simply refused to work. – Nicholas Mar 31 '15 at 12:55
  • 1
    Compiling ffmpeg on Windows is a torture, and cross-compiling it for Android is a torture in a square. I suggest that you download a VirtualBox or other free virtual machine environment and install Ubuntu there. You can find prebuilt library at http://www.origenboard.org/wiki/index.php/FFmpeg_on_Android, but I don't have personal experience with this project. – Alex Cohn Mar 31 '15 at 15:47
  • Look also at http://stackoverflow.com/questions/4725773/ffmpeg-on-android and references therein. – Alex Cohn Mar 31 '15 at 15:50
  • Thank you; I'll review them later and post back to let you know the results. – Nicholas Mar 31 '15 at 16:52
  • I looked through both links, and the links within each. Unfortunately, I couldn't find much in terms of prebuilt libraries. I'll continue working with this and post back when/if I find anything. – Nicholas Apr 03 '15 at 01:14
  • 1
    [avcodec: Remove libstagefright](http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=72673ad7eae2d4f685f3c0a895558502bfe07c8e). – llogan Jan 06 '16 at 18:37