Thriller Media Group

For Immediate Release
March 8th, 2010

Thriller Media Group, LLC announces the general availability of the Thriller ULTIMATE Encoder (TM) – Compatible with most content delivery networks, Flash Media Server, Wowza, Windows Media Server, and more!

Palm Springs, FL:  Thriller Media Group(TMG), LLC announced today the immediate availability of a top-of-the-line streaming Internet Video Encoding box, The Thriller ULTIMATE Encoder (TM).  This encoder supports all major streaming formats, including; Flash Media Server 3.5, Windows Media Server, iPhone live video, QuickTime/Darwin, RealMedia Helix, and Wowza.  It’s also compatible, Influxis, Live Stream, Multicast Media Suite, Justin.tv, uStream, and more!  The encoder will work with Akamai, Limelight, Edgecast, Level3, Bitgravity, Highwinds, Amazon Cloud, and others.

The Thriller ULTIMATE encoder (TM)  is available for rent or purchase for live webcasts, webinars, video conferencing, internet broadcasts, sporting events, corporate functions and more!  The encoder boasts a speedy CPU, plenty of RAM, ample storage, and most importantly professional hardware analog to digital encoding, all packed in a box much less than 1 cubic foot.  Miguel Dunkley, TMG President and Co-Founder says, “we found that although Digital Rapids, Viewcast, and Newtek make some of the best hardware out there, they are just too expensive for the average person to afford.  We set out to build a portable, powerful device which could compete head-to-head with the best at a fraction of the cost.  We believe we’ve achieved our goal.”.

The Thriller ULTIMATE Encoder (TM), supports component, composite, S-Video, balanced and unbalanced audio.  The device also sports USB and Firewire ports to support digital camcorders and even basic web-cams.  No other encoder on the market can support all these devices. TMG will even pre-configure and test the encoder for you before sending it out to ensure it’s ready to go out of the box.

An optional feature is the addition of the Thriller Ultimate Presenter.  This feature will allow easy integration of slide shows, images, and any other media into your broadcast.  Easily add titles, transistions, and multiple cameras to your presentation. 

TMG also offers on-site encoder management.  If you feel more comfortable having an encoding engineer on-site during the event, TMG will hand deliver the encoder, set it up, work with your A/V crew to ensure that all components are functioning.  The company also offers live event archiving, post-production video editing, post event video hosting, Flash and Silverlight player development and streaming media consulting services.

“We’re very excited about this”, says Dunkley, “No on else in the industry is offering this type of service.  We’ve talked to countless organizations who are looking to do 1 or 2 live events per year and can not or will not justify spending ten thousand dollars on encoding equipment.  This way, you can have the best of both worlds;  use a professional hardware encoder and achieve a broadcast quality live stream, but don’t invest the capital and depreciate a piece of equipment which is going to sit in a store room 11 months out of the year.”.

About Thriller Media Group, LLC
TMG is a sister company of SIGISIS, LLC, a company that provides cutting edge web and graphic design services.
Contact information:
Miguel Dunkley – miguel@rentanencoder.com
http://www.rentanencoder.com
(561) 856-3332

By:  Mike Colburn (StreamMediaGuy)

You will want to have some idea as to how much bandwidth you will use during a live webcast, webinar, or video event.  This will help you estimate costs and plan capacity. There is a fairly simple formula to calculate this.  Keep in mind that this will be an estimate and depending on your encoder, codecs, and compression methods, this number could vary.  You can use the formula to figure out how large a file will be once you encode and save your video as well.

There are 3 things we must know.
1. Video Bit Rate – this is the bit rate that you encode you video at.  If you are encoding above 1000Kbps then convert the number to Kbps don’t use Mbps.  In other words.  1Mbps=1000Kbps   2.5Mbps=2500Kbps  etc.

2. Length of the video – This can be tricky.  You don’t want to calculate the actual length, you want to estimate the amount of time each person is likely to watch.  If you are calculating for On-Demand viewing, then YES, use the whole length of the video.  But for live streams, figure about 10-20% of the actual event per viewer.  Don’t kid yourself, no one is going to watch your 4 hour antique auction in it’s entirety.  They are going to watch 30 minutes tops.

