我正在使用MediaCodec解码视频并使用sws_scale(来自ffmpeg)重新缩放它。我可以处理一种特殊的颜色格式,例如。 YUV420P,并将其重新调整为目标大小。但我必须做一些准备工作,比如将lineize和memcpy输出缓冲区放到三个普通片(data [0],data [1],data [2])。并且解码器输出颜色格式在不同的设备上有所不同如果我得到了格式,那么ffmpeg中是否有一种方法可以自动重新缩放而无需特殊处理(当然,ffmpeg应该支持颜色格式)?
答案 0 :(得分:1)
swscale / libavutil中没有直接采用OMX(MediaCodec)颜色格式的功能,您需要手动映射格式。但是你不需要将输出缓冲区存储到三个独立的缓冲区中,你可以设置三个数据指针data [0],data [1]和data [2]来指向MediaCodec的输出缓冲区(缓冲区中的相同点,否则你会记得。)
正常的颜色格式(例如YUV420P和NV12)应该可以正常工作,您只需要在格式常量之间设置映射。但是一些MediaCodec解码器(特别是高通的解码器)通常使用专有的平铺格式,需要更多的努力来解读,而swscale不直接支持那个,你需要自己解读它。
答案 1 :(得分:0)
这只是一个基于我在Raspberry Pi上使用OMX的经验的直观建议,但是,您可以查看Stagefright库是否为NDK提供了任何类似于C / C ++接口的OMX - 在这种情况下,如果不是这样的话一个解码器组件,但也是一个resize组件(Raspberry Pi有一个component),然后你可以制作一个OMX管道,然后组件可以自动协商格式,但这只是一个假设,我已经我自己从来没有深入研究Stagefright,而且我意识到它应该是从Java级别通过MediaCodec和其他类使用的,但你仍然可以看看。如果Stagefright有这样的API,我可以提供一些OMX包装代码,这些代码可以简化我为Raspberry Pi制作的组件的使用,因为从头开始构建OMX代码需要做很多工作。
修改强>
我做了一些谷歌搜索,因为它似乎有趣,并找到了NDK媒体sample - 好吧,看起来OMX的Broadcom实现有很大不同,所以大多数东西都需要用scracth构建。您能解释一下为什么需要这样做吗?如果目标只是显示已解码的流,那么您可以将预览表面设置为Java级别,因此我假设解码的其他部分是其他的。