Media Streaming Over Tor Hidden Services

Tor circuits typically deliver 1-10 Mbit/s throughput, significantly below broadband streaming requirements for HD video. Successful media streaming over Tor requires codec and bitrate selection appropriate for these constraints. H.264 video encoded at 500-1000 kbps with AAC audio at 64-128 kbps provides acceptable SD-quality streams within Tor's bandwidth envelope. HLS (HTTP Live Streaming) with short segment durations (2-4 seconds) adapts well to Tor's variable throughput because viewers buffer segments progressively. DASH (Dynamic Adaptive Streaming over HTTP) with multiple quality tiers allows clients to select quality based on available bandwidth. Avoid codecs requiring high-bitrate streams (H.265 at high quality, AV1 for 4K) in initial deployments.

The nginx-rtmp module provides a complete RTMP ingest and HLS output pipeline suitable for Tor hidden service deployment. Install nginx with the rtmp module: apt install libnginx-mod-rtmp. Configure an RTMP application block in nginx.conf: rtmp { server { listen 1935; application live { live on; hls on; hls_path /var/www/stream/hls; hls_fragment 3; } } }. The HLS output files at /var/www/stream/hls are served by the standard HTTP nginx instance listening on 127.0.0.1:8080, routed through the Tor hidden service configuration. Tor Browser can play HLS streams using the HTML5 video element with an HLS.js JavaScript player. Configure the player to use the .onion URL as the stream source.

WebRTC is disabled in Tor Browser's Safer security level to prevent IP leaks through ICE (Interactive Connectivity Establishment) candidates. This means WebRTC-based streaming (used by modern browser-based platforms like Discord video, Jitsi in peer mode) is unavailable to users with standard Tor Browser security settings. For audience members using Safer or Safest security levels, HTTP-based protocols (HLS, DASH, plain HTTP video) work while WebRTC does not. Design your streaming player to use HLS or progressive download as primary transport, with WebRTC as an optional enhancement for users who explicitly enable it at Standard security level.

Audio-only streaming has much lower bandwidth requirements and performs well over Tor. An Icecast2 server serving MP3 or Opus audio streams can be deployed behind a Tor hidden service. Configure Icecast2 to listen on 127.0.0.1 with the Tor hidden service proxying the audio stream port. A 128 kbps MP3 stream uses less bandwidth than most Tor circuits' throughput. Opus codec at 64 kbps provides excellent audio quality at half the bandwidth. Tor Browser can play audio streams directly using the HTML5 audio element with a source pointing to the .onion URL. This approach is practical for privacy-focused radio stations, community broadcasting, or audio content distribution to censored regions.

Privacy-preserving media distribution without CDN dependency requires careful server sizing. A single server handling 1000 concurrent Tor viewers of a 500 kbps stream needs 500 Mbit/s of outbound bandwidth - significant but achievable on dedicated servers with unmetered bandwidth. For larger audiences, distribute streaming infrastructure using multiple .onion-addressed servers. Publish multiple stream URLs with load guidance (Server A handles viewers 1-250, Server B handles 251-500) to distribute load without a centralized load balancer. For recorded content distribution, BitTorrent over Tor provides distributed load - publish a .torrent file at your .onion address and let peer-to-peer distribution handle bandwidth scaling. I2PSnark, Tixati, and qBittorrent support SOCKS5 proxy configuration for Tor-routed torrent traffic.