Webstreaming Explained
 

The internet has already revolutionised the way we do many things, just consider what you did before email? Or how you would find a company of product without websites? However the web is a constantly evolving space and it is not standing still. You’d have to be living in a cave not to notice the explosion of video onto the internet, almost everyone has some use for video, be it watching a TV channel or downloading a music video, right the way through to uploading a video from your mobile to YouTube.

You may have caught yourself wondering how does Webstreaming work? and what different technologies are employed to get the video from a server to you at home?

Video has to come from somewhere and the web world splits things into 2 quite nicely, live and non live. Video captured by a camera is either connected via a cable to and encoder and “transmitted live” or it is stored for later use, this used to be on a tape but it is increasingly likely that video will be directly recorded to file as an MPEG, Windows Media, DV or Quicktime file.

We’ll start with live video transmission. The video signal needs to be encoded from its raw state which may either be analogue or digital to a more manageable bitrate. As an example a professional broadcast SDI (serial digital interface) signal requires 270mbits (megabits) every second in order to capture the high resolution images. If zero compression were used (often called native or uncompressed) a 60 minute file would need 121 gigabytes of storage.

So clearly making the files and streams smaller is critical if we are going to have any hope of getting them over the internet. This task is given to an encoder, the encoder takes either the video stream (or a file) and removes information that is either unnecessary to reproduce the images or that can be reconstructed at playback using mathematical algorithms. This process is known and compression whereby the large stream is compressed to a lower bitrate, it is a lossy process so data thrown away cannot be brought back so it is critical to get it right.

For our example we’ll use a windows media 9 encoder, this is in essence a PC with a video card running a free application called (you guessed it) windows media encoder. The video card acts as a way to bring in the video to the PC while the encoding is performed in software. Settings are applied in the encoder, these will determine the frame size and resolution of the output video as well as the audio and video bitrates.

Streaming video is often encoded at a lower frame resolution than the native signal. A PAL video signal is 720 x 576 pixels, where as a CIF image is reduced to 352 × 288. Equally audio is compressed from 320kbits to as low as 32kbps on some streams, although many run at near MP3 compression rates.

All of this encoding results in an acceptable picture at around 400kbits which rather handily will fit reliably down a 512k broadband pipe. What bit rate is selected is chosen to suit the end user, just a few years ago almost all streams were provided so they would fit on a 56k dial up modem! (no wonder no one watched video online). Now with the advent of faster broadband streams of up to 2mbits are more common place bringing better quality more suited to larger screens.

So what happens to the video when it leaves the encoder? You may think it comes directly over the internet to you and to be fair that is entirely possible, but soon (after as few as 5 viewers) the encoder could not take any more connections. Instead the encoded stream is sent to Windows media servers located in data centres with large (100 – 10,000 mbit) connections to the web. These servers are often set-up in clusters so that viewers are spread across them evenly making it more reliable and able to suffer any one server failing. Often these servers are distributed geographically so that they are closer to the end users reducing the time taken from the video being encoded to it being received by your PC, this is called latency.

The network of servers delivering streams are often referred to as a CDN (content delivery network) and there are some very serious companies in this space who believe that this is the next logical growth for the web.

When you connect to a CDN there are 2 types of protocol that might be used to transfer the stream to you. The first is a point to point connection known as unicast, this method sees the PC start a connection with the CDN server and the CDN server serves up the stream. All very simple but also relatively expensive as each and every user watching the same video at the same time requires a unique stream.

The second method is called multicast, this works more like a broadcast whereby the first user connection to the CDN from a particular ISP or network starts a multicast transmission. This is a bit like terrestrial or satellite TV as the stream is now travelling to the local exchange and your PC needs to tune in to see it, this is very efficient and is seen as the future for video on the web. Sadly only 20 – 30% of ISP’s have enabled their routers to pass multicast traffic, this may seem short-sighted but currently ISP’s make money from selling bandwidth to you and me and to those streaming video. So until the volume of web streams starts to overwhelm the ISP’s they are unlikely to make multicast freely available.

The growth of home media PC’s, media centres and web enabled set-top boxes is starting to push the use of IP video or IPTV as some call it and there are in excess of 50 Tv channels available in the UK online.

Alternately the non real time applications are also having an effect on video usage, services such as YouTube, Google Video and Joost are all gaining millions of clip downloads every month. These file based systems utilise a similar encoding system where source video is compressed to a suitable size (to reduce your download time), but video for download may be encoded several times, with 3 or more passes being made in the process to provide a better quality encoding for the same or reduced bitrates.

Instead of streaming the encoded files, they are most likely uploaded using FTP to CDN system that handles files or into a P2P file sharing network. Now users connect to the CDN as unicast requests and download the file, often faster or some times (in the case of High Definition files) slower than real time. P2P requires each user to download a client and systems like Joost then use this client to act as a repeater and to send sections of the file (or stream) to another user creating a meshed network. ISP's are unlikely to want this continue for long as this creates a lot of network traffic within their cloud and as such is difficult to find someone to bill, therefore it is reasonable to assume that P2P video will finally push the use of Multicast protocols into the mainstream.

Click here for an example stream (both unicast and multicast, if your ISP allows) 400k WM9

Published - 22/04/2007


More Technology Explained-

Up ] Firewalls Explained ] HDTV Explained ] DAB Digital Radio ] How to Bluejack ] RFID Explained ] Gadgets 2004 ] GPS Explained ] Bluetooth Explained ] WiFi Explained ] Gadgets 2005 ] Gadgets 2007 ] [ Webstreaming Explained ] Broadband Explained ] TMC Explained ] Next Fest 2005 ] Gadgets 2006 ] Podcasting Explained ] WiMAX Explained ] GPRS Technology Explained ] Search Engines ] Speed Cameras Explained ] CeBit 2004 ]

 
     
Menu
 
Home
Mobiles & Accessories
Audio & Video
Computing & Networks
GPS & Navigation
Software
Gadgets Shop
Lord P Explains
Pre Release Gadgets
Buyers Guides
Links
Contact
Search
 
About Us
Monthly Newsletter
   
     
   
             
   
 
Google
Lordpercy.com
 
             
  Lordpercy.com - Your Guide To Gadgets - Independent reviews of the latest consumer electronics hardware and software
 
                   
AV Technology | Mobile Technology | Software | Pre Release Gadgets | Lord P Explains | Gadgets Shop | GPS - Navigation | Computing - Networks  | Site Map About Us | Terms of Use

Questions or problems regarding this web site should be directed to lordpercy.com via the contacts page
Copyright © 2005 lordpercy.com. London, England  All trademarks acknowledged