
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 ] |