gpt4 book ai didi

java - Android MediaCodec 在异步模式下比在同步模式下慢?

转载 作者:塔克拉玛干 更新时间:2023-11-02 22:35:42 27 4
gpt4 key购买 nike

同样,我有一个关于 Android 的 MediaCodec 类的问题。

我已成功解码原始 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。两个变体所在的类是 的子类可运行

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。

所以我尝试了使用回调的 AsyncMode,但我得到的结果比同步模式更糟糕。

我现在要问你们的问题是:

为什么?我是否滥用了异步模式?还是其他原因?

感谢任何反馈!

克里斯托夫

编辑:以下是更新后的代码。我只列出更新的部分。这样@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 中的阻塞调用是罪魁祸首,我不会感到惊讶。感觉很可能 onInputBufferAvailableonOutputBufferAvailable 在同一个线程中被调用,如果你阻塞其中一个,你就会阻止另一个运行。

我建议更改它,以便您在 onInputBufferAvailable 中将缓冲区索引插入某个队列,并向另一个线程发出信号,表明现在有另一个缓冲区可用,然后让第二个线程等待缓冲区队列,并在那里阻塞获取输入数据。

关于java - Android MediaCodec 在异步模式下比在同步模式下慢?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39999219/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com