14. Service Patterns
This document explains the two primary architectural patterns used in docker-rtmp-multistream for handling RTMP streams to different platforms.
14.1 Pattern Comparison
Choose the appropriate pattern for your service:
| Simple Relay | Transformer | |
|---|---|---|
| Use for | Services that accept streams as-is (e.g., YouTube) | Services requiring specific encoding (e.g., Twitch non-partner mode) |
| How it works | Stream forwarded directly without modification | Two-stage pipeline with FFmpeg transformation |
| Pros | No decoding or encoding, so little CPU use and the original quality is preserved | Per-service quality control, downscaling for bandwidth limits |
| Cons | No per-service quality control | Decodes and re-encodes every frame: CPU use scales with TWITCH_HEIGHT, TWITCH_FPS and TWITCH_X264_PRESET. Encoding adds delay before the stream reaches the service. |
| Example | YouTube service | Twitch service in non-partner mode (720p60 downscaling) |
Advanced: Conditional Patterns
Services can support both patterns based on configuration. The Twitch service implements a conditional pattern: partners use simple relay (TWITCH_PARTNER=TRUE), non-partners use transformer mode. See Twitch implementation for an advanced example.
14.2 Implementation Examples
14.2.1 Simple Relay (YouTube)
- Config:
apps/youtube.conf - Script:
90_configure_youtube.sh - Docs: YouTube Configuration
14.2.2 Transformer (Twitch)
- Transformer:
transformers/twitch.conf - App:
apps/twitch.conf - Script:
90_configure_twitch.sh - Docs: Twitch Configuration
14.3 See Also
- Architecture Overview - Detailed technical implementation
- Add a Streaming Service - Step-by-step implementation guide
- Service Contract Reference - Rules for includes, placeholders and scripts