Building Strydebike: Video Processing and Streaming at Scale with AWS and React Native

# Building Strydebike: Video Processing and Streaming at Scale with AWS and React Native

Strydebike brings instructor-led indoor cycling to users wherever they ride. Behind the slick mobile experience lies a video pipeline engineered for reliability, rights protection, and global delivery — all running on AWS. Here's how we illuminated that complexity.

The Streaming Challenge

Fitness content is demanding. Users expect crisp 1080p playback with zero buffering while sweating through an interval — on spotty gym WiFi or mobile data. Meanwhile, content owners need ironclad protection for their video assets and the music pumping through every class.

Three core requirements drove the architecture:

• Low-latency adaptive streaming — No one waits for buffering mid-sprint
• Rights-protected delivery — DRM enforcement across every device
• Licensing compliance — Every track in every video accounted for

Video Processing Pipeline

Ingestion and Encoding

Content starts as high-bitrate recordings from studio cameras. Rather than chaining together brittle open-source tools, we built the processing pipeline on AWS Elemental MediaConvert.

Studio Recording
  → S3 Upload (raw ProRes/DNxHD)
    → MediaConvert Job (multi-bitrate H.264/H.265)
      → S3 Output (HLS + DASH manifests)
        → CloudFront CDN

MediaConvert handles the heavy lifting: input validation, frame-rate normalization, audio normalization (LUFS for consistent volume across classes), and renditions from 360p to 1080p. Every encoding job triggers a Lambda that updates the content catalog in DynamoDB and notifies the app CDN layers.

Thumbnail and Preview Generation

Users browse classes by scrolling through preview tiles. We generate sprite sheets and animated previews using AWS Elemental MediaConvert's thumbnail generation combined with a lightweight Lambda orchestrator that stitches frame captures into WebP sprites for the React Native client.

Streaming Delivery Architecture

Adaptive Bitrate (ABR) with CloudFront

We serve HLS streams through CloudFront with regional edge caching. The ABR ladder adjusts dynamically:

The React Native player (built on react-native-video with custom HLS extensions) monitors buffer health and switches renditions before the user notices degradation. We track playback metrics — stall rate, average bitrate, start-up time — through CloudWatch and feed anomalies into our alerting pipeline.

Video Rights Protection

Content theft is an existential risk for fitness platforms. Our approach layers multiple protections:

DRM Enforcement

We use AWS Elemental MediaPackage with SPEKE (Secure Packager and Encoder Key Exchange) to integrate with a third-party DRM provider. Every HLS segment is AES-128 encrypted, with key rotation every few minutes. Playback tokens are short-lived JWTs validated by a Lambda@Edge function at the CDN layer, ensuring only authenticated app instances can retrieve decryption keys.

Watermarking

Each video stream carries a session-bound forensic watermark. If a user screen-captures and redistributes content, the watermark identifies the originating account — a deterrent that matters.

Offline Viewing Controls

Downloaded classes for offline use are encrypted at rest with device-bound keys via React Native's secure storage APIs. Classes expire based on subscription status, and the app phones home periodically to validate entitlements.

Music Licensing Compliance

Music drives indoor cycling. But every track requires synchronization and mechanical licenses — and rights societies audit platforms aggressively.

We built a music asset registry that ties every track in every video to its ISRC (International Standard Recording Code), publisher, and license metadata. During video upload, MediaConvert extracts the audio fingerprint, matches it against the registry, and flags any unregistered tracks before publication.

This pre-publication gate prevents exactly the kind of licensing dispute that can result in takedown notices or worse.

React Native: One Codebase, Two Platforms

The Strydebike app targets iOS and Android from a single React Native codebase. Key decisions:

• Native modules for video — react-native-video with platform-specific DRM bridges
• App State management — Zustand for predictable, testable state with minimal boilerplate
• Offline-first architecture — WatermelonDB for local persistence, syncing with DynamoDB when connectivity returns
• Cast support — Chromecast and AirPlay via native SDK bridges, letting users throw classes to big screens

The result: a fitness app that feels native on both platforms, with a shared video pipeline and a consistent streaming experience.

Lessons Learned

1. MediaConvert is worth the cost — Rolling your own FFmpeg cluster saves pennies and costs weeks of debugging edge cases
2. DRM planning starts on day one — Retrofitting encryption into an existing pipeline is painful
3. License metadata is product infrastructure — Treat it with the same rigor as your database schema
4. ABR monitoring pays for itself — A 2% stall rate improvement directly impacts retention

Building a video-first fitness product is as much about the invisible infrastructure as the visible experience. When the infrastructure is invisible, you've done it right.

---

Building a video streaming product? Let's illuminate the path forward.