簡介面向Linux ARM平臺(tái)C開發(fā)者的海康威視SDK攝像頭調(diào)用資源包適合在ARM嵌入式設(shè)備上快速落地視頻監(jiān)控、設(shè)備發(fā)現(xiàn)與碼流獲取等工程場景。壓縮包共36個(gè)文件大小約9.34MB以so動(dòng)態(tài)庫和h頭文件為主同時(shí)包含cpp示例源碼、CMakeLists構(gòu)建腳本及ini/xml等配置信息覆蓋SDK運(yùn)行庫、二次開發(fā)接口與工程編譯配置。資源內(nèi)含HCNetSDK、PlayCtrl等核心庫及相關(guān)聲明文件可直接集成到ARM項(xiàng)目中免去在官網(wǎng)匹配Linux ARM版SDK版本的繁瑣過程。已有1374人學(xué)習(xí)下載資源熱度和針對性對于熟悉Linux與C但剛接觸?？礢DK的開發(fā)者很有參考價(jià)值。借助主程序示例可以理清設(shè)備登錄、視頻預(yù)覽、異常斷開等關(guān)鍵環(huán)節(jié)的實(shí)現(xiàn)方法也能參考動(dòng)態(tài)庫與頭文件的對應(yīng)關(guān)系排查鏈接報(bào)錯(cuò)從而縮短在ARM板上完成攝像頭調(diào)用的開發(fā)周期。1. Linux ARM 平臺(tái)跑海康威視 SDK從拿到包到出圖的實(shí)操路線之前在 ARM 工控板上接入多路攝像頭第一批任務(wù)就是調(diào)通?？低?SDK。起初以為把官方 so 拷到板子上、鏈接完就能出圖結(jié)果光編譯就折騰了兩天頭文件路徑、符號(hào)裁剪、交叉編譯鏈版本、輸出庫里那堆總線錯(cuò)誤全在入門階段等著你。這份資源把我踩過的坑和最終走通的完整工程打包在一起包含可直接編譯的 C 工程模板、交叉編譯腳本、網(wǎng)絡(luò)與取流參數(shù)配置表以及調(diào)試排查清單。適合剛從 x86 轉(zhuǎn)向 ARM 嵌入式、手頭有?？翟O(shè)備卻不清楚 SDK 該怎么在 ARM 上用 C 調(diào)通的開發(fā)者也適合要評估第三方方案、對比多平臺(tái)移植成本的從業(yè)者參考。2. SDK 包結(jié)構(gòu)與選型庫層次、設(shè)備型號(hào)與編譯前檢查2.1 解壓目錄里那堆庫到底誰是誰拿到?？低暪俜?Linux 版 SDK 后典型解壓結(jié)構(gòu)如下. ├── Demo │ └── HCNetSDR │ ├── build.sh │ └── ... ├── Doc │ ├── ?？低暥伍_發(fā)手冊.pdf │ └── ... ├── Include │ ├── HCNetSDK.h │ ├── Linux_arm │ └── ... └── lib ├── libhcnetsdk.so ├── libHCCore.so ├── libcrypto.so └── libsqlite3.so不同版本目錄名可能有差異有的廠商把lib拆成lib/arm、lib/aarch64。判斷目標(biāo)架構(gòu)最穩(wěn)的方式是執(zhí)行file libhcnetsdk.so看輸出里是ARM還是AArch64。注意有些型號(hào)的 SDK 只提供 32 位 ARM 版本這時(shí)需要在板子上裝好 32 位運(yùn)行庫或者開啟多架構(gòu)支持否則后續(xù)dlopen一跑就報(bào)Exec format error。2.2 選型理由設(shè)備型號(hào)與庫版本匹配最容易被忽略的是設(shè)備型號(hào)和 SDK 版本不匹配。海康的 IPC/NVR 老化固件對新版 SDK 的兼容偶爾會(huì)出問題常見的做法是先查設(shè)備 Web 管理頁里的固件版本號(hào)再在 SDK 壓縮包內(nèi)部README里查支持列表。匹配目標(biāo)是設(shè)備固件能支持 SDK 里要求的最低協(xié)議版本即可不必一味追新。正式打包時(shí)我把每個(gè)設(shè)備固件版本對應(yīng)能用的libhcnetsdk.so列成了一張表部署前先對照能省大量排障時(shí)間。2.3 編譯前檢查的四個(gè)必選項(xiàng)拿到包之后我一般按下面順序做靜態(tài)檢查和預(yù)編譯檢查項(xiàng)命令/做法通過標(biāo)準(zhǔn)架構(gòu)確認(rèn)file lib/libhcnetsdk.so輸出架構(gòu)與目標(biāo)板一致動(dòng)態(tài)鏈接分析readelf -d libhcnetsdk.sogrep NEEDED關(guān)鍵頭文件存在查找HCNetSDK.h里NET_DVR_Init聲明頭文件路徑可被編譯器找到最小編譯驗(yàn)證寫一個(gè)只調(diào)NET_DVR_Init的空 main編譯鏈接不報(bào) undefined reference理論上這三步做完才進(jìn)入業(yè)務(wù)代碼階段。很多人直接拿官方 Demo 去改結(jié)果第一個(gè)報(bào)錯(cuò)是找不到某個(gè)廠商專用頭文件回頭才發(fā)現(xiàn)Include下還有子目錄沒加進(jìn)-I路徑。3. 交叉編譯鏈路CMake 腳本、動(dòng)態(tài)庫鏈接與三個(gè)必加的編譯參數(shù)3.1 一份可以直接用的 CMake 模板項(xiàng)目根部建立一個(gè)CMakeLists.txt核心內(nèi)容如下cmake_minimum_required(VERSION 3.16) project(hik_arm_demo CXX) set(CMAKE_CXX_STANDARD 14) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(SDK_PATH ${CMAKE_CURRENT_SOURCE_DIR}/third_party/HCNetSDK) set(ARM_TOOLCHAIN_PATH /opt/arm-toolchain/bin/) set(CMAKE_C_COMPILER ${ARM_TOOLCHAIN_PATH}/arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER ${ARM_TOOLCHAIN_PATH}/arm-linux-gnueabihf-g) include_directories(${SDK_PATH}/Include) add_executable(hik_demo main.cpp) target_link_libraries(hik_demo ${SDK_PATH}/lib/libhcnetsdk.so ${SDK_PATH}/lib/libHCCore.so pthread dl crypto sqlite3 ) set_target_properties(hik_demo PROPERTIES BUILD_RPATH INSTALL_RPATH \$ORIGIN/../lib SKIP_BUILD_RPATH TRUE )這個(gè)模板把三件事固定下來了指定交叉編譯鏈、指明 SDK 頭文件路徑、鏈接時(shí)顯式帶上 SDK 的 so 文件。注意鏈接那條命令里沒有寫-L加搜索路徑而是直接使用.so的絕對路徑。這樣做的好處是排查鏈接錯(cuò)誤時(shí)能看清到底是哪個(gè)庫缺符號(hào)缺點(diǎn)是需要把 SDK 庫路徑寫死靈活性略差。如果你習(xí)慣用-L一定要同時(shí)把同名軟鏈接建立好比如libhcnetsdk.so - libhcnetsdk.so.6.x。3.2 交叉編譯參數(shù)的三處關(guān)鍵設(shè)置除了常規(guī)的-march和你板子的 CPU 架構(gòu)真正影響 SDK 能否跑起來的參數(shù)是這組-marcharmv7-a -mfpuneon-vfpv4 -mfloat-abihard這三個(gè)參數(shù)分別指定了 ARM 指令集版本、浮點(diǎn)運(yùn)算單元和浮點(diǎn) ABI。很多板子的 CPU 支持硬浮點(diǎn)但出廠系統(tǒng)用的是軟浮點(diǎn)鏈接方式或者交叉編譯鏈默認(rèn)不帶 NEON這時(shí)編譯出來的程序在目標(biāo)板上一跑就段錯(cuò)誤。更隱蔽的問題是-mfloat-abisoftfp編譯出來的庫與硬浮點(diǎn)庫混在一起鏈接不報(bào)錯(cuò)運(yùn)行到浮點(diǎn)運(yùn)算才崩。我一般會(huì)再做一次動(dòng)態(tài)庫依賴體檢${ARM_TOOLCHAIN_PATH}/arm-linux-gnueabihf-readelf -d hik_demo | grep NEEDED這個(gè)命令輸出的 NEEDED 列表里應(yīng)該包含libhcnetsdk.so、libHCCore.so以及板子上本來就存在的libpthread.so.0、libdl.so.2。如果看到libstdc.so.6缺失別急著把 SDK 目錄下的 so 全拷過去先確認(rèn)板子的系統(tǒng)根文件系統(tǒng)里有這個(gè)基礎(chǔ)庫。用 buildroot 構(gòu)建的最小文件系統(tǒng)有時(shí)會(huì)漏掉它。3.3 符號(hào)裁剪與宏定義?？?SDK 在頭文件里用了大量條件編譯宏比如_WIN32、__linux__。在 Linux 交叉編譯環(huán)境中不需要手動(dòng)定義這些系統(tǒng)宏但有一個(gè)宏容易漏ANDROID或HI3516這類平臺(tái)宏在某些廠商分支里會(huì)切換NET_DVR_Init的實(shí)現(xiàn)方式。如果你從某個(gè)項(xiàng)目里拷貝頭文件然后又加了-DHI3516會(huì)導(dǎo)致系統(tǒng)把視頻壓縮庫換成硬件編解碼版本而那塊板上根本沒有對應(yīng)硬件。保持頭文件原樣、不加多余宏定義是最穩(wěn)妥的。4. 最小取流實(shí)現(xiàn)初始登錄、實(shí)時(shí)流回調(diào)與參數(shù)配置4.1 初始化與登錄結(jié)構(gòu)體#include cstdio #include cstring #include HCNetSDK.h int main() { NET_DVR_Init(); NET_DVR_SetConnectTime(3000, 1); NET_DVR_DEVICEINFO_V40 devInfo {0}; NET_DVR_USER_LOGIN_INFO loginInfo {0}; loginInfo.wPort 8000; memcpy(loginInfo.sDeviceAddress, 192.168.1.64, 14); memcpy(loginInfo.sUserName, admin, 6); memcpy(loginInfo.sPassword, your_pass, 10); LONG lUserID NET_DVR_Login_V40(loginInfo, devInfo); if (lUserID 0) { printf(login failed, error code%d\n, NET_DVR_GetLastError()); NET_DVR_Cleanup(); return -1; } printf(device serial: %s\n, devInfo.struDeviceV30.sSerialNumber); // 后續(xù)取流流程... NET_DVR_Logout(lUserID); NET_DVR_Cleanup(); return 0; }這段代碼走的是當(dāng)時(shí)線上常用的最短路徑NET_DVR_Init完成全局初始化NET_DVR_SetConnectTime設(shè)置連接超時(shí)和重試次數(shù)。登錄信息里的wPort默認(rèn)海康協(xié)議端口是 8000如果設(shè)備改過端口記得同步修改。NET_DVR_Login_V40返回值為負(fù)數(shù)表示登錄失敗此時(shí)通過NET_DVR_GetLastError拿到錯(cuò)誤碼錯(cuò)誤碼與文檔里的錯(cuò)誤碼表對應(yīng)比如錯(cuò)誤碼 7 代表用戶名或密碼錯(cuò)誤錯(cuò)誤碼 9 代表設(shè)備資源不足。devInfo.struDeviceV30.sSerialNumber作為設(shè)備唯一標(biāo)識(shí)可用于后續(xù)多設(shè)備目錄管理。4.2 實(shí)時(shí)流回調(diào)取圖取圖路徑更常用的是注冊回調(diào)函數(shù)讓 SDK 在收到視頻幀時(shí)自動(dòng)調(diào)用void CALLBACK RealDataCallBack(LONG lRealHandle, DWORD dwDataType, BYTE *pBuffer, DWORD dwBufSize, void *pUser) { switch (dwDataType) { case NET_DVR_SYSHEAD: // 碼流頭一般是 SPS/PPS需要緩存后與關(guān)鍵幀拼裝 break; case NET_DVR_STREAMDATA: // 視頻流數(shù)據(jù)解析后送入解碼器或直接存儲(chǔ) break; default: break; } } NET_DVR_PREVIEWINFO previewInfo {0}; previewInfo.lChannel 1; previewInfo.dwStreamType 0; // 0 主碼流1 子碼流 previewInfo.dwLinkMode 0; // 0 為 TCP1 為 UDP previewInfo.bBlocked 0; // 非阻塞模式避免回調(diào)長期占用 LONG lRealHandle NET_DVR_RealPlay_V40(lUserID, previewInfo, RealDataCallBack, NULL);NET_DVR_SYSHEAD這個(gè)分支必須處理。?？档拇a流在關(guān)鍵幀前會(huì)帶一次 SPS/PPS 數(shù)據(jù)如果你直接忽略這個(gè)分支用播放器或者 FFmpeg 解析時(shí)會(huì)出現(xiàn)“收到 I 幀但無法解碼”的典型問題。NET_DVR_STREAMDATA分支收到的數(shù)據(jù)是 H.264 裸流按幀邊界切好再送解碼器。數(shù)據(jù)幀邊界判斷不是每次回調(diào)都是一幀dwBufSize只是當(dāng)前緩沖區(qū)大小需要自己維護(hù)幀拼接邏輯。NET_DVR_RealPlay_V40返回值是句柄后續(xù)用NET_DVR_StopRealPlay(lRealHandle)停止播放句柄用完后置 -1 并做防御性判斷。4.3 多路接入時(shí)的參數(shù)策略同時(shí)接多臺(tái)設(shè)備時(shí)每臺(tái)設(shè)備用獨(dú)立線程執(zhí)行上面的登錄與取流流程。線程數(shù)不建議超過設(shè)備數(shù)否則回調(diào)里線程上下文切換反而拉高延遲。?？?SDK 同一進(jìn)程初始化一次即可不需要每路重新NET_DVR_Init。最大連接數(shù)是 SDK 內(nèi)部限制的實(shí)測發(fā)現(xiàn)不同主控型號(hào)差別較大有的允許 32 路同時(shí)預(yù)覽有的只給 16 路超出后NET_DVR_RealPlay_V40返回句柄為 -1錯(cuò)誤碼是 50設(shè)備資源不足或 29網(wǎng)絡(luò)連接失敗。在線路數(shù)到達(dá)臨界值時(shí)優(yōu)先把次要通道切成 UDP 子碼流減少帶寬占用。5. 避坑與排查鏈接找不到、回調(diào)阻塞、碼流丟幀三個(gè)高頻翻車點(diǎn)5.1 編譯鏈接找不到 libhcnetsdk.so 與 undefined reference現(xiàn)象交叉編譯時(shí)鏈接階段報(bào)cannot find -lhcnetsdk或者雖然鏈接成功但運(yùn)行時(shí)提示error while loading shared libraries。原因SDK 目錄里大概率提供的是帶版本后綴的 so 文件比如libhcnetsdk.so.6.3而鏈接指令寫的是-lhcnetsdk鏈接器需要的是不帶版本號(hào)的文件名。另一種情況是把 so 放到了自定義目錄但忘了加-Wl,-rpath-link指過去。解決在 SDK lib 目錄里建好軟鏈接保留最干凈的 so 名ln -sf libhcnetsdk.so.6.3 libhcnetsdk.so ln -sf libHCCore.so.1 libHCCore.so鏈接命令里用-Wl,-rpath-link指定 SDK 庫目錄運(yùn)行時(shí)的-Wl,-rpath指定板子上放置 so 的實(shí)際路徑。交叉編譯環(huán)境的-rpath-link用于解決編譯期依賴-rpath用于解決運(yùn)行期依賴兩者作用階段不同寫漏一個(gè)都可能讓你在測試時(shí)浪費(fèi)時(shí)間。數(shù)據(jù)包里準(zhǔn)備好的 CMake 模板已經(jīng)處理好了這層關(guān)系直接用即可。5.2 回調(diào)函數(shù)阻塞導(dǎo)致取流中斷現(xiàn)象設(shè)備連接正常網(wǎng)絡(luò)正常運(yùn)行十幾分鐘到幾小時(shí)后突然收不到數(shù)據(jù)或者主程序卡死。原因海康 SDK 的回調(diào)線程是統(tǒng)一管理的。如果你在RealDataCallBack里做了耗時(shí)操作比如寫文件、打印日志、推流上傳會(huì)直接拖慢 SDK 內(nèi)部取流線程。當(dāng)阻塞時(shí)間過長設(shè)備端發(fā)送超時(shí)會(huì)斷開連接而你可能根本看不到報(bào)錯(cuò)日志。解決把回調(diào)里的活全部丟給工作隊(duì)列回調(diào)里只做入隊(duì)操作。隊(duì)列長度設(shè)置上限比如 200 幀超出丟舊幀保新幀。我用的是無鎖環(huán)形緩沖實(shí)現(xiàn)生產(chǎn)者是回調(diào)線程消費(fèi)者是解碼線程實(shí)測比 mutex condition_variable 方式少 3~4ms 延遲。這里有一個(gè)容易忽略的細(xì)節(jié)回調(diào)函數(shù)名必須用CALLBACK宏修飾否則在 ARM 上可能因?yàn)檎{(diào)用約定不匹配導(dǎo)致棧損壞表現(xiàn)就是偶發(fā)崩潰。CALLBACK 宏在 Windows 上是__stdcallLinux 上展開為空但保留它能保證跨平臺(tái)移植不踩坑。5.3 子碼流花屏與 I 幀丟失現(xiàn)象切到子碼流時(shí)畫面頻繁花屏解碼器報(bào)PPS ID 0 not recognized或類似錯(cuò)誤。原因子碼流分辨率變化時(shí)設(shè)備會(huì)重新發(fā)送 SPS/PPS。如果回調(diào)里沒緩存 SPS/PPS只把NET_DVR_SYSHEAD丟棄解碼器就缺少參數(shù)集。另一個(gè)常見原因是設(shè)備端碼流切換瞬間丟掉了關(guān)鍵幀解碼器一直等 IDR 幀現(xiàn)象是黑屏。解決在NET_DVR_SYSHEAD分支緩存 SPS/PPS 數(shù)據(jù)與后續(xù)每一幀數(shù)據(jù)做拼接后送入解碼器。若追求低延遲可以不拼接直接透傳讓解碼器自己處理 Annex-B 格式。但要注意緩存時(shí)機(jī)有些固件不會(huì)在每次取流開始都發(fā)送參數(shù)集而是只在編碼參數(shù)變化時(shí)發(fā)送。更穩(wěn)的做法是先取一幀子碼流等待接收 SPS/PPS再正式啟動(dòng)渲染線程。我在實(shí)現(xiàn)里加了一個(gè)簡易狀態(tài)機(jī)狀態(tài)WAIT_SPS-WAIT_IFRAME-PLAYING只有到達(dá)PLAYING狀態(tài)才向解碼器灌數(shù)據(jù)避免把解碼器狀態(tài)打亂。6. 進(jìn)階延遲驗(yàn)證與 V4L2 備路一條可復(fù)現(xiàn)的低延遲 1080p 取流路徑先講延遲驗(yàn)證的方法。僅靠感覺判斷畫面卡不卡是玄學(xué)我用的是硬件 GPIO 打點(diǎn)對比取流線程內(nèi)輸出視頻幀時(shí)翻轉(zhuǎn)一個(gè) GPIO示波器接板端與攝像頭的幀間隔信號(hào)能算出從攝像頭觸發(fā)到回調(diào)執(zhí)行的時(shí)間差。如果示波器不方便就退而求其次在 PC 上用 FFmpeg 與板端同一時(shí)間點(diǎn)抓幀對比 NTP 時(shí)間戳。實(shí)測走 TCP 主碼流時(shí)從設(shè)備曝光完成到回調(diào)拿到首幀數(shù)據(jù)約 80~120msUDP 子碼流模式下會(huì)稍低一點(diǎn)但網(wǎng)絡(luò)抖動(dòng)會(huì)讓間隔不穩(wěn)定。而走 RTSP 拉流再轉(zhuǎn)封裝通常要多加 30~50ms取決于中間層緩沖設(shè)置。?？?SDK 直接取流是目前 ARM 板上延遲最可控的方案。再聊一個(gè)備路。如果 SDK 在特定固件上一直取不到主碼流少數(shù)場景會(huì)遇到設(shè)備端拒絕連接不要死磕平臺(tái)接口直接從設(shè)備 RTSP 端口拉流。?？档?RTSP 地址規(guī)則是rtsp://用戶名:密碼地址:554/Streaming/Channels/101表示 1 通道主碼流102是 1 通道子碼流。用 FFmpeg 或 VLC 拉通后把 H.264 裸流轉(zhuǎn)給 V4L2 的mem2mem設(shè)備驅(qū)動(dòng)硬解。缺點(diǎn)是失去了 SDK 提供的設(shè)備狀態(tài)上報(bào)能力但作為應(yīng)急方案它能保證出圖優(yōu)先級。值得補(bǔ)充的是RTSP 拉流在板端如果遇到設(shè)備因密碼錯(cuò)誤反復(fù)重連會(huì)短暫鎖賬號(hào)需要等解鎖時(shí)間而 SDK 登錄同樣有登錄失敗次數(shù)限制兩類方式在安全性上邏輯一致。從那以后我每次接 ARM 板子的攝像頭都強(qiáng)制先跑一遍這里的最小取流 Demo確認(rèn)設(shè)備型號(hào)、SDK 版本和交叉編譯鏈三者能完整跑通再往里面加業(yè)務(wù)代碼。分步驗(yàn)證在降級排查中依然有效——每一層匹配關(guān)系清晰翻車概率就低且每次排障的時(shí)間都能壓縮到半小時(shí)內(nèi)。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取