Originally Posted by TenoBell
Over all your argument is a collection of vague technical jargon with very little substance that clearly explains why RTSP is so much better than HTTP.
That sounds quite petty for someone who seems so knowledgeable. RTSP runs over UDP to start with, no need to send useless acknowledgments like HTTP requires (HTTP rides over TCP, the real time nature of streaming makes UDP much more suitable because if a packet is lost, you don't really care, it's real time, if the information is lost, you simply move on). But RTSP is just a piece of the puzzle. The brilliant part is RTCP, RTSP's out of band buddy, which controls everything, and helps adapt bitrate and framerate in real time (both RTCP and RTSP sessions are opened when using RTSP). HTTP simply can't do that, the only thing it does is "download a chunk then play, if everything OK then download another chunk then play" and so on. Real time and HTTP are by essence contradictory. From wikipedia (I would assume most people can understand wikipedia's simple description):
RTCP provides out-of-band statistics and control information for an RTP flow. It partners RTP in the delivery and packaging of multimedia data, but does not transport any media streams itself. The primary function of RTCP is to provide feedback on the quality of service (QoS) in media distribution by periodically sending statistics information to participants in a streaming multimedia session. RTCP gathers statistics for a media connection and information such as transmitted octet and packet counts, lost packet counts, jitter, and round-trip delay time. An application may use this information to control quality of service parameters, perhaps by limiting flow, or using a different codec.
The RTSP protocol has similarities to HTTP, but RTSP adds new requests. While HTTP is stateless, RTSP is a stateful protocol. A session identifier is used to keep track of sessions when needed; thus, no permanent TCP connection is needed.