In my experience, the only types of live broadcasts which get watched in their entirety are big name concerts and church services.  Otherwise, plan on 10-20% of the length of the stream per user.

3.  Lastly, how many people will watch the event?  You may have 2 Million visitors to your site each year, or a mailing list of 500,000 but consider this when planning.   What is the event?  When is it?  Is it a concert on a Saturday night (do you think your audience is home in front of their computer Saturday night or out doing what they do then?  Oprah Winfrey got 500,000 people to watch her book club online webinar.  She has a viewing audience of 50,000,000 dedicated viewers.  This content was ONLY going to be available on the web, not TV as well.  She has about as much pull in the media as anyone anywhere.  So if you think you’re going to get 1Million people to watch your stream, think again.  (unless you’re Oprah or maybe Barack Obama).

Here’s the formula.

Bit Rate X Time (in seconds)

———————————  = Y

………………..8

Take Y and divide that number by 1000.  This will give your number for 1 Viewer watching for that amount of time represented in MegaBytes (MB)

Now multiply that number by the number of viewers you’re expecting and that will be how much bandwidth you will use.

Remember:

• 1000MB=1GB
• 1000GB=1TB
• 1000TB=1PB
• Approximately 1TB=10Mbps
• I know 1MB is really 1024KB.  Most CDNs and ISPs will round 1 MB to 1000KB, it makes for better billing

Example: 750Kbps for 1 Hour watched by 1500 people

750 X 3600 =2700000 / 8 = 337500/1000 = 337.50 X 1500= 506250MB or 506GB

You can use this same formula to estimate how large a file will be once you encode it.  Just don’t multiply it at the end by the number of viewers.  Of course if want to estimate your Content Delivery Network (CDN) usage, then just take the file size and multiply it by the number of monthly views.  This will estimate how much you should commit to your provider.

When choosing to use a CDN there may be numerous ways to integrate your content to deliver it.

Most CDNs employ one of 2 methods for delivering content.  The first is origin pull or off-site origin.  This evolves the CDN pulling the content from some outside source.  This origin could be your webserver, a cloud computing service, something like Amazon S3 or any other internet connected HTTP server.  The key is, that the CDN needs to access your content via HTTP GET requests.

The second method is CDN storage.  This is storage that the CDN supplies to you on their network.  This is usually a preferred method as the CDN does not have to go far to get your content to cache it on edge servers.  You can expect to pay for this storage on top of your other CDN charges.  Typically, you will FTP the content to the CDN storage or in some cases, there will be an HTTP upload option or even RSYNC may be an option.  If your content is large in size, larger than 5-10MB its recommended  you store the content on the CDN.

Using CNAMEs to access content

Most CDN’s will use CNAMEs to allow you to access your content.  A canonical name or CNAME is simply an alias.  For example   ‘static.domain.com’  could point to the CDN URL. You can use this instead of the URL that CDN supplies to you.  This way you can better brand your site and won’t have the CDN URL floating around on your site somewhere.  Talk to your CDN on how to implement a CNAME, they may have special requirements or might not even allow them.

When you do off-site storage, the CDN usually needs to know where you store that content.  So be prepared to supply the CDN the CNAME and the Source/Origin URL.  Origin, being the URL where the CDN can go to, to pickup your content.

When you write your HTML instead of using a relative path to a file like “./images/logo.jpg” you will use an absolute URL instead, such as “http://static.domain.com/images/logo.jpg”.  This way you are essentially embedding content from the CDN on your website.

If you are using a content management system, check to see if there is a way to address all your static elements like images, CSS, java script, PDF, MP3, FLV, MP4, etc at once.  You may be able to specify a “pre-pend” URL for specific file types.  This would make switching to a CDN easy and quick.  You could “CDN enable” your whole site in one click.

WordPress users, see the CDN Rewrites Plugin –

How do you know if your content is cacheable?

If you are uploading the content to the CDN then it will be cacheable.  If the CDN is going to pull the content from you then you need to consider a few things.  Most CDNs will honor any cache control headers you put on your content.  For example, if you put a Max-Age=86400 on your content, then the CDN will consider that piece of content fresh for 24 hours.  Don’t think for a second you can tell the CDN how long to hold a piece of content in cache for.  They will decide when that piece of content needs to be purged from an edge server.  However, setting this TTL will tell the CDN that after 24 hours they need to look to see if there is a new version of the file.

Also consider this, if your content has a Private, or No-Cache header on it, then the CDN will probably not cache it, you’re wasting bandwidth.   You are trying to deliver non-cacheable content through the CDN, they will go back to your origin for every request.

Some CDNs can address this issue by implementing some custom work around, so talk to your CDN of choice for advice.  Also, check with your CDN to see if they require specific cache control headers to be present, you may need to alter your headers in order to make your content cacheable even if you don’t have a No-Cache type header.

Conclusion

This was a basic overview on how CDNs handle basic caching of content from different origins as well as how to deliver your content through the CDN.  Consider the issues of cache control headers, these can be very powerful and allow for flexibility on how your content is cached and for how long.  You should always work with your CDN of choice directly as they will have specifics for implementing their solution.  No 2 CDNs are exactly alike.

When choosing to buy CDN service there are a lot of factors which go into play.  Obviously, you want the best service for the best price.  Use the following as guide to help you when interviewing CDN service providers.

1. Bandwidth needs
What are your bandwidth needs?  Are you going to use 50GB/month or 50TB/month?  CDNs charge by GB transferred (in most cases).  If you’re only delivering a small amount of traffic, it may not be necessary to purchase CDN service.  You might be able to get away with upping your current web host provider from a shared environment to a dedicated environment.  Maybe it’s time to move to a business class web host, instead of that $5/month provider you’re using now.

It doesn’t make sense to pay a Tier 1 CDN thousands of dollars a year to deliver 4 videos.  If you’re having so much problems with your video or software downloads, then look at the root cause and fix it!

When you are delivering about 500GB/month it starts to make sense to off load that heavy lifting to a CDN.  By now, you are getting several thousand requests per month or even per second and your single web server in 1 data center won’t be able to keep up with the traffic.

Certainly when you are doing over 1TB/month of static content delivery, you should use a CDN.  This will ensure your videos, podcasts, music, images, documents, and software downloads are getting to your customers quickly and efficiently.

2. Network Performance

All CDNs big and small say they have the best network!  There are basically 3 kinds of CDNs:  Internet based, Peering/Private based, and Peer to Peer (P2P).

About the only Internet based CDN is Akamai.  Akamai has thousands of servers all over the place.  Then using some fancy algorithms, they route traffic from 1 PoP to the next getting your content onto the backbone of what ever ISP your end user is on.  They then cache the content in that closest PoP so the next person in that region/ISP has the content already close to them.  Obviously, this method works as Akamai is the biggest CDN on the globe and boasts the most customers.

A peering/private CDN is one who puts servers in regionalized PoPs around the world.  Then in those PoPs they peer with, or directly connect with as many ISPs and backbones as they can.  Then when someone requests a piece of content, the file is delivered directly from the CDN to the end user network and is able to by-pass the Internet all together, in most cases.  Most other CDNs use this model.  Limelight Networks is the most successful in this configuration.  They have a private fiber backbone as well to move content from Origin Server to PoP.  Other CDNs who follow this model are Panther, EdgeCast, Level3, CDNetworks, and others.

Finally, the idea of P2P is intriguing.  Simply have all content viewers act as a PoP and replicate the content around the globe.  There’s little or no infrastructure cost and theoretically you can get your content on to any ISP in the world.   P2P has it’s place, but as a means to deliver mission critical and revenue generating content, this method should be avoided.

As a side note, there are Hybrid CDNs who employ P2P and Peering/Private methods.  These are intriguing, however for secure delivery, using a P2P is less desirable as your content will end up on hundreds to thousands of individual computers with little or no control over who gets access to it.

3. Technology
Does your CDN support the technology you require?  All CDNs will deliver content via HTTP Progressive download.  But does your CDN support true Flash Streaming (RTMP), true Windows Media Streaming (MMS, RTSP), Quicktime or Real Media streaming?  What about Flash Live or Windows Media Live?  Can they do MP3 Live?  Do they have a Token Based Authentication secure URL product?  Can they do pseudo-Flash streaming?  Do they have any special services for HD delivery?  What about a mobile CDN platform? Is it easy to get content to the CDN?

Finally, what about their analytics?  Do they offer quality analytics? Is it easy to use?  Does it show number of request per object?  Is there a content management piece?  Do they offer Geo-Reporting?  Can you get raw logs?

4. Other products and services
What else can your CDN of choice do for you?  Do they have a professional services department?  Can they help with monetization?  Do they offer encoding/transcoding?  What about digital rights management (DRM)?  Do they offer a live event monitoring service? Is there a content management system or digital asset management system available?  Does your service include embeddable media players?  Can they cache whole web sites?  Do they support e-Commerce or shopping carts?

5. Support
What kind of support can your CDN offer?  Ask for the number of the helpdesk and call it.  How quickly did they answer?  Did you get a person or just voice mail?  Is there email support available?  Do you have access to technical personnel during the integration phase?  Who do you call if you have a question about your bill?  Does your CDN even offer support?  What happens if you call in the off hours?  What does their Service Level Agreement look like?  Most CDNs offer a 100% SLA, but what does that really mean and how do you get credit if they don’t meet their SLA?

6. Contracts
Does your CDN require an annual contract?  Do they offer a month-to-month contract?  Are they asking you to commit to a minimum amount of money per month whether or not you use that much?  What happens if you go over your commit, how much is that going to cost you?  Can you pay with a credit card?  Do you have to pay with a credit card?

7. Longevity
How long has your CDN been in business?  Are they funded by venture capital?  Do they have huge amounts of outstanding debt?  Are they facing an uncertain law suite by a competitor?  How much cash do they have in the bank?  Over the past 12 months there have been some major moves in the CDN industry.  There have been a number of players who have all but disappeared.  There have been some acquisitions and mergers, and some major players are bleeding cash so much that they may not be around in the next 12 months.  Be careful about putting content on an iffy CDN.  Research them independently and see if they have had any major complaints or severe outages.

8. Cost
Notice cost is at the bottom of the list?  This is because cost should not be your number one concern.  You will find huge differences in cost from CDN to CDN.  Expect to pay anywhere from a few cents per GB up to over $1 per GB.  There are a number of factors that will dictate what you pay.  Don’t expect to get the same pricing that a big boy like Netflix will get when you are passing 200GB/month.  Your price will be based on how much traffic you pass.  The more you pass, the cheaper the price will be.  Also, most of the other items mentioned above will factor in your cost.

If the CDN you decide to go with is too expensive or is asking for more of a commit than you want.  Ask them if they have resellers you can go through.  Usually these resellers can offer better terms.  You may pay more per GB than going straight with the CDN, but you might only pay for what you use.  Also beware that going with a reseller may limit you to support from that reseller.  You might not be able to call up the CDN directly for support.  You may also only get basic reporting with a reseller instead of the full blow analytics package offered by the CDN.

Conclusion
Consider all these factors when deciding which CDN to go with.  The biggest factor is how much traffic are you going to pass.  You may have fun driving that Lexus, but you can still get to work in your Toyota.   Choose a CDN that meets your needs and fits your budget.

If you have any questions about this topic, please feel free to post them here and I will respond.

Thanks,

Mike Colburn (DigitalMediaGuy)

The online video delivery experience

When delivering online videos there are generally two distinct ways to do it. HTTP Progressive Download or Streaming. You may assume that all videos are streaming, but you’ll be surprised to know that most aren’t.

So what are these two methods? How do they differ? What are the advantages and disadvantages of both? Why would I want to use one method over another?

Progressive Download
All web servers are capable of progressive download. This is merely the method of a video file being delivered via HTTP to a browser. This is similar to someone downloading a file from your website. In fact the video is delivered in the same manner that an image, a CSS, a JS, PDF, or any other file on your web site is.

The real difference is that media players can begin to show the video while it’s downloading. For example, a FLV file being delivered via HTTP Progressive download will begin to play in your Flash Player as soon as a little bit of data is received by the browser. The same is true for Windows Media files. Quick Time will wait until the entire file is downloaded before it plays, unless the QuickTime player on the PC/Mac is set for progressive play. So be careful when posting QuickTime videos.

It’s quite obvious when a video is being delivered via HTTP Progressive Download. You will typically see the little status bar grow as the video downloads. You won’t be able to move the scrubber button past the amount that has downloaded already. This makes it impossible to jump to the end of the video before that portion has downloaded. If you have a slow web server or limited bandwidth or the end user is on a slow Internet connection, then it’s possible for the enduser to notice buffering.

Buffering occurs when the download can’t stay ahead of video. The video will stop while it downloads more. If you pause the video and it allow to download a large portion, then you can watch the video uninterrupted. In either case, this is a poor enduser experience, this is when you would consider using a CDN.

There is a technology called Psuedo or Seek streaming. This method utilized TCP/IP Range Requests to allow the user to jump to any portion of the video and the player will make a range request of the file to download that portion. This method is usually only for FLV videos and requires special services, or servers and custom Flash players to function.

When a video is delivered via HTTP, it is actually downloaded to the end users computer. This is good and bad. It’s good because if the person watches the video again, it’s already cached on their computer. It’s bad because it makes it extremely easy for someone to steal your content.

Finally, if someone only watches the first minute of your video but doesn’t stop the download, the browser will download the whole file and you will pay for the delivery of the file even though the person didn’t watch the whole thing.

Streaming Video
Streaming video requires access to a streaming media server. Some servers are Flash Media Server, Wowza Media Server, Windows Media Server, Darwin Media Server (QuickTime), Real Media Server. These servers usually require licensing and may cost several thousands of dollars.

Some well known streaming protocols are RTMP, RTSP, and MMS.

When a video streams, it is being sent via UDP protocol to a player on the end users compter. The user will have the ability to fast forward or rewind the video. The video isn’t being downloaded to the end users computer so it is less likely that the content will be stolen. Also if the user only watches 5 minutes of a 30 minute video, then you only pay for the delivery of 5 mintues, not the whole video.

The biggest disadvantage of streaming over progressive download is if the user watches the same video over and over you will pay for the delivery of it each time.  Videos are also streamed at what ever bit rate they are encoded at.  Keep this in mind when creating HD quality video.  8Mbps video may sound and look great, but most homes can’t sustain an 8Mbps connection.  If you have really high bit rate video, consider delivering via HTTP.

Most web hosting providers or Content Delivery Networks (CDN) will have streaming media servers available to use. Historically, Flash video was more expensive to deliver than other forms. Recently prices have compressed and you will find that it costs about the same to deliver Flash or Windows Media files. In the past I would have said if your video is more than 10 minutes in length deliver it via Stream and less do progressive. Since prices have come down, I would consider streaming for any length video since streaming typically begins to play faster than progressive.

If you are looking at using a service such as a CDN or Cloud Computing and they say you can stream your videos, confirm with their tech support that they are utilizing a streaming server and not just offering bandwidth.

If you are delivering Flash videos, then you should be delivering via RTMP or RTMPE protocol for streaming and http for progressive. Windows Media uses either MMS or RTSP. Quicktime and Real Media use RTSP.

I hope you find this article of interest? This is a good guide to help you through deciding to use streaming delivery of videos or HTTP Progressive Download.

If you have any questions about this topic, please feel free to post them here and I will respond.  As always I ask that you support our sponsors.

Thanks,

Mike Colburn (DigitalMediaGuy)
Top Content Delivery Networks which support Streaming
* Limelight Networks
* EdgeCast Networks
* CDNetworks
* Level3
* Akamai