Free Video Hosting

Introduction

This is a practical, hands‑on guide to choosing and implementing free-video-hosting for live and VOD use cases. It maps common, real-world options to clear next steps, gives runnable commands and configuration snippets, and explains trade‑offs so you can convert a decision into a working pipeline quickly. For this workflow, teams usually combine Paywall & access, 24/7 streaming channels, and Ingest & route. If you need a step by step follow-up, read Video Sharing Platforms: Practical Evaluation and Deployment Guide. If you need a step by step follow-up, read Upload Video.

If your priority is Low latency live video streaming via SRT for contribution from the field, read the sections on SRT gateways and the ffmpeg examples — browsers don’t play SRT directly, so the usual pattern is SRT for contribution and HLS/RTMP/WebRTC for distribution.

Decisions: pick the right hosting path

Choose a path based on audience, control, latency and operational willingness:

• Public reach, zero infra effort (best immediate conversion): Use YouTube Live / Twitch / Facebook Live. Ingest via RTMP, minimal ops, built‑in CDN and player. Trade‑offs: platform policies, ads/branding, limited control, typical player latency 10–30s.
• Private or brandable player with small audience: Self‑host Nginx‑RTMP or PeerTube on a small VPS and serve HLS. You run the server and player; you pay for egress once you scale. Good for custom UX and basic analytics.
• Field contribution with unreliable networks (recommended for remote production): Use SRT from camera/encoder into an SRT gateway (self‑hosted or managed). Then transcode or restream to HLS/RTMP/WebRTC for playback. This is the pattern for reliable, low‑loss contribution.
• Ultra low latency interactive (<1s): Use WebRTC or managed low‑latency platforms. This usually requires more infra or a paid service (SFU/turns/latency‑optimized CDN).

Which product aligns to each path (quick mapping):

• Public: YouTube Live, Twitch, Facebook Live.
• Self‑host basic: Nginx‑RTMP + HLS, PeerTube for federated hosting.
• SRT gateways / managed: srt-live-transmit (SRT project tools), ffmpeg (SRT support), managed vendors (Wowza / Haivision / other commercial providers) if you outgrow DIY.
• Low‑latency playback: Ant Media / mediasoup / Janus (self‑hosted or paid managed offerings).

Practical configurations — runnable examples

1) Quick public streaming (YouTube / Twitch) — RTMP with OBS

Steps:

1. Create the channel and get the RTMP URL and stream key from the platform.
2. In OBS (or any encoder), set output: keyframe interval 2s (2 seconds), encoder: x264 or hardware (NVENC/QuickSync), rate control: CBR for RTMP to consumer platforms.

Recommended encoder settings (starter):

• 720p30: 2,500–4,000 kbps video, 128 kbps audio
• 1080p30: 4,500–6,000 kbps video, 128–160 kbps audio
• Keyframe interval: 2s; Profile: main; Tune: zerolatency (if available)

2) SRT contribution pipeline (field encoder → SRT gateway → distribution)

Pattern: encoder uses SRT to push to an SRT listener you control (on a small cloud VM). The listener forwards to a CDN/RTMP or transcodes to HLS or WebRTC for viewers.

Send (encoder → gateway) example using ffmpeg:

ffmpeg -re -i input.mp4 \
  -c:v libx264 -preset veryfast -tune zerolatency -b:v 2500k -maxrate 2500k -bufsize 5000k \
  -g 50 -keyint_min 50 \
  -c:a aac -b:a 128k -ar 48000 \
  -f mpegts "srt://srt.example.com:6000?pkt_size=1316&latency=200"

Run an SRT listener that forwards to YouTube RTMP:

ffmpeg -i "srt://:6000?listen=1&latency=200" \
  -c:v copy -c:a copy -f flv "rtmp://a.rtmp.youtube.com/live2/YOUR_STREAM_KEY"

Notes:

• Use -c copy only if incoming is H.264/AAC. Otherwise transcode.
• latency=200 sets receiver buffer in ms; raise it on noisy networks, lower it for tighter latency.
• SRT is for contribution. Convert to HLS/WebRTC/RTMP for browser playback.

3) SRT → HLS (serve with Nginx web server)

Create an HLS stream on the SRT gateway (example):

ffmpeg -i "srt://:6000?listen=1" \
  -c:v libx264 -preset veryfast -b:v 2500k -g 50 -sc_threshold 0 \
  -c:a aac -b:a 128k \
  -hls_time 2 -hls_list_size 6 -hls_flags delete_segments+append_list \
  /var/www/html/hls/stream.m3u8

