Video SDK
A video SDK (software development kit) is a package of code you install in an app or backend to add video features without writing them from scratch. Client SDKs run on a device, in a browser, on iOS or Android, or inside a cross-platform framework, and handle playback, uploads, live capture or analytics. Server SDKs wrap a provider's video API in a language such as Node or Python. An SDK runs inside your code; the API it calls runs on the provider's servers.
Video SDK vs. video API
A video API is the contract: HTTP endpoints, request bodies, responses and webhooks. A video SDK is code that implements that contract for one environment. You can always call the API directly with an HTTP client, and many backends do. The SDK saves writing authentication headers, pagination, retries with backoff, typed models for every response and webhook signature checks.
On the client the gap is wider, because the work is not just HTTP. A player SDK has to parse HLS or DASH manifests, run adaptive bitrate logic, handle DRM license requests, manage captions and picture-in-picture, and work with each platform's media stack: AVPlayer on iOS, ExoPlayer (now part of Android's Media3 library) on Android, and Media Source Extensions in browsers. An upload SDK has to split files, track progress and resume after a dropped connection. Those are hard to rebuild for every platform, which is why client SDKs usually matter more than server ones.
What types of video SDKs are there?
Most products end up using several video SDKs, one per job, and they need to agree on what a video is called. Streaming SDKs and calling SDKs are often confused, but they solve different latency problems. The common types:
- Player SDKs play HLS and DASH with adaptive bitrate, captions and DRM.
- Upload SDKs send large files in resumable chunks from browsers and phones.
- Live capture SDKs turn a phone camera into an encoder that publishes over RTMP or SRT.
- Analytics SDKs attach to a player and report startup, rebuffering and errors per view.
- Server SDKs wrap the REST API for backend languages.
- Real-time calling SDKs run two-way WebRTC sessions, a separate category from streaming.
How do you choose a video SDK?
Start with platform coverage. List every surface the product ships on, including smart TVs and cross-platform frameworks such as Flutter or React Native, and check that each SDK exists there and is maintained, not just a community wrapper. Gaps get filled with hand-written code that drifts out of date.
Then check how the SDK sits on the native stack. A mobile player SDK that wraps AVPlayer and Media3 inherits their codec and DRM support and their background-playback behavior; one that ships its own decoder brings its own bugs. Check whether the player is open source, so you can read and patch it, and whether it can be themed without forking. For upload SDKs, test on a throttled network and kill the connection mid-file. For analytics SDKs, check whether they work with players you already use. Finally, confirm that every SDK uses the same asset and playback IDs as the server API, so logs and support tickets line up.
What are common video SDK problems?
Most SDK trouble shows up on real devices, not in the simulator. App size grows when an SDK bundles its own media engine. Older Android versions and low-end phones expose decoder limits, so a stream that offers HEVC renditions has to fall back cleanly to H.264. Smart TV platforms run older browser engines, and a web player that works on desktop can stall on a TV.
Version drift is the slower problem. Mobile apps update on the user's schedule, so several SDK versions run in the field at once, and the server has to stay compatible with all of them. Uploads are another weak point: an uploader that restarts from zero after a network change loses long recordings on mobile data. Analytics gaps hide issues too. If the analytics SDK is separate from the player, it can miss events or report a different session ID, which makes an error hard to trace to a device or CDN.
Which video SDKs does FastPix offer?
FastPix ships an SDK for each layer, all against the same media and playback IDs. On the server, SDKs for Node, Python, Java, Go, Ruby, PHP and .NET wrap the REST API, from asset creation to signing keys for JWT playback tokens. On the client, upload SDKs for web, iOS, Android and Flutter send large files in chunks and resume after a dropped connection. iOS and Android live SDKs publish from a phone camera.
FastPix Player is free and open source, with four platform-native SDKs. The web SDK runs in browsers, smart TVs, set-top boxes and game consoles, with HLS, DASH, DRM and Chromecast in beta. The Android SDK is built on Media3 (ExoPlayer) for phones and Android TV, and the iOS SDK on AVPlayer for iPhone, iPad, tvOS and visionOS, with picture-in-picture. Flutter has its own SDK, and a React Native SDK exists too. On Android, fast start begins playback after 500 ms of buffered media, where Media3's stock default is 1000 ms, and a feed profile starts at 250 ms. Preloading, disk caching and pre-rendering of the next entry's first frame keep swipes free of black screens, and FastPixPlayerPool manages players for reels and carousels. Branding colours, layout, seek preview thumbnails, chapters and a custom domain for video and posters are configurable. Video Data is built into the player, and also runs on 17 player surfaces, including Shaka, hls.js, Video.js, dash.js, ExoPlayer and AVPlayer. Real-time two-way calling is not part of the SDK set, and WebRTC is on the roadmap.
None of the SDKs is sold as a product. Charges come from the usage they create through the API: encoding per source minute, free on Standard up to 4K, storage per rendition-minute and streaming per minute watched. The free plan needs no card.
