Demo 的作用
StreamCore SDK Demo 用于在正式集成前验证 API、媒体链路和目标机器环境。它不是生产授权，也不应把 Demo 授权复制到其他应用中使用。Demo 验证范围应覆盖播放、采集、推流、GB28181、日志和错误回调。
桌面端可重点看 Qt Demo 的播放、推流和 GB28181 页面；移动端可重点看 Android 采集、播放和发布链路；.NET 示例用于验证 C# 包装层和 Windows 客户端集成方式。
在 Windows Qt Demo 中验证 Processor
打开“AI 特效接入演示”，选摄像头或本地视频，先选内置黑白效果。即使没有 AI 特效扩展包，也能从“处理前 / 处理后”两个画面确认帧已经过 Processor；需要验证输出时，再填写可用的 RTMP 地址并勾选推流。建议把接收端画面与处理后预览对照，避免只看本地窗口就认定推流也应用了效果。
美颜、换脸和身形调整由独立扩展包提供，不随 SDK 或公开 Demo 默认附带；需要在 Qt Demo 中体验时可从产品页的演示说明了解获取方式和适用范围。下图是装入效果包后的美颜页面，展示的是一次演示画面，不代表不同摄像头、光线或人物都会得到相同效果。
点击截图可查看原尺寸。
如果要将自己的算法接入产品，继续阅读集成前核对清单和交付文档中的“Capture Processor 实时算法接入”。Demo 里能看到效果，只证明这条演示链路在当前机器上运行；自有应用仍需验证线程、帧所有权、处理耗时及授权。
建议验证顺序
建议依次验证三个方向：播放，包括 RTSP / RTMP / HTTP(S)、软解 / 硬解、低延迟参数、错误状态和日志；采集推流，包括摄像头、麦克风、屏幕、媒体文件及 RTMP / RTSP / SRT 目标；GB28181，包括注册、保活、目录、INVITE 应答和媒体发送。
验证通过后，再按正式发布平台申请商业授权，并确认宿主进程名、包名、Bundle ID、平台架构和版本维护范围。
建议保留的测试记录
集成团队在评估时应记录平台、架构、SDK 版本、Demo 版本、测试流、推流目标、首帧时间、CPU/GPU 占用、错误日志和授权状态。后续进入正式项目时，这些记录比单纯截图更有助于判断是否需要标准版、专业版或定制支持。
不同角色看什么
客户端开发人员通常关注 API 调用、回调状态、渲染窗口和错误码；项目负责人更关心目标平台是否覆盖、Demo 授权边界是否清楚、正式授权需要哪些绑定信息；测试人员则需要记录码流、分辨率、编码格式、首帧时间和长时间运行结果。把这些问题在 Demo 阶段分开验证，能减少正式集成后的返工。
如果项目同时包含桌面端和移动端，不建议只看一个平台的演示效果。桌面端适合验证推流、播放参数、低延迟和 GB28181；移动端适合验证系统权限、相机采集、后台切换和包名绑定；服务端或 .NET 示例适合确认部署依赖和进程绑定。