：V4L2采集與硬編碼)
1. 為什么選 RK3588 做 WiFi 無線攝像頭推流方案選型與硬件準(zhǔn)備先聊點實在的。我這個項目最開始其實不是非 RK3588 不可當(dāng)時手里同時有樹莓派 4B 和一塊全志 H6 的開發(fā)板都試過做 USB 攝像頭采集推流。結(jié)果怎么說呢要么是編碼性能拉胯1080p 推流 CPU 直接燒到 80% 以上要么是 WiFi 吞吐不穩(wěn)定畫面時不時卡成幻燈片。后來換了 RK3588整體體驗完全不一樣了。RK3588 這芯片在嵌入式開發(fā)圈里這兩年熱度一直很高8 核 ARM 架構(gòu)4 個 Cortex-A76 大核加 4 個 Cortex-A55 小核算力相當(dāng)充裕而且自帶 NPU雖然這個項目暫時沒用到 AI 推理但后續(xù)如果想在端側(cè)跑個目標(biāo)檢測、人臉識別再做智能推流硬件底子是現(xiàn)成的。更重要的是RK3588 內(nèi)置了 VPU視頻編解碼單元硬編 H.264/H.265 都是常規(guī)操作這樣 CPU 就能從編碼這種重活里解放出來哪怕 4K 分辨率的視頻流推出去系統(tǒng)負載也能保持在一個很健康的水位。再一個原因就是接口資源。RK3588 的 MIPI-CSI 接口支持多路攝像頭輸入USB 3.0 Host 口也夠多這意味著無論是接 MIPI 攝像頭模組還是免驅(qū) UVC 攝像頭都非常靈活。我這套方案用的是一個普通的 USB 攝像頭走的標(biāo)準(zhǔn) V4L2 協(xié)議根本不需要額外寫驅(qū)動插上就能識別對新手來說特別友好。硬件準(zhǔn)備清單如下硬件/軟件型號/版本說明開發(fā)板RK3588 開發(fā)板我用的是某國產(chǎn)廠商的核心板加底板方案8GB 或 16GB 內(nèi)存都行存儲建議 32GB 以上攝像頭USB UVC 免驅(qū)攝像頭支持 1080p選 YUYV/MJPEG 輸出格式的兼容性好系統(tǒng)Ubuntu 22.04RK3588 移植版或者 Debian內(nèi)核 5.10 以上自帶 V4L2 框架WiFiUSB 無線網(wǎng)卡或板載 WiFi 模塊支持 AP/STA 模式我用的板載 WiFi 6 模塊實測吞吐穩(wěn)定軟件GStreamer、FFmpeg、VLC用于驗證核心推流工具下面細說提示RK3588 的很多開發(fā)板出廠帶的是 Android 系統(tǒng)做嵌入式 Linux 開發(fā)之前記得先刷成 Ubuntu 或 Debian 的固件網(wǎng)上針對各廠商板子的移植教程已經(jīng)比較成熟了實在不行用系統(tǒng)自帶的 SDK 自己編一個也行只是耗時比較長。這里想特別強調(diào)一下選 USB UVC 攝像頭而不是 MIPI 攝像頭的原因。MIPI-CSI 攝像頭的畫質(zhì)上限確實更高但驅(qū)動適配是個大坑不同廠商的 sensor 芯片驅(qū)動差異很大很多 RK3588 的板子即使有 DTS 配置也要反復(fù)調(diào)。USB UVC 攝像頭走的是標(biāo)準(zhǔn)協(xié)議Linux 內(nèi)核里已經(jīng)有現(xiàn)成的uvcvideo驅(qū)動插上就能枚舉出/dev/video0對做應(yīng)用層開發(fā)的人來說省了不止一個晚上的折騰時間。2. V4L2 攝像頭采集鏈路從設(shè)備枚舉到原始幀讀取V4L2 的全稱是 Video for Linux 2是 Linux 內(nèi)核里一套標(biāo)準(zhǔn)化的視頻設(shè)備驅(qū)動框架。你可以理解成攝像頭在 Linux 系統(tǒng)里的普通話協(xié)議——不管底層是什么 sensor、什么接口上層應(yīng)用只要按 V4L2 的規(guī)范操作/dev/videoX這個設(shè)備節(jié)點就能拿到圖像數(shù)據(jù)。這種設(shè)計思路和 POSIX 文件操作很像一切都是文件一切都是標(biāo)準(zhǔn)接口。2.1 先用命令行確認攝像頭能被系統(tǒng)正確識別動手寫代碼之前先跑幾個命令確認攝像頭工作正常。插上 USB 攝像頭后在 RK3588 的終端里執(zhí)行l(wèi)susb ls /dev/video* v4l2-ctl --list-devices正常情況下v4l2-ctl --list-devices會輸出類似這樣的內(nèi)容USB Camera (1bcf:2c87): /dev/video0接著查看攝像頭支持的像素格式和分辨率v4l2-ctl -d /dev/video0 --list-formats-ext輸出里如果能看到Y(jié)UYV或者MJPG就說明攝像頭在 UVC 協(xié)議下工作正常。這里有個重要概念YUYV 是無壓縮的裸數(shù)據(jù)格式一幀 1080p 圖像在 YUYV 下大約是1920 * 1080 * 2字節(jié)算下來差不多 4MB如果以 30fps 采集每秒數(shù)據(jù)量是 120MB 以上這個數(shù)據(jù)量直接扔到網(wǎng)絡(luò)上是不現(xiàn)實的。MJPG 是攝像頭內(nèi)部做了 JPEG 壓縮后輸出的格式同樣一幀 1080p 可能只需要 100KB 到 300KB流量壓力小很多但代價是畫質(zhì)有損、解碼需要算力。所以這里要鋪墊一個貫穿整個項目的判斷攝像頭采集端到底輸出什么格式?jīng)Q定了后面推流鏈路的復(fù)雜度。我的建議是如果攝像頭支持 MJPG優(yōu)先用 MJPG 做網(wǎng)絡(luò)傳輸如果只支持 YUYV那就老老實實在板子上做硬編碼壓縮別想著裸流直接推。2.2 V4L2 編程的基本套路打開設(shè)備、設(shè)置格式、申請緩沖區(qū)、啟動采集命令行驗證完下面進入正式的主題——用 C 語言寫一個 V4L2 采集程序。這里先給出完整可運行的代碼然后逐段拆解關(guān)鍵邏輯。#include stdio.h #include stdlib.h #include string.h #include fcntl.h #include unistd.h #include errno.h #include sys/ioctl.h #include sys/mman.h #include linux/videodev2.h #define DEVICE_PATH /dev/video0 #define WIDTH 1920 #define HEIGHT 1080 #define BUFFER_COUNT 4 struct buffer_info { void *start; size_t length; }; static struct buffer_info buffers[BUFFER_COUNT]; static int xioctl(int fd, unsigned long request, void *arg) { int r; do { r ioctl(fd, request, arg); } while (r -1 errno EINTR); return r; } int main(void) { int fd open(DEVICE_PATH, O_RDWR | O_NONBLOCK, 0); if (fd 0) { perror(open video device failed); return -1; } struct v4l2_format fmt; memset(fmt, 0, sizeof(fmt)); fmt.type V4L2_BUF_TYPE_VIDEO_CAPTURE; fmt.fmt.pix.width WIDTH; fmt.fmt.pix.height HEIGHT; fmt.fmt.pix.pixelformat V4L2_PIX_FMT_YUYV; fmt.fmt.pix.field V4L2_FIELD_NONE; if (xioctl(fd, VIDIOC_S_FMT, fmt) 0) { perror(set format failed); close(fd); return -1; } struct v4l2_requestbuffers req; memset(req, 0, sizeof(req)); req.count BUFFER_COUNT; req.type V4L2_BUF_TYPE_VIDEO_CAPTURE; req.memory V4L2_MEMORY_MMAP; if (xioctl(fd, VIDIOC_REQBUFS, req) 0) { perror(request buffers failed); close(fd); return -1; } for (int i 0; i BUFFER_COUNT; i) { struct v4l2_buffer buf; memset(buf, 0, sizeof(buf)); buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; buf.index i; if (xioctl(fd, VIDIOC_QUERYBUF, buf) 0) { perror(query buffer failed); close(fd); return -1; } buffers[i].length buf.length; buffers[i].start mmap(NULL, buf.length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, buf.m.offset); if (buffers[i].start MAP_FAILED) { perror(mmap failed); close(fd); return -1; } } enum v4l2_buf_type type V4L2_BUF_TYPE_VIDEO_CAPTURE; for (int i 0; i BUFFER_COUNT; i) { struct v4l2_buffer buf; memset(buf, 0, sizeof(buf)); buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; buf.index i; if (xioctl(fd, VIDIOC_QBUF, buf) 0) { perror(queue buffer failed); return -1; } } if (xioctl(fd, VIDIOC_STREAMON, type) 0) { perror(stream on failed); close(fd); return -1; } for (int frame_count 0; frame_count 300; frame_count) { fd_set fds; FD_ZERO(fds); FD_SET(fd, fds); struct timeval tv; tv.tv_sec 2; tv.tv_usec 0; int sel select(fd 1, fds, NULL, NULL, tv); if (sel 0) { perror(select failed); break; } if (sel 0) { fprintf(stderr, select timeout, no frame\n); continue; } struct v4l2_buffer buf; memset(buf, 0, sizeof(buf)); buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; if (xioctl(fd, VIDIOC_DQBUF, buf) 0) { perror(dequeue buffer failed); break; } // 到這里buffers[buf.index].start 就是一幀圖像數(shù)據(jù) // 幀大小為 buf.bytesused 字節(jié) printf(frame %d: size%d bytes\n, frame_count, buf.bytesused); // 實際項目中這里會把 buf 里的數(shù)據(jù)交給編碼器/網(wǎng)絡(luò)模塊處理 if (xioctl(fd, VIDIOC_QBUF, buf) 0) { perror(requeue buffer failed); break; } } type V4L2_BUF_TYPE_VIDEO_CAPTURE; xioctl(fd, VIDIOC_STREAMOFF, type); for (int i 0; i BUFFER_COUNT; i) { munmap(buffers[i].start, buffers[i].length); } close(fd); return 0; }2.3 這段采集代碼里幾個值得琢磨的細節(jié)先看打開設(shè)備那一步。我這里用了O_NONBLOCK非阻塞模式然后靠select()來等待幀數(shù)據(jù)準(zhǔn)備好。如果不用非阻塞模式VIDIOC_DQBUF會在沒有幀數(shù)據(jù)時一直卡住主線程就被堵死了。用select()的好處是能設(shè)置超時時間一旦攝像頭異常比如線松了、設(shè)備被占用程序不至于掛死可以及時報錯處理。實際項目里我還會把超時后的重連邏輯加進去比如連續(xù)超時 5 次就自動重新打開設(shè)備這對長時間運行的監(jiān)控設(shè)備特別重要。然后是緩沖區(qū)機制。V4L2 經(jīng)典的REQBUFS - QUERYBUF - mmap - QBUF - DQBUF流程本質(zhì)上是一個生產(chǎn)者消費者模型攝像頭硬件是生產(chǎn)者往 DMA 緩沖區(qū)里寫圖像數(shù)據(jù)應(yīng)用層是消費者從緩沖區(qū)里把數(shù)據(jù)取走。用多個緩沖區(qū)這里設(shè)了 4 個能避免一幀數(shù)據(jù)還沒處理完下一幀就被覆蓋的情況。緩沖區(qū)數(shù)量也不是越多越好多了占內(nèi)存少了容易丟幀4 到 8 個是比較合理的區(qū)間。還有一個常被忽略的坑VIDIOC_S_FMT設(shè)置格式不保證一定成功特別是某些攝像頭不支持你指定的分辨率和像素格式時驅(qū)動會靜默改成自己支持的最接近值。所以設(shè)置完格式之后一定要再調(diào)用VIDIOC_G_FMT讀回來確認一下實際生效的參數(shù)不然你按 1080p 分配緩沖區(qū)攝像頭卻輸出 640x480后面全是內(nèi)存越界問題排查起來非常酸爽。3. 推流方案的技術(shù)選型GStreamer 硬編碼管線 vs FFmpeg 軟編碼采集到原始幀之后畫面數(shù)據(jù)是有了但離WiFi 推流還有一道關(guān)鍵工序編碼成 H.264/H.265 再封裝成適合網(wǎng)絡(luò)傳輸?shù)牧鞲袷絉TSP/RTP/FLV。市面上主流的選擇就是 GStreamer 和 FFmpeg 這兩個框架我這次兩個方案都實測過下面分別說說優(yōu)缺點和適用場景。3.1 GStreamer RK3588 硬件編碼性能和效率的首選RK3588 的 VPU 在 GStreamer 里對應(yīng)的插件是mpph264encMpp 是 Rockchip 媒體處理平臺的簡稱。用 GStreamer 拼一條推流管線核心思路就是v4l2src 采集視頻 - 像素格式轉(zhuǎn)換 - mpph264enc 硬編碼 - rtph264pay 打包 - udpsink 或 rtsp 服務(wù)端一條完整的命令行推流示例推 UDP 到局域網(wǎng)內(nèi)的一臺 PC 上用 VLC 接收gst-launch-1.0 v4l2src device/dev/video0 ! \ video/x-raw,width1920,height1080,framerate30/1 ! \ videoconvert ! \ video/x-raw,formatI420 ! \ mpph264enc bitrate2000000 ! \ h264parse ! \ rtph264pay config-interval1 pt96 ! \ udpsink host192.168.1.100 port5000這里解釋一下每個插件的用途v4l2src從 V4L2 設(shè)備采集視頻幀。注意如果你把攝像頭格式設(shè)成了 MJPG這里還需要插入jpegdec解壓成原始圖像否則后面的編碼器不認。常見的坑是視頻格式?jīng)]有協(xié)商好看到Internal data stream error多半就是格式協(xié)商不通過解決辦法是在 Caps 里明確指定video/x-raw的格式和分辨率。videoconvert做像素格式轉(zhuǎn)換。攝像頭的輸出是 YUYV而 H.264 編碼器輸入通常要求 I420這中間差一步轉(zhuǎn)換。別小看這個插件它在 CPU 上做轉(zhuǎn)換的時候也有開銷如果能直接在采集端拿到 I420 格式會好一點但大部分 UVC 攝像頭原生只給 YUYV 或 MJPEG。mpph264encRK3588 的硬編碼器bitrate參數(shù)直接控制碼率。我實測 2Mbps 下 1080p30 的畫面在室內(nèi)場景基本上畫質(zhì)能接受運動劇烈一點的場景建議提到 4Mbps。h264parsertph264pay把 H.264 裸流封裝成 RTP 包這樣才能走 UDP 推給播放器。udpsink把 RTP 包發(fā)到指定主機的指定端口。這種 GStreamer 管線的好處是完全不用寫代碼一條命令就能跑起來而且硬編碼對 CPU 占用極低。我在 RK3588 上實測1080p30 硬編碼推流時四個 A76 大核的 CPU 占用率加起來不超過 15%大部分時候維持在 5% 以內(nèi)真的是殺雞用牛刀級別的輕松。3.2 FFmpeg x264 軟編碼兼容性優(yōu)先的備選方案如果你不想在板子上裝一堆 GStreamer 插件或者你的攝像頭輸出的格式比較奇葩FFmpeg 是更大眾的選擇。在 RK3588 上FFmpeg 也可以調(diào)用 Rockchip 的硬件編碼器但需要專門編譯帶--enable-rkmpp選項的版本很多發(fā)行版自帶的 FFmpeg 默認不啟用這個能力。不帶硬件加速的話直接用軟件 x264 編碼也能跑命令如下ffmpeg -f v4l2 -input_format yuyv422 -video_size 1920x1080 -framerate 30 \ -i /dev/video0 -c:v libx264 -preset veryfast -b:v 2M \ -f rtsp rtsp://192.168.1.100:8554/live這里-preset veryfast是為了降低編碼延遲x264 的編碼速度直接決定實時性表現(xiàn)。我的實測結(jié)果是在 RK3588 上用veryfast檔位編碼 1080p30CPU 占用大約 30% 到 40%比硬編碼高不少但還在可接受范圍。如果你用的是性能更弱的板子這個方案可能就撐不住了。FFmpeg 方案最大的優(yōu)勢是協(xié)議支持全面。不管你要推 RTSP、RTMP 還是直接錄成 MP4 文件FFmpeg 一個工具全搞定而且參數(shù)調(diào)起來非常直觀適合快速驗證。但它在低延遲場景下表現(xiàn)不如 GStreamer 的純 RTP 管線靈活因為 FFmpeg 的 RTSP 服務(wù)模式是轉(zhuǎn)發(fā)模式內(nèi)部會有緩沖延遲通常會比 GStreamer 的 UDP 直推高一截。3.3 我最終的選擇雙路并行策略這個項目最終我采用了GStreamer 做主干推流FFmpeg 做輔助錄制的組合方案。主干推流用 GStreamer mpph264enc 保證低延遲和低 CPU 占用同時在板子上定時用 FFmpeg 拉取本地的 RTSP 流做切片錄制這樣既滿足了實時監(jiān)看的延遲要求又保證了關(guān)鍵時刻有錄像留存。這種一魚兩吃的做法在真實項目里非常常見因為運維監(jiān)控場景既要看得見也要留得住。4. WiFi 推流的網(wǎng)絡(luò)痛點為什么局域網(wǎng)延遲時好時壞以及如何優(yōu)化攝像頭數(shù)據(jù)采集和編碼都搞定之后最大的不可控因素就剩 WiFi 了。我最初在局域網(wǎng)里用普通 2.4GHz WiFi 測試的時候延遲經(jīng)常在 200ms 到 2 秒之間反復(fù)橫跳畫面時不時卡頓一下一度以為是自己代碼寫的太爛后來排查發(fā)現(xiàn)根因在網(wǎng)絡(luò)這一層。4.1 WiFi 頻段選擇對推流質(zhì)量的影響2.4GHz 頻段的穿透能力確實好但干擾源也多——藍牙、微波爐、鄰居的路由器全擠在 2.4GHz 這不到 100MHz 的頻譜里環(huán)境稍微復(fù)雜一點WiFi 吞吐量就會劇烈抖動。而視頻流最怕的就是吞吐量抖動因為直播類應(yīng)用對帶寬是持續(xù)占滿型的需求不像網(wǎng)頁瀏覽那樣有突發(fā)性容忍度。我實測下來的數(shù)據(jù)WiFi 環(huán)境1080p30 推流延遲卡頓情況2.4GHz普通路由器多設(shè)備共存300ms - 2s頻繁輕微卡頓偶爾爆卡5GHz路由器較近3 米內(nèi)100ms - 300ms基本流暢5GHz穿一堵墻300ms - 800ms輕微卡頓建議是做 WiFi 推流時板子和路由器之間盡量用 5GHz 頻段并且縮短物理距離。如果只能走 2.4GHz那就降低推流碼率和分辨率比如 720p 加 1Mbps 碼率老老實實換體驗。另外注意一個容易忽略的點RK3588 開發(fā)板上的無線網(wǎng)卡很多是同時支持 AP 和 STA 模式的也就是板和手機可以組成一個獨立的 WiFi 熱點網(wǎng)絡(luò)。在戶外沒有路由器的時候可以讓板子開一個 AP手機連上板的 WiFi 熱點就能直接看視頻流。這種無基礎(chǔ)設(shè)施的玩法在無人機圖傳、車載監(jiān)控等場景特別實用而且因為跳過了路由器轉(zhuǎn)發(fā)數(shù)據(jù)路徑更短延遲反而更低。4.2 TCP 還是 UDP這是個問題推流傳輸層協(xié)議的選擇同樣關(guān)鍵。GStreamer 里如果推 RTSP底層默認走 TCP可靠傳輸?shù)貍鳈C制會帶來額外延遲如果要低延遲可以用 UDP 直推不可靠傳輸丟包就直接丟幀但不卡頓。TCP 和 UDP 在視頻推流場景下的表現(xiàn)差異非常大。TCP 雖然不會丟包但一旦網(wǎng)絡(luò)出現(xiàn)瞬時擁塞TCP 的擁塞控制算法會主動降低發(fā)送速率導(dǎo)致視頻延遲節(jié)節(jié)攀升畫面雖然不花屏但越來越卡頓其實是延遲越來越大。UDP 則不會做這種退避丟掉的包直接丟棄播放端畫面雖然可能偶發(fā)花屏、馬賽克但時間線上是實時的不會有延遲持續(xù)積累的問題。我的經(jīng)驗是內(nèi)網(wǎng)可控環(huán)境用 UDP廣域網(wǎng)環(huán)境用 TCP。內(nèi)網(wǎng)丟包率極低UDP 完全夠用公網(wǎng)上丟包不可避免TCP 重傳至少保證畫面完整延遲高一點也能接受。4.3 碼率匹配策略別讓編碼輸出和網(wǎng)絡(luò)帶寬打架很多人做推流時只關(guān)注編碼參數(shù)忽略了網(wǎng)絡(luò)帶寬這個木桶短板。RK3588 的 mpph264enc 設(shè)置的固定碼率在 2Mbps但如果 WiFi 的有效吞吐只有 1.5Mbps那畫面必然卡頓。這里建議在應(yīng)用層做一層自適應(yīng)碼率控制定期檢測網(wǎng)絡(luò)的往返時延RTT和發(fā)送隊列的堆積情況如果 RTT 持續(xù)偏高就把編碼器的bitrate參數(shù)動態(tài)調(diào)低例如從 2Mbps 降到 1.2Mbps讓畫面更流暢。在 GStreamer 里可以通過mpph264enc的bitrateproperty 動態(tài)設(shè)置gst-launch-1.0 v4l2src device/dev/video0 ! \ video/x-raw,width1280,height720,framerate30/1 ! \ videoconvert ! video/x-raw,formatI420 ! \ mpph264enc bitrate1200000 ! \ h264parse ! rtph264pay config-interval1 pt96 ! \ udpsink host192.168.1.100 port50004.4 網(wǎng)絡(luò)緩沖區(qū)的隱藏雷區(qū)還有一個坑我從沒見文檔里寫明過GStreamer 的udpsink插件默認有一個發(fā)送緩沖區(qū)如果網(wǎng)絡(luò)擁堵導(dǎo)致數(shù)據(jù)堆積緩沖區(qū)會被填滿然后udpsink會開始丟包。這種行為本身沒問題但會導(dǎo)致畫面突然出現(xiàn)大范圍花屏。解決辦法是通過udpsink的max-lateness和qos參數(shù)控制發(fā)送節(jié)奏讓過期的幀直接丟棄而不是堆積等待。加入 QoS服務(wù)質(zhì)量機制后播放端收到的幀是最新鮮的延遲會明顯下降代價是網(wǎng)絡(luò)差時幀率會掉。命令行加參數(shù)的方式udpsink host192.168.1.100 port5000 qostrue max-lateness10000000這里的max-lateness單位是納秒10000000納秒就是 10ms超過這個時間的幀直接丟。經(jīng)過這樣調(diào)整后WiFi 環(huán)境下的畫面流暢度和延遲一致性提升很明顯。5. 完整代碼實現(xiàn)推流主程序的架構(gòu)設(shè)計和關(guān)鍵模塊拆解前面講了不少概念和命令行方案下面寫一個稍微體面的 C 程序把這些要素整合起來。這個程序不依賴 GStreamer 的命令行而是直接用 V4L2 采集 RKMPP 硬編碼 RTP 打包可以理解成一個精簡版的推流器。5.1 程序整體架構(gòu)整個推流程序分四個線程采集線程V4L2 循環(huán)取幀放進幀隊列。編碼線程從幀隊列取出原始幀交給 RKMPP 硬編碼為 H.264放進編碼幀隊列。發(fā)送線程從編碼幀隊列取 H.264 數(shù)據(jù)封裝成 RTP 包通過 UDP socket 發(fā)出。控制線程響應(yīng)命令行輸入如修改碼率、打印狀態(tài)實現(xiàn)簡單的運行管理。用多線程而非單線程循環(huán)是因為采集、編碼和網(wǎng)絡(luò)發(fā)送三個環(huán)節(jié)的速度不恒等如果串行執(zhí)行任何一環(huán)變慢都會拖垮整條鏈路。用隊列解耦之后即使網(wǎng)絡(luò)短暫擁塞編碼線程也可以繼續(xù)工作把數(shù)據(jù)積壓在編碼幀隊列里一旦網(wǎng)絡(luò)恢復(fù)發(fā)送線程能快速追上進度。5.2 關(guān)鍵結(jié)構(gòu)體和隊列封裝#include pthread.h #include semaphore.h #include stdint.h #include rga/RgaApi.h #include rockchip/rk_mpi.h #define MAX_QUEUE_SIZE 8 typedef struct { void *data; size_t size; uint64_t pts; } frame_t; typedef struct { frame_t frames[MAX_QUEUE_SIZE]; int head; int tail; int count; pthread_mutex_t lock; sem_t empty_slots; sem_t full_slots; } frame_queue_t; void queue_init(frame_queue_t *q) { q-head 0; q-tail 0; q-count 0; pthread_mutex_init(q-lock, NULL); sem_init(q-empty_slots, 0, MAX_QUEUE_SIZE); sem_init(q-full_slots, 0, 0); } void queue_push(frame_queue_t *q, frame_t *frame) { sem_wait(q-empty_slots); pthread_mutex_lock(q-lock); q-frames[q-tail] *frame; q-tail (q-tail 1) % MAX_QUEUE_SIZE; q-count; pthread_mutex_unlock(q-lock); sem_post(q-full_slots); } int queue_pop(frame_queue_t *q, frame_t *frame) { sem_wait(q-full_slots); pthread_mutex_lock(q-lock); if (q-count 0) { pthread_mutex_unlock(q-lock); return -1; } *frame q-frames[q-head]; q-head (q-head 1) % MAX_QUEUE_SIZE; q-count--; pthread_mutex_unlock(q-lock); sem_post(q-empty_slots); return 0; }用信號量 互斥鎖組合的方式實現(xiàn)了一個經(jīng)典的有界阻塞隊列。這里沒有用無鎖隊列因為賽道上這幾個線程的數(shù)據(jù)量并不算極端加鎖完全可以接受。如果將來要做 4K 60fps 那種高吞吐場景再考慮無鎖隊列或者環(huán)形緩沖區(qū)也不遲。5.3 采集線程的實現(xiàn)采集線程就是把之前那段 V4L2 代碼放到線程函數(shù)里然后每取到一幀塞進raw_frame_queue。void *capture_thread(void *arg) { // 參數(shù)設(shè)備路徑幀隊列指針 char *dev_path ((char **)arg)[0]; frame_queue_t *q (frame_queue_t *)(((void **)arg)[1]); int fd open(dev_path, O_RDWR | O_NONBLOCK, 0); if (fd 0) { perror(open device failed); return NULL; } // 設(shè)置 1080p YUYV 格式 struct v4l2_format fmt; memset(fmt, 0, sizeof(fmt)); fmt.type V4L2_BUF_TYPE_VIDEO_CAPTURE; fmt.fmt.pix.width 1920; fmt.fmt.pix.height 1080; fmt.fmt.pix.pixelformat V4L2_PIX_FMT_YUYV; fmt.fmt.pix.field V4L2_FIELD_NONE; xioctl(fd, VIDIOC_S_FMT, fmt); // 讀回實際格式并檢查 struct v4l2_format actual; memset(actual, 0, sizeof(actual)); actual.type V4L2_BUF_TYPE_VIDEO_CAPTURE; xioctl(fd, VIDIOC_G_FMT, actual); if (actual.fmt.pix.width ! 1920 || actual.fmt.pix.height ! 1080) { fprintf(stderr, Warning: actual format is %dx%d\n, actual.fmt.pix.width, actual.fmt.pix.height); } // 申請緩沖區(qū)、mmap、QBUF 等同前文示例代碼 // 采集循環(huán) struct v4l2_buffer buf; for (;;) { fd_set fds; FD_ZERO(fds); FD_SET(fd, fds); struct timeval tv {2, 0}; select(fd 1, fds, NULL, NULL, tv); memset(buf, 0, sizeof(buf)); buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; if (xioctl(fd, VIDIOC_DQBUF, buf) 0) { continue; } frame_t frame; frame.data malloc(buf.bytesused); memcpy(frame.data, buffers[buf.index].start, buf.bytesused); frame.size buf.bytesused; frame.pts (uint64_t)((double)clock() / CLOCKS_PER_SEC * 1000); queue_push(q, frame); xioctl(fd, VIDIOC_QBUF, buf); } }這里注意我從 mmap 緩沖區(qū)里memcpy了一份數(shù)據(jù)到堆內(nèi)存然后才入隊。為什么不直接把 mmap 緩沖區(qū)地址傳下去因為緩沖區(qū)在 DQBUF 之后再次 QBUF 時硬件可能立刻往里寫下一幀如果編碼線程還在讀這塊內(nèi)存就會產(chǎn)生數(shù)據(jù)競爭。要么加鎖保護要么拷貝一份我選擇了性價比更高的拷貝方式——內(nèi)存占用多一點但邏輯簡單安全。5.4 編碼線程調(diào)用 RKMPP 硬編碼RKMPPRockchip Media Process Platform是 Rockchip 官方提供的多媒體編程接口。相比直接用 V4L2 的VIDIOC_ENCODER_CMD或者 GStreamer 插件RKMPP 的 API 更貼近底層適合做精細控制。編碼線程的核心代碼void *encode_thread(void *arg) { frame_queue_t *input_q (frame_queue_t *)(((void **)arg)[0]); frame_queue_t *output_q (frame_queue_t *)(((void **)arg)[1]); MppCtx ctx; MppApi *mpi; mpp_create(ctx, mpi); mpp_init(ctx, MPF_CTX_ENC, MPP_VIDEO_CodingAVC); MppEncPrepCfg prep_cfg; memset(prep_cfg, 0, sizeof(prep_cfg)); prep_cfg.width 1920; prep_cfg.height 1080; prep_cfg.format MPP_FMT_YUV420SP; prep_cfg.frame_rate 30; mpi-control(ctx, MPP_ENC_SET_PREP_CFG, prep_cfg); MppEncCodecCfg codec_cfg; memset(codec_cfg, 0, sizeof(codec_cfg)); codec_cfg.codec_type MPP_VIDEO_CodingAVC; codec_cfg.h264.profile 100; codec_cfg.h264.level 40; codec_cfg.h264.cabac_en 1; codec_cfg.h264.cabac_idc 0; codec_cfg.h264.trans_8x8 1; mpi-control(ctx, MPP_ENC_SET_CODEC_CFG, codec_cfg); MppEncRcCfg rc_cfg; memset(rc_cfg, 0, sizeof(rc_cfg)); rc_cfg.rc_mode MPP_RC_CBR; rc_cfg.bps 2000000; rc_cfg.bps_max 2500000; rc_cfg.bps_min 1500000; mpi-control(ctx, MPP_ENC_SET_RC_CFG, rc_cfg); // 幀數(shù)據(jù)搬運到 MPP 緩沖區(qū)并編碼 frame_t raw_frame; while (!stop_flag) { if (queue_pop(input_q, raw_frame) 0) continue; // 將 YUYV 轉(zhuǎn)為 NV12RKMPP 輸入格式 // 這里也可以用 RGA 硬件加速下文會提到 uint8_t *nv12_data convert_yuyv_to_nv12( (uint8_t *)raw_frame.data, 1920, 1080); // 申請 MPP 編碼使用的輸入包 MppPacket packet NULL; mpp_packet_init(packet, nv12_data, 1920 * 1080 * 3 / 2); mpi-encode_put_packet(ctx, packet); MppPacket out_packet NULL; mpi-encode_get_packet(ctx, out_packet); if (out_packet) { frame_t enc_frame; enc_frame.data malloc(mpp_packet_get_size(out_packet)); memcpy(enc_frame.data, mpp_packet_get_data(out_packet), mpp_packet_get_size(out_packet)); enc_frame.size mpp_packet_get_size(out_packet); enc_frame.pts raw_frame.pts; queue_push(output_q, enc_frame); mpp_packet_deinit(out_packet); } free(nv12_data); free(raw_frame.data); mpp_packet_deinit(packet); } mpp_destroy(ctx); return NULL; }5.5 發(fā)送線程RTP 封包和 UDP 發(fā)送RTP 封包這部分H.264 的 NAL 單元如果大于 MTU通常 1500 字節(jié)就需要做分片F(xiàn)U-A否則播放端無法正確重組。這里實現(xiàn)一個簡化的分包邏輯void send_h264_rtp(int sockfd, struct sockaddr_in *dst, uint8_t *nal_data, size_t nal_size, uint32_t *timestamp) { // 跳過 NAL 起始碼 00 00 00 01 或 00 00 01 uint8_t *nal_start nal_data; while (nal_start nal_data nal_size - 4) { if (*(uint32_t *)nal_start 0x00000001 || *(uint32_t *)nal_start 0x00000100) { break; } nal_start; } size_t header_size (nal_start[2] 1) ? 3 : 4; uint8_t *payload nal_start header_size; size_t payload_size nal_size - (payload - nal_data); uint8_t nal_header payload[0]; uint8_t nal_type nal_header 0x1f; if (payload_size MAX_RTP_PAYLOAD) { // 單包封裝 uint8_t rtp_buf[1500]; rtp_buf[0] 0x80; rtp_buf[1] 96; // payload type PT96 rtp_buf[2] (uint8_t)((*timestamp) 8); rtp_buf[3] (uint8_t)(*timestamp); rtp_buf[4] 0x00; rtp_buf[5] 0x00; rtp_buf[6] 0x00; rtp_buf[7] 0x01; // SSRC memcpy(rtp_buf 12, payload, payload_size); sendto(sockfd, rtp_buf, 12 payload_size, 0, (struct sockaddr *)dst, sizeof(*dst)); } else { // FU-A 分片封裝 uint8_t fu_indicator (nal_header 0xe0) | 28; uint8_t fu_header; uint8_t rtp_buf[1500]; size_t offset 0; int first 1; while (offset payload_size) { size_t chunk_size payload_size - offset; if (chunk_size MAX_RTP_PAYLOAD - 2) chunk_size MAX_RTP_PAYLOAD - 2; rtp_buf[0] 0x80; rtp_buf[1] 96; rtp_buf[2] (uint8_t)((*timestamp) 8); rtp_buf[3] (uint8_t)(*timestamp); // ... 填充 RTP header fu_header (nal_type 0x1f); if (first) fu_header | 0x80; if (offset chunk_size payload_size) fu_header | 0x40; rtp_buf[12] fu_indicator; rtp_buf[13] fu_header; memcpy(rtp_buf 14, payload offset, chunk_size); sendto(sockfd, rtp_buf, 14 chunk_size, 0, (struct sockaddr *)dst, sizeof(*dst)); offset chunk_size; first 0; } } }5.6 完整示例代碼倉庫結(jié)構(gòu)這個程序如果完整寫完代碼量在 500 行左右。一個合理的工程目錄結(jié)構(gòu)可以是rtsp_streamer/ ├── Makefile ├── src/ │ ├── main.c # 主函數(shù)、線程創(chuàng)建 │ ├── v4l2_capture.c # 采集模塊 │ ├── encoder_mpp.c # RKMPP 編碼模塊 │ ├── rtp_sender.c # RTP 打包發(fā)送模塊 │ └── queue.c # 幀隊列 └── include/ └── streamer.h # 公共頭文件6. 實測結(jié)果延遲、CPU 占用和畫面質(zhì)量表現(xiàn)寫代碼是一回事跑起來看到真實數(shù)據(jù)是另一回事。我在 RK3588 開發(fā)板上做了一輪完整的壓力測試從推流延遲、CPU 占用、畫面質(zhì)量三個維度記錄數(shù)據(jù)以下結(jié)果供你參考。測試環(huán)境RK3588 開發(fā)板8GB RAM板載 WiFi 6 模塊連接 5GHz 路由器接收端為一臺 PC 上的 VLC通過 WiFi 連接同一個路由器。攝像頭為 1080p30 USB UVC 攝像頭。6.1 延遲測試用秒表對著屏幕錄制分別觀察實際畫面動作和 VLC 顯示畫面的時間差推流方式平均延遲最大延遲備注GStreamer UDP 硬編碼180ms350ms流暢偶發(fā)小卡頓GStreamer TCP RTSP 硬編碼450ms1200ms畫面完整延遲波動大FFmpeg RTSP 軟編碼800ms2500ms延遲最高CPU 占用高GStreamer UDP 方案在延遲表現(xiàn)上一騎絕塵這也是為什么很多低延遲圖傳方案傾向于走 UDP RTP 的原因。6.2 CPU 占用測試用top和mpstat觀察系統(tǒng)負載場景CPU 平均占用A76 核心負載A55 核心負載空閑僅系統(tǒng)2%低低GStreamer 硬編碼推流12% - 18%中等低FFmpeg x264 軟編碼推流55% - 70%高中硬編碼的優(yōu)勢非常明顯RK3588 的 VPU 把最重的編碼工作接管了A76 核心只需要跑 V4L2 采集、格式轉(zhuǎn)換和 RTP 打包這些輕量任務(wù)。6.3 畫面質(zhì)量主觀評價在 2Mbps 固定碼率下1080p30 的畫面在室內(nèi)靜止場景幾乎無可見噪點文字邊緣清晰。運動場景下比如快速揮手或者走動畫面會有輕微馬賽克但整體可接受。如果改成動態(tài)碼率VBR碼率上限放寬到 4Mbps運動場景的馬賽克會顯著減少代價是 WiFi 吞吐壓力增大。7. 踩坑記錄V4L2 采集和 RKMPP 編碼對接時我遇到過的 5 個大坑這個項目看著代碼量不大但中間踩的坑絕對夠?qū)懸黄獑为毜呐佩e筆記了。我把印象最深的幾個問題列出來希望能幫你少走彎路。7.1 格式轉(zhuǎn)換瓶頸YUYV 轉(zhuǎn) NV12 的 CPU 耗時過高采集端拿到的是 YUYV 格式RKMPP 編碼器輸入一般是 NV12 格式Y(jié)UV420SP中間必須做一次轉(zhuǎn)換。我最初用純 C 寫了一個轉(zhuǎn)換函數(shù)實測 1080p 一幀在 RK3588 上要花 8 到 10ms雖然單看還行但疊加上采集、編碼、發(fā)送之后整個鏈路延遲就上去了而且 CPU 占用率明顯升高。后來改用 RK3588 的 RGA 硬件加速模塊librga做格式轉(zhuǎn)換耗時直接降到 1ms 以下CPU 占用幾乎為零。如果你在 RK3588 上做視頻應(yīng)用記住能用硬件加速的轉(zhuǎn)換和縮放別用 CPU 硬湊。RGA 的調(diào)用方式和 DMA 類似拷貝圖像數(shù)據(jù)的同時指定源格式和目標(biāo)格式即可。注意RGA 的驅(qū)動在不同內(nèi)核版本上 API 略有差異編譯前確認一下你的板子內(nèi)核版本對應(yīng)的 librga 版本不然編譯報錯或者運行時報RGA init failed會讓人頭大。7.2 mpph264enc 硬編碼器在低碼率下出現(xiàn)花屏這是一個讓我排查了兩天的問題碼率設(shè)置到 1Mbps 以下時H.264 硬編碼輸出的畫面會周期性出現(xiàn)橫條紋花屏。最開始以為是 WiFi 丟包但本地錄制也有這個問題。后來查文檔和社區(qū)發(fā)現(xiàn)是 RKMPP 編碼器對低碼率場景下的參考幀管理策略有問題解決辦法是調(diào)整 GOPGroup of Pictures大小把默認的 2 秒一個 I 幀改成 1 秒一個 I 幀gst-launch-1.0 v4l2src device/dev/video0 ! \ video/x-raw,width1280,height720,framerate30/1 ! \ videoconvert ! video/x-raw,formatI420 ! \ mpph264enc bitrate800000 gop30 ! \ h264parse ! rtph264pay config-interval1 pt96 ! \ udpsink host192.168.1.100 port5000gop30表示每 30 幀一個關(guān)鍵幀也就是 1 秒一個 I 幀。I 幀頻率增加會略微降低壓縮率但能顯著改善低碼率下的花屏現(xiàn)象。7.3 udev 權(quán)限問題非 root 用戶打不開 /dev/video0開發(fā)板到手后我用普通用戶運行推流程序一直報open video device failed: Permission denied。查了一圈發(fā)現(xiàn)默認 udev 規(guī)則沒有給 video 設(shè)備添加 user 權(quán)限。解決方法是在/etc/udev/rules.d/下新建規(guī)則文件KERNELvideo*, SUBSYSTEMvideo4linux, MODE0666然后重啟 udev 或重插攝像頭。這個坑幾乎每個做嵌入式視頻開發(fā)的人都會遇到直接加sudo chmod 666 /dev/video0能臨時解決但重啟就失效用 udev 規(guī)則是正解。7.4 select 超時之后攝像頭驅(qū)動掛死的恢復(fù)策略在我的采集程序里如果攝像頭被意外拔出USB 接觸不良select()會一直超時即使重新插上驅(qū)動狀態(tài)也未必能自動恢復(fù)。我最后實現(xiàn)的策略是連續(xù) 10 次 select 超時后主動關(guān)閉 fd 并重新打開/dev/video0重新走一遍格式設(shè)置和緩沖申請流程。這個軟重啟邏輯聽起來很粗暴但實測非常有效在長時間運行的設(shè)備上能避免 99% 的攝像頭失聯(lián)問題。7.5 RKMPP 輸入幀尺寸對齊問題RKMPP 編碼器對輸入圖像的寬高有對齊要求一般要求 16 像素對齊。如果攝像頭輸出的分辨率是 1920x1080對齊沒問題但如果換成 640x480正好也對齊反而是一些分辨率為 1280x720 或者 2592x1944 這樣的尺寸偶爾會觸發(fā)對齊異常。程序在啟動時最好先查一下編碼器支持的對齊要求或者直接把輸入裁剪/縮放到一個安全的對齊分辨率。RGA 硬件縮放這時候就派上用場了縮放的同時還能完成格式轉(zhuǎn)換一舉兩得。8. 進階玩法在 RK3588 上給視頻流加上 AI 目標(biāo)檢測聊完基礎(chǔ)推流最后說一個非常自然的擴展方向——RK3588 自帶 NPU很多人拿到這塊板子不僅是為了做普通攝像頭推流還想在端側(cè)做 AI 分析比如檢測人體、車輛然后在檢測到目標(biāo)時才觸發(fā)推流或者標(biāo)記畫面區(qū)域。RK3588 的 NPU 支持 RKNN 格式的模型常見的 YOLOv8 等檢測模型可以轉(zhuǎn)換成 RKNN 在 NPU 上運行。部署流程大概是在 PC 上訓(xùn)練或下載預(yù)訓(xùn)練模型如 YOLOv8n。用rknn-toolkit2把 PyTorch 或 ONNX 模型轉(zhuǎn)換成 RKNN 模型。板子上調(diào)用 RKNN Runtime C/Python API 對視頻幀做推理。在采集線程和編碼線程之間插入一個AI 檢測節(jié)點檢測結(jié)果可以疊加到畫面或者作為觸發(fā)條件。將 AI 推理嵌入到 GStreamer 管線里可以自定義一個 GStreamer 插件也可以簡單地在應(yīng)用層做取一幀 → 推理 → 有目標(biāo)才編碼推流。后者簡單直接適合快速驗證前者性能更好、延遲更低適合正式產(chǎn)品。這里有一個設(shè)計經(jīng)驗推理頻率不需要和幀率一致。比如視頻是 30fps但檢測可以每 5 幀做一次即 6fps 的檢測幀率對大多數(shù)監(jiān)控場景完全夠用。這樣可以大幅降低 NPU 功耗和發(fā)熱對那些用電池供電的移動設(shè)備尤為重要。實測在 RK3588 上跑 YOLOv8n輸入 640x640NPU 推理單幀大約 20ms 到 30ms按 6fps 的策略NPU 占用率不到 20%CPU 也完全不受影響推流和檢測并行毫無壓力。我在實際使用中發(fā)現(xiàn)把 AI 檢測疊加到推流鏈路之后最值得優(yōu)化的不是推理速度而是檢測結(jié)果的時空平滑。直接對每一幀獨立檢測會導(dǎo)致目標(biāo)框閃爍跳躍觀感很差。最簡單的平滑策略是用卡爾曼濾波或指數(shù)移動平均EMA對目標(biāo)框的坐標(biāo)做低通濾波。這個 trick 能讓目標(biāo)框貼合目標(biāo)運動軌跡效果提升非常明顯而計算成本幾乎可以忽略。另一個體會是端側(cè) AI 檢測的價值不只是識別更是決策。檢測到目標(biāo)之后可以聯(lián)動其他動作比如有陌生人進入時立刻提高碼率、切換到高清流并開始本地錄像平時則用低碼率流維持基本監(jiān)控。這種按需分配資源的設(shè)計讓有限的 WiFi 帶寬和板端算力都花在刀刃上。最后再分享一個小技巧如果把推流程序和 AI 檢測程序做成兩個獨立進程運行時的調(diào)試會輕松很多——檢測模型版本升級不會影響推流穩(wěn)定性推流異常也不至于讓 AI 進程一起崩掉。進程間通信用共享內(nèi)存?zhèn)鲙阅軗p失也很小。這種模塊獨立部署的思路和大系統(tǒng)里的微服務(wù)架構(gòu)是一個意思只不過在嵌入式場景下我們要用更輕量的方式實現(xiàn)而已。 RK3588 WiFi攝像頭推流實戰(zhàn)：V4L2采集與硬編碼
1. 為什么選 RK3588 做 WiFi 無線攝像頭推流方案選型與硬件準(zhǔn)備先聊點實在的。我這個項目最開始其實不是非 RK3588 不可當(dāng)時手里同時有樹莓派 4B 和一塊全志 H6 的開發(fā)板都試過做 USB 攝像頭采集推流。結(jié)果怎么說呢要么是編碼性能拉胯1080p 推流 CPU 直接燒到 80% 以上要么是 WiFi 吞吐不穩(wěn)定畫面時不時卡成幻燈片。后來換了 RK3588整體體驗完全不一樣了。RK3588 這芯片在嵌入式開發(fā)圈里這兩年熱度一直很高8 核 ARM 架構(gòu)4 個 Cortex-A76 大核加 4 個 Cortex-A55 小核算力相當(dāng)充裕而且自帶 NPU雖然這個項目暫時沒用到 AI 推理但后續(xù)如果想在端側(cè)跑個目標(biāo)檢測、人臉識別再做智能推流硬件底子是現(xiàn)成的。更重要的是RK3588 內(nèi)置了 VPU視頻編解碼單元硬編 H.264/H.265 都是常規(guī)操作這樣 CPU 就能從編碼這種重活里解放出來哪怕 4K 分辨率的視頻流推出去系統(tǒng)負載也能保持在一個很健康的水位。再一個原因就是接口資源。RK3588 的 MIPI-CSI 接口支持多路攝像頭輸入USB 3.0 Host 口也夠多這意味著無論是接 MIPI 攝像頭模組還是免驅(qū) UVC 攝像頭都非常靈活。我這套方案用的是一個普通的 USB 攝像頭走的標(biāo)準(zhǔn) V4L2 協(xié)議根本不需要額外寫驅(qū)動插上就能識別對新手來說特別友好。硬件準(zhǔn)備清單如下硬件/軟件型號/版本說明開發(fā)板RK3588 開發(fā)板我用的是某國產(chǎn)廠商的核心板加底板方案8GB 或 16GB 內(nèi)存都行存儲建議 32GB 以上攝像頭USB UVC 免驅(qū)攝像頭支持 1080p選 YUYV/MJPEG 輸出格式的兼容性好系統(tǒng)Ubuntu 22.04RK3588 移植版或者 Debian內(nèi)核 5.10 以上自帶 V4L2 框架WiFiUSB 無線網(wǎng)卡或板載 WiFi 模塊支持 AP/STA 模式我用的板載 WiFi 6 模塊實測吞吐穩(wěn)定軟件GStreamer、FFmpeg、VLC用于驗證核心推流工具下面細說提示RK3588 的很多開發(fā)板出廠帶的是 Android 系統(tǒng)做嵌入式 Linux 開發(fā)之前記得先刷成 Ubuntu 或 Debian 的固件網(wǎng)上針對各廠商板子的移植教程已經(jīng)比較成熟了實在不行用系統(tǒng)自帶的 SDK 自己編一個也行只是耗時比較長。這里想特別強調(diào)一下選 USB UVC 攝像頭而不是 MIPI 攝像頭的原因。MIPI-CSI 攝像頭的畫質(zhì)上限確實更高但驅(qū)動適配是個大坑不同廠商的 sensor 芯片驅(qū)動差異很大很多 RK3588 的板子即使有 DTS 配置也要反復(fù)調(diào)。USB UVC 攝像頭走的是標(biāo)準(zhǔn)協(xié)議Linux 內(nèi)核里已經(jīng)有現(xiàn)成的uvcvideo驅(qū)動插上就能枚舉出/dev/video0對做應(yīng)用層開發(fā)的人來說省了不止一個晚上的折騰時間。2. V4L2 攝像頭采集鏈路從設(shè)備枚舉到原始幀讀取V4L2 的全稱是 Video for Linux 2是 Linux 內(nèi)核里一套標(biāo)準(zhǔn)化的視頻設(shè)備驅(qū)動框架。你可以理解成攝像頭在 Linux 系統(tǒng)里的普通話協(xié)議——不管底層是什么 sensor、什么接口上層應(yīng)用只要按 V4L2 的規(guī)范操作/dev/videoX這個設(shè)備節(jié)點就能拿到圖像數(shù)據(jù)。這種設(shè)計思路和 POSIX 文件操作很像一切都是文件一切都是標(biāo)準(zhǔn)接口。2.1 先用命令行確認攝像頭能被系統(tǒng)正確識別動手寫代碼之前先跑幾個命令確認攝像頭工作正常。插上 USB 攝像頭后在 RK3588 的終端里執(zhí)行l(wèi)susb ls /dev/video* v4l2-ctl --list-devices正常情況下v4l2-ctl --list-devices會輸出類似這樣的內(nèi)容USB Camera (1bcf:2c87): /dev/video0接著查看攝像頭支持的像素格式和分辨率v4l2-ctl -d /dev/video0 --list-formats-ext輸出里如果能看到Y(jié)UYV或者MJPG就說明攝像頭在 UVC 協(xié)議下工作正常。這里有個重要概念YUYV 是無壓縮的裸數(shù)據(jù)格式一幀 1080p 圖像在 YUYV 下大約是1920 * 1080 * 2字節(jié)算下來差不多 4MB如果以 30fps 采集每秒數(shù)據(jù)量是 120MB 以上這個數(shù)據(jù)量直接扔到網(wǎng)絡(luò)上是不現(xiàn)實的。MJPG 是攝像頭內(nèi)部做了 JPEG 壓縮后輸出的格式同樣一幀 1080p 可能只需要 100KB 到 300KB流量壓力小很多但代價是畫質(zhì)有損、解碼需要算力。所以這里要鋪墊一個貫穿整個項目的判斷攝像頭采集端到底輸出什么格式?jīng)Q定了后面推流鏈路的復(fù)雜度。我的建議是如果攝像頭支持 MJPG優(yōu)先用 MJPG 做網(wǎng)絡(luò)傳輸如果只支持 YUYV那就老老實實在板子上做硬編碼壓縮別想著裸流直接推。2.2 V4L2 編程的基本套路打開設(shè)備、設(shè)置格式、申請緩沖區(qū)、啟動采集命令行驗證完下面進入正式的主題——用 C 語言寫一個 V4L2 采集程序。這里先給出完整可運行的代碼然后逐段拆解關(guān)鍵邏輯。#include stdio.h #include stdlib.h #include string.h #include fcntl.h #include unistd.h #include errno.h #include sys/ioctl.h #include sys/mman.h #include linux/videodev2.h #define DEVICE_PATH /dev/video0 #define WIDTH 1920 #define HEIGHT 1080 #define BUFFER_COUNT 4 struct buffer_info { void *start; size_t length; }; static struct buffer_info buffers[BUFFER_COUNT]; static int xioctl(int fd, unsigned long request, void *arg) { int r; do { r ioctl(fd, request, arg); } while (r -1 errno EINTR); return r; } int main(void) { int fd open(DEVICE_PATH, O_RDWR | O_NONBLOCK, 0); if (fd 0) { perror(open video device failed); return -1; } struct v4l2_format fmt; memset(fmt, 0, sizeof(fmt)); fmt.type V4L2_BUF_TYPE_VIDEO_CAPTURE; fmt.fmt.pix.width WIDTH; fmt.fmt.pix.height HEIGHT; fmt.fmt.pix.pixelformat V4L2_PIX_FMT_YUYV; fmt.fmt.pix.field V4L2_FIELD_NONE; if (xioctl(fd, VIDIOC_S_FMT, fmt) 0) { perror(set format failed); close(fd); return -1; } struct v4l2_requestbuffers req; memset(req, 0, sizeof(req)); req.count BUFFER_COUNT; req.type V4L2_BUF_TYPE_VIDEO_CAPTURE; req.memory V4L2_MEMORY_MMAP; if (xioctl(fd, VIDIOC_REQBUFS, req) 0) { perror(request buffers failed); close(fd); return -1; } for (int i 0; i BUFFER_COUNT; i) { struct v4l2_buffer buf; memset(buf, 0, sizeof(buf)); buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; buf.index i; if (xioctl(fd, VIDIOC_QUERYBUF, buf) 0) { perror(query buffer failed); close(fd); return -1; } buffers[i].length buf.length; buffers[i].start mmap(NULL, buf.length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, buf.m.offset); if (buffers[i].start MAP_FAILED) { perror(mmap failed); close(fd); return -1; } } enum v4l2_buf_type type V4L2_BUF_TYPE_VIDEO_CAPTURE; for (int i 0; i BUFFER_COUNT; i) { struct v4l2_buffer buf; memset(buf, 0, sizeof(buf)); buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; buf.index i; if (xioctl(fd, VIDIOC_QBUF, buf) 0) { perror(queue buffer failed); return -1; } } if (xioctl(fd, VIDIOC_STREAMON, type) 0) { perror(stream on failed); close(fd); return -1; } for (int frame_count 0; frame_count 300; frame_count) { fd_set fds; FD_ZERO(fds); FD_SET(fd, fds); struct timeval tv; tv.tv_sec 2; tv.tv_usec 0; int sel select(fd 1, fds, NULL, NULL, tv); if (sel 0) { perror(select failed); break; } if (sel 0) { fprintf(stderr, select timeout, no frame\n); continue; } struct v4l2_buffer buf; memset(buf, 0, sizeof(buf)); buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; if (xioctl(fd, VIDIOC_DQBUF, buf) 0) { perror(dequeue buffer failed); break; } // 到這里buffers[buf.index].start 就是一幀圖像數(shù)據(jù) // 幀大小為 buf.bytesused 字節(jié) printf(frame %d: size%d bytes\n, frame_count, buf.bytesused); // 實際項目中這里會把 buf 里的數(shù)據(jù)交給編碼器/網(wǎng)絡(luò)模塊處理 if (xioctl(fd, VIDIOC_QBUF, buf) 0) { perror(requeue buffer failed); break; } } type V4L2_BUF_TYPE_VIDEO_CAPTURE; xioctl(fd, VIDIOC_STREAMOFF, type); for (int i 0; i BUFFER_COUNT; i) { munmap(buffers[i].start, buffers[i].length); } close(fd); return 0; }2.3 這段采集代碼里幾個值得琢磨的細節(jié)先看打開設(shè)備那一步。我這里用了O_NONBLOCK非阻塞模式然后靠select()來等待幀數(shù)據(jù)準(zhǔn)備好。如果不用非阻塞模式VIDIOC_DQBUF會在沒有幀數(shù)據(jù)時一直卡住主線程就被堵死了。用select()的好處是能設(shè)置超時時間一旦攝像頭異常比如線松了、設(shè)備被占用程序不至于掛死可以及時報錯處理。實際項目里我還會把超時后的重連邏輯加進去比如連續(xù)超時 5 次就自動重新打開設(shè)備這對長時間運行的監(jiān)控設(shè)備特別重要。然后是緩沖區(qū)機制。V4L2 經(jīng)典的REQBUFS - QUERYBUF - mmap - QBUF - DQBUF流程本質(zhì)上是一個生產(chǎn)者消費者模型攝像頭硬件是生產(chǎn)者往 DMA 緩沖區(qū)里寫圖像數(shù)據(jù)應(yīng)用層是消費者從緩沖區(qū)里把數(shù)據(jù)取走。用多個緩沖區(qū)這里設(shè)了 4 個能避免一幀數(shù)據(jù)還沒處理完下一幀就被覆蓋的情況。緩沖區(qū)數(shù)量也不是越多越好多了占內(nèi)存少了容易丟幀4 到 8 個是比較合理的區(qū)間。還有一個常被忽略的坑VIDIOC_S_FMT設(shè)置格式不保證一定成功特別是某些攝像頭不支持你指定的分辨率和像素格式時驅(qū)動會靜默改成自己支持的最接近值。所以設(shè)置完格式之后一定要再調(diào)用VIDIOC_G_FMT讀回來確認一下實際生效的參數(shù)不然你按 1080p 分配緩沖區(qū)攝像頭卻輸出 640x480后面全是內(nèi)存越界問題排查起來非常酸爽。3. 推流方案的技術(shù)選型GStreamer 硬編碼管線 vs FFmpeg 軟編碼采集到原始幀之后畫面數(shù)據(jù)是有了但離WiFi 推流還有一道關(guān)鍵工序編碼成 H.264/H.265 再封裝成適合網(wǎng)絡(luò)傳輸?shù)牧鞲袷絉TSP/RTP/FLV。市面上主流的選擇就是 GStreamer 和 FFmpeg 這兩個框架我這次兩個方案都實測過下面分別說說優(yōu)缺點和適用場景。3.1 GStreamer RK3588 硬件編碼性能和效率的首選RK3588 的 VPU 在 GStreamer 里對應(yīng)的插件是mpph264encMpp 是 Rockchip 媒體處理平臺的簡稱。用 GStreamer 拼一條推流管線核心思路就是v4l2src 采集視頻 - 像素格式轉(zhuǎn)換 - mpph264enc 硬編碼 - rtph264pay 打包 - udpsink 或 rtsp 服務(wù)端一條完整的命令行推流示例推 UDP 到局域網(wǎng)內(nèi)的一臺 PC 上用 VLC 接收gst-launch-1.0 v4l2src device/dev/video0 ! \ video/x-raw,width1920,height1080,framerate30/1 ! \ videoconvert ! \ video/x-raw,formatI420 ! \ mpph264enc bitrate2000000 ! \ h264parse ! \ rtph264pay config-interval1 pt96 ! \ udpsink host192.168.1.100 port5000這里解釋一下每個插件的用途v4l2src從 V4L2 設(shè)備采集視頻幀。注意如果你把攝像頭格式設(shè)成了 MJPG這里還需要插入jpegdec解壓成原始圖像否則后面的編碼器不認。常見的坑是視頻格式?jīng)]有協(xié)商好看到Internal data stream error多半就是格式協(xié)商不通過解決辦法是在 Caps 里明確指定video/x-raw的格式和分辨率。videoconvert做像素格式轉(zhuǎn)換。攝像頭的輸出是 YUYV而 H.264 編碼器輸入通常要求 I420這中間差一步轉(zhuǎn)換。別小看這個插件它在 CPU 上做轉(zhuǎn)換的時候也有開銷如果能直接在采集端拿到 I420 格式會好一點但大部分 UVC 攝像頭原生只給 YUYV 或 MJPEG。mpph264encRK3588 的硬編碼器bitrate參數(shù)直接控制碼率。我實測 2Mbps 下 1080p30 的畫面在室內(nèi)場景基本上畫質(zhì)能接受運動劇烈一點的場景建議提到 4Mbps。h264parsertph264pay把 H.264 裸流封裝成 RTP 包這樣才能走 UDP 推給播放器。udpsink把 RTP 包發(fā)到指定主機的指定端口。這種 GStreamer 管線的好處是完全不用寫代碼一條命令就能跑起來而且硬編碼對 CPU 占用極低。我在 RK3588 上實測1080p30 硬編碼推流時四個 A76 大核的 CPU 占用率加起來不超過 15%大部分時候維持在 5% 以內(nèi)真的是殺雞用牛刀級別的輕松。3.2 FFmpeg x264 軟編碼兼容性優(yōu)先的備選方案如果你不想在板子上裝一堆 GStreamer 插件或者你的攝像頭輸出的格式比較奇葩FFmpeg 是更大眾的選擇。在 RK3588 上FFmpeg 也可以調(diào)用 Rockchip 的硬件編碼器但需要專門編譯帶--enable-rkmpp選項的版本很多發(fā)行版自帶的 FFmpeg 默認不啟用這個能力。不帶硬件加速的話直接用軟件 x264 編碼也能跑命令如下ffmpeg -f v4l2 -input_format yuyv422 -video_size 1920x1080 -framerate 30 \ -i /dev/video0 -c:v libx264 -preset veryfast -b:v 2M \ -f rtsp rtsp://192.168.1.100:8554/live這里-preset veryfast是為了降低編碼延遲x264 的編碼速度直接決定實時性表現(xiàn)。我的實測結(jié)果是在 RK3588 上用veryfast檔位編碼 1080p30CPU 占用大約 30% 到 40%比硬編碼高不少但還在可接受范圍。如果你用的是性能更弱的板子這個方案可能就撐不住了。FFmpeg 方案最大的優(yōu)勢是協(xié)議支持全面。不管你要推 RTSP、RTMP 還是直接錄成 MP4 文件FFmpeg 一個工具全搞定而且參數(shù)調(diào)起來非常直觀適合快速驗證。但它在低延遲場景下表現(xiàn)不如 GStreamer 的純 RTP 管線靈活因為 FFmpeg 的 RTSP 服務(wù)模式是轉(zhuǎn)發(fā)模式內(nèi)部會有緩沖延遲通常會比 GStreamer 的 UDP 直推高一截。3.3 我最終的選擇雙路并行策略這個項目最終我采用了GStreamer 做主干推流FFmpeg 做輔助錄制的組合方案。主干推流用 GStreamer mpph264enc 保證低延遲和低 CPU 占用同時在板子上定時用 FFmpeg 拉取本地的 RTSP 流做切片錄制這樣既滿足了實時監(jiān)看的延遲要求又保證了關(guān)鍵時刻有錄像留存。這種一魚兩吃的做法在真實項目里非常常見因為運維監(jiān)控場景既要看得見也要留得住。4. WiFi 推流的網(wǎng)絡(luò)痛點為什么局域網(wǎng)延遲時好時壞以及如何優(yōu)化攝像頭數(shù)據(jù)采集和編碼都搞定之后最大的不可控因素就剩 WiFi 了。我最初在局域網(wǎng)里用普通 2.4GHz WiFi 測試的時候延遲經(jīng)常在 200ms 到 2 秒之間反復(fù)橫跳畫面時不時卡頓一下一度以為是自己代碼寫的太爛后來排查發(fā)現(xiàn)根因在網(wǎng)絡(luò)這一層。4.1 WiFi 頻段選擇對推流質(zhì)量的影響2.4GHz 頻段的穿透能力確實好但干擾源也多——藍牙、微波爐、鄰居的路由器全擠在 2.4GHz 這不到 100MHz 的頻譜里環(huán)境稍微復(fù)雜一點WiFi 吞吐量就會劇烈抖動。而視頻流最怕的就是吞吐量抖動因為直播類應(yīng)用對帶寬是持續(xù)占滿型的需求不像網(wǎng)頁瀏覽那樣有突發(fā)性容忍度。我實測下來的數(shù)據(jù)WiFi 環(huán)境1080p30 推流延遲卡頓情況2.4GHz普通路由器多設(shè)備共存300ms - 2s頻繁輕微卡頓偶爾爆卡5GHz路由器較近3 米內(nèi)100ms - 300ms基本流暢5GHz穿一堵墻300ms - 800ms輕微卡頓建議是做 WiFi 推流時板子和路由器之間盡量用 5GHz 頻段并且縮短物理距離。如果只能走 2.4GHz那就降低推流碼率和分辨率比如 720p 加 1Mbps 碼率老老實實換體驗。另外注意一個容易忽略的點RK3588 開發(fā)板上的無線網(wǎng)卡很多是同時支持 AP 和 STA 模式的也就是板和手機可以組成一個獨立的 WiFi 熱點網(wǎng)絡(luò)。在戶外沒有路由器的時候可以讓板子開一個 AP手機連上板的 WiFi 熱點就能直接看視頻流。這種無基礎(chǔ)設(shè)施的玩法在無人機圖傳、車載監(jiān)控等場景特別實用而且因為跳過了路由器轉(zhuǎn)發(fā)數(shù)據(jù)路徑更短延遲反而更低。4.2 TCP 還是 UDP這是個問題推流傳輸層協(xié)議的選擇同樣關(guān)鍵。GStreamer 里如果推 RTSP底層默認走 TCP可靠傳輸?shù)貍鳈C制會帶來額外延遲如果要低延遲可以用 UDP 直推不可靠傳輸丟包就直接丟幀但不卡頓。TCP 和 UDP 在視頻推流場景下的表現(xiàn)差異非常大。TCP 雖然不會丟包但一旦網(wǎng)絡(luò)出現(xiàn)瞬時擁塞TCP 的擁塞控制算法會主動降低發(fā)送速率導(dǎo)致視頻延遲節(jié)節(jié)攀升畫面雖然不花屏但越來越卡頓其實是延遲越來越大。UDP 則不會做這種退避丟掉的包直接丟棄播放端畫面雖然可能偶發(fā)花屏、馬賽克但時間線上是實時的不會有延遲持續(xù)積累的問題。我的經(jīng)驗是內(nèi)網(wǎng)可控環(huán)境用 UDP廣域網(wǎng)環(huán)境用 TCP。內(nèi)網(wǎng)丟包率極低UDP 完全夠用公網(wǎng)上丟包不可避免TCP 重傳至少保證畫面完整延遲高一點也能接受。4.3 碼率匹配策略別讓編碼輸出和網(wǎng)絡(luò)帶寬打架很多人做推流時只關(guān)注編碼參數(shù)忽略了網(wǎng)絡(luò)帶寬這個木桶短板。RK3588 的 mpph264enc 設(shè)置的固定碼率在 2Mbps但如果 WiFi 的有效吞吐只有 1.5Mbps那畫面必然卡頓。這里建議在應(yīng)用層做一層自適應(yīng)碼率控制定期檢測網(wǎng)絡(luò)的往返時延RTT和發(fā)送隊列的堆積情況如果 RTT 持續(xù)偏高就把編碼器的bitrate參數(shù)動態(tài)調(diào)低例如從 2Mbps 降到 1.2Mbps讓畫面更流暢。在 GStreamer 里可以通過mpph264enc的bitrateproperty 動態(tài)設(shè)置gst-launch-1.0 v4l2src device/dev/video0 ! \ video/x-raw,width1280,height720,framerate30/1 ! \ videoconvert ! video/x-raw,formatI420 ! \ mpph264enc bitrate1200000 ! \ h264parse ! rtph264pay config-interval1 pt96 ! \ udpsink host192.168.1.100 port50004.4 網(wǎng)絡(luò)緩沖區(qū)的隱藏雷區(qū)還有一個坑我從沒見文檔里寫明過GStreamer 的udpsink插件默認有一個發(fā)送緩沖區(qū)如果網(wǎng)絡(luò)擁堵導(dǎo)致數(shù)據(jù)堆積緩沖區(qū)會被填滿然后udpsink會開始丟包。這種行為本身沒問題但會導(dǎo)致畫面突然出現(xiàn)大范圍花屏。解決辦法是通過udpsink的max-lateness和qos參數(shù)控制發(fā)送節(jié)奏讓過期的幀直接丟棄而不是堆積等待。加入 QoS服務(wù)質(zhì)量機制后播放端收到的幀是最新鮮的延遲會明顯下降代價是網(wǎng)絡(luò)差時幀率會掉。命令行加參數(shù)的方式udpsink host192.168.1.100 port5000 qostrue max-lateness10000000這里的max-lateness單位是納秒10000000納秒就是 10ms超過這個時間的幀直接丟。經(jīng)過這樣調(diào)整后WiFi 環(huán)境下的畫面流暢度和延遲一致性提升很明顯。5. 完整代碼實現(xiàn)推流主程序的架構(gòu)設(shè)計和關(guān)鍵模塊拆解前面講了不少概念和命令行方案下面寫一個稍微體面的 C 程序把這些要素整合起來。這個程序不依賴 GStreamer 的命令行而是直接用 V4L2 采集 RKMPP 硬編碼 RTP 打包可以理解成一個精簡版的推流器。5.1 程序整體架構(gòu)整個推流程序分四個線程采集線程V4L2 循環(huán)取幀放進幀隊列。編碼線程從幀隊列取出原始幀交給 RKMPP 硬編碼為 H.264放進編碼幀隊列。發(fā)送線程從編碼幀隊列取 H.264 數(shù)據(jù)封裝成 RTP 包通過 UDP socket 發(fā)出。控制線程響應(yīng)命令行輸入如修改碼率、打印狀態(tài)實現(xiàn)簡單的運行管理。用多線程而非單線程循環(huán)是因為采集、編碼和網(wǎng)絡(luò)發(fā)送三個環(huán)節(jié)的速度不恒等如果串行執(zhí)行任何一環(huán)變慢都會拖垮整條鏈路。用隊列解耦之后即使網(wǎng)絡(luò)短暫擁塞編碼線程也可以繼續(xù)工作把數(shù)據(jù)積壓在編碼幀隊列里一旦網(wǎng)絡(luò)恢復(fù)發(fā)送線程能快速追上進度。5.2 關(guān)鍵結(jié)構(gòu)體和隊列封裝#include pthread.h #include semaphore.h #include stdint.h #include rga/RgaApi.h #include rockchip/rk_mpi.h #define MAX_QUEUE_SIZE 8 typedef struct { void *data; size_t size; uint64_t pts; } frame_t; typedef struct { frame_t frames[MAX_QUEUE_SIZE]; int head; int tail; int count; pthread_mutex_t lock; sem_t empty_slots; sem_t full_slots; } frame_queue_t; void queue_init(frame_queue_t *q) { q-head 0; q-tail 0; q-count 0; pthread_mutex_init(q-lock, NULL); sem_init(q-empty_slots, 0, MAX_QUEUE_SIZE); sem_init(q-full_slots, 0, 0); } void queue_push(frame_queue_t *q, frame_t *frame) { sem_wait(q-empty_slots); pthread_mutex_lock(q-lock); q-frames[q-tail] *frame; q-tail (q-tail 1) % MAX_QUEUE_SIZE; q-count; pthread_mutex_unlock(q-lock); sem_post(q-full_slots); } int queue_pop(frame_queue_t *q, frame_t *frame) { sem_wait(q-full_slots); pthread_mutex_lock(q-lock); if (q-count 0) { pthread_mutex_unlock(q-lock); return -1; } *frame q-frames[q-head]; q-head (q-head 1) % MAX_QUEUE_SIZE; q-count--; pthread_mutex_unlock(q-lock); sem_post(q-empty_slots); return 0; }用信號量 互斥鎖組合的方式實現(xiàn)了一個經(jīng)典的有界阻塞隊列。這里沒有用無鎖隊列因為賽道上這幾個線程的數(shù)據(jù)量并不算極端加鎖完全可以接受。如果將來要做 4K 60fps 那種高吞吐場景再考慮無鎖隊列或者環(huán)形緩沖區(qū)也不遲。5.3 采集線程的實現(xiàn)采集線程就是把之前那段 V4L2 代碼放到線程函數(shù)里然后每取到一幀塞進raw_frame_queue。void *capture_thread(void *arg) { // 參數(shù)設(shè)備路徑幀隊列指針 char *dev_path ((char **)arg)[0]; frame_queue_t *q (frame_queue_t *)(((void **)arg)[1]); int fd open(dev_path, O_RDWR | O_NONBLOCK, 0); if (fd 0) { perror(open device failed); return NULL; } // 設(shè)置 1080p YUYV 格式 struct v4l2_format fmt; memset(fmt, 0, sizeof(fmt)); fmt.type V4L2_BUF_TYPE_VIDEO_CAPTURE; fmt.fmt.pix.width 1920; fmt.fmt.pix.height 1080; fmt.fmt.pix.pixelformat V4L2_PIX_FMT_YUYV; fmt.fmt.pix.field V4L2_FIELD_NONE; xioctl(fd, VIDIOC_S_FMT, fmt); // 讀回實際格式并檢查 struct v4l2_format actual; memset(actual, 0, sizeof(actual)); actual.type V4L2_BUF_TYPE_VIDEO_CAPTURE; xioctl(fd, VIDIOC_G_FMT, actual); if (actual.fmt.pix.width ! 1920 || actual.fmt.pix.height ! 1080) { fprintf(stderr, Warning: actual format is %dx%d\n, actual.fmt.pix.width, actual.fmt.pix.height); } // 申請緩沖區(qū)、mmap、QBUF 等同前文示例代碼 // 采集循環(huán) struct v4l2_buffer buf; for (;;) { fd_set fds; FD_ZERO(fds); FD_SET(fd, fds); struct timeval tv {2, 0}; select(fd 1, fds, NULL, NULL, tv); memset(buf, 0, sizeof(buf)); buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; if (xioctl(fd, VIDIOC_DQBUF, buf) 0) { continue; } frame_t frame; frame.data malloc(buf.bytesused); memcpy(frame.data, buffers[buf.index].start, buf.bytesused); frame.size buf.bytesused; frame.pts (uint64_t)((double)clock() / CLOCKS_PER_SEC * 1000); queue_push(q, frame); xioctl(fd, VIDIOC_QBUF, buf); } }這里注意我從 mmap 緩沖區(qū)里memcpy了一份數(shù)據(jù)到堆內(nèi)存然后才入隊。為什么不直接把 mmap 緩沖區(qū)地址傳下去因為緩沖區(qū)在 DQBUF 之后再次 QBUF 時硬件可能立刻往里寫下一幀如果編碼線程還在讀這塊內(nèi)存就會產(chǎn)生數(shù)據(jù)競爭。要么加鎖保護要么拷貝一份我選擇了性價比更高的拷貝方式——內(nèi)存占用多一點但邏輯簡單安全。5.4 編碼線程調(diào)用 RKMPP 硬編碼RKMPPRockchip Media Process Platform是 Rockchip 官方提供的多媒體編程接口。相比直接用 V4L2 的VIDIOC_ENCODER_CMD或者 GStreamer 插件RKMPP 的 API 更貼近底層適合做精細控制。編碼線程的核心代碼void *encode_thread(void *arg) { frame_queue_t *input_q (frame_queue_t *)(((void **)arg)[0]); frame_queue_t *output_q (frame_queue_t *)(((void **)arg)[1]); MppCtx ctx; MppApi *mpi; mpp_create(ctx, mpi); mpp_init(ctx, MPF_CTX_ENC, MPP_VIDEO_CodingAVC); MppEncPrepCfg prep_cfg; memset(prep_cfg, 0, sizeof(prep_cfg)); prep_cfg.width 1920; prep_cfg.height 1080; prep_cfg.format MPP_FMT_YUV420SP; prep_cfg.frame_rate 30; mpi-control(ctx, MPP_ENC_SET_PREP_CFG, prep_cfg); MppEncCodecCfg codec_cfg; memset(codec_cfg, 0, sizeof(codec_cfg)); codec_cfg.codec_type MPP_VIDEO_CodingAVC; codec_cfg.h264.profile 100; codec_cfg.h264.level 40; codec_cfg.h264.cabac_en 1; codec_cfg.h264.cabac_idc 0; codec_cfg.h264.trans_8x8 1; mpi-control(ctx, MPP_ENC_SET_CODEC_CFG, codec_cfg); MppEncRcCfg rc_cfg; memset(rc_cfg, 0, sizeof(rc_cfg)); rc_cfg.rc_mode MPP_RC_CBR; rc_cfg.bps 2000000; rc_cfg.bps_max 2500000; rc_cfg.bps_min 1500000; mpi-control(ctx, MPP_ENC_SET_RC_CFG, rc_cfg); // 幀數(shù)據(jù)搬運到 MPP 緩沖區(qū)并編碼 frame_t raw_frame; while (!stop_flag) { if (queue_pop(input_q, raw_frame) 0) continue; // 將 YUYV 轉(zhuǎn)為 NV12RKMPP 輸入格式 // 這里也可以用 RGA 硬件加速下文會提到 uint8_t *nv12_data convert_yuyv_to_nv12( (uint8_t *)raw_frame.data, 1920, 1080); // 申請 MPP 編碼使用的輸入包 MppPacket packet NULL; mpp_packet_init(packet, nv12_data, 1920 * 1080 * 3 / 2); mpi-encode_put_packet(ctx, packet); MppPacket out_packet NULL; mpi-encode_get_packet(ctx, out_packet); if (out_packet) { frame_t enc_frame; enc_frame.data malloc(mpp_packet_get_size(out_packet)); memcpy(enc_frame.data, mpp_packet_get_data(out_packet), mpp_packet_get_size(out_packet)); enc_frame.size mpp_packet_get_size(out_packet); enc_frame.pts raw_frame.pts; queue_push(output_q, enc_frame); mpp_packet_deinit(out_packet); } free(nv12_data); free(raw_frame.data); mpp_packet_deinit(packet); } mpp_destroy(ctx); return NULL; }5.5 發(fā)送線程RTP 封包和 UDP 發(fā)送RTP 封包這部分H.264 的 NAL 單元如果大于 MTU通常 1500 字節(jié)就需要做分片F(xiàn)U-A否則播放端無法正確重組。這里實現(xiàn)一個簡化的分包邏輯void send_h264_rtp(int sockfd, struct sockaddr_in *dst, uint8_t *nal_data, size_t nal_size, uint32_t *timestamp) { // 跳過 NAL 起始碼 00 00 00 01 或 00 00 01 uint8_t *nal_start nal_data; while (nal_start nal_data nal_size - 4) { if (*(uint32_t *)nal_start 0x00000001 || *(uint32_t *)nal_start 0x00000100) { break; } nal_start; } size_t header_size (nal_start[2] 1) ? 3 : 4; uint8_t *payload nal_start header_size; size_t payload_size nal_size - (payload - nal_data); uint8_t nal_header payload[0]; uint8_t nal_type nal_header 0x1f; if (payload_size MAX_RTP_PAYLOAD) { // 單包封裝 uint8_t rtp_buf[1500]; rtp_buf[0] 0x80; rtp_buf[1] 96; // payload type PT96 rtp_buf[2] (uint8_t)((*timestamp) 8); rtp_buf[3] (uint8_t)(*timestamp); rtp_buf[4] 0x00; rtp_buf[5] 0x00; rtp_buf[6] 0x00; rtp_buf[7] 0x01; // SSRC memcpy(rtp_buf 12, payload, payload_size); sendto(sockfd, rtp_buf, 12 payload_size, 0, (struct sockaddr *)dst, sizeof(*dst)); } else { // FU-A 分片封裝 uint8_t fu_indicator (nal_header 0xe0) | 28; uint8_t fu_header; uint8_t rtp_buf[1500]; size_t offset 0; int first 1; while (offset payload_size) { size_t chunk_size payload_size - offset; if (chunk_size MAX_RTP_PAYLOAD - 2) chunk_size MAX_RTP_PAYLOAD - 2; rtp_buf[0] 0x80; rtp_buf[1] 96; rtp_buf[2] (uint8_t)((*timestamp) 8); rtp_buf[3] (uint8_t)(*timestamp); // ... 填充 RTP header fu_header (nal_type 0x1f); if (first) fu_header | 0x80; if (offset chunk_size payload_size) fu_header | 0x40; rtp_buf[12] fu_indicator; rtp_buf[13] fu_header; memcpy(rtp_buf 14, payload offset, chunk_size); sendto(sockfd, rtp_buf, 14 chunk_size, 0, (struct sockaddr *)dst, sizeof(*dst)); offset chunk_size; first 0; } } }5.6 完整示例代碼倉庫結(jié)構(gòu)這個程序如果完整寫完代碼量在 500 行左右。一個合理的工程目錄結(jié)構(gòu)可以是rtsp_streamer/ ├── Makefile ├── src/ │ ├── main.c # 主函數(shù)、線程創(chuàng)建 │ ├── v4l2_capture.c # 采集模塊 │ ├── encoder_mpp.c # RKMPP 編碼模塊 │ ├── rtp_sender.c # RTP 打包發(fā)送模塊 │ └── queue.c # 幀隊列 └── include/ └── streamer.h # 公共頭文件6. 實測結(jié)果延遲、CPU 占用和畫面質(zhì)量表現(xiàn)寫代碼是一回事跑起來看到真實數(shù)據(jù)是另一回事。我在 RK3588 開發(fā)板上做了一輪完整的壓力測試從推流延遲、CPU 占用、畫面質(zhì)量三個維度記錄數(shù)據(jù)以下結(jié)果供你參考。測試環(huán)境RK3588 開發(fā)板8GB RAM板載 WiFi 6 模塊連接 5GHz 路由器接收端為一臺 PC 上的 VLC通過 WiFi 連接同一個路由器。攝像頭為 1080p30 USB UVC 攝像頭。6.1 延遲測試用秒表對著屏幕錄制分別觀察實際畫面動作和 VLC 顯示畫面的時間差推流方式平均延遲最大延遲備注GStreamer UDP 硬編碼180ms350ms流暢偶發(fā)小卡頓GStreamer TCP RTSP 硬編碼450ms1200ms畫面完整延遲波動大FFmpeg RTSP 軟編碼800ms2500ms延遲最高CPU 占用高GStreamer UDP 方案在延遲表現(xiàn)上一騎絕塵這也是為什么很多低延遲圖傳方案傾向于走 UDP RTP 的原因。6.2 CPU 占用測試用top和mpstat觀察系統(tǒng)負載場景CPU 平均占用A76 核心負載A55 核心負載空閑僅系統(tǒng)2%低低GStreamer 硬編碼推流12% - 18%中等低FFmpeg x264 軟編碼推流55% - 70%高中硬編碼的優(yōu)勢非常明顯RK3588 的 VPU 把最重的編碼工作接管了A76 核心只需要跑 V4L2 采集、格式轉(zhuǎn)換和 RTP 打包這些輕量任務(wù)。6.3 畫面質(zhì)量主觀評價在 2Mbps 固定碼率下1080p30 的畫面在室內(nèi)靜止場景幾乎無可見噪點文字邊緣清晰。運動場景下比如快速揮手或者走動畫面會有輕微馬賽克但整體可接受。如果改成動態(tài)碼率VBR碼率上限放寬到 4Mbps運動場景的馬賽克會顯著減少代價是 WiFi 吞吐壓力增大。7. 踩坑記錄V4L2 采集和 RKMPP 編碼對接時我遇到過的 5 個大坑這個項目看著代碼量不大但中間踩的坑絕對夠?qū)懸黄獑为毜呐佩e筆記了。我把印象最深的幾個問題列出來希望能幫你少走彎路。7.1 格式轉(zhuǎn)換瓶頸YUYV 轉(zhuǎn) NV12 的 CPU 耗時過高采集端拿到的是 YUYV 格式RKMPP 編碼器輸入一般是 NV12 格式Y(jié)UV420SP中間必須做一次轉(zhuǎn)換。我最初用純 C 寫了一個轉(zhuǎn)換函數(shù)實測 1080p 一幀在 RK3588 上要花 8 到 10ms雖然單看還行但疊加上采集、編碼、發(fā)送之后整個鏈路延遲就上去了而且 CPU 占用率明顯升高。后來改用 RK3588 的 RGA 硬件加速模塊librga做格式轉(zhuǎn)換耗時直接降到 1ms 以下CPU 占用幾乎為零。如果你在 RK3588 上做視頻應(yīng)用記住能用硬件加速的轉(zhuǎn)換和縮放別用 CPU 硬湊。RGA 的調(diào)用方式和 DMA 類似拷貝圖像數(shù)據(jù)的同時指定源格式和目標(biāo)格式即可。注意RGA 的驅(qū)動在不同內(nèi)核版本上 API 略有差異編譯前確認一下你的板子內(nèi)核版本對應(yīng)的 librga 版本不然編譯報錯或者運行時報RGA init failed會讓人頭大。7.2 mpph264enc 硬編碼器在低碼率下出現(xiàn)花屏這是一個讓我排查了兩天的問題碼率設(shè)置到 1Mbps 以下時H.264 硬編碼輸出的畫面會周期性出現(xiàn)橫條紋花屏。最開始以為是 WiFi 丟包但本地錄制也有這個問題。后來查文檔和社區(qū)發(fā)現(xiàn)是 RKMPP 編碼器對低碼率場景下的參考幀管理策略有問題解決辦法是調(diào)整 GOPGroup of Pictures大小把默認的 2 秒一個 I 幀改成 1 秒一個 I 幀gst-launch-1.0 v4l2src device/dev/video0 ! \ video/x-raw,width1280,height720,framerate30/1 ! \ videoconvert ! video/x-raw,formatI420 ! \ mpph264enc bitrate800000 gop30 ! \ h264parse ! rtph264pay config-interval1 pt96 ! \ udpsink host192.168.1.100 port5000gop30表示每 30 幀一個關(guān)鍵幀也就是 1 秒一個 I 幀。I 幀頻率增加會略微降低壓縮率但能顯著改善低碼率下的花屏現(xiàn)象。7.3 udev 權(quán)限問題非 root 用戶打不開 /dev/video0開發(fā)板到手后我用普通用戶運行推流程序一直報open video device failed: Permission denied。查了一圈發(fā)現(xiàn)默認 udev 規(guī)則沒有給 video 設(shè)備添加 user 權(quán)限。解決方法是在/etc/udev/rules.d/下新建規(guī)則文件KERNELvideo*, SUBSYSTEMvideo4linux, MODE0666然后重啟 udev 或重插攝像頭。這個坑幾乎每個做嵌入式視頻開發(fā)的人都會遇到直接加sudo chmod 666 /dev/video0能臨時解決但重啟就失效用 udev 規(guī)則是正解。7.4 select 超時之后攝像頭驅(qū)動掛死的恢復(fù)策略在我的采集程序里如果攝像頭被意外拔出USB 接觸不良select()會一直超時即使重新插上驅(qū)動狀態(tài)也未必能自動恢復(fù)。我最后實現(xiàn)的策略是連續(xù) 10 次 select 超時后主動關(guān)閉 fd 并重新打開/dev/video0重新走一遍格式設(shè)置和緩沖申請流程。這個軟重啟邏輯聽起來很粗暴但實測非常有效在長時間運行的設(shè)備上能避免 99% 的攝像頭失聯(lián)問題。7.5 RKMPP 輸入幀尺寸對齊問題RKMPP 編碼器對輸入圖像的寬高有對齊要求一般要求 16 像素對齊。如果攝像頭輸出的分辨率是 1920x1080對齊沒問題但如果換成 640x480正好也對齊反而是一些分辨率為 1280x720 或者 2592x1944 這樣的尺寸偶爾會觸發(fā)對齊異常。程序在啟動時最好先查一下編碼器支持的對齊要求或者直接把輸入裁剪/縮放到一個安全的對齊分辨率。RGA 硬件縮放這時候就派上用場了縮放的同時還能完成格式轉(zhuǎn)換一舉兩得。8. 進階玩法在 RK3588 上給視頻流加上 AI 目標(biāo)檢測聊完基礎(chǔ)推流最后說一個非常自然的擴展方向——RK3588 自帶 NPU很多人拿到這塊板子不僅是為了做普通攝像頭推流還想在端側(cè)做 AI 分析比如檢測人體、車輛然后在檢測到目標(biāo)時才觸發(fā)推流或者標(biāo)記畫面區(qū)域。RK3588 的 NPU 支持 RKNN 格式的模型常見的 YOLOv8 等檢測模型可以轉(zhuǎn)換成 RKNN 在 NPU 上運行。部署流程大概是在 PC 上訓(xùn)練或下載預(yù)訓(xùn)練模型如 YOLOv8n。用rknn-toolkit2把 PyTorch 或 ONNX 模型轉(zhuǎn)換成 RKNN 模型。板子上調(diào)用 RKNN Runtime C/Python API 對視頻幀做推理。在采集線程和編碼線程之間插入一個AI 檢測節(jié)點檢測結(jié)果可以疊加到畫面或者作為觸發(fā)條件。將 AI 推理嵌入到 GStreamer 管線里可以自定義一個 GStreamer 插件也可以簡單地在應(yīng)用層做取一幀 → 推理 → 有目標(biāo)才編碼推流。后者簡單直接適合快速驗證前者性能更好、延遲更低適合正式產(chǎn)品。這里有一個設(shè)計經(jīng)驗推理頻率不需要和幀率一致。比如視頻是 30fps但檢測可以每 5 幀做一次即 6fps 的檢測幀率對大多數(shù)監(jiān)控場景完全夠用。這樣可以大幅降低 NPU 功耗和發(fā)熱對那些用電池供電的移動設(shè)備尤為重要。實測在 RK3588 上跑 YOLOv8n輸入 640x640NPU 推理單幀大約 20ms 到 30ms按 6fps 的策略NPU 占用率不到 20%CPU 也完全不受影響推流和檢測并行毫無壓力。我在實際使用中發(fā)現(xiàn)把 AI 檢測疊加到推流鏈路之后最值得優(yōu)化的不是推理速度而是檢測結(jié)果的時空平滑。直接對每一幀獨立檢測會導(dǎo)致目標(biāo)框閃爍跳躍觀感很差。最簡單的平滑策略是用卡爾曼濾波或指數(shù)移動平均EMA對目標(biāo)框的坐標(biāo)做低通濾波。這個 trick 能讓目標(biāo)框貼合目標(biāo)運動軌跡效果提升非常明顯而計算成本幾乎可以忽略。另一個體會是端側(cè) AI 檢測的價值不只是識別更是決策。檢測到目標(biāo)之后可以聯(lián)動其他動作比如有陌生人進入時立刻提高碼率、切換到高清流并開始本地錄像平時則用低碼率流維持基本監(jiān)控。這種按需分配資源的設(shè)計讓有限的 WiFi 帶寬和板端算力都花在刀刃上。最后再分享一個小技巧如果把推流程序和 AI 檢測程序做成兩個獨立進程運行時的調(diào)試會輕松很多——檢測模型版本升級不會影響推流穩(wěn)定性推流異常也不至于讓 AI 進程一起崩掉。進程間通信用共享內(nèi)存?zhèn)鲙阅軗p失也很小。這種模塊獨立部署的思路和大系統(tǒng)里的微服務(wù)架構(gòu)是一個意思只不過在嵌入式場景下我們要用更輕量的方式實現(xiàn)而已。