Start with the Target Application
Media SDK integration depends on the application shape: Windows desktop, Linux server, Android app, iOS app, macOS tool, .NET client, Qt application, or embedded device. Package format, rendering, permissions, logging, threading, and licensing identity all change by platform.
1. Playback
Confirm protocols such as RTSP, RTMP, and HTTP(S), plus H.264/H.265, software or hardware decoding, render targets, first-frame events, network state, reconnect behavior, low-latency controls, and frame callbacks.
2. Capture
Confirm capture sources: camera, microphone, screen, window, region, media file, still image, or application-provided frames. Test the official demo on the target machine before planning production integration.
3. Publishing
Confirm publishing targets and input sources. StreamCore SDK covers RTMP and RTSP publishing in the standard workflow, with Professional protocol extensions such as SRT.
4. GB28181 and ONVIF
GB28181 is for platform interconnection. StreamCore SDK registers to an upper platform, keeps the session alive, exposes catalog entries, and sends PS/RTP media after INVITE. ONVIF is used for discovery and stream URL resolution rather than as a playback protocol.
5. Logs, State, and Licensing
Production applications should surface runtime logs, error codes, license status, and binding information so field issues can be diagnosed without guessing.
6. Recommended Process
Run the official demo first, replace sample sources with real sources, validate playback and capture, then publishing and GB28181, and only then finalize package and license scope.
Define the Host Boundary First
SDK projects often underestimate the host application boundary. Confirm which process loads the SDK, the target platforms and CPU architecture, UI framework, hardware decoding needs, camera and microphone capture, RTMP/RTSP/SRT publishing, and how logs and error codes are exposed to users.
Correct Use of Demo Projects
Demo projects are not the final product shape. They validate API order, media paths, platform permissions, codec capabilities, and licensing identifiers. Production integration should move playback, capture, publishing, and GB28181 workflows into the customer application modules while preserving logs and error callbacks.
Release Checklist
Before release, validate 32-bit and 64-bit runtime needs, graphics drivers, camera and microphone permissions, install directory permissions, offline license loading, dependency packaging, and recovery after abnormal exit.
Preparation
Confirm platform, language, host application type, and license identity. Native desktop/server packages focus on DLL/SO, headers, import libraries, and runtime dependencies. Android uses AAR, iOS/macOS use XCFramework, and .NET uses NuGet plus native runtime.
Integration Order
Run the official demo first, then integrate the smallest required capability into your own app. Recommended order: runtime and logging, license loading, single playback or capture, callbacks and error handling, then publishing, recording, GB28181, or hardware decoding.
Release Checklist
Before release, confirm SDK package, runtime dependencies, license file, CPU architecture, ABI, and host identity. Demo success does not replace commercial application authorization.
Team Workflow
Record demo validation, target platform packages, license identity, error handling, log paths, and runtime dependencies in the project README so later platform or version changes do not restart the investigation.