Streaming Video: An Overview
So what is this stream we speak of?
In very basic terms, streaming is the distribution of real time or live audio or video through the internet.
For the purposes of this discussion, there are three primary characteristics that define streaming media:
1) It enables real-time or on-demand access to audio, video content through the internet.
The ability to provide On Demand content can’t be understated. Any video you produce can be accessed at any time from anywhere.
2)It is transmitted by a media server application- for example your ParaFX web account which sits on a Humber server- and is played back and processed by a client player application- in this case the Flash Player 8 - as it is received.
In basic terms, the video is transferred to a web page using a server application such as a web server or a Flash Media Server and is displayed in a browser using a client application such as the Flash Player 8. The rate the data is fed into the client by the server is, in general terms, the stream. This stream of data into a Flash Player is the key issue surrounding the successful delivery and playback of a video. If too much information is moving into the client, it can’t keep up. When this happens the information is buffered. A buffer is nothing more than a place where enough data is stored to start playing the video and to play it successfully through to completion. Video that takes an inordinate amount of time to load and play or videos that start and stop are symptomatic of a developer that didn’t pay attention to the stream of data from the server to the client.
Though a hallmark of streaming media technologies is that that file has to download before it starts to play, Flash Video sort of moves in a different direction. It uses a Progressive Download which starts the video playing before the download completes.
3) Streamed files are received, processed and played when they arrive and no residual copy of the video is left behind.
This is true of files that are streamed to the Flash Player 8 through a Flash Media Server. FLV files arriving via your regular web server will wind up in the Browser cache. Obviously, if security of the files is paramount then the Media Server is a logical solution.
Image 11: True streaming uses a streaming server.
Image 12: When a true stream isn't available Flash uses a Progressive Download.
Getting from here to there:
Before digging into the numbers and nuances of creating Flash Video, it is important that you understand how a video file gets from you machine to a server and from the server to your viewer’s browser.
Streams are sent from a streaming media server using a protocol known as RTP ( Real-time Transport Protocol). It is quite similar to its HTTP and FTP cousins but there are some differences.
In our slice of the virtual world a “protocol” is a set of standards that define how information is moved and how the parties- the server and the client- interact. It really is no different from those occasions where say, the President of the United States visits the Prime Minister of Canada. They don’t just get together and have a few drinks and solve the problems of the world. There are a whole series of rules regarding how they will treat each other, where people will sit a dinners, who has what rank in speaking to whom and so on. This is laid out by a set of diplomacy rules under the name of “Protocol”.
In our world, if the rules weren’t there, the President wouldn’t know who is the Prime Minister and information passed between the parties would either be misinterpreted or even lost.
The Internet is one great big bag of conflicting standards or protocols that connect a great variety of platforms from cell phones and PDA’s to rooms full of servers in the Pentagon using a vast array of communications mediums.
To wrap your mind around this concept of protocols let’s not use the internet. Instead I am going to talk about the phone that sits on my desk in my office at home. If I want to call the College from my office in Oakville there are a ton of protocols going on in the background: area code (905 to 416), exchange and phone number are all part of the addressing protocol; when I wish to get hold of James Cullin there is another protocol in place whereby I have to enter his extension number; when I connect to him there is another protocol used to determine how my voice goes from my phone to his and from his to mine and there is even a societal protocol requiring me to identify myself and to indicate the conversation has ended by saying “Goodbye”.
The most common protocol suite on the internet is TCP/IP. In many respects it is much like the post office because this global standard makes sure the information or data gets to the right address and gets there in one piece. IP (Internet Protocol) is the basis for the overwhelming majority of protocols on the internet. Its job is to break the data into large data chunks called “packets”. In addition to the data being sent, each one of those packets ( known as a datagram) carries a header containing the source and the destination IP address as well as a number ( sequencing information) that allows the computer receiving the data to unscramble it and put it in the right order when it arrives.
This number is critical because the packets don’t move in a straight line from the web server to your computer. Some packets may head through Japan and Spain to get to your computer while others may move through Argentina and Norway depending on network conditions. If lightning were to strike the line between James and I during our telephone call, the packets of information from my phone to his would be rerouted. Therefore, IP focuses mainly on the location of the computers and getting the information from one to the other using the most efficient route available.
TCP (Transfer Control Protocol) focuses on software, assuring that data is sent, delivered and correctly assembled on the user’s computer. If one of the packets is somehow corrupted during the transfer, TCP will ask for it to be resent. TCP also acts like the device on the fire hydrant that controls the flow of water to a garden hose. In many respects, TCP optimizes bandwidth by slowing the data transfer if the network is congested or speeding up if there is minimal traffic.
HTTP (HyperText Transfer Protocol) is used to move web pages from here to there. Let’s get real clear on this. HyperText is simply a database system by which related objects (Text, pictures,video,audio) can all be linked together. Hypertext is also interactive in that the user clicks on something to see it. This means it requires a two-way communication protocol that allows the user to communicate back through the network to access the hypertext links to content on a page. Don’t ever confuse HTTP with HTML (HyperText Markup Language). HTML is a language describing how web pages look and behave.
FTP (File Transfer Protocol) is a set of rules for moving files from one device to another. It does not rely on the web and you can see this when you open an FTP application such as WS_FTP (PC) or Transmit (Mac) because one option is the ability to move a folder from one computer to another. If it was strictly web based this option wouldn’t be there. FTP’s most common use is to move a folder of files from your computer to your web server. When I write books, inevitably my publisher will send me an FTP address where I am to place the folder containing the manuscript, screen shots and exercises used in the chapter.
HTTP and FTP are lousy streaming solutions
Both HTTP and FTP are placed on top of TCP, the standard that ensures the data gets from there to here in one piece. Video transferred using these protocols will get there in one piece… eventually. Lost or damaged packets are simply resent which is fine if you want the video to play only after the entire file has been received. The downside is the user is going to have to sit around and twiddle his or her thumbs waiting for this blessed event to occur.
When HTTP is used for a Progressive Download, the very reliability of this protocol can jump up and bite you and bite you in the butt. Remember, the video starts to play through the Flash Player when enough information to ensure smooth playback is received. What happens if, when the video starts to play a packet used later in the video becomes corrupted and needs to be resent? There will most likely be a hiccup and the video file will have to be reassembled. This is why a buffer is a great solution because anything in the buffer is intact. Still, HTTP and FTP can’t be used for real streaming because of this error correction scheme. It will undermine the temporal relationship between the audio and the video packets. Neither protocol can deal with the data transfer rate to the audio or the video transfer rate.
Though the Flash Player 8 will use a Progressive download to “stream” a video into a web page, you can gather from this that the you have no control over how long it takes to get from the server to player and if the connection speed is less that the video’s data rate, smooth playback simply isn’t possible.
This work is licensed under a Creative Commons License.
