So I'm a software engineer trying to understand some nitty gritty details about how streaming media works. I've spent the lion's share of the day trying to understand the various codecs, container formats and streaming protocols that are pertinent to my application. So far, here is my understanding of how it works, which could very well be misled:
- Streaming media really boils down to container format and streaming protocol:
- All the audio data is encoded (via audio codec) into an audio bitstream
- All the video data is encoded (again, via codec) into a video bitstream
- The two streams are merged (multiplexed?) together into a container which ultimately becomes a file (such as MP4, etc.)
- A special media server then serves this container (MP4 file, or some other format) to a client (perhaps an HTML5 Video player running inside someone's browser) via some standard streaming protocol, such as RTSP
- In the case of a browser client, I assume the browser itself has an RTSP client that it then somehow presents to the users HTML5 Video Player
- I could host an MP4 file from a web server, such as nginx or httpd, but since those servers aren't RTSP servers, would only be able to treat requests for the MP4 as download requests, and thus, would be unable to stream the media files
- Likewise, if I were to use
curl
to fetch the files from an nginx server, since neithercurl
nor nginx speak RTSP, it would be treated as a file download
- Likewise, if I were to use
- But, when I host an MP4 file from a streaming media server (VideoLAN, Red5, Wowza, etc.), and I use an RTSP client (or any supported streaming media client) to request a stream from that server, that then and only then does any actual streaming occur
- Hence even though YouTube or Vimeo "videos" are hosted on HTML pages served over HTTP(S) by HTTP servers, I assume that the embedded video players on those pages (which are where the videos actually play out of) are actually starting a second, subsequent connection to a streaming server, and streaming is occurring over RTSP or some other non-HTTP protocol
So that's my understanding, and I guess I'd first ask that if anything I've stated above is incorrect, please begin by correcting me! Assuming I'm more or less correct:
How do streaming media players, running inside HTML pages and served by HTML servers, establish streaming (RTSP, etc.) connections with streaming media servers (serving RTSP requests)?
Best Answer
Common Applications
RTSP currently seems to be used more with applications/device interfaces that directly live stream (e.g. IP camera) or re-stream (like an engine) than it is for streaming saved media files from a physical location via an HTTP web playback interface with an embedded player.
It seems that RTSP is a stateful protocol and it uses UDP more than TCP when streaming, and it's used more as a server device (like an IP camera) that is connected to a TCP/IP network, and feeds out streams via UDP, etc. You then connect to these feeds (the server) as the client on the same network and you can issue RTSP requests to utilize accordingly.
Logical Flow
The way I understand the flow of streaming media in this form is:
Please see the Streaming Technologies section below for a general comparison of HTTP versus RTSP.
Furthermore
In the below 10 Reasons Why You Should Never Host Your Own Videos section I've quoted the parts that get to the point to help answer your question in "general" without being too specific.
Essentially it says that the website that has the embedded media player controls will: