Demo 的作用
StreamCore SDK Demo 用于在正式集成前验证 API、媒体链路和目标机器环境。它不是生产授权，也不应把 Demo 授权复制到其他应用中使用。用户应通过 Demo 先确认播放、采集、推流、GB28181、日志和错误回调是否满足项目需求。
桌面端可重点看 Qt Demo 的播放、推流和 GB28181 页面；移动端可重点看 Android 采集、播放和发布链路；.NET 示例用于验证 C# 包装层和 Windows 客户端集成方式。
建议验证顺序
先验证播放：RTSP / RTMP / HTTP(S)、软解 / 硬解、低延迟参数、错误状态和日志。再验证采集推流：摄像头、麦克风、屏幕、媒体文件、RTMP / RTSP / SRT 目标。最后验证 GB28181：注册、保活、目录、INVITE 应答和媒体发送。
验证通过后，再按正式发布平台申请商业授权，并确认宿主进程名、包名、Bundle ID、平台架构和版本维护范围。
Demo 不只是演示界面
StreamCore SDK Demo 的重点是验证真实集成路径。桌面 Qt Demo 可用于查看播放、采集、推流和 GB28181 工作流；Android Demo 可用于验证移动端相机采集、播放、推流和包名授权；iOS / macOS Demo 更关注 Bundle ID、XCFramework 集成和系统权限；.NET Demo 适合验证 C# 应用加载 native 依赖、渲染和错误回调。
Demo 授权只用于官方 Demo，不应被复制到客户正式进程或其他 App 中使用。正式授权需要按实际宿主进程名、包名、Bundle ID 或合同约定的绑定信息申请。这样能让评估阶段低摩擦，同时保证商用交付边界清楚。
建议保留的测试记录
集成团队在评估时应记录平台、架构、SDK 版本、Demo 版本、测试流、推流目标、首帧时间、CPU/GPU 占用、错误日志和授权状态。后续进入正式项目时，这些记录比单纯截图更有助于判断是否需要标准版、专业版或定制支持。
不同角色看什么
客户端开发人员通常先看 API 调用、回调状态、渲染窗口和错误码；项目负责人更关心目标平台是否覆盖、Demo 授权边界是否清楚、正式授权需要哪些绑定信息；测试人员则需要记录码流、分辨率、编码格式、首帧时间和长时间运行结果。把这些问题在 Demo 阶段分开验证，能减少正式集成后的返工。
如果项目同时包含桌面端和移动端，不建议只看一个平台的演示效果。桌面端适合验证推流、播放参数、低延迟和 GB28181；移动端适合验证系统权限、相机采集、后台切换和包名绑定；服务端或 .NET 示例适合确认部署依赖和进程绑定。