Android MediaCodec 在异步模式下比在同步模式下慢?
Android MediaCodec slower in async-mode than in synchronous mode?
同样,我有一个关于 Android 的 MediaCodec class 的问题。
我已成功解码原始 h264 内容并在两个 TextureView 中显示结果。
h264 流来自 运行 openGL 场景的服务器。
场景有一个摄像头,因此可以响应用户输入。
为了进一步减少服务器上的输入与智能手机上的实际结果之间的延迟,我正在考虑在其异步模式下使用 MediaCodec。
以下是我设置两种变体的方式:同步和异步:
异步:
//decoderCodec is "video/avc"
MediaFormat fmt = MediaFormat.createVideoFormat(decoderCodec, 1280,720);
codec.setCallback(new MediaCodec.Callback() {
@Override
public void onInputBufferAvailable(MediaCodec codec, int index) {
byte[] frameData;
try {
frameData = frameQueue.take(); //this call is blocking
} catch (InterruptedException e) {
return;
}
ByteBuffer inputData = codec.getInputBuffer(index);
inputData.clear();
inputData.put(frameData);
codec.queueInputBuffer(index, 0, frameData.length, 0, 0);
}
@Override
public void onOutputBufferAvailable(MediaCodec codec, int index, MediaCodec.BufferInfo info) {
codec.releaseOutputBuffer(index, true);
}
//The two other methods are left blank at the moment.
});
codec.configure(fmt, surface, null, 0);
codec.start();
Sync:(除 codec.setCallback(...)
部分外,设置与 Async 类似。两个变体所在的 class 是子 class Runnable
.
public void run() {
while(!Thread.interrupted())
{
if(!IS_ASYNC) {
byte[] frameData;
try {
frameData = frameQueue.take(); //this call is blocking
} catch (InterruptedException e) {
break;
}
int inIndex = codec.dequeueInputBuffer(BUFFER_TIMEOUT);
if (inIndex >= 0) {
ByteBuffer input = codec.getInputBuffer(inIndex);
input.clear();
input.put(frameData);
codec.queueInputBuffer(inIndex, 0, frameData.length, 0, 0);
}
MediaCodec.BufferInfo bufferInfo = new MediaCodec.BufferInfo();
int outIndex = codec.dequeueOutputBuffer(bufferInfo, BUFFER_TIMEOUT);
if(outIndex >= 0)
codec.releaseOutputBuffer(outIndex, true);
}
else sleep(3000); //Just for testing, if we are in Async, this thread has nothing to do actually...
}
}
这两种方法都有效,但我观察到在同步模式下播放的视频更流畅,延迟也更低。
我想出了使用异步模式的想法,因为 frameQueue
是一个 LinkedBlockingDeque
并且我推断如果同步解码器等待新帧数据到达的时间过长,解码输出可能已经可用但不会显示,因为队列的阻塞性质。另一方面,我不想做 busy wait
之类的事情并一直轮询队列、inputBuffers 和 outputBuffers。
所以我尝试了使用回调的异步模式,但我得到的结果比同步模式更糟糕。
我现在要问你们的问题是:
为什么?我是否滥用了异步模式?还是其他原因?
感谢任何反馈!
克里斯托夫
编辑:
以下是更新后的代码。我只列出更新的部分。这样
@mstorsjo 正确指出,罪魁祸首是我在 onInputBufferAvailable()
中等待更多帧数据。更新版本为另一个 BlockingQueue 提供可用的缓冲区索引。在另一个线程中,我们正在等待新的帧数据和新的缓冲区索引来对帧数据进行排队以进行解码。
public class DisplayThread implements Runnable {
private BlockingQueue<Integer> freeInputBuffers;
//skipped the uninteresting parts.
private void initCodec(String decoderCodec) {
//skipped the uninteresting parts.
codec.setCallback(new MediaCodec.Callback() {
@Override
public void onInputBufferAvailable(MediaCodec codec, int index) {
freeInputBuffers.add(index);
}
//Dont care about the rest of the Callbacks for this demo...
}
}
@Override
public void run() {
while(!Thread.interrupted())
{
byte [] frameData;
int inputIndex;
try {
frameData = frameQueue.take();
//this was, indeed the culprit. We can wait in an additional thread for an buffer index to
// become free AND to get new frameData. When waiting in the callback, we will slow down
// the decoder.
inputIndex = freeInputBuffers.take();
} catch (InterruptedException e) {
break;
}
ByteBuffer inputData = codec.getInputBuffer(inputIndex);
inputData.clear();
inputData.put(frameData);
codec.queueInputBuffer(inputIndex, 0, frameData.length, 0, 0);
}
codec.stop();
codec.release();
}
}
如果 onInputBufferAvailable
中的阻塞调用是罪魁祸首,我不会感到惊讶。感觉 onInputBufferAvailable
和 onOutputBufferAvailable
很可能在同一个线程中被调用,如果你阻塞其中一个,你就会从 运行.
中停止另一个
我建议更改它,以便您在 onInputBufferAvailable
中只需将缓冲区索引推入某个队列,并向不同的线程发出信号,表明现在有另一个缓冲区可用,然后让第二个线程等待来自排队,并在那里阻塞获取输入数据。
同样,我有一个关于 Android 的 MediaCodec class 的问题。
我已成功解码原始 h264 内容并在两个 TextureView 中显示结果。 h264 流来自 运行 openGL 场景的服务器。
场景有一个摄像头,因此可以响应用户输入。
为了进一步减少服务器上的输入与智能手机上的实际结果之间的延迟,我正在考虑在其异步模式下使用 MediaCodec。
以下是我设置两种变体的方式:同步和异步:
异步:
//decoderCodec is "video/avc"
MediaFormat fmt = MediaFormat.createVideoFormat(decoderCodec, 1280,720);
codec.setCallback(new MediaCodec.Callback() {
@Override
public void onInputBufferAvailable(MediaCodec codec, int index) {
byte[] frameData;
try {
frameData = frameQueue.take(); //this call is blocking
} catch (InterruptedException e) {
return;
}
ByteBuffer inputData = codec.getInputBuffer(index);
inputData.clear();
inputData.put(frameData);
codec.queueInputBuffer(index, 0, frameData.length, 0, 0);
}
@Override
public void onOutputBufferAvailable(MediaCodec codec, int index, MediaCodec.BufferInfo info) {
codec.releaseOutputBuffer(index, true);
}
//The two other methods are left blank at the moment.
});
codec.configure(fmt, surface, null, 0);
codec.start();
Sync:(除 codec.setCallback(...)
部分外,设置与 Async 类似。两个变体所在的 class 是子 class Runnable
.
public void run() {
while(!Thread.interrupted())
{
if(!IS_ASYNC) {
byte[] frameData;
try {
frameData = frameQueue.take(); //this call is blocking
} catch (InterruptedException e) {
break;
}
int inIndex = codec.dequeueInputBuffer(BUFFER_TIMEOUT);
if (inIndex >= 0) {
ByteBuffer input = codec.getInputBuffer(inIndex);
input.clear();
input.put(frameData);
codec.queueInputBuffer(inIndex, 0, frameData.length, 0, 0);
}
MediaCodec.BufferInfo bufferInfo = new MediaCodec.BufferInfo();
int outIndex = codec.dequeueOutputBuffer(bufferInfo, BUFFER_TIMEOUT);
if(outIndex >= 0)
codec.releaseOutputBuffer(outIndex, true);
}
else sleep(3000); //Just for testing, if we are in Async, this thread has nothing to do actually...
}
}
这两种方法都有效,但我观察到在同步模式下播放的视频更流畅,延迟也更低。
我想出了使用异步模式的想法,因为 frameQueue
是一个 LinkedBlockingDeque
并且我推断如果同步解码器等待新帧数据到达的时间过长,解码输出可能已经可用但不会显示,因为队列的阻塞性质。另一方面,我不想做 busy wait
之类的事情并一直轮询队列、inputBuffers 和 outputBuffers。
所以我尝试了使用回调的异步模式,但我得到的结果比同步模式更糟糕。
我现在要问你们的问题是:
为什么?我是否滥用了异步模式?还是其他原因?
感谢任何反馈!
克里斯托夫
编辑:
以下是更新后的代码。我只列出更新的部分。这样
@mstorsjo 正确指出,罪魁祸首是我在 onInputBufferAvailable()
中等待更多帧数据。更新版本为另一个 BlockingQueue 提供可用的缓冲区索引。在另一个线程中,我们正在等待新的帧数据和新的缓冲区索引来对帧数据进行排队以进行解码。
public class DisplayThread implements Runnable {
private BlockingQueue<Integer> freeInputBuffers;
//skipped the uninteresting parts.
private void initCodec(String decoderCodec) {
//skipped the uninteresting parts.
codec.setCallback(new MediaCodec.Callback() {
@Override
public void onInputBufferAvailable(MediaCodec codec, int index) {
freeInputBuffers.add(index);
}
//Dont care about the rest of the Callbacks for this demo...
}
}
@Override
public void run() {
while(!Thread.interrupted())
{
byte [] frameData;
int inputIndex;
try {
frameData = frameQueue.take();
//this was, indeed the culprit. We can wait in an additional thread for an buffer index to
// become free AND to get new frameData. When waiting in the callback, we will slow down
// the decoder.
inputIndex = freeInputBuffers.take();
} catch (InterruptedException e) {
break;
}
ByteBuffer inputData = codec.getInputBuffer(inputIndex);
inputData.clear();
inputData.put(frameData);
codec.queueInputBuffer(inputIndex, 0, frameData.length, 0, 0);
}
codec.stop();
codec.release();
}
}
如果 onInputBufferAvailable
中的阻塞调用是罪魁祸首,我不会感到惊讶。感觉 onInputBufferAvailable
和 onOutputBufferAvailable
很可能在同一个线程中被调用,如果你阻塞其中一个,你就会从 运行.
我建议更改它,以便您在 onInputBufferAvailable
中只需将缓冲区索引推入某个队列,并向不同的线程发出信号,表明现在有另一个缓冲区可用,然后让第二个线程等待来自排队,并在那里阻塞获取输入数据。