Streaming Media From Inside HTML Pages, by Example

rtspstreamingvideo streamingvlc-media-player

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 neither curl nor nginx speak RTSP, it would be treated as a file download
  • 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

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)?

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.


Protocol directives

While similar in some ways to HTTP, RTSP defines control sequences useful in controlling multimedia playback. While HTTP is stateless, RTSP has state; an identifier is used when needed to track concurrent sessions. Like HTTP, RTSP uses TCP to maintain an end-to-end connection and, while most RTSP control messages are sent by the client to the server, some commands travel in the other direction (i.e. from server to client).

Presented here are the basic RTSP requests. Some typical HTTP requests, like the OPTIONS request, are also available. The default transport layer port number is 554[3] for both TCP and UDP, the latter being rarely used for the control requests.

source


Stateless

A stateless protocol does not require the server to retain session information or status about each communications partner for the duration of multiple requests. In contrast, a protocol which requires keeping of the internal state on the server is known as a stateful protocol.

A disadvantage of statelessness is that it may be necessary to include additional information in every request, and this extra information will need to be interpreted by the server.

source


Logical Flow

The way I understand the flow of streaming media in this form is:

  • the server where the media content resides will encapsulate, compress, encode, etc. the video/audio data content in the proper formats and segments for stream delivery
  • the web server that listens for connections to access the streaming media will deliver all resources needed to stream the media
  • the client requests and downloads applicable resources and files, and then assembles them in a continuous fashion for playback via the URL pointer as configured and other parameters. The playback software at the client level assembles the packets transmitted in sequence to allow proper playback of the content.

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:

  • (1)detect the client web browser settings upon "connection and request" from the client and
  • (2)this will set the codec and any other client side detection settings to applicable parameter values, and then
  • (3)it'll stream the video directly from the streaming server you host the video and audio files on based on further code in your embedded media player configurations pointing to the URL of the media file on the hosted server.

Streaming Technologies

The client browser must receive the data from the server and pass it to the streaming application for processing. The streaming application converts the data into pictures and sounds. An important factor in the success of this process is the ability of the client to receive data faster that the application can display the information. Excess data is stored in a buffer – an area of memory reserved for data storage within the application. If the data is delayed in transfer between the two systems, the buffer empties and the presentation of the material will not be smooth.

HTTP Protocol

The HTTP is the predominant way in which documents are linked on the Internet. The client makes a connection to the server containing the file to be streamed, the file is retrieved and the connection closed. The HTTP server communicates to the browser the type of file to be transferred.

Benefits Using HTTP

When streaming a file using HTTP, a special streaming server is not required. As long as your browser understands MIME types it can receive a streaming file from a HTTP server. One of the distinct advantages of streaming files using HTTP is that it can pass through firewalls and utilize proxy servers.

Some Disadvantages

HTTP streaming uses TCP/IP (Transmission Control Protocol and Internet Protocol) to ensure reliable delivery of the files. This process checks for missing packets and asks for them to be retransmitted. This become problematic in the streaming scenario when you want the data to be disregarded if it is lost in delivery, so dynamic files keep playing. HTTP cannot detect modem speed so server administrators must purposefully produce files at different compression rates to server users with different types of connections. Streaming files from HTTP servers is not recommended for high-demand situations.

RTSP Protocol

RTSP is the standard protocol used by most of the streaming server vendors. RTSP servers use the UDP (User Datagram Protocol) to transfer media files. UDP does not continually check that files have arrived at their destination. This is an advantage for streaming applications because it allows for file transfers to be interrupted as long as the delay is not too long. The result of this method is that there is data loss at times, but files continue to play if the delay is small.

source


10 Reasons Why You Should Never Host Your Own Videos

We’re Talking About Embedding vs. Self-Hosted Video

First, you upload your video file to a third-party video hosting service like YouTube, Vimeo, or Wistia.

Then, you copy a small bit of code that they furnish to you, and paste it into your post or page on your own WordPress site. The video will appear on your site, in the location where you pasted the embed code, but the video itself is being streamed from the video host’s servers, as opposed to your own web server, where your WordPress site is hosted.

4. No Single File Format Standard for Web Video

The current HTML5 draft specification does not specify which video formats browsers should support. As a result, the major web browsers have diverged, each one supporting a different format. Internet Explorer and Safari will play H.264 (MP4) videos, but not WebM or Ogg. Firefox will play Ogg or WebM videos, but not H.264. Thankfully, Chrome will play all the major video formats, but if you want to ensure your video will play back on all the major web browsers, you’ll have to convert your video into multiple formats: .mp4, .ogv, and .webm

5. Hope you like converting videos. A lot.

Most of your audience will likely watch your videos from their desktop or laptop with the benefit of a high-speed Internet connection. For those folks, you’ll want to deliver a large, HD-quality file so they can watch it full-screen if they so choose. Generally, this means a 1080p or 720p file at a high streaming bitrate (5000 – 8000 kbps).

But you’ll also want to encode a smaller, lower-resolution version for delivery to mobile devices like phones and tablets, as well as delivery to viewers with slower Internet connections.

6. Video Players

A video player is a small piece of web software you install on your site that will automatically detect which device is requesting your video, along with its connection speed, and then deliver the appropriate version to that person.

7. Cumbersome Code [or Shortcodes]

Whether you use a third-party plugin or WordPress’ built-in video capabilities, you’ll need to create a bit of code to tell the video player which formats you’ve created, as well as their location on the server. It looks something like this…

<video poster="movie.jpg" controls>
<source src="movie.webm" type='video/webm; codecs="vp8.0, vorbis"'/>
<source src="movie.ogg" type='video/ogg; codecs="theora, vorbis"'/>
<source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
<p>This is fallback content</p>
</video>

So what’s the best solution for adding video to your site?

Simply use a third-party video hosting service, then just embed your video into your WordPress post or page.

Step One: Upload your video to one of the popular, well-established video hosting services like Vimeo PRO.

Step Two: Once your video has been uploaded and is ready for viewing, copy the URL to your video. Return to your WordPress site and paste the URL into your post or page where you want the video to appear.


When folks view your page, the video will appear in the location where you pasted the URL. But the video file itself will be streamed from the video host’s servers, as opposed to your own server, where your WordPress site is hosted.

The embedded video player will automatically detect the user’s device, browser, and Internet connection speed, and then serve the appropriate version of the video file to them. Nothing to install on your site. No plugins to keep up to date. No tricky code.

source

Related Question