Minimal Nginx‑RTMP + HTTP config to serve HLS (nginx.conf snippets):

rtmp {
    server {
        listen 1935;
        chunk_size 4096;
        application live {
            live on;
            record off;
            hls on;
            hls_path /var/www/html/hls;
            hls_fragment 2s;
            hls_playlist_length 10s;
        }
    }
}
http {
    server {
        listen 80;
        location /hls {
            types {
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }
            root /var/www/html;
            add_header Cache-Control no-cache;
        }
    }
}

Reminder: nginx‑rtmp module does not accept SRT; use ffmpeg to receive SRT and push to nginx or write HLS files into nginx hls_path.

4) Local debugging and tests

• Generate a test pattern and push to an SRT listener:
  

  ffmpeg -f lavfi -i testsrc=size=1280x720:rate=30 -f lavfi -i sine=frequency=1000 \
        -c:v libx264 -preset ultrafast -tune zerolatency -b:v 1500k -c:a aac -b:a 64k \
        "srt://srt.example.com:6000?pkt_size=1316"

• Check incoming streams: ffprobe -v error -show_streams "srt://:6000?listen=1"
• Port test: ensure UDP/TCP ports are open on VM firewall and cloud security groups (SRT uses UDP by default).

Trade‑offs and practical limits

• Free platforms vs control: YouTube/Twitch remove infra work and cost but limit branding, custom players, and policies. Self‑hosting gives control but you own reliability and egress costs.
• Latency vs stability: Lower latency needs smaller buffers and/or WebRTC; that increases sensitivity to packet loss and requires more operational work (TURN servers, SFU, transcoding).
• SRT role: SRT excels for contribution (resilient over bad networks). It is not a browser playback protocol; you must convert to HLS/WebRTC/RTMP for viewers.
• Scaling: A single small VPS can accept a few concurrent SRT inputs and restream to a small audience. For hundreds-thousands of viewers, you need a CDN (paid) or a managed platform.
• Costs hidden in “free”: cloud egress, high‑CPU instances for transcoding, and operational time. “Free” hosting often shifts cost to constraints or removal of features.

Common mistakes and how to fix them

• No connect / SRT fails: Firewall/NAT blocking UDP port. Fix: open port in cloud security group and server firewall; verify listen=1 on the receiver; test with local ffmpeg producer and receiver.
• Black video or no video: Codec mismatch or illegal profile. Fix: ensure H.264 (baseline/main) and AAC; test with ffprobe, or re-encode with compatible codec flags (-c:v libx264 -profile:v main).
• Audio missing: Encoder didn’t include audio codec acceptable to the player. Fix: use AAC -c:a aac -b:a 128k.
• High CPU on host: Using slow presets or software encode. Fix: use hardware encode (NVENC / QuickSync) or raise instance type; reduce resolution/bitrate for the contributor stream.
• Excessive latency: Small segment sizes, large buffers. Fix: reduce HLS segment length, tune SRT latency parameter, or move to WebRTC for sub‑second needs.
• Playback not starting in browser: CORS or wrong MIME. Fix: set add_header Access-Control-Allow-Origin * and correct MIME mappings for m3u8/ts.

Next step

Pick one of the short, decisive actions below and run it now — small wins move you from research to production.

1. Immediate public stream: Create a YouTube/Twitch channel, copy the RTMP URL + key, open OBS and paste the server/key. Use 720p30 at 2.5–4 Mbps and keyframe 2s. Start the stream and verify playback on the platform.
2. Test SRT contribution (if you need reliability from the field): On a cloud VM install ffmpeg, run the listener:

   ffmpeg -i "srt://:6000?listen=1&latency=200" -c copy -f flv rtmp://a.rtmp.youtube.com/live2/YOUR_KEY

   Then run a local ffmpeg push (or configure OBS to push SRT if supported) to the gateway and verify the chain works end‑to‑end.
3. Self‑host a basic HLS test: Deploy nginx + nginx‑rtmp on a small VPS, deploy the example ffmpeg HLS command above, and open the generated M3U8 in a browser or hls.js player.
4. If you need help or expect scale: Decide whether you want to (A) hire a streaming engineer to set up a resilient SRT gateway + CDN pipeline, or (B) trial a managed vendor that supports SRT ingest and low‑latency playback. Use the product mapping above to shortlist candidates.

Want the minimal shell script or Docker Compose to deploy an SRT gateway + ffmpeg restreamer that you can run on a small VPS? Reply with which cloud provider you prefer and the target distribution (YouTube / HLS / WebRTC) and I’ll provide a tested deployment script tailored to that stack.