ffmpeg优化为Core-i5xxx，那么该组合是否提供“硬件H.264编码支持”的功能？如果没有，那么特别采用的Raspberry-Pi-ffmpeg会更快吗？如果是，是否已经有速度比较？#1 楼
目前，即使正式宣布Raspberry Pi确实支持h264硬件编码，似乎仍没有稳定的软件来使用该硬件编码h264视频。因此，我们无法进行基准测试来将性能与普通PC进行比较。现有的libav项目（请参阅他在12月2日09:23的答复）。评论
我不知道从哪里开始，但我可能愿意尝试一下。我一直在寻找寻找libavcodec src或确切地说是x264的原因。
–towi
2012年12月14日在12:37
GStreamer库能够插入Broadcom芯片的OpenMax API，并且似乎可以进行硬件编码：gstreamer.freedesktop.org/releases/gst-omx/1.0.0.html
–speedplane
2014年12月29日20:30在
#2 楼
截至2015年4月，Raspbian中包含的GStreamer 1.2通过omxh264enc支持OpenMAX硬件加速的H.264编码。我已经进行了一些基准测试比较：
MacBook Pro （2011年初）双核i7-2620M 2.7GHz（Sandy Bridge）-4GB RAM
RaspBerry Pi 2 Model B 900MHz四核ARM Cortex-A7 CPU-1GB RAM
示例文件：60年代电影Alatriste（2006）中的样本。原始文件为1080p，占用30MB。我将文件转码为720p。忽略了所有音轨，将精力集中在视频转码上。
结果：
在（1）上，使用Handbrake（x264编解码器），我用x264设置veryslow和平均比特率1145kbps（1次通过），产生了7.7MB的文件。 Profile High，4.0级。使用4个线程，编码耗时3分36秒。累计的手刹CPU费用约为380％。视频质量非常好。可以观察到很少的伪像，并且不容易观察到细节丢失。仍然参见下文。
在（2）上，我使用GStreamer和omxh264enc（硬件加速）以target-bitrate = 1145000（1145kbps），control-rate = 1（可变比特率控制方法）进行了转码在6.9MB的文件中。使用1个线程进行编码需要7分4秒。 gst-launch-1.0〜100％的累计CPU总费用。视频质量明显下降，伪影清晰可见，细节容易观察到。仍请参见下文。 omxh264enc实际上使用了GPU。另外，在（2）中使用x264enc时，时间超过15分钟。
结论：
对于相当相似的文件大小，硬件加速的RaspBerry Pi 2 GPU编码器所花费的时间几乎是双核i7-2620M上软件x264编码器所花费的时间的两倍。由于在此测试期间RaspBerry Pi上大量未使用的CPU，因此添加音频转码和多路复用可能会弥补这一差距。视频质量明显优于软件编码的文件。与x264编码器相比，omxh264enc（由gst-inspect-1.0公开）的可用配置选项受到限制，但进一步的实验可以提供更好的质量。
附件：
从Raspbian信息库安装GStreamer和OpenMax：
gst-launch-1.0 -v filesrc location=sample-1080p.mp4 ! decodebin ! videoconvert ! \
videoscale ! video/x-raw,width=1280,height=688 ! omxh264enc control-rate=1 \
target-bitrate=1145000 ! h264parse ! mp4mux ! \
filesink location=sample-720p-OMX-1145kbps.mp4在MacBook上使用HandBrake（x264）对720p视频进行QuickTime X静止Pro（完整的详细信息，请打开或下载图像）：
QuickTime X静止图像在Raspberry Pi 2上使用GStreamer（通过OpenMAX进行硬件编码）转码后的720p视频（打开或下载图像以获取详细信息）：
更新：
method=lanczos至videoscale。编码过程在时间上翻了一番，从大约7分钟跳到了14分钟（37秒）。结果的质量几乎等于没有方法的质量（默认双线性）。确实，缺陷主要来自硬件的编码过程。它们显然是压缩伪像。评论
对于GStreamer转码后的图像质量，应考虑另一个因素。在gstreamer将其发送到omxh264enc之前，视频缩放的不同参数会对图像产生影响。 Videoscale使用双线性作为默认选项。 Lanczos更好，但速度太慢。 gstreamer的开发人员正在研究视频缩放的更多选项，但它们尚未处于稳定版本中。一些生成的模式可能有助于比较不同的选项：
– ecc29
2015年4月16日在16:17
gst-launch-1.0 -e videotestsrc pattern = zone-plate kx2 = 80 ky2 = 45 num-buffers = 1！ video / x-raw，宽= 1920，高= 1080！视频转换！ videoscale method = lanczos！ video / x-raw，宽度= 1280，高度= 720！ avimux！ filesink位置= lanczos_1280.avi
– ecc29
2015年4月16日在16:17
我已经用lanczos缩放方法的结果更新了帖子。
– M. Rubio-Roy
15年4月18日在11:38
考虑购买3 b +。三年半后有更新吗？现在可以进行实时编码吗？
–akostadinov
19年1月19日在18:54
#3 楼
RPi中的GPU非常强大。我读过关于编码的信息，您可以编码1080p @ 30fps。也可以对多个流进行编码。还相信您可以使用RPi即时编码视频。但是。现代图形卡具有在GPU上运行整个编码的功能，这是GPU真正擅长的功能。 RPi可能不会比中等规格的显卡快。但是我认为这会比您想象的要快得多。甚至可能接近75％的速度。
我找不到任何地方可用的比较。
评论
我不应该认为Raspberry Pi会比台式PC快。显然应该有人进行基准测试并显示一些结果。
@XTL你能做到吗？ ;-)
这是非常好的结果。.您能在示例命令中添加音频转码吗？