简介一个基于C#的ONVIF协议客户端工具源代码包适用于Visual Studio 2015环境完整实现了ONVIF规范中常用的设备管理接口包括设备发现与探测、设备鉴权、设备信息读取、网络参数设置、用户增删改查、系统重启与固件升级等。视频部分则负责获取与配置RTSP流参数并利用Live555库对RTSP流进行解析与显示能够直接预览网络摄像头画面。整个代码包共约两千个文件压缩后约三十二兆字节以一千八百余个C#源文件为主体另含一千一百余个C源文件、五百余个头文件以及XAML界面、XML配置、DLL动态库等工程结构清晰将ONVIF协议模块、Live555封装层、WPF界面等分开组织便于按需修改与扩展。值得一提的是包内还随附了大量FFmpeg相关源代码有助于理解视频解码与流媒体处理的底层原理对于想深入分析ONVIF报文交互或移植到其他语言的开发者来说是一份实用的参考实现。目前已有1406人浏览/学习适合具备一定C#基础、希望二次开发或研究网络视频接入的开发者。 不管你是做安防项目集成、设备统一管理平台还是给上层的业务系统做底层视频接入层总会在某个时间点遇到这样一个需求手头有一堆不同品牌的网络摄像头海康、大华、宇视、安讯士品牌五花八门但领导只丢给你一句话把它们都接进来出一个统一的预览和管理界面。每个厂商的SDK各有一套协议文档厚得能砸死人对接联调能拖掉你一两周。这时候你会想起还有ONVIF这个东西——它是安防设备互联的标准协议只要设备厂商支持就能用一套客户端代码通吃。这篇博文我就分享一个基于C#语言、用Visual Studio 2015开发的ONVIF协议客户端工具的完整思路和源码实现覆盖从设备发现、能力协商、取流到PTZ控制的全部常用功能。先说我为什么选择C#和VS 2015这个组合。安防行业里C#配合.NET Framework做上位机、做工具类软件是主流选择开发效率高WinForm/WPF出界面快而且ONVIF协议基于SOAP/XML Web ServiceC#对Web Service的调用支持非常成熟无论是直接添加服务引用还是用HttpClient手工拼SOAP报文都很顺手。VS 2015对应的.NET Framework 4.5.2/4.6在工业现场和项目交付环境里兼容性足够好很多客户的工控机、服务器老系统跑的就是这个运行时。这篇里的源码我按VS 2015 .NET Framework 4.5来组织如果你用更高版本打开也基本可以直接编译只有个别语法层面很小的兼容问题。整个工具我按功能拆成了几个模块设备发现模块、设备信息与能力协商模块、RTSP取流与预览模块、PTZ云台控制模块、OSD与参数配置模块。下面我按模块讲实现思路把关键代码和踩过的坑一起放出来方便你直接抄作业。1. 开局先搞定设备发现WS-Discovery的坑与替代方案ONVIF设备发现走的是WS-Discovery协议本质是一个基于UDP组播的SOAP探测流程。客户端往组播地址239.255.255.250:3702发一条Probe消息支持ONVIF的设备收到后会回复ProbeMatch里面带设备的XAddrs设备服务地址和类型信息。1.1 必须避开的组播坑网卡选择与防火墙第一次做的时候我用UdpClient直接往组播地址发消息结果发现有的设备能发现有的发现不了同一台设备在不同网络环境下表现还不一样。排查了一圈核心原因有两个。第一个是网卡选择。你本机如果有多个网卡有线、无线、虚拟机的虚拟网卡UdpClient默认走的网卡和你摄像头实际所在的网段可能不是同一张组播消息根本没到摄像头的网段。第二个是Windows防火墙默认会拦截UDP入站组播消息程序如果没有放行或者没有绑定到正确的端口ProbeMatch就回不来。我的做法是在发现前枚举本机所有IPv4网卡地址绑定到指定本地网卡发送同时绑定本地UDP端口并且把防火墙的入站规则加上。你要是只想快速跑通可以先手动关防火墙仅限开发环境局域网内上百个设备也不会出问题但正式工具必须做网卡选择UI。// WS-Discovery Probe 消息模板SOAP over UDP string probeMessage ?xml version\1.0\ encoding\UTF-8\?\n e:Envelope xmlns:e\http://www.w3.org/2003/05/soap-envelope\\n xmlns:w\http://schemas.xmlsoap.org/ws/2004/08/addressing\\n xmlns:d\http://schemas.xmlsoap.org/ws/2005/04/discovery\\n xmlns:dn\http://www.onvif.org/ver10/network/wsdl\\n e:Header\n w:MessageIDuuid: Guid.NewGuid().ToString() /w:MessageID\n w:Tourn:schemas-xmlsoap-org:ws:2005:04:discovery/w:To\n w:Actionhttp://schemas.xmlsoap.org/ws/2005/04/discovery/Probe/w:Action\n /e:Header\n e:Body\n d:Probe\n d:Typesdn:NetworkVideoTransmitter/d:Types\n /d:Probe\n /e:Body\n /e:Envelope;发送的时候要把这个消息编码成UTF-8字节数组用UdpClient.Send发到239.255.255.250:3702。接收的时候异步收ReceiveTimeout要设置成3到5秒因为组播响应是谁听到谁回有快有慢。1.2 实时性太差的补充方案ONVIF Device Manager的思路这里必须说一个实际情况OSD自带的ONVIF Device Manager官方工具发现速度快、健壮性好但它内部不只是发了Probe还会对已经知道的历史设备IP做直连探测。我自己测试纯靠WS-Discovery在大型局域网里经常有两三秒的延迟甚至丢包而官方工具几乎是秒出结果。所以我的工具里除了组播发现还加了一个手动添加的入口——用户直接填设备IP和端口程序通过GetSystemDateAndTime和GetDeviceInformation两个接口探测设备是否在线、是否支持ONVIF。这样规避了组播的所有不确定性实际项目里反而是主力方式。组播发现适合广播段内的设备跨三层网络就只能靠手动添加或者走厂商自己的SDK做设备搜索了。2. 能力协商是ONVIF客户端的握手环节不能跳发现设备后第一件事不是急着取流而是做能力协商。ONVIF设备能力分为两大类一是设备自身的能力分类GetCapabilities接口返回的Capabilities二是某个具体服务的地址比如Media服务、PTZ服务的地址和服务端口。不同厂商的IPC甚至同一厂商不同固件版本服务地址都可能不一样你必须在运行时动态获取不能把/onvif/device_service这种路径写死。2.1 三种方式实现SOAP通信我推荐哪种C#调用ONVIF的SOAP接口无非三种套路工程里添加Web服务引用生成代理类、用svcutil生成客户端类、直接HttpClient手写SOAP XML然后解析返回值。三种我都用过说说各自的定位。添加服务引用最省事IDE自动把WSDL转成C#代理类方法调用像本地函数一样。但坑在于ONVIF的WSDL不是单文件而是多个WSDL互相import服务地址又要求在运行时替换成设备的IP服务引用默认绑定的地址是写死的你得手动改EndpointAddress。而且一旦WSDL升级或设备实现有差异生成代码可能报序列化错误。手写SOAP看起来费劲但可控性最高。ONVIF的请求和响应本质上是固定结构的XML你不必每一条都从零写核心公共部分封装好后每个接口只需要定义Body里的业务节点和响应里的取值路径。我推荐用它处理那些调用频率高或者格式比较简单的接口比如GetDeviceInformation、GetSystemDateAndTime、Reboot。折中的方案是用svcutil把ONVIF的核心WSDL尤其是Device、Media、PTZ这几个服务生成一个统一的C#客户端文件这个文件不依赖VS的服务引用配置地址在运行时指定处理起来比手工拼接XML省一半代码量。我的工具主体就是用这个方案再辅助手写SOAP做补充。2.2 设备信息与能力分类代码下面这段代码是用HttpClient直接调GetDeviceInformation的极简示例重点是演示SOAP请求的结构和命名空间。实际工程中你还得处理摘要认证的挑战响应后面单独说。using System; using System.Net.Http; using System.Text; using System.Xml; public class OnvifDeviceInfo { public string Manufacturer { get; set; } public string Model { get; set; } public string FirmwareVersion { get; set; } public string SerialNumber { get; set; } public string HardwareId { get; set; } public static OnvifDeviceInfo GetDeviceInfo(string deviceAddress, string username, string password) { // 这里deviceAddress形如: http://192.168.1.64/onvif/device_service string requestXml ?xml version\1.0\ encoding\UTF-8\?\n s:Envelope xmlns:s\http://www.w3.org/2003/05/soap-envelope\\n xmlns:tds\http://www.onvif.org/ver10/device/wsdl\\n s:Body\n tds:GetDeviceInformation/\n /s:Body\n /s:Envelope; using (var client new HttpClient()) { var content new StringContent(requestXml, Encoding.UTF8, application/soapxml); // 实际项目这里要加 WS-Security 头部或 HTTP Digest 认证见第3节 var response client.PostAsync(deviceAddress, content).Result; string responseXml response.Content.ReadAsStringAsync().Result; var doc new XmlDocument(); doc.LoadXml(responseXml); var ns new XmlNamespaceManager(doc.NameTable); ns.AddNamespace(tds, http://www.onvif.org/ver10/device/wsdl); ns.AddNamespace(tt, http://www.onvif.org/ver10/schema); return new OnvifDeviceInfo { Manufacturer doc.SelectSingleNode(//tds:GetDeviceInformationResponse/tds:Manufacturer, ns)?.InnerText, Model doc.SelectSingleNode(//tds:GetDeviceInformationResponse/tds:Model, ns)?.InnerText, FirmwareVersion doc.SelectSingleNode(//tds:GetDeviceInformationResponse/tds:FirmwareVersion, ns)?.InnerText, SerialNumber doc.SelectSingleNode(//tds:GetDeviceInformationResponse/tds:SerialNumber, ns)?.InnerText, HardwareId doc.SelectSingleNode(//tds:GetDeviceInformationResponse/tds:HardwareId, ns)?.InnerText }; } } }看到没请求体就是一层比一层深的XML节点。ONVIF的这套协议本质就是定义了一堆请求长这样、响应长那样的标准模板你把模板记住或者查规范文档剩下的事情就是XML解析。2.3 为什么推荐先拿GetCapabilities再决定后续流程很多新手会忽略GetCapabilities直接调用GetProfiles、GetStreamUri。这在某些设备上能跑通但属于碰运气写法。规范里GetCapabilities返回的Media、PTZ、Event、Device等类别各自的XAddr才是你这个设备真正开放的服务基地址有些设备会把Media服务和Device服务放在同一个地址上有些会分开到不同的path比如/onvif/Media和/onvif/device_service。如果不拿Capabilities直接调Media相关接口刚好碰上分开部署的设备请求就会404或者返回Action not supported。所以我设计工具时的逻辑是设备发现之后强制走一遍GetCapabilities把返回的服务地址缓存下来后续所有调用都基于这个缓存地址。另外GetCapabilities的返回里还带了Network、Security等能力标志你可以根据标志决定UI上要不要显示PTZ控制面板、要不要显示视频编码配置页做到连上什么设备就显示什么功能。3. 认证机制是重点中的重点四种方式我全踩过ONVIF认证是项目里卡住最多人的地方没有之一。我刚接触的时候拿着官方的WSDL生成代理类加上了用户名密码调用设备居然报401或者Not Authorized折腾了好久才发现认证不是简单地在HTTP请求头里塞个Authorization: Basic ...就行。3.1 WS-Security UsernameToken与HTTP Digest的使用场景对比ONVIF的认证机制分两类一类是WS-Security里的UsernameToken用户名密码放在SOAP Header里密码可以用明文或者PasswordDigest摘要另一类是HTTP级别的认证常见的是Digest认证也就是我们浏览器访问设备网页时弹窗输账号密码的那个机制。具体选哪种取决于设备实现的ONVIF版本和配置。老设备ONVIF 2.0之前的很多只支持UsernameToken的明文密码方式对应的WSDL服务端口往往也配置的是Transport安全模式还是HTTP安全模式新设备普遍支持Digest。我的工具采取的策略是自动协商先尝试UsernameToken PasswordDigest如果返回401再尝试UsernameToken明文如果还不行就尝试HTTP Digest。实际测试下来覆盖市面上95%以上的设备没有问题。3.2 PasswordDigest的生成逻辑贴代码PasswordDigest的算法不复杂但细节容易错using System; using System.Security.Cryptography; using System.Text; public static string GeneratePasswordDigest(string password, string nonce, string createdTime) { // nonce是随机生成的字节数组createdTime是UTC时间如 2024-01-01T00:00:00Z byte[] nonceBytes Convert.FromBase64String(nonce); byte[] createdBytes Encoding.UTF8.GetBytes(createdTime); byte[] passwordBytes Encoding.UTF8.GetBytes(password); // 步骤1: nonce created password 拼接 byte[] combined new byte[nonceBytes.Length createdBytes.Length passwordBytes.Length]; Buffer.BlockCopy(nonceBytes, 0, combined, 0, nonceBytes.Length); Buffer.BlockCopy(createdBytes, 0, combined, nonceBytes.Length, createdBytes.Length); Buffer.BlockCopy(passwordBytes, 0, combined, nonceBytes.Length createdBytes.Length, passwordBytes.Length); // 步骤2: SHA1哈希必须一次哈希不能多次 using (var sha1 SHA1.Create()) { byte[] hash sha1.ComputeHash(combined); return Convert.ToBase64String(hash); } }生成之后把这个Digest和Nonce、Created一起放进SOAP Header的Security节点里格式如下s:Header Security s:mustUnderstand1 xmlnshttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd UsernameToken Usernameadmin/Username Password Typehttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigestBase64Digest字符串/Password Nonce EncodingTypehttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64BinaryBase64Nonce/Nonce Created xmlnshttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd2024-01-01T00:00:00Z/Created /UsernameToken /Security /s:Header这里最容易翻车的三个点Nonce必须是Base64字符串而算法里用的又是解码后的字节数组Created必须是UTC时间不是本地时间mustUnderstand1要带上部分设备对缺少这个属性的请求直接拒绝。3.3 用HttpClient拦截挑战响应实现Digest的完整思路如果是走HTTP Digest思路是另一个套路先发一个不带认证头部的请求服务端返回401且带WWW-Authenticate: Digest ...响应头里面包含realm、nonce、qop然后用这些参数计算Authorization头重新请求。我把这个写成了一个小工具类调用任何ONVIF接口前先尝试无认证请求识别到401再自动补齐摘要。你会遇到的一个细节是有些设备的Digest Realm是一个固定字符串有些是根据用户名动态生成的必须从401响应里去取不能写死。4. 取流预览是工具的核心Profile、StreamUri、RTSP认证三位一体ONVIF取流是整个工具最核心的体验环节。用户在界面上看到画面才算真正连通了设备。但这里牵涉三个概念理解透了才能顺畅实现。4.1 Media服务三步走GetProfiles、GetStreamUri、RTSP播放器接入第一步是GetProfiles返回这个设备当前配置好的媒体Profile列表。一个Profile可以理解成一套分辨率和编码参数的套餐组合通常设备会预置MainStream主码流高清和SubStream子码流流畅两个Profile也可能有更多自定义Profile。你要在UI上给用户下拉选择而不是默认取第一个——因为有的设备第一个Profile是子码流画质模糊容易让用户认为这个工具接入效果差。第二步是拿选中的Profile去调GetStreamUri传一个StreamSetup参数比如RTP-Unicast、RTSP协议返回结果是一个MediaUri对象里面真正的RTSP地址形如rtsp://192.168.1.64:554/Streaming/Channels/101?transportmodeunicast。第三步才是把RTSP地址交给播放器模块去解码渲染。这里的播放器选型很关键。在WinForm里做RTSP播放市面上的方案无外乎VLC.DotNet、libvlc、FFmpeg系的自封装播放控件、OpenCvSharp的Cv2.VideoCapture拉流再转Bitmap显示。我个人的选择是工具界面预览用libvlc的WinForm控件封装原因是VLC的RTSP兼容性最好市面上各种奇葩编码H.265、MJPEG、某些厂商的私有封装VLC基本都能硬扛下来而且支持硬件解码CPU占用低。OpenCvSharp更适合需要做图像处理的场景但它的RTSP拉流对网络抖动容忍度略低画面容易卡顿或掉帧。如果你的设备编码是MJPEGOpenCvSharp反而是最轻量的选择因为它解码MJPEG就是解码JPEG非常快。4.2 RTSP地址里暗藏的认证陷阱拿到RTSP地址之后很多人直接拿VLC去Open结果弹窗要求输账号密码。这是因为GetStreamUri返回的URI里通常不带用户名密码RTSP服务端认证和ONVIF的SOAP认证是两套体系。解决办法就是在播放前把URI改成带认证信息的格式rtsp://用户名:密码IP:554/...。有一点要注意密码里有、:、/这些特殊字符时需要做URL编码。我见过不少人在这里踩坑密码里带个符号结果播放一直报401或者连接失败。public static string BuildRtspUrlWithAuth(string rawRtspUrl, string username, string password) { var uri new Uri(rawRtspUrl); string encodedUser Uri.EscapeDataString(username); string encodedPass Uri.EscapeDataString(password); // 把原始URL的scheme://host部分替换为带认证信息的格式 return ${uri.Scheme}://{encodedUser}:{encodedPass}{uri.Authority}{uri.PathAndQuery}; }另外GetStreamUri的请求参数里还有个StreamSetup的Transport属性部分设备在传RTSP的RTP-Unicast时会在返回URI里自动附带transportmodeunicast参数不必再手动加加重复可能导致某些严格实现的设备报错。4.3 预览不出来的通用排查顺序我在实际联调中把预览失败的问题归成了三类按顺序排查效率最高一是RTSP地址本身能不能通用VLC桌面版直接打开原始地址测能通则问题在控件接入二是网络链路和端口放通情况确认554端口能通注意跨网段的防火墙和安全策略三是认证信息是否写对RTSP服务端账号密码和管理员Web登录的账号密码通常是同一套但有的设备区分admin和operator等级别权限不足时可能取流失败但Web登录正常。建议工具调试时先做一个连接诊断按钮依次检测Ping、TCP端口、SOAP接口、RTSP取流哪一步挂了直接告诉用户用户体验完全不一样。5. Media Profile里到底有什么解析编码与分辨率信息接上面第4节的GetProfiles既然要让用户选码流那么界面上就要把Profile里的编码格式、分辨率、帧率这些信息展示出来。这需要你解析GetProfiles返回的复杂XML结构。5.1 从Profile XML里提取视频编码和分辨率一个Profile响应看起来长这样简化后trt:GetProfilesResponse trt:Profiles tokenProfile_1 fixedtrue tt:NameMainStream/tt:Name tt:VideoEncoderConfiguration tokenVideoEncoder_1 tt:NameMainStream/tt:Name tt:EncodingH264/tt:Encoding tt:Resolution tt:Width1920/tt:Width tt:Height1080/tt:Height /tt:Resolution tt:RateControl tt:FrameRateLimit25/tt:FrameRateLimit /tt:RateControl /tt:VideoEncoderConfiguration /tt:Profiles /trt:GetProfilesResponse解析的时候SelectSingleNode配合XmlNamespaceManager是最稳定的方式。注意Profiles节点上的token属性才是Profile的唯一标识调GetStreamUri时传的是这个token不是Name。Name只是给人看的。5.2 编码参数不匹配导致的取流黑屏问题有些设备默认用H.265编码但部分VLC版本对H.265的RTSP兼容性不如H.264会出现画面黑屏但进度条一直走的情况。对于工具类软件我建议在UI上用不同颜色或图标标注编码格式让用户一眼知道这个码流是H.264还是H.265。如果你确认要兼容老旧的播放控件可以在连接之后通过SetVideoEncoderConfiguration接口把设备编码临时切到H.264前提是设备支持且你不想破坏设备原有配置时慎用。我通常不建议工具自动去改设备编码很容易把用户的生产配置改乱更好的是让用户自己在设备Web页面上调。6. PTZ控制ContinuousMove与绝对定位的两种用法PTZ云台控制是安防工具里另一个高频功能。ONVIF PTZ服务提供了几类控制方式连续移动ContinuousMove、相对移动RelativeMove、绝对定位AbsoluteMove、预置位GotoPreset/SetPreset以及辅助功能AuxiliaryCommand。客户端工具里最常用的是连续移动和预置位因为这两个最贴近用户直觉。6.1 ContinuousMove的Velocity参数向量归一化的细节ContinuousMove的请求体里有一个Velocity参数是PTZSpeed类型包含PanTilt的x、y以及Zoom的x。这几个值的范围是-1.0到1.0正负号代表方向大小代表速度比例。实际使用时要特别留意x对应水平方向向右为正y对应垂直方向向上为正。很多设备在垂直方向上可能做了反向我遇到过某品牌的IPC你想让画面往上y必须传负值。因此我的工具UI上放了反向开关供用户适配不同设备。Zoom则是一个标量正数拉近负数拉远。操作PTZ时连续移动只需要按住移动和松开停止两个动作所以UI上做一个十字方向控制盘加上缩放手柄就够了。每次按下时调ContinuousMove松开时调Stop。注意Stop接口有两个参数PanTilt和Zoom分别表示是否停止水平和垂直、是否停止变焦我实际测试很多设备必须两个都传true才完全停住只传一个会导致某个方向还在动。6.2 预置位管理与无效返回的容错预置位的核心接口是SetPreset设置当前位置为某个预置位、GotoPreset转动到指定预置位、RemovePreset删除预置位。返回的PresetToken是字符串有的设备是数字有的设备是一串UUID一定要用string格式接收别掉进int转换的坑。另外GotoPreset需要传入Speed参数这是移动到该预置位时的速度0到1.0不传的话部分设备会按最大速度猛转体验很差。有些设备在调用PTZ接口时报Not Supported不是说设备没有云台而是这个Profile没有关联PTZ配置。排查思路是先看GetCapabilities里的PTZ服务地址是否为空再调GetConfigurations确认设备里是否存在PTZ配置节点最后检查Profile的PTZConfiguration字段是否非空。顺序不能乱。6.3 一个容易被忽略的细节连续移动的单位时间值ONVIF规范里ContinuousMove的Velocity虽然是个比例值但部分设备实现里真正的速度是PanTilt的x/y乘以一个内部的PanTiltSpeed缩放系数这个系数在GetConfiguration的PanTiltLimits里可以查到。因此同样传0.5有的设备转得很慢有的转得很猛。工具里最好提供速度滑条让用户根据实际反馈调整而不是写死一个推荐值。7. OSD与图像参数配置把国产设备改字的刚需做进去最后这块内容是提高工具完整度的加分项。做安防项目的朋友大概率遇到过这种需求客户需要把摄像头画面上叠加的字改了比如把东门入口改成西门出口或者把时间格式换一下。直接登录设备Web后台也能改但如果要批量处理几十上百台设备用工具批量下发就省事多了。7.1 GetOSD与SetOSD的XML操作ONVIF的GetOSDs接口返回设备当前所有OSD配置里面最关键的信息是OSDToken和TextString。修改文字就是SetOSD传入原来的OSD配置副本把TextString改成新值然后整体提交。注意这里有个先查后改的坑SetOSD请求里的内容必须包含完整的OSD配置结构不是你只传一个token和新文字就行要把VideoSourceConfigurationToken、Position、Text这些字段都带全否则设备会报请求参数错误。// 简化版SetOSD请求结构 string setOsdRequest trt:SetOSD\n trt:OSD\n tt:tokenOSD_TOKEN_001/tt:token\n tt:VideoSourceConfigurationTokenVideoSource_001/tt:VideoSourceConfigurationToken\n tt:Text\n tt:PlainText新的通道名称/tt:PlainText\n /tt:Text\n tt:Position\n tt:TypeCustom/tt:Type\n tt:Pos\n tt:X0.5/tt:X\n tt:Y0.1/tt:Y\n /tt:Pos\n /tt:Position\n /trt:OSD\n /trt:SetOSD;Position里的X、Y是归一化坐标范围0到1(0,0)是左上角(0.5,0.1)大约是上方居中的位置。这个坐标系的定义各家设备实现略有差异有的设备认为Y是垂直向下为正有的则是向上为正所以如果改了后发现文字跑到了画面外优先怀疑这个坐标方向问题。7.2 批量改OSD的注意点因型号差异而必须走能力差异化前面说过不同设备能力不同批量改OSD同样面临这个问题。有的设备只支持一个OSD有的支持多个有的只支持文本OSD有的还支持时间OSD。批量脚本里我会在遍历设备后调用GetOSDs根据返回的数量和类型动态生成修改列表只改那些实际存在的OSD。绝不假设所有设备都有OSD_TOKEN_001——跨品牌这么做必炸。7.3 图像亮度、对比度、饱和度调节入口GetImagingSettings和SetImagingSettings用来调节图像参数包括Brightness亮度、Contrast对比度、ColorSaturation饱和度、Sharpness锐度。作用在VideoSourceConfigurationToken上所以要改哪个视频源的图像参数先通过Profile拿到对应的VideoSourceToken。这里最容易忽略的是SetImagingSettings的第二个参数ForcePersistence官方文档意思是是否强制持久化到设备非易失存储如果你希望设备重启后设置还在必须传true。8. 最后再聊几个我踩过的实现细节前几节的代码思路已经能支撑一个基础可用的ONVIF客户端工具了但工程化落地的时候还有一些边角细节这里集中说一下。8.1 应用层超时与重试机制ONVIF设备在负载高的时候响应慢是常事尤其老款IPC在同时被多个客户端访问时SOAP接口偶尔会出现5秒甚至10秒的延迟。因此所有HTTP请求的超时时间我建议设成10秒并且配合指数退避重试。但重试仅限于幂等操作查询型接口对于SetOSD、SetImagingSettings这类写操作不要自动重试否则可能重复执行或产生半更新状态。另外重试需要和用户界面的操作状态联动别让用户感觉软件卡死了。8.2 SOAP请求的XML字符转义手写SOAP报文时老手也会在字符串拼接上栽跟头。用户名、密码、OSD文字里如果含有、、、、这些XML保留字符必须转义成amp;、lt;、gt;等实体。我封装了一个工具方法凡是进入XML节点值的文本一律过一遍SecurityElement.Escape省得出事。8.3 WSDL生成代理类后的命名空间误区使用svcutil生成ONVIF代理类时默认命名空间会非常长比如http://www.onvif.org/ver10/device/wsdl。这些命名空间字符串不能随意改动SOAP是严格匹配的哪怕多了个斜杠或者少个ver10请求都会失败。我曾经为了让代码好看手动把生成的代理类里的命名空间常量整理了一遍结果导致所有设备都报Action不匹配排查了很久才意识到是命名空间被改了。这个警告新手最好记在心里生成的代码能不动的尽量不动。8.4 工具里加一个抓包辅助开关当设备接入不上时最有效的排查方式是抓包。我做的工具里留了一个日志抓包功能开启后把所有发出的SOAP请求XML和接收到的响应XML写到本地日志文件不直接展示在主界面但排查问题的时候打开日志看一眼就知道请求被设备拒在哪一步。很多时候客户反馈接不上设备你远程把日志文件拉回来几秒钟就能定位是认证问题还是地址问题比自己瞎猜靠谱得多。9. 这个工具后续还能怎么扩展写到这儿基于C#和VS 2015的ONVIF客户端工具的核心内容就全了。但工具的价值往往是在项目迭代中逐渐显现的我列几个我实际加过的扩展方向供你参考。一个是把发现、取流、PTZ、OSD这些能力封装成独立类库为上层业务平台提供统一接口。安防项目很少只需要一个孤立的客户端工具多数情况是需要嵌入到一个大的管理系统里工具前期验证协议可行后面类库直接复用代码不白写。另一个是事件订阅PullPoint/WebHookONVIF的Event模块支持设备主动推送告警事件比如移动侦测、视频丢失、IO报警。把这个模块加上工具就从被动取流预览进化成主动接收报警这在安防项目里的价值非常大。还有一个是设备批量配置能力比如批量修改IP、批量设置时间同步、批量升级固件。这些本质上是调用NetworkInterface配置、SystemReboot、SystemUpdate等接口的批处理流程配合一个Excel任务清单就能变成一个半自动化的交付工具。说到底ONVIF客户端工具的价值就是把一件原来需要登录每台设备Web界面手动操作的事情变成程序化、批量化、可复用的一套工具。如果你正卡在设备接入、协议调试或者客户要求统一管控不同品牌摄像头的需求上希望这篇的源码思路和踩坑记录能帮你省下几天时间。有问题可以留言交流联调中遇到的具体报错发出来我帮你看看。本文还有配套的精品资源点击获取