当前位置：首页 > news >正文

FFmpeg实现USB摄像头H264帧采集与RTMP直播推流实战

news 2026/4/15 10:15:21

1. USB摄像头H264采集与RTMP推流基础

第一次尝试用FFmpeg操作USB摄像头时，我踩了个大坑——本以为直接调用avformat_open_input就能获取H264码流，结果发现大多数摄像头默认输出的是YUV裸数据。这就像你买了台智能电视，却发现它只能输出零件需要自己组装。经过反复测试，发现关键点在于V4L2驱动的格式协商。

现代USB摄像头通常支持多种输出格式，通过v4l2-ctl工具可以查看：

v4l2-ctl --list-formats -d /dev/video0

典型输出会显示类似这样的信息：

[0]: 'YUYV' (YUYV 4:2:2) [1]: 'H264' (H.264)

要启用H264格式，必须通过V4L2的ioctl设置像素格式为V4L2_PIX_FMT_H264。我在代码中是这样实现的：

struct v4l2_format fmt; memset(&fmt, 0, sizeof(fmt)); fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_H264; // 关键参数 fmt.fmt.pix.width = 1280; fmt.fmt.pix.height = 720; ioctl(fd, VIDIOC_S_FMT, &fmt);

这里有个细节要注意：不是所有摄像头都支持直接输出H264，有些低端设备可能需要先获取YUV再软编码。实测罗技C920、奥尼A31等型号能原生输出H264，节省CPU资源效果显著。

2. V4L2内存映射优化技巧

直接读取摄像头数据就像用吸管喝珍珠奶茶——珍珠（帧数据）经常卡住。V4L2提供了内存映射(mmap)机制，实测效率比read()提升3倍以上。具体实现分三步走：

首先申请缓冲区：

struct v4l2_requestbuffers req; req.count = 4; // 双缓冲不够，建议4个 req.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; req.memory = V4L2_MEMORY_MMAP; ioctl(fd, VIDIOC_REQBUFS, &req);

然后映射到用户空间：

struct buffer *buffers = calloc(req.count, sizeof(*buffers)); for (int i = 0; i < req.count; ++i) { struct v4l2_buffer buf; buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; buf.index = i; ioctl(fd, VIDIOC_QUERYBUF, &buf); buffers[i].length = buf.length; buffers[i].start = mmap(NULL, buf.length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, buf.m.offset); }

最后启用队列机制：

for (int i = 0; i < req.count; ++i) { struct v4l2_buffer buf; buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory = V4L2_MEMORY_MMAP; buf.index = i; ioctl(fd, VIDIOC_QBUF, &buf); } type = V4L2_BUF_TYPE_VIDEO_CAPTURE; ioctl(fd, VIDIOC_STREAMON, &type);

我在树莓派4B上测试，1280x720@30fps时，mmap方式CPU占用仅12%，而read()方式高达35%。不过要注意缓冲区数量配置——双缓冲在复杂场景下容易丢帧，4缓冲更稳定。

3. FFmpeg自定义AVIOContext实战

FFmpeg默认的文件操作接口不适合实时流，我们需要自定义读取逻辑。这就像给FFmpeg装个特制的水龙头，让它按我们的方式喝水。核心是实现read_buffer回调：

