Android mediacodec实时解码h264流，延迟约1秒
我正在尝试解码h264现场流从WIFI摄像头的madiacodec在Galaxy S3，视频播放还可以，但似乎mediacode低电平总是缓冲1秒的视频帧，一个新的帧可以解码只有一个新的传入NAL单元。这会导致大约1秒的延迟。
调用mediacodec.createDecoderByType（“video/avc”）；时,我可以从logcat看到分配了22个缓冲区,
01-04 15:39:02.799: I/ExtendedCodec(13374): Smoothstreaming Enabled
01-04 15:39:02.809: I/ACodec(13374): [OMX.qcom.video.decoder.avc] Now Loaded->Idle
01-04 15:39:02.809: I/ACodec(13374): [OMX.qcom.video.decoder.avc] Allocating 22 buffers from a native window of size 245760 on output port
01-04 15:39:02.889: D/DecodeActivity(13374): Decoder started at --- 1388867942894
01-04 15:39:02.889: I/ACodec(13374): [OMX.qcom.video.decoder.avc] Now Idle->Executing
01-04 15:39:03.019: I/ACodec(13374): [OMX.qcom.video.decoder.avc] Now Executing
我可以看到大约16个NAL单元需要推入解码器才能得到任何帧。
我的问题是为什么这个视频缓冲？如果这是问题所在，我可以尝试分配更少的缓冲区。有没有任何东西我可以减少这个视频缓冲？
共有1个答案
首先，你确定每个NAL单元对应一帧吗？H.264没有规定每帧有多少个NAL单元，这取决于编码器的实现。第二件事，我在使用高通芯片组的设备时也有类似的问题。我使用的不是MediaCodec，而是IOMX接口，但基本上我得到的延迟是一样的。我想知道你，你在logcat中是否有打印，说明mnay输入缓冲区是如何分配的。这些将与问题更相关，而不是输出端口上的缓冲区。
-
我正在尝试用Android6.0的MediaCodec将h264编码成实时低延迟的流。有大约6帧的延迟从编码器，我想知道如何减少 零件代码为： 编码器以320×480 60 fps的速度由屏幕表面馈入,通过dequeueOutputBuffer（）输出流数据。大约有6个帧的数据没有被dequeueOutputBuffer（）及时返回到编码器。换句话说，当馈送第n帧时，编码器输出第(N-6)帧的数据
-
我正在尝试获取关于h264位流中帧的信息。特别是宏块的运动矢量。我想，我不得不为它使用ffmpeg代码，但它真的很庞大，很难理解。那么，有没有人可以给我一些从h264流的单帧原始数据中进行部分解码的技巧或Exapms？ 谢谢你。
-
我正在尝试用android低级媒体API实时解码h264 nals。 每个nal都包含一个完整的帧，所以我希望在用我的nal提供输入并调用之后，它会“立即”（当然有一个litle延迟）显示我的帧，但它没有显示。我看到了第一个帧，出列器返回第一个缓冲区，只有在将第二个缓冲区馈送给解码器之后才返回第一个缓冲区，此时该缓冲区应该呈现第二个帧。帧编码时预置为x264，因此没有B帧等。 我想可能有一种方法可
-
我需要一些帮助，使ffplay接收和解码一个实时流编码在H264。 我试图在接收Kinect视频帧的计算机a和运行ffplay的计算机B之间建立点对点流，以显示直播。 计算机A(RPI 3） 这就是ffmpeg输出的内容： out流在10-20帧之间运行。不是很好，但我能接受。 计算机B streaming.sdp 我得到了流，但大约0.0001 fps，这是非常糟糕的。我的猜测是我在ffplay
-
我正在使用对三星S6上的h264流进行解码，发现mediacodec的输入缓冲区必须以“0001”开头（并且不需要设置pps、sps)，否则ACodec将报告错误。 我也尝试使用mediaextractor播放一个mp4文件，它工作良好，但缓冲区到mediacodec不是以“0001”开始。 我不知道为什么decodec一个h264流有这样的限制，目前我需要从socket分析流，并将数据切割成小包
-
应用程序创建的h264帧被发送到标准输出，在标准输出中，使用ffmpeg将该流重新复用为mp4，并将其传递给服务器，服务器根据请求将其传递给客户端。 这是个好办法吗？这甚至可能创建一个低延迟30fps视频流使用这种方法？