如题。一个ffmpeg转码的程序，流程为:视频-->解码元数据-->压缩（指定大小）-->第三方xh264库编码为h264文件。音频-->解码元数据-->faac第三方库转为aac文件。aac和h264 mux为新的mp4文件。程序在虚拟机centos7跑，1080X720的视频转为640的mp4基本耗时是1:1（视频多长转码多久）,移植到安卓后耗时大约是6-10倍。请问大家有优化的方法吗？还是说我的算法太复杂。

Ps:已经开了双线程视频音频同时解码。

转码这种是典型的CPU计算密集型操作,此时Android ARM计算能力不如x86的劣势就体现出来了,1个小时的视频,Linux x86上转码花1小时,但Android ARM上转码花10个小时也是正常的.
同样的C语言程序:
1千万次冒泡排序,树莓派2B(BCM2709)需要花费6.8秒.
1亿次冒泡排序,i5-3230M需要花费6.3秒.
也就是说,BCM2709(ARM)跟i5-3230M(x86)的单核计算性能相差十几倍. 评论 ( 1 ) 引用此答案 嗯嗯，我也觉得太慢了。不过我看微信的小视频功能做得不错，也很快。不知道他们是怎么处理的，他们限制在10s，分辨率限制为320，处理起来2.3秒就搞定。现在开了多线程，也只是快了十几秒，无补于事。 @zabcd117 : 好的，了解，谢谢。不过我按照上网教程，重新编译支持neon的ffmpeg库之后，用新版本的库也没有太大提速。不知道运行时是不是真的开启了neon加速。反正编译的时候查看是开启了。 额，我也觉得手机做图像和视频太慢了。数据量太大，不过刚毕业公司就安排这个项目，只能慢慢摸索。微信的小视频这方面做得很快很好。另外我不是android端的，刚百度一下neon才知道是什么，请指教。 本来 react + vite 用得好好的，前几天看到几只前端在鼓吹 react + nextjs 合流，说什么 nextjs 也支持 spa。 就试着迁移过去，结果把自己坑得七荤八素，最后组件状态保持直接给我劝退了。 spa 是从 ssr 进化出来，但又和 ssr 完全不同的产物。一小撮前端为了实现 seo 优化，逆向退化出 nextjs。 作为远古人，我需要你们逆向退化吗？是 php 实现不了 ssr 还是 python 实现不了 ssr？ 就算 nextjs 比 php 和 python 有优势（如可以和 spa 项目共享一部分界面组件库），也不能把 nextjs 吹得无所不能吧。 这个 nextjs 所谓的 react 的未来，在我看来除了 ssr 简直一无是处。