GStreamer如何实现video/x-h264转video/x-raw并降低CPU占用？

无解码器转换方案可行性结论 #

H.264是压缩编码格式，video/x-h264、application/x-rtp（承载H.264包）存储的是经过帧间/帧内压缩的编码数据，而video/x-raw是逐像素存储的原始未压缩视频帧，二者底层数据结构完全不同，不存在跳过解码器就能完成该格式转换的方案。要使用textoverlay叠加文字，必须经过「解码拿到原始帧→叠加文字→重新编码回H.264」的流程。

性能优化方案 #

1. 优先使用硬件编解码（降CPU占用效果最明显） #

你当前测试用的avdec_h264、x264enc都是纯CPU软编软解，高占用是必然的，根据你运行的硬件平台替换为对应硬件编解码元件即可，CPU占用普遍可以降到10%以内：

• 英特尔平台：用vaapidecode解码、vaapih264enc编码，搭配vaapipostproc做格式转换，无需使用videoconvert
• 英伟达平台：用nvh264dec解码、nvh264enc编码
• 嵌入式ARM/树莓派平台：用v4l2h264dec解码、v4l2h264enc编码

英特尔平台流水线示例：

gst-launch-1.0 -e rtspsrc user-id="admin" user-pw="syrus" latency=200 location="rtsp://...:554/user=a...._channel=1_stream=0.sdp?real_stream" name=src \
src. ! rtph264depay ! h264parse config-interval=-1 ! vaapidecode ! vaapipostproc ! textoverlay text="自定义叠加文字" ! vaapih264enc key-int-max=30 ! h264parse ! splitmuxsink location=/media/device/video/file_test_%02d.mp4 max-files=5 max-size-time=10000000000 send-keyframe-requests=true

2. 无硬件编解码能力时的软编软解优化 #

如果平台不支持硬件编解码，可通过调整参数降低开销：

• 解码侧：你之前设置的avdec_h264 skip-frame=5超出了该参数的有效取值范围（有效值0~3，0=不跳帧、2=跳过所有B帧、3=跳过B帧+P帧），实际不会生效，建议设置为skip-frame=2 thread-count=[你的CPU核心数]，在不明显影响画面流畅度的前提下降低解码压力
• 编码侧：你之前设置的x264enc key-int-max=0/1不合理，设为1时每帧都是关键帧，编码压力会翻倍，建议设置为key-int-max=30 speed-preset=ultrafast tune=zerolatency，牺牲不必要的编码压缩率换速度
• 链路优化：videoconvert添加throttle-time=0参数减少调度开销，如果业务允许，可在解码后加videoscale/videorate降低分辨率、帧率，进一步减少处理压力

3. 通用优化项 #

• RTSP源的latency参数不要设置过小，小于网络抖动值会导致频繁丢包重传，反而增加额外开销，建议设为200~300
• splitmuxsink添加send-keyframe-requests=true参数，切文件时无需等待编码侧主动生成关键帧，运行更流畅
• 文字叠加操作尽量放在硬件处理链路内，避免像素数据在CPU和GPU之间反复拷贝增加开销

内容的提问来源于stack exchange，提问作者F.Ramirez