Microsoft Smooth Streaming (Silverlight, 2008).Adobe HTTP Dynamic Streaming (HDS, 2010-ish).MPEG Dynamic Adaptive Streaming over HTTP (DASH, 2011).However, not all connections were equal, and HTTP is stateless.ģ gorillas developed different technologies based on the idea of Adaptive Bitrate Streaming: With the increase in available bandwidth, and increasingly effective compression algorithms (codecs), HTTP became viable again as a transport protocol for extremely large files. It eventually mutated into an SSL version (RTMPS), an encrypted DRM version (RTMPE), a tunnel version for NAT traversal (RTMPT), and a UDP variant ( Real-time Media Flow Protocol, RTMFP).Īround the same time, competitors and innovators sprung up. It was slightly similar to MPEG transport, with different channels to handle different data types, such as Flash Video and Action Message Format (AMF: ) for binary data. 2002 bought along Macromedia's Real-time Messaging Protocol (RTMP: ) for audio, video, and data.
It wasn't long before the funky animation plugin transformed into a suite of products which offered functionality on the backend. An example PLAY request looked like this: C->S: PLAY rtsp:///media.mp4 RTSP/1.0 The theory was fairly simple: it worked as stateful protocol on port 554 over TCP, and was a control layer on top of Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP). In the old 90s days of POTS modems, RealNetworks pioneered the Real-time Streaming Protocol (RTSP: more: ) as a specialist alternative to HTTP then produced RealServer, which morphed into Helix Server ( (multimedia_project). How do we mutate to that from what we know about an HTTP web application?įirst, some streaming history. It's an arbitrary number as usually only 5% of your users are on simultaneously. Let's say we need to create 10,000 video streaming servers which can read static files from their origin (with unlimited bandwidth), but also host live services which record to disk. We all know how Peering ( ) and CDNs ( ) work. We all know the high-availability architecture for web applications using load balancers. To be honest, it's never been easy the problem has merely moved location: from the pipe, to the server farm. If you want to spin up a service like Netflix or Youtube, it's easier because of the technologies available, but it's tougher because of the scale.
If it wasn't the client CPU speed and bad codecs, it was the ISP bandwidth, or the server capacity.
It used to be hours of tedious work, combined with expensive proprietary licenses for single-server software desperately straining a CDN.