int read_buffer(void *opaque, uint8_t *buf, int buf_size) { // 使用poll监控摄像头文件描述符 struct pollfd pfd = {.fd = camera_fd, .events = POLLIN}; if (poll(&pfd, 1, -1) <= 0) return AVERROR(EAGAIN); // 从mmap缓冲区获取数据 struct v4l2_buffer v4l2_buf = {0}; v4l2_buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; v4l2_buf.memory = V4L2_MEMORY_MMAP; if (ioctl(camera_fd, VIDIOC_DQBUF, &v4l2_buf) < 0) return AVERROR(errno); // 确保不溢出 int size = MIN(v4l2_buf.bytesused, buf_size); memcpy(buf, buffers[v4l2_buf.index].start, size); // 重要！重新入队 ioctl(camera_fd, VIDIOC_QBUF, &v4l2_buf); return size; }

初始化时这样挂接回调：

AVFormatContext *fmt_ctx = avformat_alloc_context(); AVIOContext *avio_ctx = avio_alloc_context( av_malloc(IO_BUFFER_SIZE), // 内部缓冲区 IO_BUFFER_SIZE, // 缓冲区大小 0, // write_flag NULL, // opaque read_buffer, // 关键回调 NULL, // write_packet NULL); // seek fmt_ctx->pb = avio_ctx;

实测发现IO_BUFFER_SIZE设置96KB比较合适，太小会导致频繁回调影响性能，太大又增加内存开销。这个方案比用内存中转文件效率高20%左右。

4. RTMP推流参数调优

推流到SRS或Nginx-RTMP服务器时，默认参数经常出现延迟高、卡顿问题。经过多次踩坑，我总结出这些黄金配置：

// 输出格式上下文配置 AVDictionary *options = NULL; av_dict_set(&options, "flvflags", "no_duration_filesize", 0); av_dict_set(&options, "movflags", "faststart", 0); av_dict_set(&options, "preset", "ultrafast", 0); av_dict_set(&options, "tune", "zerolatency", 0); // 视频流参数配置 AVCodecContext *cctx = out_stream->codec; cctx->bit_rate = 1500000; // 1.5Mbps cctx->gop_size = 30; // 关键帧间隔 cctx->max_b_frames = 0; // 禁用B帧降低延迟 cctx->thread_count = 2; // 适合4核CPU cctx->profile = FF_PROFILE_H264_BASELINE; // 时间基设置 out_stream->time_base = (AVRational){1, 1000}; // 毫秒级

延迟优化关键点：

设置zerolatency参数禁用缓冲
GOP不宜过长，建议2秒（如30fps则gop_size=60）
音频采用AAC-LC编码，采样率44100Hz
视频帧率与摄像头采集帧率严格一致

在百兆局域网环境下，这套配置可以实现端到端延迟稳定在400ms以内。我曾对比过不同preset参数的效果：

ultrafast：延迟最低但码率波动大
medium：码率稳定但延迟增加200ms
superfast：平衡性最佳

5. 多线程处理与丢帧对策

单线程方案就像用一只手接球——当你要处理RTMP打包时，摄像头数据就漏接了。我的解决方案是双线程+环形缓冲区：

typedef struct { uint8_t *data; size_t size; int64_t pts; } FrameBuffer; #define RING_SIZE 8 FrameBuffer ring[RING_SIZE]; int wp = 0, rp = 0; pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; pthread_cond_t cond = PTHREAD_COND_INITIALIZER; // 采集线程 void *capture_thread(void *arg) { while (running) { FrameBuffer *fb = &ring[wp]; int len = read_frame(fb); // 从摄像头读取 pthread_mutex_lock(&lock); wp = (wp + 1) % RING_SIZE; pthread_cond_signal(&cond); pthread_mutex_unlock(&lock); } return NULL; } // 推流线程 void *stream_thread(void *arg) { while (running) { pthread_mutex_lock(&lock); while (rp == wp) // 缓冲区空 pthread_cond_wait(&cond, &lock); FrameBuffer *fb = &ring[rp]; send_to_rtmp(fb); // 推流处理 rp = (rp + 1) % RING_SIZE; pthread_mutex_unlock(&lock); } return NULL; }

实测这个方案在树莓派上能稳定处理720p@30fps流，丢帧率从15%降到0.3%。几个优化细节：

环形缓冲区大小建议是帧率的2倍（如30fps用60缓冲）
使用pthread_cond_timedwait避免死锁
当缓冲区超过75%时主动丢帧保实时性
内存对齐到64字节提升拷贝效率

6. 常见问题排查指南

问题1：VIDIOC_S_FMT失败

检查摄像头是否被其他进程占用：lsof /dev/video0
确认支持的格式：v4l2-ctl --list-formats-ext
尝试更低分辨率如640x480

问题2：RTMP连接被拒绝

测试服务器端口是否开放：telnet 192.168.1.100 1935
检查防火墙设置：sudo ufw allow 1935/tcp
尝试简单推流验证：ffmpeg -re -i test.mp4 -c copy -f flv rtmp://server/live

问题3：播放端花屏

检查关键帧间隔：ffprobe -show_frames input.flv | grep key_frame
调整GOP大小：cctx->gop_size = fps * 2
添加错误恢复参数：av_dict_set(&options, "fflags", "discardcorrupt", 0);

问题4：高延迟

测量各阶段耗时：

# 采集延迟 time v4l2-ctl --stream-mmap --stream-count=100 # 网络延迟 ping rtmp_server # 解码延迟 ffmpeg -i rtmp_url -f null -

启用低延迟模式：av_dict_set(&options, "tune", "zerolatency", 0);

7. 性能优化进阶技巧

DMA-BUF内存共享在支持DRM的平台上，可以绕过用户空间拷贝：

req.memory = V4L2_MEMORY_DMABUF; // 替代MMAP ioctl(fd, VIDIOC_REQBUFS, &req);

硬件加速编码如果摄像头只输出YUV，可用VAAPI加速：

AVCodecContext *cctx = ...; cctx->hw_frames_ctx = av_hwframe_ctx_alloc(AV_HWDEVICE_TYPE_VAAPI); AVHWFramesContext *hw_ctx = (AVHWFramesContext*)cctx->hw_frames_ctx->data; hw_ctx->format = AV_PIX_FMT_VAAPI; hw_ctx->sw_format = AV_PIX_FMT_NV12; hw_ctx->width = 1280; hw_ctx->height = 720; av_hwframe_ctx_init(cctx->hw_frames_ctx);

自适应码率控制根据网络状况动态调整：

if (net_slow) { cctx->bit_rate = 800000; // 降码率 cctx->rc_max_rate = 800000; av_dict_set(&options, "preset", "ultrafast", 0); } else { cctx->bit_rate = 1500000; cctx->rc_max_rate = 1500000; av_dict_set(&options, "preset", "superfast", 0); }

在RK3399开发板上测试，VAAPI方案能将1080p编码功耗从12W降到4W，温度下降20℃。不过要注意驱动兼容性问题，建议先用vainfo检查支持情况。

查看全文

http://www.jsqmd.com/news/644211/