This course will become read-only in the near future. Tell us at community.p2pu.org if that is a problem.

Taking Video to Web [Dec. 15, 2012, 10:39 a.m.]



Great. So up until now you have experienced Video in the Offline World. Now let´s take your knowledge one step further and tackle real-life use cases for video in the Online World.

1. Download

The simplest form of Video on the Web is a downloadable file resisting on a web server. The consumer can begin playback once the whole file is downloaded to the computer. While downloading, you cannot access the file and play it.

Video Files on Streaming websites can be downloaded as well, even if you cannot access the whole file at once (e.g. Youtube). You can use software to do so, either special download software or media players (i.e. VLC) or browser plugin software. Most of the times downloading these files will take as long as it would take to watch them at normal playback speed. The software uses the data stream to generate a video file.

If you want to offer a video file for download all you really have to do is store it on your server within a publicly accessible path and link to it on an HTML website. The user then can right-click on that link and chose the "download to computer" option in the context menu.

 

2. Progressive Download

[Infro from Wikipedia: http://en.wikipedia.org/wiki/Progressive_download ]

 

A progressive download is the transfer of digital media files from a server to a client, typically using the HTTP protocol when initiated from a computer. You can do this either inside your browser if it is enabled to display video files or with a video player software (e.g. VLC).

The consumer may begin playback of the media before the download is complete. The key difference between streaming media and progressive download is in how the digital media data is received and stored by the end user device that is accessing the digital media.

A media player that is capable of progressive download playback relies on meta data located in the header of the file to be intact and a local buffer of the digital media file as it is downloaded from a web server. At the point in which a specified amount of data becomes available to the local playback device, the media will begin to play. This specified amount of buffer is embedded into the file by the producer of the content in the encoder settings and is reinforced by additional buffer settings imposed by the media player.

History

Initially the digital media file type known as jpeg was the first visual media to render a progressive visual display as the digital media was downloaded and actually referred to as a progressive download. The distinction between the technical behavior of progressive download as opposed to the common or commercial use of the term progressive download to describe that behavior was not documented and there is a good deal of question regarding the origin of the term versus the origin of the technical implementation. Apple in reference to their QuickTime media player employed the term Fast Start[1] in 1997, to describe what was commercially referred to as progressive download playback of encoded digital media content.

This fast start playback is the result of moving the meta data from the end of the digital media file to the front, this move of the meta data gave the media player all the information it required to begin playback as the file was still being downloaded. Prior to that change, the meta data summary was located at the end of a digital media file and the entire file would need to be downloaded in order for the meta data to be read and the player begin play back.[citation needed]

HTTP Progressive Download versus Streaming Media

The end user experience is similar to streaming media, however the digital file is downloaded to a physical drive on the end user's device, the digital file is typically stored in the temp folder of the associated web browser if the digital media was embedded into a web page or is diverted to a storage directory that is set in the preferences of the media player used for playback. The digital media file will stutter or stop play back if the rate of play back exceeds the rate at which the file is downloaded. The file will begin to play again after further download.

3. Streaming

[Infro from Wikipedia: http://en.wikipedia.org/wiki/Streaming_media ]

Streaming media is multimedia that is constantly received by and presented to an end-user while being delivered by a provider. Its verb form, "to stream", refers to the process of delivering media in this manner; the term refers to the delivery method of the medium rather than the medium itself.

A client media player can begin playing the data (such as a movie) before the entire file has been transmitted. Distinguishing delivery method from the media distributed applies specifically to telecommunications networks, as most other delivery systems are either inherently streaming (e.g., radio, television) or inherently nonstreaming (e.g., books, video cassettes, audio CDs). For example, in the 1930s, muzak was among the earliest popularly available streaming media; nowadays Internet television is a common form of streamed media. The term "streaming media" can apply to media other than video and audio such as live closed captioning, stock ticker, and real-time text, which are all considered "streaming text". The term "streaming" was first used in the early 1990s as a better description for video on demand on IP networks; at the time such video was usually referred to as "store and forward video", which was misleading nomenclature.

Live streaming, delivering live over the Internet, involves a camera for the media, an encoder to digitize the content, a media publisher, and a content delivery network to distribute and deliver the content.

4. Adaptive Streaming

[info from Wikipedia: http://en.wikipedia.org/wiki/Adaptive_bitrate_streaming ]

Adaptive bitrate streaming is a technique used in streaming multimedia over computer networks. While in the past most video streaming technologies utilized streaming protocols such RTP with RTSP, today's adaptive streaming technologies are almost exclusively based on HTTP and designed to work efficiently over large distributed HTTP networks such as the Internet.

It works by detecting a user's bandwidth and CPU capacity in real time and adjusting the quality of a video stream accordingly. It requires the use of an encoder which can encode a single source video at multiple bit rates. The player client switches between streaming the different encodings depending on available resources. "The result: very little buffering, fast start time and a good experience for both high-end and low-end connections."

More specifically, and as the implementations in use today are, Adaptive bitrate streaming is method of video streaming over HTTP where the source content is encoded at multiple bit rates, then each of the different bit rate streams are segmented into small multi-second parts. The streaming client is made aware of the available streams at differing bit rates, and segments of the streams by a manifest file. When starting the client requests the segments from the lowest bit rate stream. If the client finds the download speed is greater than the bit rate of the segment downloaded, then it will request the next higher bit rate segments. Later, if the client finds the download speed for a segment is lower than the bit rate for the segment, and therefore the network throughput has deteriorated, then it will request a lower bit rate segment. The segment size can vary depending on the particular implementation, but they are typically between two (2) and ten (10) seconds.

Current uses

Post-production houses, content delivery networks and studios use adaptive bit rate technology in order to provide consumers with higher quality video using less manpower and fewer resources. The creation of multiple video outputs, particularly for adaptive bit rate streaming, adds great value to consumers.[3] If the technology is working as designed, the end user or consumer should be completely unaware of it. Therefore, even though media companies have been actively using adaptive bit rate technology for many years now and it has essentially become a standard practice for high-end streaming providers, mainstream consumers are relatively ignorant of its necessity.

Benefits of adaptive bit rate streaming

Consumers of streaming media experience the highest quality material when adaptive bit rate streaming is used because the user's network and playback conditions are automatically adapted to at any given time under changing conditions.

The media and entertainment industry are the main beneficiaries of adaptive bit rate streaming. As the video space grows exponentially, content delivery networks and video providers can provide customers with a superior viewing experience. Adaptive bit rate technology requires less encoding which simplifies overall workflow and creates better results.

A CDN is often used to deliver media streaming to an Internet audience, as it allows scalability. The CDN receives the stream from the source at its Origin server, then replicates it to many or all of its Edge cache servers. The end-user requests the stream and is redirected to the "closest" Edge server. The use of HTTP-based adaptive streaming allows the Edge server to run a simple HTTP server software, whose licence cost is cheap or free, reducing software licencing cost, compared to costly media server licences (e.g. Adobe Flash Media Streaming Server). The CDN cost for HTTP streaming media is then similar to HTTP web caching CDN cost.

History

Adaptive bit rate was created by the DVD Forum at the WG1 Special Streaming group in October 2002. The group was coo-chaired by Toshiba and Phoenix Technologies, The expert group count with the collaboration of Microsoft, Apple Computer, DTS, Warner Brothers, 20th Century Fox, Digital Deluxe, Disney, Macromedia and Akamai. The technology was originally called DVDoverIP and was an integral effort of the DVD ENAV book. The concept came from storing MPEG-1 and MPEG-2 DVD TS Sectors into small 2KB files, which will be serve using an HTTP server to the player. The MPEG-1 segments provided the lower bandwidth stream, while the MPEG-2 provided a higher bit rate stream. The original XML schema provided a simple playlist of bit rates, languages and url servers. The first working prototype was presented to the DVD Forum by Phoenix Technologies at the Harman Kardon Lab in Villingen Germany.