[As Apple sees it the] biggest issue with RTSP is that the protocol or its necessary ports may be blocked by routers or firewall settings, preventing a device from accessing the stream. As the standard protocol for the Web, though, HTTP is generally accessible. Furthermore, no special server is required other than a standard HTTP server, which is more widely supported in content distribution networks, and more expertise in optimizing HTTP delivery is generally available than for RTSP.
Enter HTTP Live Streaming. The basic mechanics involve using software on the server to break an MPEG-2 transport stream into small chunks saved as separate files, and an extension to the .m3u playlist specification (.m3u8) to tell the client where to get the files that make up the complete stream. The media player client merely downloads and plays the small chunks in the order specified in the playlist, and in the case of a live stream, periodically refreshes the playlist to see if there have been any new chunks added to the stream.
This is in contrast to real-time streaming, as there would necessarily be a minimum latency of whatever duration the server slices the stream into (Apple refers to 10 seconds as an example). As the server encodes the video and slices it into 10 second clips, for instance, it creates or updates a playlist for the stream with the URL of the next clip. The client begins by downloading one or more of the clips, playing them in order. As one clip plays, the client begins downloading the next specified clip until it reaches a tag in the playlist that signals the end of the stream.null
Good luck with that.
