Despite the term having entered common vernacular, “streaming” remains a distinctly difficult term to accurately and clearly define. By understanding why a “live” stream may lag behind “real life" we begin to appreciate that in the context of digital televisual communications “things must happen” to enable the communication. These “things” can be one or a series of continuous, synchronous processes all working together to bring the subject of the video to the receiver as fast as possible, or these “things” can be a sequence of asynchronous processes that occur over a much wider timespan, sometimes occurring a long time after the event that is the subject of the video is over, and where the audience can access the content at a later time, be that of their choosing or of the video service providers scheduling.
In a packet network, such as the Internet, whatever the underlying processes that contribute to a communication of data, that “item” of data will, by definition, be broken up into a series of constituent packets that must be sent in a coordinated way over the network, sequenced by the receiver, usually having any missing packets “re-ordered and re-delivered,” and then the receiver must process those packets to reconstitute the item and restore it to being a usable communication.
Typically, when we think about these “items” of data being sent over the Internet, we think of messages, files, images, or pages. This thinking persists for most people when they think about video, not least because most people make extensive use of on-demand services such as YouTube and Netflix, and the impression is that some entire “film” is being downloaded in the same way an email is downloaded when you wish to read it. Our traditional perception of obtaining such data in the nonvirtual world is filled with content in the form of letters, books, photographs, and so on, and we have a tradition of understanding the content being preserved as discrete items in some form of medium - Intellectual Property lawyers call these “fixations.”
Streaming changes that.
One of the first things to be understood when trying to understand streaming is what it tries to achieve. Let's take a look at mp3 audio as an example. In the early 1990s when the Internet was expanding into the domestic environment, users typically could access via dial up over standard telephone lines, and the typical access speed was 14.4 kbps. Today domestic broadband speeds are usually faster than 1Mbps - so over a thousand times faster than in the mid- 1990s - and many are over 100Mbps. In this new age a single 5 MB mp3 file may only take a few seconds to download - noticeably less time than it takes to play that mp3 file - however, in the mid-1990s, when mp3 first emerged, it could take at least as long as the play duration of the file to download - so a 5 minute long piece of music would take often more than 5 minutes between the point of choosing to listen to it, and the point it could be heard. This is was far from satisfactory from the user's point of view.
One of the problems was that once a download of the mp3 was started, even though much of the audio data was available on the local computer, the computer itself could not make sense of the file - it was not a discrete item.
Because computer data files typically needed to accurately convey information, files needed to have a clear structure, and this not only included the title and the first information about the file (the “file headers”) at the front (called the Front of File data) to configure the software that would handle the incoming file as its processing began, but it also needed the last bit of data, the so-called End of File (EOF), which often included error-checking information at the very least. Only when the EOF was received, and error checking was complete, was the downloaded file “released” to the operating system as a complete data item for use in applications such as media players. Among other things, this protected the computer from endlessly downloading data and filling up its local memory, which ultimately would have brought the computer to a standstill.
Engineers noted that during the file transfer, the data already received by the computer could potentially be used by the “media player application,” even though there was more being delivered by the download process. The logic was: if this were possible, then the listener need not wait until the download of an mp3 completed in entirety before their player could begin to process the incoming data and play the music “as it arrived”....
Note that while the file was still in mid-transfer, it was being transferred by being broken into small “chunks” by the underlying packet network process. Each chunk was in its own right a small file - it just happened that the data it contained made little sense in isolation as a single “item” to the application layer technologies such as the media players. However, by accruing enough of these chunks in a buffer between the source and the point of processing, a media player application could be set up so that it really made no difference if the chunks were being retrieved from disc or from a buffer. The result was that playback of the mp3 became possible despite no EOF being present, and for as long as the buffer contained “the next” chunk that the player requested.
This continuous flow of chunks of data derived from a larger file and delivered over a packet network became known as a “stream.” It is important to note here that a continuously updated source of a stream could potentially be configured to play forever. This configuration or model is the starting point for understanding what a live stream is.
In summary: A series of chunks of audio or video data that are being continuously generated by a source or origin (now usually called an “encoder”), and transferred (by a network of distribution servers) to a recipient (the “decoder”).
Live streaming is a linear process, synchronous in nature. The EOF may or may not be part of the story - some modern models have evolved so the “chunks” may actually have many EOFs, but for the purposes of common understanding a key difference between a “live stream” and an “on-demand” stream is that, in the case of a live stream at least, the EOF will never be transferred while the transmission is “live.”