HLS streaming from a mobile device is not trivial. The phone acts as a source: it captures video in segments, uploads them to an HTTP server, and updates the m3u8 playlist. Unlike HLS playback, here it is important to ensure stable capture, fast packaging into TS, and reliable upload. We implement such projects turnkey: from protocol selection to CDN integration. Below we break down the technical details.
How HLS-push from a device works
The classic scheme: phone → HTTP PUT/POST TS segments + update .m3u8 → origin HTTP server → CDN → viewers. Alternative: phone → RTMP → media server → HLS for viewers (then HLS is generated by the server, not the phone). Direct HLS-push is supported by: Apple Media Stream Segmenter (macOS only), CloudFront with WebDAV, Akamai Media Services, and a custom nginx with ngx_http_dav_module. We prefer a customizable origin server because it gives full control over latency and segment format.
Comparison of approaches on iOS and Android
| Platform | Tool | Encoder | Segment Format | Reliability | Latency |
|---|---|---|---|---|---|
| iOS | FFmpegKit (h264_videotoolbox) | Hardware H.264 | MPEG-TS | High | 6–30 s (standard) / 2–4 s (LL-HLS via server) |
| iOS | Custom TS segmenter | Hardware H.264 | MPEG-TS (manual PES/PMT) | Medium (packaging errors) | Similar |
| Android | FFmpegKit (h264_mediacodec) | Hardware H.264 | MPEG-TS or fMP4 | High | 6–30 s |
| Android | MediaMuxer with fMP4 | Hardware H.264 | fMP4 (HLS v7+) | Low (non-standard) | Higher due to buffering |
Why choose direct HLS-push over RTMP?
RTMP is a protocol with a persistent connection, requiring a relay server (e.g., Nginx-RTMP). This adds an extra hop and increases latency. Direct HLS-push works over HTTP, allowing direct upload of segments to CDN (Akamai, CloudFront). The downside is that it requires smarter client code for TS packaging and uploading. Our experience shows that for live streams with up to 10,000 viewers, HLS-push works more stably and cheaper than RTMP+CDN. Infrastructure savings can reach 30–40%.
How to implement HLS streaming on iOS?
iOS has no built-in HLS encoder for live—only AVAssetExportSession for files. For live HLS we build the pipeline manually:
AVCaptureSession → AVCaptureVideoDataOutput → VideoToolbox (encode H.264) → accumulate NAL units into TS segments of 2–4 seconds → URLSession.uploadTask to server → update m3u8 manifest Assembling MPEG-TS from NAL units requires manual packaging of PES packets with PAT/PMT tables. There is no ready-made library in Swift. Therefore, in practice we use FFmpegKit:
-f avfoundation -i 0:0 -c:v h264_videotoolbox -b:v 2M -hls_time 2 -hls_list_size 5 -hls_flags delete_segments -method PUT http://origin/stream/index.m3u8 h264_videotoolbox is the hardware encoder. The flag -method PUT uploads segments and the playlist to the server. It works with moderate CPU load.
What is Low-Latency HLS and when is it needed?
Standard HLS has 6–30 seconds of latency. LL-HLS reduces it to 2–4 seconds using EXT-X-PART directives (introduced by Apple at WWDC). Generating LL-HLS parts (0.2–0.5 s duration) from a mobile device is extremely difficult without a specialized encoder. A more practical approach: the device pushes RTMP with a small buffer, and the media server (Nimble Streamer, Wowza) with an LL-HLS plugin generates the stream for viewers. This is a proven solution that we recommend if latency is critical.
Comparison of schemes: direct HLS-push vs RTMP+server
| Criterion | Direct HLS-push | RTMP + media server |
|---|---|---|
| Latency | 6–30 s (standard) | 8–35 s (including relay) |
| Infrastructure | Origin HTTP server | RTMP server (Nginx-RTMP, Wowza) |
| Client complexity | High (segmentation) | Medium (RTMP pushing) |
| CDN integration | Direct (PUT requests) | Via relay server |
| Fault tolerance | High (HTTP easier to cache) | Medium (RTMP connection must be persistent) |
What is included in turnkey HLS streaming implementation
- Requirements analysis: bitrate, resolution, target audience, CDN.
- Scheme selection: direct HLS-push or RTMP → server.
- Client app development: iOS (Swift + FFmpegKit) or Android (Kotlin + FFmpegKit).
- Origin server setup: nginx with DAV module or third-party CDN (Akamai, CloudFront).
- Testing: load testing, latency checks, stability under weak signal.
- Documentation and training: integration description, provisioning profile setup for push notifications and background tasks.
Apple HLS Authoring Specification
More about origin server setup
To set up an origin server, we often use nginx with the ngx_http_dav_module. The configuration allows accepting PUT requests from the device and serving TS segments and the m3u8 playlist. Example location block: /stream { dav_methods PUT; dav_access user:rw group:rw; }Work process
- Analysis: determine protocol, required latency, server storage capacity.
- Design: pipeline scheme (capture → encode → segment → upload → manifest).
- Implementation: write code in Swift/Kotlin, integrate FFmpegKit.
- Testing: on real devices (iPhone 12, Pixel 6) with different bitrates and networks.
- Deployment: publish to App Store / Google Play, server setup, monitoring.
Estimated timelines
Implementation via FFmpegKit with upload to origin: from 2 to 3 days. Custom TS segmenter and LL-HLS: from 1 to 2 weeks. Exact timelines depend on integration complexity (number of bitrates, background streaming support).
Typical mistakes and how to avoid them
- Ignoring Push Notifications: for HLS-push in the background, properly configure
Background Modes(iOS) andForeground Service(Android). - Incorrect segment timing: segments longer than 6 seconds increase latency and the risk of viewer-side interruption.
- Lack of upload error handling: HTTP 4xx/5xx should trigger segment retransmission with exponential backoff.
- Neglecting PAT/PMT tables: in manual TS assembly, any error makes the stream unreadable for players.
Our experience: 5+ years in mobile streaming and over 10 completed projects. Get a consultation to evaluate your project. Contact us—we will analyze your requirements for free and propose the optimal HLS streaming architecture from a mobile device. We guarantee stable operation and compliance with App Store Review Guidelines (iOS) and Google Play policies.