简介一套基于Delphi7实现的海康TCG-225预览与车牌识别示例工程面向需要在桌面端接入海康摄像头、验证预览抓拍与车牌识别流程的开发者。工程覆盖视频预览、手动抓拍、开启监听并接收抓拍事件后提取车牌号码等环节也包含监听地址与端口配置、视频检测方式及检测线触发抓拍的测试思路适合作为SDK集成与功能验证的参考样例。压缩包共54个文件约14.25MB以32个DLL运行库、7个LIB导入库为主辅以PAS、DFM、DPR等Delphi源码与窗体文件以及DCU编译单元、EXE示例程序和CFG等配置项便于直接运行或按工程结构查阅。已有1396人学习下载可作为海康TCG-225在Delphi7环境下做预览、抓拍与车牌识别功能验证的参考资料。1. 从立杆上那台抓拍机说起Delphi7 做预览与车牌识别的真实处境园区道闸旁边立着一台 TCG-225 抓拍机岗亭里的老客户端要能看实时预览后台还要把车牌识别结果写进数据库。麻烦在于岗亭那套管理系统是十几年前用 Delphi7 写的源码还在、业务还在跑、报表还挂在上面客户明确说不动语言。于是预览和车牌识别这两件事最后都落在同一个 D7 工程里解决。这个项目适合谁手上有存量 Delphi7 系统、必须对接网络摄像机或抓拍机、又不想整站重写的开发者。它最难的地方是 DLL 边界而不是业务逻辑一句stdcall声明写错、一个结构体对齐错了程序就会崩在某次回调里。2. 架构与选型Delphi7、设备 SDK 与识别引擎的三层分工2.1 工程目录与三层的边界这套东西我一直按三层来切最底下是 SDK 声明层只管函数签名和结构体中间是会话层管登录、预览、布防、重连最上面是界面和业务。目录大概长这样PlateGate/ ├─ src/ │ ├─ uMain.pas 主窗体预览面板、日志、按钮 │ ├─ uSdk.pas SDK 函数声明与结构体唯一引用 DLL 的单元 │ ├─ uDeviceSession.pas 登录/预览/布防/重连的会话封装 │ ├─ uPlateEngine.pas 本地识别引擎的 HTTP 客户端 │ ├─ uPlateStore.pas 识别结果落库ADO │ └─ uTypes.pas 共用类型、消息常量 ├─ bin/ │ ├─ PlateGate.exe │ ├─ SdkCore.dll 必须是 32 位 │ └─ config.ini IP/端口/账号/引擎地址/通道表 └─ db/ └─ plate.sql 建表脚本把 SDK 声明全部塞进uSdk.pas这一个单元是这套架构里最值钱的一条约定。原因很现实设备固件升级、SDK 换版本、甚至后面换成别家的抓拍机改动都集中在同一个文件里业务窗体一行都不用碰。反过来我见过不少老项目直接在uMain.pas顶部写几十行external声明三年后没人敢动那个窗体。会话层uDeviceSession.pas承担的是状态机职责未初始化、已登录、预览中、已布防、断线重连中。界面层只调用Start、Stop、Capture这样的方法不关心userID是几。这一层多写两百行后面排查问题时能省掉一整晚。2.2 为什么把 DLL 调用收进一个薄封装单元Delphi7 调 C 写的 DLL本质就三件事调用约定、参数类型、返回值含义。三者任何一个错位表现都是“莫名其妙”。所以我在uSdk.pas里只放声明不写任何业务unit uSdk; interface const SDK_DLL SdkCore.dll; // 必须是 32 位版本D7 编不出 64 位宿主 type TDeviceInfo packed record dwSoftwareVersion : DWORD; dwDeviceType : DWORD; byChanNum : Byte; byRes : array[0..3] of Byte; end; TClientInfo packed record hWnd : THandle; // 绑定的窗口句柄 byProtoType : Byte; // 0 私有协议 bBlocked : Byte; // 0 非阻塞 dwUser : DWORD; // 透传给回调的上下文 end; // 全部 stdcall和 C 侧 WINAPI 对齐 function SDK_Init: LongBool; stdcall; external SDK_DLL; function SDK_Cleanup: LongBool; stdcall; external SDK_DLL; function SDK_GetLastError: DWORD; stdcall; external SDK_DLL; function SDK_Login(sIP: PAnsiChar; wPort: Word; sUser, sPwd: PAnsiChar; var devInfo: TDeviceInfo; var err: DWORD): LongInt; stdcall; external SDK_DLL; function SDK_Logout(userID: LongInt): LongBool; stdcall; external SDK_DLL; function SDK_StartRealPlay(userID: LongInt; var clientInfo: TClientInfo; cb: Pointer; pUser: Pointer; nWaittime: DWORD): LongInt; stdcall; external SDK_DLL; function SDK_StopRealPlay(handle: LongInt): LongBool; stdcall; external SDK_DLL; implementation end.这段声明的关键点有三个。第一是stdcallC 侧导出的是__stdcallD7 里漏写就会在函数返回时把栈弹乱典型症状是“第一次调用没事第二次调用整个进程没了”这种玄学问题八成出在这。第二是LongBool而不是BooleanC 的BOOL是 4 字节Delphi 的Boolean是 1 字节用错会把后面的参数全部读偏。第三是句柄类的返回值统一用LongInt判断失败时写if h 0不要写if h 0。提示D7 只能生成 32 位程序所以工程里那份 DLL 必须是 32 位。手上只有 64 位 DLL 时别想着在 D7 里绕直接换一条路比如起一个 32 位中间进程转发否则启动就报“找不到入口点”。2.3 结构体映射AnsiChar 数组和 C 的 char[]这是最容易翻车的一层。C 头文件里的char sLicense[16]在 D7 里要写成array[0..15] of AnsiChar不能用string也不能用array of CharD7 的Char是 1 字节 AnsiChar其实等价但没人保证以后不改成WideChar。常用类型对照大致如下我基本照着这张表核对C 侧类型Delphi7 写法注意点char[N]array[0..N-1] of AnsiChar取值用StrPas并确保末尾有#0DWORDDWORD/LongWord别写成Integer和时间戳比较大小时会出负数LONG句柄LongInt失败返回 -1用 0判断BOOLLongBool4 字节不能用BooleanWORDWord端口号用它回调函数指针function(...): LongBool; stdcall不能带of object见 5.3嵌套结构packed record或显式{$A4}以 SDK 手册的偏移为准别猜对齐这件事我不想给一个“万能写法”因为不同 SDK 编译选项不一样。我的做法是拿手册里给的结构体总长度在单元初始化段里写一句断言Assert(SizeOf(TPlateResult) 手册值)跑一次就知道对不对比事后调试强得多。3. 预览链路拆解从登录拿 userID 到句柄出画面3.1 初始化与登录把 userID 当成会话凭据登录返回的userID是整个会话的凭据预览、布防、抓图、对讲全靠它。所以它不能是窗体上的一个局部变量必须挂在会话对象里随登录/登出成对变化。function TDeviceSession.Login: Boolean; var devInfo : TDeviceInfo; errCode : DWORD; begin Result : False; if FLogged then Exit; if not SDK_Init then begin // 整个进程只调一次 FLastError : SDK_GetLastError; Exit; end; SDK_SetConnectTime(3000, 2); // 3 秒超时失败重试 2 次 SDK_SetReconnect(10000, True); // 交给 SDK 自己保活 ZeroMemory(devInfo, SizeOf(devInfo)); FUserID : SDK_Login(PAnsiChar(AnsiString(FIP)), FPort, PAnsiChar(AnsiString(FUser)), PAnsiChar(AnsiString(FPwd)), devInfo, errCode); if FUserID 0 then begin FLastError : SDK_GetLastError; Exit; end; FLogged : True; Result : True; end;几个细节值得说。PAnsiChar(AnsiString(FIP))这种写法在 D7 里是安全的临时AnsiString在表达式结束前一直持有引用指针不会悬空。但如果把PAnsiChar(FIP)直接强转FIP是string在某些情况下拿到的不是首地址。SetConnectTime的两个参数分别是超时毫秒数和重试次数别把超时设成 10000 以上界面会像卡死一样。SetReconnect是 SDK 层的断线重连它只负责网络层不负责重新布防这点后面第五章会细说。登录失败时不要只弹一个“登录失败”把SDK_GetLastError的数值一起打日志。密码错、端口错、设备被别的客户端占满错误码是不一样的有码才有排查方向。3.2 预览启动与 hWnd 绑定预览这块最简单也最稳的做法是用TPanel当画布把它的Handle交给 SDK剩下的解码送显 SDK 全包了。procedure TDeviceSession.StartPreview(APanel: TPanel); var ci: TClientInfo; begin if not FLogged then Exit; if FRealHandle 0 then Exit; // 已经在预览别重复起流 ZeroMemory(ci, SizeOf(ci)); ci.hWnd : APanel.Handle; // 必须是有窗口句柄的控件 ci.byProtoType : 0; // 私有协议 ci.bBlocked : 0; // 非阻塞GUI 不假死 ci.dwUser : DWORD(PtrUInt(Self)); FRealHandle : SDK_StartRealPlay(FUserID, ci, RealDataCallBack, Pointer(Self), 5000); if FRealHandle 0 then begin FLastError : SDK_GetLastError; raise Exception.CreateFmt(启动预览失败错误码 %d, [FLastError]); end; FLastFrameTick : GetTickCount; end;hWnd这里有个常见误解TImage没有窗口句柄把Image1.Handle传进去编译不过有人绕过去传Form1.Handle结果是画面盖在整个窗体上。TPanel、TPaintBox、TForm都有Handle选TPanel是因为它天然带边框和对齐属性布局最省事。bBlocked一定要给 0。给 1 意味着 SDK 在调用线程里同步等第一帧而这个调用发生在主线程网络一慢整个界面就白屏转圈用户以为程序死了。如果业务上必须自己画比如要叠加车牌框、画区域线那就不能靠hWnd送显了得接回调里的 YUV 数据自己转 RGB再用Canvas.Draw贴上去。这条路的代价是 CPU 占用翻几倍D7 里做 YUV420 转 RGB 最好用 MMX/SSE 汇编或者找个现成的转换单元纯 Pascal 三层循环在 1080P 下基本跑不动。3.3 码流回调里只做三件事回调函数跑在 SDK 的内部线程里不是主线程。这个认知非常重要它决定了回调里能干什么、不能干什么。function RealDataCallBack(lRealHandle: LongInt; dwDataType: DWORD; pBuffer: PByte; dwBufSize: DWORD; dwUser: DWORD): Pointer; stdcall; begin Result : nil; case dwDataType of 0: ; // 系统头跳过 1: begin // 私有码流绑了 hWnd 时 SDK 自己解码送显 InterlockedExchange(gLastFrameTick, GetTickCount); end; 2: ; // YUV 原始数据要自己分析才用 3: ; // 音频 end; end;我在这类回调里只做三件事更新“最后一帧时间戳”给看门狗用、把关键帧拷进一块复用的缓冲给抓图用、必要时PostMessage通知主线程。绝不在这里ShowMessage、绝不在这里操作 VCL 控件、绝不在这里做 HTTP 请求。InterlockedExchange是为了避免 32 位读写被打断——严格说 32 位对齐读写在 x86 上是原子的但用它更省心也顺便表达了“这是跨线程共享变量”的意图。最后那个dwUser参数就是启动预览时传进来的Pointer(Self)回调里可以把它转回会话对象。这种“上下文指针”模式在 C 风格回调里非常通用比用全局变量干净得多。4. 车牌识别落地设备侧布防取结果与本地抓图兜底4.1 报警布防与车牌结果结构抓拍机自己带识别能力让它主动把结果推上来是成本最低的路子。做法是布防然后接收报警回调。// 注册回调要在布防之前否则布防瞬间产生的事件会丢 SDK_SetAlarmCallBack(AlarmCallBack, Pointer(Self)); FAlarmHandle : SDK_SetupAlarmChan(FUserID); if FAlarmHandle 0 then raise Exception.CreateFmt(布防失败错误码 %d, [SDK_GetLastError]);回调长这样重点是结构体解析和内存生命周期function AlarmCallBack(lCommand: DWORD; lHandle: LongInt; pBuf: PByte; dwLen: DWORD; pUser: Pointer): LongBool; stdcall; var pr : TPlateResult; msg : PPlateMsg; begin Result : True; if (pUser nil) or (pBuf nil) then Exit; if lCommand CMD_PLATE_CAPTURE then Exit; // 只要车牌抓拍这一类 ZeroMemory(pr, SizeOf(pr)); Move(pBuf^, pr, Min(dwLen, SizeOf(pr))); // 防御性拷贝防止越界 New(msg); msg^.Plate : Trim(StrPas(pr.struPlateInfo.sLicense)); msg^.Color : pr.struPlateInfo.byColor; msg^.Channel : pr.dwChannel; msg^.ShotAt : Now; msg^.PicData : nil; // 图片缓冲只在回调内有效必须马上拷出来 if (pr.dwPicLen 0) and (pr.pPicBuffer nil) then begin SetLength(msg^.PicData, pr.dwPicLen); Move(pr.pPicBuffer^, msg^.PicData[0], pr.dwPicLen); end; PostMessage(gMainWnd, WM_PLATE_ARRIVED, 0, LPARAM(msg)); // 交给主线程 end;这里最要命的一句注释是“图片缓冲只在回调内有效”。pPicBuffer指向的是 SDK 内部缓冲回调一返回就可能被复用或释放。血泪经验是我在回调里只存了指针主线程处理时再Move结果白天跑得好好的晚上车一多就抓到花屏图片查了两天才反应过来。结构体定义要跟手册逐字段对别嫌麻烦type TPlateInfo packed record byPlateSize : Byte; sLicense : array[0..15] of AnsiChar; // GBK 编码一字一字节 byColor : Byte; byRes : array[0..2] of Byte; end; TPlateResult packed record dwChannel : DWORD; struPlateInfo : TPlateInfo; dwPicLen : DWORD; pPicBuffer : PByte; sAbsTime : array[0..31] of AnsiChar; end;4.2 本地识别兜底JPEG 抓图 HTTP 送引擎设备侧识别不是万能的。逆光、车牌脏污、非标车牌比如工程车、临时牌设备给的置信度会很低。所以工程里补了一条兜底链路定时抓图本地送识别引擎。function TDeviceSession.CaptureJPEG(const AFile: AnsiString): Boolean; begin Result : False; if not FLogged then Exit; // 路径必须是纯英文 ANSI 路径中文目录在部分 SDK 里会直接失败 Result : SDK_CaptureJPEG(FUserID, FChannel, 0, PAnsiChar(AFile)); if not Result then FLastError : SDK_GetLastError; end;抓图之后送引擎用 Indy 的TIdHTTP是最省事的D7 自带 Indy 9Post重载接受TStreamfunction TPlateEngine.Recognize(const APicFile: AnsiString): string; var ms : TMemoryStream; http : TIdHTTP; resp : AnsiString; begin Result : ; ms : TMemoryStream.Create; http : TIdHTTP.Create(nil); try ms.LoadFromFile(APicFile); ms.Position : 0; http.ConnectTimeout : 800; // 短超时宁可漏一张也别拖住线程 http.ReadTimeout : 2500; http.Request.ContentType : image/jpeg; resp : http.Post(FUrl /v1/plate, ms); // 引擎返回 UTF-8 的 JSON Result : string(Utf8Decode(resp)); finally http.Free; ms.Free; end; end;ConnectTimeout和ReadTimeout这两个值我改过好几次。设太大一遇到引擎卡顿抓图线程就排一长串任务内存蹭蹭涨设太小稍微抖动一下就丢张。最后定在 800/2500配合一个长度受限的队列效果比较稳。D7 没有内置 JSON 解析常见做法是引一份第三方单元比如 superobject或者干脆写个只认几个字段的Pos/Copy解析函数。这个项目选的是后者因为返回结构稳定plate:苏A12345,confidence:0.93这种格式用两个Pos就切出来了比引依赖省事。4.3 中文车牌编码与落库车牌是中文的省份简称是 GBK 编码的两个字节。D7 里string是 ANSI直接StrPas(sLicense)得到的是 GBK 串写进 SQL Server 的nvarchar字段时如果走字符串拼接就是一堆问号。我的做法是统一转 UTF-8落库前只走一种编码function GbkToUtf8(const S: AnsiString): AnsiString; var n : Integer; ws: WideString; begin Result : ; if S then Exit; n : MultiByteToWideChar(936, 0, PAnsiChar(S), Length(S), nil, 0); if n 0 then Exit; SetLength(ws, n); MultiByteToWideChar(936, 0, PAnsiChar(S), Length(S), PWideChar(ws), n); n : WideCharToMultiByte(CP_UTF8, 0, PWideChar(ws), n, nil, 0, nil, nil); SetLength(Result, n); WideCharToMultiByte(CP_UTF8, 0, PWideChar(ws), Length(ws), PAnsiChar(Result), n, nil, nil); end;936是 GBK 的代码页不要写成CP_ACP因为服务器区域设置不一样CP_ACP可能是别的编码本地测没问题、部署到客户现场就乱码。落库这一步参数化查询是底线别拼 SQLprocedure TPlateStore.Save(const APlate: string; const APic: TBytes; AAt: TDateTime); begin with FQuery do begin Close; SQL.Text : INSERT INTO t_plate(plate_no, shot_at, pic) VALUES(:p, :t, :img); ParamByName(p).AsString : APlate; ParamByName(t).AsDateTime : AAt; ParamByName(img).LoadFromStream(TMemoryStream.Create, ftBlob); // 实例化后自行释放 ExecSQL; end; end;图片字段用ftBlob存一张 200KB 左右一天两千条就是 400MB所以表要按天分区或者定期归档。这个决定最好在一开始就定好等库涨到几十 G 再改DBA 看你的眼神会很复杂。5. 避坑与排查五个让我返工的细节5.1 一开预览就黑屏或直接闪退现象点“开始预览”后面板全黑界面无响应几秒有时候直接 Access Violation堆栈指向 SDK 内部。原因三个高频点。一是把TImage的“句柄”硬塞进去TImage没有窗口句柄传过去的是无效值二是bBlocked给了 1SDK 在主线程同步等第一帧三是工程里放的是 64 位 DLLD7 加载失败但错误被吞掉了。解决换成TPanel并确认Panel.Handle 0bBlocked固定为 0用依赖查看工具确认 DLL 的位数和导出函数名。导出名这一项特别容易漏——如果是 C 编的__stdcall函数名可能被修饰成_SDK_Login20这种声明时名字对不上运行时才报“找不到入口点”。D7 里可以在声明后加name 修饰名来兜住。5.2 车牌号乱码、只显示第一个字现象数据库里存的是??A12345或者干脆只剩一个A。原因sLicense是 GBK 的char数组。用WideString(sLicense)隐式转换D7 会按 ANSI 走一遍默认代码页非当前代码页的汉字直接变问号用StrPas之后直接拼接到 SQL 字符串里同样丢字。还有一种情况是数组中间出现#0StrPas提前截断只剩省份简称。解决先StrPas拿到AnsiString显式用MultiByteToWideChar(936, ...)转宽字符再转 UTF-8 落库见 4.3 的函数。如果确实存在#0说明长度要靠byPlateSize字段判断不能靠StrPas// 按长度取不依赖 #0 结尾 SetLength(tmp, pr.struPlateInfo.byPlateSize); if Length(tmp) 0 then Move(pr.struPlateInfo.sLicense[0], tmp[1], Length(tmp)); Plate : GbkToUtf8(tmp);5.3 回调函数写成对象方法编译过但一调就崩现象SDK_SetAlarmCallBack(Self.OnAlarm, ...)这种写法能编译但设备一推事件进程立刻挂。原因Delphi 的对象方法带一个隐藏的Self参数二进制层面跟 C 的函数指针完全不是一个东西。传进去的地址被 C 侧当普通函数调用栈帧直接错位。解决回调必须是独立的普通函数或者单元级的stdcall函数把对象实例通过pUser/dwUser传进去函数内部再转回对象function AlarmCallBack(...; pUser: Pointer): LongBool; stdcall; var Sess: TDeviceSession; begin Result : True; Sess : TDeviceSession(pUser); if Sess nil then Exit; Sess.HandleAlarm(lCommand, pBuf, dwLen); // 真正的逻辑写在对象里 end;这样既保持了可测试性又避开了调用约定的坑。5.4 跑一晚上内存涨到七百兆现象白天测试正常第二天早上任务管理器里进程占 700MB 以上重启就好。原因报警回调里New(PPlateMsg)之后PostMessage到主线程主线程处理完忘了Dispose。另一个来源是抓图循环里每次都TMemoryStream.Create异常路径没走finally。这两处泄漏都是每张车牌漏几十 KB 到几百 KB量小但架不住一天几千次。解决凡是跨线程传指针的约定“谁 New 谁不管谁收到谁释放”处理函数第一行写try ... finally Dispose(msg); end;。抓图这类高频分配改成复用缓冲会话对象里挂一个TMemoryStream每次Clear后重用只在尺寸不够时才SetLength。5.5 拔网线再插上预览再也回不来现象现场施工拔了一次交换机电源恢复后其他客户端都正常只有这台 D7 客户端黑屏重启程序才恢复。原因三个叠加。一是SetReconnect只重建网络连接不重建布防报警回调从此收不到二是重连定时器和用户点“重连”按钮同时在建会话旧userID没LogoutSDK 内部会话表被占满三是进程退出时没调SDK_Cleanup下一次启动偶发端口占用。解决重连加一个互斥标志正在重连时其他入口直接返回失败路径统一走StopRealPlay → Logout → Cleanup → Init的完整重建并且重建之后必须重新布防程序FormClose里按同样顺序释放一遍。注意重连不要写成while True do Login设备侧有登录频率限制打太密会被临时拒绝。指数退避1s、2s、4s、8s封顶 30s是最省心的策略。6. 二次开发改造多通道轮询、断线重连与效果验证单通道跑通之后绝大多数需求都会变成“我这有八个门口”。这时候第一件事不是加循环是确认 SDK 的会话模型一个userID能带多个通道还是一个通道一个会话。两种模型都见过写代码前先翻手册不然八个通道登录八次设备直接把你拉黑。我一般把会话对象拆成“设备级”和“通道级”两层type TChannel class private FUserID : LongInt; // 设备级会话多通道共享 FChannel : Integer; FRealHandle : LongInt; FLastFrameTick: Cardinal; FAlarmHandle : LongInt; public procedure Start; // 起预览 布防 procedure Stop; function Alive: Boolean; end;Start里只起自己那一路的预览和布防Stop里只停自己那一路FUserID由外层设备对象统一持有和释放。这样某一路出问题不会连累其他通道日志也能带上通道号。重连这块我用“最后一帧时间戳”做看门狗比直接探活可靠procedure TChannel.CheckHealth; var nowTick: Cardinal; begin if FBusy then Exit; // 防重入 nowTick : GetTickCount; if nowTick - FLastFrameTick 15000 then Exit; // 有帧就正常 Inc(FFailCount); if FFailCount 3 then begin Stop; // 先停流再退会话 FDelay : Min(30000, 1000 shl Min(FFailCount, 5)); // 指数退避 ScheduleRelogin(FDelay); end; end;FLastFrameTick在码流回调里更新见 3.3。判断依据不是“连接还在不在”而是“画面还在不在动”这能同时覆盖网络断开、码流卡死、设备重启三种情况比我之前写的任何探活逻辑都实在。改造完怎么验证没把老功能弄坏我有一张固定清单每次都走一遍验证项操作通过标准冷启动双击 exe不登录直接看主界面不报错按钮置灰正常链路登录 → 预览 → 抓图 → 落库画面 3 秒内出库里有记录断网恢复拔网线 30 秒再插回30 秒内自动恢复画面和布防异常退出任务管理器强杀进程重开后能正常登录无端口占用长时间连续跑 12 小时内存波动不超过 30MB最后说一个习惯。从那以后我每次改回调相关的代码都会先在回调里加一行OutputDebugString打时间戳和线程 ID用调试工具看一眼确认它确实在 SDK 线程而不是主线程——这个动作花十秒能挡掉后面至少半天的玄学问题。希望帮到你。本文还有配套的精品资源点击获取
