视频编码避坑指南：FFmpeg与GStreamer选型实战
看了一堆教程，对着代码敲了两遍，结果项目一上生产环境，内存泄漏、卡顿、黑屏问题全来了。这种“懂了但不会写”的困境，在视频开发领域太常见了。很多人觉得视频编码就是调个库的事，其实这里的水深得很。今天这篇避坑指南，不讲虚的理论，直接带你拆解两个最主流的方案：FFmpeg和GStreamer。我会把两者掰开揉碎了讲，从底层原理到代码实战，再到怎么选才不踩雷，全是干货。
1. 定位不同：瑞士军刀 vs 流水线
很多人一上来就问“FFmpeg和GStreamer哪个好”，这问题本身就问错了。它们根本不是同类竞品，而是两种完全不同的设计哲学。
FFmpeg 更像是一个超级工具箱或者瑞士军刀。它的核心定位是“处理单个文件”或“处理媒体流”。你给它一个输入文件，指定输出格式、分辨率、码率，它就能帮你把活干完。它的优势在于功能极其丰富，几乎支持所有的音视频格式、编码器和容器。无论是H.264、HEVC、AV1，还是MP4、FLV、MKV，FFmpeg全都能搞定。在命令行里，一条命令就能完成转码、截取、合并、加水印等操作。它的API（libavcodec, libavformat等）非常底层，灵活度极高，但同时也意味着你需要自己处理很多细节，比如内存管理、线程同步、错误恢复等。
GStreamer 则是一个媒体处理框架，它的核心思想是流水线（Pipeline）。你不再关注“处理这个文件”，而是构建一条数据流：从源（Source）开始，经过解码（Decode）、处理（Filter）、编码（Encode），最后到输出（Sink）。GStreamer的优势在于实时性和硬件加速支持。它天生为流媒体、实时视频通话、低延迟场景设计。它的插件机制非常优雅，可以动态加载不同的编码器、解码器、滤波器。但是，它的上手难度比FFmpeg高很多，因为你需要理解它的对象模型、元素（Element）连接、状态机管理。
简单来说：FFmpeg适合离线处理、文件转码、工具类应用；GStreamer适合实时流媒体、低延迟直播、嵌入式设备。
2. 核心差异对比：一张表看懂
为了让你更直观地理解两者的区别，我整理了一张对比表。这张表是我踩了无数坑后总结出来的，建议截图保存。特性
FFmpeg (libav*)
GStreamer核心模型
基于文件/流的线性处理
基于管道（Pipeline）的数据流上手难度
低（命令行简单，API较繁琐）
高（概念多，学习曲线陡峭）实时性能
中等，需手动优化线程和缓冲
优秀，内置调度器和缓冲管理硬件加速
支持，但配置复杂，易出错
支持良好，通过插件无缝集成格式支持
极广，几乎全兼容
广，但依赖插件，需检查编译选项内存管理
需手动关注，易泄漏
框架自动管理，相对安全适用场景
转码、剪辑、格式转换、工具链
直播、视频通话、嵌入式、实时预览调试难度
中等，日志详细但杂乱
高，需使用gst-inspect, gst-launch社区生态
庞大，文档丰富，例子多
活跃，文档结构清晰，但例子较少关键点解读：内存管理是FFmpeg最大的坑。很多初学者用libavcodec解码时，忘记调用av_frame_unref或av_frame_free，导致内存持续增长，直到程序崩溃。而GStreamer的框架机制会在数据流结束时自动释放资源，虽然也有泄漏可能，但概率低很多。
硬件加速方面，GStreamer的VAAPI、NVDEC等插件封装得更好，开发者只需在管道中加入vaapisink或nvv4l2decoder即可。FFmpeg虽然也支持硬件解码，但你需要手动配置AVCodecContext的hwaccel字段，并处理帧的上传下载，容易出Bug。3. 代码写法对比：从入门到踩坑
光说不练假把式。下面我分别给出FFmpeg和GStreamer的一个简单示例：读取一个RTSP流，解码并打印帧信息。
3.1 FFmpeg 实现
FFmpeg的代码通常分为：打开输入 - 查找流 - 解码循环 - 关闭。注意，这里我用C语言编写，因为FFmpeg的核心API就是C。
#include stdio.h
#include libavformat/avformat.h
#include libavcodec/avcodec.hint main(int argc, char *argv[]) {const char *url = rtsp://192.168.1.100:554/stream;AVFormatContext *ifmt_ctx = NULL;int video_stream_index = -1;AVCodecContext *dec_ctx = NULL;AVFrame *frame = av_frame_alloc();AVPacket *packet = av_packet_alloc();int ret;// 1. 打开输入文件if ((ret = avformat_open_input(ifmt_ctx, url, NULL, NULL)) 0) {fprintf(stderr, Could not open input file\n);return -1;}// 2. 获取媒体信息if ((ret = avformat_find_stream_info(ifmt_ctx, NULL)) 0) {fprintf(stderr, Failed to retrieve stream info\n);goto cleanup;}// 3. 查找视频流video_stream_index = av_find_best_stream(ifmt_ctx, AVMEDIA_TYPE_VIDEO, -1, -1, dec_ctx, NULL);if (video_stream_index 0) {fprintf(stderr, Failed to find a suitable video stream\n);goto cleanup;}// 4. 打开解码器if ((ret = avcodec_open2(dec_ctx, NULL, NULL)) 0) {fprintf(stderr, Failed to open decoder\n);goto cleanup;}// 5. 解码循环while (av_read_frame(ifmt_ctx, packet) = 0) {if (packet-stream_index == video_stream_index) {// 发送包到解码器avcodec_send_packet(dec_ctx, packet);// 接收解码后的帧while ((ret = avcodec_receive_frame(dec_ctx, frame)) == 0) {printf(Decoded frame: width=%d, height=%d, pts=%lld\n,frame-width, frame-height, frame-pts);// 这里可以处理帧数据，比如显示、编码、保存}// 注意：AVERROR(EAGAIN)表示需要更多输入或输出，不是错误if (ret != AVERROR(EAGAIN) ret != AVERROR_EOF) {fprintf(stderr, Error during decoding\n);break;}}av_packet_unref(packet);}cleanup:if (frame) av_frame_free(frame);if (packet) av_packet_free(packet);if (ifmt_ctx) avformat_close_input(ifmt_ctx);return 0;
}逐行讲解与避坑：avformat_open_input：如果URL权限不对或网络不通，这里会失败。务必检查返回值。
av_find_best_stream：这个函数会自动查找最佳视频流，比手动遍历ifmt_ctx-streams更稳妥。
解码循环：这是FFmpeg最核心的部分。avcodec_send_packet和avcodec_receive_frame是分离的。你可能发送一个包，收到多个帧；也可能发送多个包，才收到一个帧。这就是为什么代码里有两个while循环。
AVERROR(EAGAIN)：这是新手最容易忽略的。它表示“现在没数据，再等等”。如果你把它当错误处理，程序会提前退出。
资源释放：av_frame_free和av_packet_free必须调用。如果在循环中频繁创建和销毁对象，务必确保成对释放。3.2 GStreamer 实现
GStreamer的代码结构完全不同。我们不再关心“打开文件”、“找流”，而是构建一条管道。这里我用Python绑定（gi.repository）来演示，因为Python写GStreamer更简洁，且能体现管道思想。
import gi
gi.require_version('Gst', '1.0')
from gi.repository import Gst, GLibGst.init(None)# 定义管道字符串
# rtspsrc ! rtpjitterbuffer ! decodebin ! videoconvert ! appsink
pipeline_str = rtspsrc location=rtsp://192.168.1.100:554/stream latency=100 ! rtpjitterbuffer ! decodebin ! videoconvert ! appsink max-buffers=10 drop=true
pipeline = Gst.parse_launch(pipeline_str)def on_new_sample(self, data):# 获取样本sample = self.emit('pull-sample')if sample:buffer = sample.get_buffer()# 获取帧信息caps = sample.get_caps()structure = caps.get_structure(0)width = structure.get_value('width')height = structure.get_value('height')print(fReceived frame: width={width}, height={height})# 这里可以处理帧数据return Truedef on_state_changed(pipeline, state):if state == Gst.StateChangeReturn.SUCCESS:print(Pipeline is playing)# 创建管道
pipeline.set_state(Gst.State.PLAYING)# 获取appsink元素
sink = pipeline.get_by_name(appsink)
if sink:# 连接信号，当有新数据时触发sink.connect('new-sample', on_new_sample)# 运行主循环
loop = GLib.MainLoop()
loop.run()逐行讲解与避坑：Gst.parse_launch：这是GStreamer的精髓。你用一行字符串描述了整个数据流。rtspsrc是源，decodebin是自动解码器，videoconvert是像素格式转换，appsink是输出到应用程序的接口。
rtpjitterbuffer：在RTSP流中，这个元素至关重要。它用来缓冲网络抖动，防止画面卡顿。很多初学者忽略它，导致直播画面一顿一顿的。
appsink：这是应用程序与管道交互的接口。你通过连接new-sample信号来获取解码后的帧。注意max-buffers和drop=true参数，这能防止缓冲区溢出导致内存暴涨。
GLib.MainLoop：GStreamer是基于事件驱动的。你需要运行一个主循环来接收和处理信号。这和FFmpeg的阻塞式循环完全不同。
硬件加速：如果你想用NVIDIA硬件解码，只需把decodebin换成nvv4l2decoder，或者在decodebin后面加nvv4l2decoder。GStreamer会自动匹配插件。4. 适用场景：别用错地方
选错技术栈，后期维护成本会呈指数级上升。以下是我根据项目经验总结的选型建议。
选 FFmpeg 的场景：离线转码服务：比如用户上传视频，后台批量转成HLS/DASH格式。FFmpeg的命令行工具ffmpeg本身就极其强大，甚至不需要写代码，直接调用shell命令即可。
格式转换工具：开发一个“MP4转GIF”、“视频加水印”的小工具。FFmpeg的libavfilter提供了丰富的滤镜链，易于实现。
跨平台桌面应用：如果应用不需要低延迟，只需要稳定地播放或处理文件，FFmpeg的libavformat和libavcodec是首选，因为它们被封装成了Qt、Electron等框架的插件，集成方便。
需要极致控制的场景：比如你需要自定义解码器参数、手动管理帧队列、实现复杂的音画同步逻辑。FFmpeg的API虽然繁琐，但自由度极高。选 GStreamer 的场景：实时视频通话/直播：低延迟是刚需。GStreamer的调度器和缓冲区管理天生为实时性优化。如果你在做类似Zoom、腾讯会议的产品，GStreamer是更好的选择。
嵌入式设备：树莓派、Jetson Nano等嵌入式设备资源有限。GStreamer的插件机制允许你只加载必要的组件，减少内存占用。而且它对硬件加速的支持更友好。
复杂媒体管道：比如你需要同时处理视频、音频、数据轨道，并进行复杂的混合、路由、切换。GStreamer的管道模型可以清晰地表达这些逻辑。
需要动态加载插件：如果你的应用需要支持多种编码器，且希望在不重启应用的情况下切换，GStreamer的动态插件加载机制非常方便。5. 选型建议：避坑终极指南先看需求，再看技术：如果需求是“处理文件”，选FFmpeg。
如果需求是“处理流”，选GStreamer。
如果两者都要，考虑用FFmpeg做后端转码，用GStreamer做前端播放/推流。不要重复造轮子：FFmpeg的命令行工具ffmpeg和ffprobe是神器。很多简单的转码、探测任务，直接用shell脚本调用即可，没必要写C代码。
GStreamer的gst-launch-1.0命令也是调试利器。在写代码前，先用gst-launch把管道跑通，确认元素名称、属性、连接关系正确，再迁移到代码中。关注官方文档：FFmpeg的官方文档（ffmpeg.org/documentation.html）虽然晦涩，但最权威。特别是avcodec.h和avformat.h的头文件注释，是理解API的最佳来源。
GStreamer的官方文档（gstreamer.freedesktop.org/documentation/) 结构清晰，有大量的“Recipes”（食谱），比如“如何播放RTSP流”、“如何实现低延迟”，直接照抄改参数即可。测试硬件加速：在生产环境部署前，务必测试硬件加速是否生效。用nvidia-smi或intel_gpu_top监控GPU占用率。如果GPU占用率为0，说明你用的是软解，性能会大打折扣。日志与调试：FFmpeg：设置环境变量FFMPEG_LOGLEVEL=debug，可以输出详细日志。
GStreamer：设置环境变量GST_DEBUG=3，可以查看管道状态变化、缓冲区填充情况等。这些日志是排查问题的金钥匙。视频编码这块，坑多但逻辑清晰。只要你理清了FFmpeg和GStreamer的定位，根据场景选型，再结合官方文档和实战调试，就能避开大部分雷区。记住，没有最好的技术，只有最适合场景的技术。
这个知识点你面试被问过吗？留言说说 视频编码避坑指南：FFmpeg与GStreamer选型实战
视频编码避坑指南：FFmpeg与GStreamer选型实战
看了一堆教程，对着代码敲了两遍，结果项目一上生产环境，内存泄漏、卡顿、黑屏问题全来了。这种“懂了但不会写”的困境，在视频开发领域太常见了。很多人觉得视频编码就是调个库的事，其实这里的水深得很。今天这篇避坑指南，不讲虚的理论，直接带你拆解两个最主流的方案：FFmpeg和GStreamer。我会把两者掰开揉碎了讲，从底层原理到代码实战，再到怎么选才不踩雷，全是干货。
1. 定位不同：瑞士军刀 vs 流水线
很多人一上来就问“FFmpeg和GStreamer哪个好”，这问题本身就问错了。它们根本不是同类竞品，而是两种完全不同的设计哲学。
FFmpeg 更像是一个超级工具箱或者瑞士军刀。它的核心定位是“处理单个文件”或“处理媒体流”。你给它一个输入文件，指定输出格式、分辨率、码率，它就能帮你把活干完。它的优势在于功能极其丰富，几乎支持所有的音视频格式、编码器和容器。无论是H.264、HEVC、AV1，还是MP4、FLV、MKV，FFmpeg全都能搞定。在命令行里，一条命令就能完成转码、截取、合并、加水印等操作。它的API（libavcodec, libavformat等）非常底层，灵活度极高，但同时也意味着你需要自己处理很多细节，比如内存管理、线程同步、错误恢复等。
GStreamer 则是一个媒体处理框架，它的核心思想是流水线（Pipeline）。你不再关注“处理这个文件”，而是构建一条数据流：从源（Source）开始，经过解码（Decode）、处理（Filter）、编码（Encode），最后到输出（Sink）。GStreamer的优势在于实时性和硬件加速支持。它天生为流媒体、实时视频通话、低延迟场景设计。它的插件机制非常优雅，可以动态加载不同的编码器、解码器、滤波器。但是，它的上手难度比FFmpeg高很多，因为你需要理解它的对象模型、元素（Element）连接、状态机管理。
简单来说：FFmpeg适合离线处理、文件转码、工具类应用；GStreamer适合实时流媒体、低延迟直播、嵌入式设备。
2. 核心差异对比：一张表看懂
为了让你更直观地理解两者的区别，我整理了一张对比表。这张表是我踩了无数坑后总结出来的，建议截图保存。特性
FFmpeg (libav*)
GStreamer核心模型
基于文件/流的线性处理
基于管道（Pipeline）的数据流上手难度
低（命令行简单，API较繁琐）
高（概念多，学习曲线陡峭）实时性能
中等，需手动优化线程和缓冲
优秀，内置调度器和缓冲管理硬件加速
支持，但配置复杂，易出错
支持良好，通过插件无缝集成格式支持
极广，几乎全兼容
广，但依赖插件，需检查编译选项内存管理
需手动关注，易泄漏
框架自动管理，相对安全适用场景
转码、剪辑、格式转换、工具链
直播、视频通话、嵌入式、实时预览调试难度
中等，日志详细但杂乱
高，需使用gst-inspect, gst-launch社区生态
庞大，文档丰富，例子多
活跃，文档结构清晰，但例子较少关键点解读：内存管理是FFmpeg最大的坑。很多初学者用libavcodec解码时，忘记调用av_frame_unref或av_frame_free，导致内存持续增长，直到程序崩溃。而GStreamer的框架机制会在数据流结束时自动释放资源，虽然也有泄漏可能，但概率低很多。
硬件加速方面，GStreamer的VAAPI、NVDEC等插件封装得更好，开发者只需在管道中加入vaapisink或nvv4l2decoder即可。FFmpeg虽然也支持硬件解码，但你需要手动配置AVCodecContext的hwaccel字段，并处理帧的上传下载，容易出Bug。3. 代码写法对比：从入门到踩坑
光说不练假把式。下面我分别给出FFmpeg和GStreamer的一个简单示例：读取一个RTSP流，解码并打印帧信息。
3.1 FFmpeg 实现
FFmpeg的代码通常分为：打开输入 - 查找流 - 解码循环 - 关闭。注意，这里我用C语言编写，因为FFmpeg的核心API就是C。
#include stdio.h
#include libavformat/avformat.h
#include libavcodec/avcodec.hint main(int argc, char *argv[]) {const char *url = rtsp://192.168.1.100:554/stream;AVFormatContext *ifmt_ctx = NULL;int video_stream_index = -1;AVCodecContext *dec_ctx = NULL;AVFrame *frame = av_frame_alloc();AVPacket *packet = av_packet_alloc();int ret;// 1. 打开输入文件if ((ret = avformat_open_input(ifmt_ctx, url, NULL, NULL)) 0) {fprintf(stderr, Could not open input file\n);return -1;}// 2. 获取媒体信息if ((ret = avformat_find_stream_info(ifmt_ctx, NULL)) 0) {fprintf(stderr, Failed to retrieve stream info\n);goto cleanup;}// 3. 查找视频流video_stream_index = av_find_best_stream(ifmt_ctx, AVMEDIA_TYPE_VIDEO, -1, -1, dec_ctx, NULL);if (video_stream_index 0) {fprintf(stderr, Failed to find a suitable video stream\n);goto cleanup;}// 4. 打开解码器if ((ret = avcodec_open2(dec_ctx, NULL, NULL)) 0) {fprintf(stderr, Failed to open decoder\n);goto cleanup;}// 5. 解码循环while (av_read_frame(ifmt_ctx, packet) = 0) {if (packet-stream_index == video_stream_index) {// 发送包到解码器avcodec_send_packet(dec_ctx, packet);// 接收解码后的帧while ((ret = avcodec_receive_frame(dec_ctx, frame)) == 0) {printf(Decoded frame: width=%d, height=%d, pts=%lld\n,frame-width, frame-height, frame-pts);// 这里可以处理帧数据，比如显示、编码、保存}// 注意：AVERROR(EAGAIN)表示需要更多输入或输出，不是错误if (ret != AVERROR(EAGAIN) ret != AVERROR_EOF) {fprintf(stderr, Error during decoding\n);break;}}av_packet_unref(packet);}cleanup:if (frame) av_frame_free(frame);if (packet) av_packet_free(packet);if (ifmt_ctx) avformat_close_input(ifmt_ctx);return 0;
}逐行讲解与避坑：avformat_open_input：如果URL权限不对或网络不通，这里会失败。务必检查返回值。
av_find_best_stream：这个函数会自动查找最佳视频流，比手动遍历ifmt_ctx-streams更稳妥。
解码循环：这是FFmpeg最核心的部分。avcodec_send_packet和avcodec_receive_frame是分离的。你可能发送一个包，收到多个帧；也可能发送多个包，才收到一个帧。这就是为什么代码里有两个while循环。
AVERROR(EAGAIN)：这是新手最容易忽略的。它表示“现在没数据，再等等”。如果你把它当错误处理，程序会提前退出。
资源释放：av_frame_free和av_packet_free必须调用。如果在循环中频繁创建和销毁对象，务必确保成对释放。3.2 GStreamer 实现
GStreamer的代码结构完全不同。我们不再关心“打开文件”、“找流”，而是构建一条管道。这里我用Python绑定（gi.repository）来演示，因为Python写GStreamer更简洁，且能体现管道思想。
import gi
gi.require_version('Gst', '1.0')
from gi.repository import Gst, GLibGst.init(None)# 定义管道字符串
# rtspsrc ! rtpjitterbuffer ! decodebin ! videoconvert ! appsink
pipeline_str = rtspsrc location=rtsp://192.168.1.100:554/stream latency=100 ! rtpjitterbuffer ! decodebin ! videoconvert ! appsink max-buffers=10 drop=true
pipeline = Gst.parse_launch(pipeline_str)def on_new_sample(self, data):# 获取样本sample = self.emit('pull-sample')if sample:buffer = sample.get_buffer()# 获取帧信息caps = sample.get_caps()structure = caps.get_structure(0)width = structure.get_value('width')height = structure.get_value('height')print(fReceived frame: width={width}, height={height})# 这里可以处理帧数据return Truedef on_state_changed(pipeline, state):if state == Gst.StateChangeReturn.SUCCESS:print(Pipeline is playing)# 创建管道
pipeline.set_state(Gst.State.PLAYING)# 获取appsink元素
sink = pipeline.get_by_name(appsink)
if sink:# 连接信号，当有新数据时触发sink.connect('new-sample', on_new_sample)# 运行主循环
loop = GLib.MainLoop()
loop.run()逐行讲解与避坑：Gst.parse_launch：这是GStreamer的精髓。你用一行字符串描述了整个数据流。rtspsrc是源，decodebin是自动解码器，videoconvert是像素格式转换，appsink是输出到应用程序的接口。
rtpjitterbuffer：在RTSP流中，这个元素至关重要。它用来缓冲网络抖动，防止画面卡顿。很多初学者忽略它，导致直播画面一顿一顿的。
appsink：这是应用程序与管道交互的接口。你通过连接new-sample信号来获取解码后的帧。注意max-buffers和drop=true参数，这能防止缓冲区溢出导致内存暴涨。
GLib.MainLoop：GStreamer是基于事件驱动的。你需要运行一个主循环来接收和处理信号。这和FFmpeg的阻塞式循环完全不同。
硬件加速：如果你想用NVIDIA硬件解码，只需把decodebin换成nvv4l2decoder，或者在decodebin后面加nvv4l2decoder。GStreamer会自动匹配插件。4. 适用场景：别用错地方
选错技术栈，后期维护成本会呈指数级上升。以下是我根据项目经验总结的选型建议。
选 FFmpeg 的场景：离线转码服务：比如用户上传视频，后台批量转成HLS/DASH格式。FFmpeg的命令行工具ffmpeg本身就极其强大，甚至不需要写代码，直接调用shell命令即可。
格式转换工具：开发一个“MP4转GIF”、“视频加水印”的小工具。FFmpeg的libavfilter提供了丰富的滤镜链，易于实现。
跨平台桌面应用：如果应用不需要低延迟，只需要稳定地播放或处理文件，FFmpeg的libavformat和libavcodec是首选，因为它们被封装成了Qt、Electron等框架的插件，集成方便。
需要极致控制的场景：比如你需要自定义解码器参数、手动管理帧队列、实现复杂的音画同步逻辑。FFmpeg的API虽然繁琐，但自由度极高。选 GStreamer 的场景：实时视频通话/直播：低延迟是刚需。GStreamer的调度器和缓冲区管理天生为实时性优化。如果你在做类似Zoom、腾讯会议的产品，GStreamer是更好的选择。
嵌入式设备：树莓派、Jetson Nano等嵌入式设备资源有限。GStreamer的插件机制允许你只加载必要的组件，减少内存占用。而且它对硬件加速的支持更友好。
复杂媒体管道：比如你需要同时处理视频、音频、数据轨道，并进行复杂的混合、路由、切换。GStreamer的管道模型可以清晰地表达这些逻辑。
需要动态加载插件：如果你的应用需要支持多种编码器，且希望在不重启应用的情况下切换，GStreamer的动态插件加载机制非常方便。5. 选型建议：避坑终极指南先看需求，再看技术：如果需求是“处理文件”，选FFmpeg。
如果需求是“处理流”，选GStreamer。
如果两者都要，考虑用FFmpeg做后端转码，用GStreamer做前端播放/推流。不要重复造轮子：FFmpeg的命令行工具ffmpeg和ffprobe是神器。很多简单的转码、探测任务，直接用shell脚本调用即可，没必要写C代码。
GStreamer的gst-launch-1.0命令也是调试利器。在写代码前，先用gst-launch把管道跑通，确认元素名称、属性、连接关系正确，再迁移到代码中。关注官方文档：FFmpeg的官方文档（ffmpeg.org/documentation.html）虽然晦涩，但最权威。特别是avcodec.h和avformat.h的头文件注释，是理解API的最佳来源。
GStreamer的官方文档（gstreamer.freedesktop.org/documentation/) 结构清晰，有大量的“Recipes”（食谱），比如“如何播放RTSP流”、“如何实现低延迟”，直接照抄改参数即可。测试硬件加速：在生产环境部署前，务必测试硬件加速是否生效。用nvidia-smi或intel_gpu_top监控GPU占用率。如果GPU占用率为0，说明你用的是软解，性能会大打折扣。日志与调试：FFmpeg：设置环境变量FFMPEG_LOGLEVEL=debug，可以输出详细日志。
GStreamer：设置环境变量GST_DEBUG=3，可以查看管道状态变化、缓冲区填充情况等。这些日志是排查问题的金钥匙。视频编码这块，坑多但逻辑清晰。只要你理清了FFmpeg和GStreamer的定位，根据场景选型，再结合官方文档和实战调试，就能避开大部分雷区。记住，没有最好的技术，只有最适合场景的技术。
这个知识点你面试被问过吗？留言说说