MediaCodec does not return buffers when Traceview Method Profiling is running

Question

It seems like MediaCodec does not return input or output buffers when Traceview Method Profiling is enabled. Steps to reproduce:

1. In Eclipse, run Grafika.
2. In Grafika, select "Play Video (TextureView)" and tap "Start".
3. In Eclipse DDMS, click "Start Method Profiling" and leave the dialog box open.
4. In Grafika, tap "Play" and quickly go back to Eclipse and click "OK". Once you click "OK", Grafika will appear to hang (it does not draw any more frames).

Grafika verbose logs show that no input or output buffer is available from MediaCodec until Method Profiling is stopped.

My guess is that MediaCodec does some Looper stuff under the covers and maybe that conflicts with how Traceview is implemented, but that is just a guess.

Is this a known issue? Is there a way to workaround it and profile apps using MediaCodec?

Answer 1

Whoops.

From dalvik/vm/Thread.cpp (line 2105):

/*
 * If we're doing method trace profiling, we don't want threads to exit,
 * because if they do we'll end up reusing thread IDs.  This complicates
 * analysis and makes it impossible to have reasonable output in the
 * "threads" section of the "key" file.

Ordinarily this works out fine -- if the thread is exiting, it has nothing left to do, so it doesn't matter if we keep it around a bit longer. The signaling for Thread#join() has already happened, so there's nothing left to do.

But in this case, the thread was temporarily attached to the VM by the native ACodec thread that provides the onFrameAvailable() callback. So this pure-native thread wants to attach itself to the VM, invoke the callback, detach itself, and go back to work. But because method profiling is active, the thread detach stalls until method profiling completes... but method profiling won't complete until code execution resumes. So we're deadlocked.

So there's two problems here:

1. Dalvik shouldn't be keeping the thread alive. It would make method profiling more complicated since it loses the convenient unique thread ID, but that's just a matter of housekeeping.
2. libstagefright shouldn't be attaching and detaching every time it wants to send a "frame available" message. That's a relatively expensive operation that requires allocating a Thread object, foiling attempts to run allocation-free.

I don't see a clean way to work around this by changing the app -- you'd have to go without the frame available notification. The best bet is to forgo the TraceView profiling and use systrace instead.