About input/output delay of MediaCodec in MoviePlayer

[bbcallen]

Why no separate input loop and output loop to different threads, to avoid hungry/delay on input side or output side? With separated threads, we can dequeueInputBuffer/dequeueOutputBuffer with a long timeout.

[fadden]

You can only do that if a single MediaCodec instance can be safely accessed from multiple threads simultaneously. The documentation is silent on whether or not this is allowed, so the default assumption is "don't". (None of the CTS tests work this way, and if you've spent some time with MediaCodec you know that anything that isn't explicitly exercised by CTS is unlikely to work across devices.)

As of the Android 5.0 "Lollipop" (API 21) release, you can use MediaCodec in asynchronous mode by providing a callback (http://developer.android.com/reference/android/media/MediaCodec.Callback.html). This is the preferred solution for avoiding the wait loops.

[bbcallen]

In libstagefright, MediaCodec has serialized all operations on a message queue. MediaCodec should be safe if only dequeue/enqueue operations are concurrent. And there is nothing different for the low-level vendor codec implement,

I have did some work here:
feedInputBuffer
https://github.com/bbcallen/ijkplayer/blob/master/ijkmedia/ijkplayer/android/pipeline/ffpipenode_android_mediacodec_vdec.c#L368
drain_output_buffer
https://github.com/bbcallen/ijkplayer/blob/master/ijkmedia/ijkplayer/android/pipeline/ffpipenode_android_mediacodec_vdec.c#L630
These two functions work on different threads.

And MediaCodec works fine on all these devices:
https://github.com/bbcallen/ijkplayer/blob/master/android/ijkmediaplayer/src/tv/danmaku/ijk/media/player/IjkMediaCodecInfo.java#L31

BTW:
Regarding so many devices including some nexus devices won't get "Lollipop" upgrade, asynchronous mode is not a good option for application developers in real world for now, not to mention lack support in NDK.

[fadden]

The problem is that you can't write code against an API according to how it is currently implemented, because the implementation can be changed freely so long as the documented constraints are maintained. I've seen a lot of apps (and vendor-supplied system binaries) break because they depended on details that they shouldn't have. If the developers of the API aren't willing to state, "you may freely use these objects from multiple threads simultaneously", then you must assume that thread safety is not guaranteed.

Thread safety is especially tricky because the consequences can be subtle and hard to reproduce -- very nasty when failures start happening to users on the other side of the world. Given the broad range of devices and software versions, a slight increase in efficiency isn't worth the risk.

If you want to write code that makes assumptions about the internal structure, you are free to do so, with the understanding that even if it's working well today it might break in the future (or have been broken in the past). Grafika is expected to be an example that others will follow, so it needs to follow the API carefully... bad code in Grafika will turn into bad code in a large number of apps.

(See also http://developer.android.com/training/articles/smp.html )

[bbcallen]

Got it, thanks for your reply.