I am an amateur C++ developer who is interested in the concept in streaming live video to another computer.
This is a very a simple abstract idea i had on what happens and id like to run it though you guys to see if i got my facts straight.
The way i understand live-streaming is this:
Server sets up UDP server (would be easiest sense its message based instead of constant-connection) (I know there are many other reasons why streaming would use UDP, but parsing data is really my weakness)
- Server reads encoded video data (im not sure how fast it sends, like 1 frame worth of data at a time, etc)
- Server sends to Client
- Client recieves video and decodes
- Client displays video to user.
Is that the basic idea? Or are there more. I wanted to attach a camera to my raspberry pi and just show the live feed to a web browser (which i believe would id have to learn rstp)
First, you need to capture the video with an API like Directshow, AVFoundation, or v4l, depending on your platform.
Next, you need to use a codec to convert raw frames to something you can actually send over a practical network. Raw video data is huge, so a codec is needed to lossy compress that data. At a basic level, codecs will dedupe between frames so that anything not really changing won't be sent for every frame. Codecs are much more advanced than this though, using techniques based on what we actually perceive (prioritizing brightness changes over color changes, for example) to reduce the amount of data needed to be sent. You don't need to write a codec... such a task is not a small undertaking and is very complex. There are many existing codecs to choose from. Platform choice and compatibility will usually give you an option or two.
Now, you need a transport protocol. Most video streaming is actually done over TCP, ensuring a solid not glitchy stream. (UDP packets get reordered all the time, and can be easily lost.) Realtime applications such as video conferencing do often use UDP, as latency there matters much more than a quality stream. It's acceptable to drop frames and have the occasional glitch in a realtime conversation. It's not acceptable to have such glitches in a movie, for example, or even unidirectional live streams where latency doesn't matter much.
The application protocol you use will usually dictate whether or not you're using TCP or UDP. RTSP is an option, and there are many others. However, if want to view the stream in-browser, you either need RTMP with Flash, WebRTC, or an HTTP-based protocol like straight-up HTTP progressive, DASH, or HLS.
DASH and HLS are forms of segmented streaming, which are typically implemented by recording a few seconds and writing static files to disk, where they are served by a normal HTTP server. A manifest or playlist file is used to indicate to the client where all these files are. (You could serve the same resources directly from your application if you wish.)
WebRTC is intended for streaming data and media streams between two clients connected in a peer to peer manner. It is possible to build a server that acts like one of these clients. I don't know of any open source code for doing this in a way that allows you to send media streams. But, it has been done commercially.
HTTP progressive is where you simply stream the output to the client. Not all formats can be streamed this way. MJPEG can work this way. (MJPEG is commonly used by security cameras. It's low quality but easy to implement and will work as-is in most browsers.)
If I were doing this project today, I'd use DASH with VP8 or VP9 for the video codec (depending on compatibility), and Opus for audio. You'll need DASH.js on the client page to facilitate loading DASH segments with Media Source Extensions. This is the most compatible way to get a decent quality stream out.