我正在使用Android的MediaCodec类解码MP4 H.264视频，提取每个ByteBuffer并尝试转换为RGB，以便我们可以在其他地方使用它。
从dequeueOutputBuffer()收到有效的缓冲索引并抓住ByteBuffer后，我们使用JNI中的GetDirectBufferAddress()在C代码中抓住该缓冲区，以便我们可以在该方面进行转换。但是由于某种原因，当我们查看尺寸值和字节布局时，缓冲区正在看似乎是没有意义的。
我得到的媒体形式显然是COLOR_FormatYUV420SemiPlanar，根据上次返回MediaCodec.INFO_OUTPUT_FORMAT_CHANGED的CC_6-完整的MediaFormat字符串如下。
VideoDecoder: decoder output format changed: {image-data=java.nio.ByteArrayBuffer[position=0,limit=80,capacity=80], mime=video/raw, crop-top=0, crop-right=1279, slice-height=720, color-format=21, height=720, width=1280, what=1869968451, crop-bottom=719, crop-left=0, stride=1280}
视频的尺寸为1280*720，在YUV420SP中，我们期望每金的12位 - 从中，我们从中计算出预期的缓冲区大小为1382400字节。但是，当我们从GetDirectBufferAddress()取回缓冲区时，从GetDirectBufferCapacity()返回的大小为1433600。
看起来奇怪的另一件事是该缓冲区内的字节放置。当我们(据说(查看单个颜色的框架时，我们看到了y，u和v值的三个不同的块 - 而不是y的独特块，然后是u和v的交替值块。MediaFormat告诉我们，这没有意义。
谁能告诉我们我们的数学在哪里出错？还是我们检索价值观的方式？还是我们要忽略的缓冲或颜色格式有什么？
编辑：我们针对API级别19.调试代码时使用的设备是ASUS的Google Nexus 7，运行Android 6.0.1。
您想做的事情的一般描述听起来正确。
我不必担心缓冲区的大小；这可能是一些总体分配的缓冲区。
这是什么Android设备，您尝试过另一个设备吗？4.3或更新的任何Android设备都应相对于此(较旧的设备((臭名昭著的颜色格式值基本上是错误的，或者需要怪癖来解释YUV数据(，因为有CTS测试可以执行正确的行为。该测试也从http://bigflake.com/mediacodec/链接；EncodeDecodeTest.java是相关的。
如果您将代码连接起来，以便可以独立运行它，则可以查看测试是否在您的设备上成功，并以此为参考来找出代码中的错误，或者结论是该设备不是值得信赖(您可以忽略它，并最少需要4.3，或为其添加设备特定的解决方法(。