Lightning Speed Channel Change

The accomplishment of dynamically instantiated one-to-many servers.

• Q: How can one make Internet channels that will switch as fast (or faster) than cable TV?
• A: The only way it's possible is by having and adaptive bit rate servers that are fully "spun up" (running and ready).

If the goal is to have viewers start a live feed without delay, using the latest technology from Amazon (or other CDN's) one must have a high resolution encode (feed) supplied to multiple arrays of physical servers.

How they do it with an Amazon Web Services and others: Unicast (1 to 1)

There are seven steps (stages) and two separate connections that accomplish the readiness for fast channel switch, all of these steps use inefficient point-to-point technology:

1. A video encoder is set up for the channel which encodes one very high bit rate, unencrypted, stream (6 - 12 Mbps) which is then sent to arrays of servers.
2. For analytics, an array of webs servers geographically map the video requestor, and a plugin that runs (as its own application) and an uncontested cookie or other uncontested tracking element is transferred to the requestor device.
3. A second array of servers is implemented where the first server in the array is a high powered computer. This 1st server is used to trans-code the high resolution signal (6-12 Mb/s) into streams of the various resolutions needed for adaptive bit rate playback.
4. The trans-coded video streams are crunched into 10 second video clips of each of the various resolutions, and a playlist (map) is generated.
5. The playlist (map) and video segments are copied to the rest of an array which consists of end user web servers (providing no feedback or usage), or less efficient java based servers (Wowza usually, providing minimal usage data and no analytics)
6. The end users media player, which has accepted (loaded) a cookie or tracking agent, and has been assigned a server from step one, requests the playlist from the web server (or java server) in the array loaded and/or created in step 5.
7. A web server (or java server), loaded with segments and playlists in step 5, responds to the playlist request with a list of available segments. The end user player then request segments that it feels will match its bandwidth.  Because it's adaptive bit rate compliant, the end user media player can request a low bit rate as the first segments to play, thereby making the channel switch quicker

Keeping all the server arrays satisfied with a very-high-resolution video for them to trans-code takes a lot of (server-to-server) bandwidth in itself.  There may be no users at the time, but that very-high-resolution stream must feed the servers 24/7 in order to have them "spun up" (ready to play) when a new user wants to join the video feed. 

The cookies and plugins require a lot of engineering because there are so many platforms to accommodate. Without those cookies and plugins, there would be no analytics, and without analytics there is no financial incentive for advertisers.

How we do it with SMARTcast 7:

So here is the same process accomplished by Viewcast using hyper efficient patented point-to-multi-point technology.

1. The SMARTcast 7 Encoder pre-encodes all the adaptive bit rate video segments, combines them into on stream, and then SMARTcasts that stream to SMART Master.
2. The end user is directed to a SMART Master in their country or state. 
3. The SMARTcast Master,  emulates (pretends to be) a web server collecting and simultaneously collects the analytics and satisfies the end user with the first frames of video segments, and simultaneously assigns the further playback to an array of SMARTcast EndNode servers which are dynamically instantiated (created/started/stopped as needed).

With SMARTcast protocol (supporting point-to-multi-point communications)

• 7 steps are accomplished in three.
• By sending the playlists and video segments that are already compressed one saves bandwidth and server resources.
• All the servers are satisfied with one-to-many SMARTcast (vs. Unicast) (one stream feeds an unlimited amount of servers). Massive efficiency, with return path.
• The analytics are collected by the SMARTcast. Dynamically instantiated EndNode servers are sent back to the SMARTcast Master via SMARTcast protocol messages saving a spaghetti factory of servers and software. Our apologies to the competition but, what a kludge!