SDK 集成前先确认目标软件形态
音视频 SDK 的集成难点通常不是“调用一个播放函数”，而是目标软件形态不同：Windows 桌面、Linux 服务端、Android App、iOS App、macOS 工具、.NET 客户端、Qt 程序或嵌入式终端，对包形式、渲染窗口、权限、日志、线程和授权身份的要求都不同。
因此在报价和集成前，应先确认目标平台、CPU 架构、开发语言、UI 框架、发布方式和是否需要离线运行。
1. 播放能力
播放侧要确认协议和输出方式。常见输入包括 RTSP、RTMP、HTTP(S) 网络流。还要确认 H.264/H.265、软解/硬解、渲染窗口、首帧事件、网络状态、断线重连、低延迟参数和截图/帧回调需求。
如果摄像头来自 ONVIF 搜索，ONVIF 解决的是发现和取 RTSP 地址，不应把 ONVIF 当作独立播放协议。
2. 采集能力
采集侧要确认来源：摄像头、麦克风、屏幕、窗口、区域、本地媒体文件、图片或应用主动送入的数据。不同平台的摄像头权限、屏幕录制权限、系统音频能力和 GPU 帧导出方式差异很大，集成前要用 Demo 在目标机器验证。
3. 推流发布
推流侧要确认目标协议和输入源。StreamCore SDK 标准版覆盖 RTMP / RTSP 推流，专业版增加 SRT 等协议能力。输入可以来自本地采集，也可以来自调用方送入的原始帧或编码包。
4. GB28181 与 ONVIF
GB28181 更适合政企、行业平台和国标联网场景。SDK 的 GB28181 方向是向上级平台注册、保活、提供目录，并在收到 INVITE 后发送 PS/RTP 媒体。ONVIF 更适合搜索设备、识别 Profile、获取 RTSP 地址和做基础设备信息处理。
5. 日志、状态和授权
正式商用集成必须把日志、错误码、运行状态、License 状态和授权绑定信息接入自己的产品。这样现场问题出现时，客户界面和日志能解释是网络、协议、码流、权限、授权还是平台环境问题。
6. 集成建议
先跑官方 Demo，再把目标源替换进去；先验证播放和采集，再验证推流和 GB28181；先确认平台包和语言绑定，再确认正式授权。不要在没有真实媒体源和目标机器的情况下只按接口清单判断工作量。
集成前应先固定接口边界
SDK 集成项目最容易低估的是宿主程序边界。需要提前确认 SDK 由哪个进程加载、目标平台和架构、使用哪种 UI 技术栈、是否需要硬件解码、是否需要摄像头和麦克风采集、是否需要 RTMP/RTSP/SRT 推流，以及日志和错误码如何暴露给最终用户。
Demo 的正确用途
Demo 不是最终产品形态，而是用于验证 API 调用顺序、媒体链路、平台权限、编解码能力和授权绑定信息。正式集成时，应把 Demo 中的播放、采集、推流、GB28181 等能力拆到客户软件自己的模块里，并保留日志开关和异常回调。
发布前检查
发布前建议在目标系统上验证 32/64 位、运行库依赖、显卡和驱动、摄像头权限、麦克风权限、安装目录权限、离线授权加载和异常退出恢复。
SDK 集成建议
集成 StreamCore SDK 时，应先按 Demo 的三个方向验证：拉流播放、本地采集推流、GB28181 向上级平台注册。拉流播放主要验证 RTSP、RTMP、HTTP(S) 等网络流和播放器状态回调；本地采集推流验证摄像头、麦克风、屏幕、媒体文件以及 RTMP/RTSP/SRT 目标；GB28181 验证注册、保活、目录、INVITE 应答和 PS/RTP 媒体发送。
进入正式集成前，还需要确认平台包、宿主进程名、包名或 Bundle ID、32/64 位架构、H.264/H.265、硬件解码、日志目录和错误回调。Windows 32 位项目应使用对应架构的 SDK 包和依赖库，不要混用 x64 交付物。