COM 597Streaming Media
Lecture 3
June 27, 2006
Streaming v. Streaming
• As we discussed last week, the term “Streaming Media” has become somewhat of a catch-all phrase for digital media distributed over an IP network
• This is technically inaccurate
Streaming v. Streaming• IBM’s definition to delineate the different types of digital
media works well• Digital media is unstructured content – audio, video, and
images – that cannot be stored in a traditional database.
The two major segments of digital media are:• Media that has “intrinsic value” or in other words value that is
inherent to the media itself (e.g. movies, documentaries, and music videos)
• Media that has “business process value” where the media becomes valuable due to the context in which it is used (e.g. training and corporate communications.)
• So for the purpose of this class we will be exploring “Digital Media” over the course of the term.
• Tonight we will be studying… Streaming Media.
What is a webcast?
• Webcasts can include audio, video and other data like PowerPoint, animation, and even whiteboard applications
• Many webcasts also include some form of communication between the audience and the talent or host.
Some advantages of webcasting over traditional broadcasting
• Lower cost of entry• Unlimited spectrum – don’t need a license
from the FCC• Not limited by geography• Can be targeted to a specific audience
Some of the disadvantages of webcasting
Smaller audience
Incremental cost per viewer
Quality
• Many business and education enterprises are deploying webcasting as a cost-cutting enterprise for both internal and external communication
What is streaming media and how does it work
• Webcasting is a specialized application of streaming media technology
• Streaming enables real-time (or close to it) delivery of media across a network
• This technology is similar to how the web delivers web pages, with one big difference:
1. Web servers download files, streaming media servers stream files.2. Downloaded files are displayed after the entire file has been
delivered
Streaming files play as they are delivered (this is not progressive download)
For large files the advantage of streaming are:
• Real time• Control/interactivity (real-time presentations)• Security (not stored on the hard drive)• Live broadcasting
Bandwidth Capacity45 Mbps
YMMV
• Bandwidth of individual audience members determines how the webcast should be encoded
• The bandwidth at the site determines how much data can be sent to the distribution servers
• The aggregated bandwidth used determines the bandwidth charge
Load balancing
• Streaming media servers receive the incoming stream from an encoder (or encoders) and then may distribute the media to the audience.
• A server may also send the stream to other servers for load balancing and redundancy
• Load balancing is where a number of servers are used to distribute a webcast to improve performance and reliability
Protocols• To facilitate communication there are standardized
protocols used so the servers, players and encoders work properly
• For example “http” stands for hypertext transfer
protocol. • “ftp” stands for file transfer protocol• “rtsp” stands for real time streaming protocol This
is the most common protocol used, but not the only one.
Expected streaming media quality at different bit rates
Excellent full screen quality for almost all content
Business Considerations
• Who is the intended audience for this webcast?• What is the purpose of the webcast? What is the
need? Is a webcast the most efficient way to distribute the message?
• Where is the webcast taking place?• When is the event?• Why? Is there really a need to do this or is it just
“cool”? Will the webcast pay for itself with new revenue or through cost savings?
If you have good answers to the previous questions then ask these:
• Does it have to be live?• What are the cost considerations?• What is the ROI?• Are there legal considerations?
Live is always more expensive than recording and archiving it for later use.
What are possible events with time sensitive content?
• Breaking News• Distance Learning• Stock Market activities• Music Events• Sporting Events• Community Event
Where are you going to spend your money?
• Budget will determine both the quality and reliability of a webcast
• Single or three camera shoot? – Your most exorbitant line item will be your production costs.
• Bandwidth costs
Where are you going to spend your money?
Unlike radio or broadcast television, you must pay for the additional bandwidth required each time someone tunes into your webcast. The prices are astoundingly random based upon what carrier you use. Figure somewhere between $75 and $35 per megabit from network carriers. Shop around before you buy.
How do you know your bandwidth needs?
• Measured in bits per second (bps) of the information sent concurrently
• Because these numbers get big fast we use Kbps and Mbps
• A kilobit is 1024 bits • Megabit is 1024 Kilobits (1024x1024) or
1,048,576 bits
How do you know your bandwidth needs?
• Here is the rub…
• Data is measured in bytes, not bits.• There are 8 bits to a byte • A gigabit is 1024 Megabits
So…
Let’s say you have a show
• There are 100 viewers for your webcast• They will all watch a 300Kbps stream • 300Kbps x 100 = 30000Kbps This number is too unwieldy, so let’s figure out
how many Megabits per second
30000 / 1024 = 29.3 Mbps • Add about 20% for overhead and you land at:• 35Mbps sustained bandwidth
But how long is your show?
Let’s say it is 1 hour • 35Mbps x 60 seconds per minute x 60 minutes
per hour 35x60x60 = 126000 Megabits
But wait, we need bytes, not bits.
126000 / 8 = 15750 Megabytes • The number is still too unwieldy so divide by
1024 to get Gigabytes 15750 / 1024 = 15.38 gigabytes
How do you know your bandwidth needs?
So when you talk with a content delivery network about prices you can confidently state that you need approximately 35 megabits of concurrent capacity, and you expect to transfer about 16 gigabytes of data.
Usage Logs and Metrics
• They will vary based on the CDN you chose• How many watched• How long they watched• Where they were from
Rights
• Do you have rights to the images and music used in the webcast?
• Do you have rights to the graphics and video used?• How likely are you going to be sued?• Do you have releases from all people and locations
used in the webcast?• Do you have a labor union to deal with either on
site or licensed material?
So how are webcasts produced?
• The process is essentially the same as producing a program for broadcast, except the signal is sent to a streaming encoding solution instead of a broadcast tower or cable system.
The same approach of good audio and video
engineering applies to both. • Crap in equals crap out.
The difference between an on demand streaming file and a webcast is there is no room for error. It is live so you need to have it tested and working prior to the event. Because it is a real-time event, it will affect every phase of production.
This includes:• Planning – justifying costs, location, tools, crew• Production• Encoding• Authoring – connecting the audience to the
webcast via a link on a web page• Distribution – securing an infrastructure that is
robust for your needs Remember: If you have not planned it right your webcast
can grind to a halt. This can be a career-ending move. Be certain you have not only created a plan, but you have redundancy in place in case of failure
Where do we start?
• Step one: Plan – 95% of the work happens before the event
• Step two: Plan some more• Step three: Check out your location – do you
have power? How do you connect to the web? What are the acoustics like? Who are your points of contact?
• Step four: Change your plans
Where do we start?• Spend a significant amount of time planning• Do a site check• Acquire and test all the equipment necessary for the webcast• Acquire and test all the encoding hardware necessary, bring
extra• Examine and test your streaming server architecture – any
license issues with the number of streams you expect to distribute simultaneously?
• Do a body count – do you have enough of the right people in the right jobs?
• Test connectivity on site BEFORE the webcast This includes testing the broadcast equipment, load-testing the server, test the links on the website
Where do we start?
Bottom line:• Take the time to plan• Keep it simple• Bring two of everything• Be kind• Start early
Business considerations
As discussed earlier:
• Who is your audience?• Do you really NEED to do a webcast?
Is there a better solution?• How much might it cost?• What is the return?
Production Considerations
Do it yourself or outsourcing
• Which parts?• How do you find a partner?
– Production Partner– Distribution partner– Marketing partner
• Ask to see examples of their work
Some nasty questions to ask a potential encoding partner
• Do they know how to set up redundant encoders?• Have they had experience bonding ISDN lines and
knowing how to force them to dial long distance?• Do they know how to remix the audio and switch
between multiple video inputs?• Do they know how to work with the camera
technicians to have the video shot in a way that works best for a webcast?
• Will they advise you on what backgrounds and colors work best for streaming media?
From “Hands-On Guide to Webcasting”
Pricing and Providers
Entering into an agreement with a CDN (Content Deleivery Network) is not unlike buying a car
There is lots of smoke and mirrors and no one
can agree on what to call the same service from provider to provider
Two primary charge models for webcasting distribution:
• RSVP Model – charged based on the number of simultaneous streams used at any one given time. Usually a reserved number of streams
• Throughput model – charged based on the total amount of data delivered over the
network during the course of the event.
The factors common to any charging model would be:
o Length of the evento Time of the evento Number of formatso Number and size of bit rateso Geographic distribution
Additional fees may include:
• Some sort of registration to authenticate a user
• Pay Per View• Late notice or last minute event
Who to talk to about a CDN Solution
• Limelight Networks (www.limelightnetworks.com)• Akamai (www.akamai.com)• Mirror Image (www.mirror-image.com)• SAVVIS (www.savvis.com)• VitalStream (www.vitalstream.com)
For Small Business• PlayStream (www.playstream.com)
For Financial Business• Thompson (www.thompson.com)• ON24 (www.on24.com)
OK, you are on your own
Equipment and crew
• What is your video source (type and fps of video feed)?
• What is your audio source?• Are you renting the gear? Purchasing it?• Are you hiring a 3rd party company to
produce the video feed?
Some of the gear you will need:• Microphones (Lav, handheld, shotgun, spares)• Cables of many types• Camera• Audio mixer• Video switcher if multi-camera• Distribution Amps (so you can split your feeds)• Isolating transformers and humbuckers• Batteries• Encoding computers• Monitors• Communication system (for crew and back to
broadcast operations center)
What Crew might you need?
• Camera Operators• Audio Engineers• Video Engineer / Technical Director• Encoding Technician• Production Assistants• Director• Producer
Computer hardware• How much horsepower will you need?• Do you need a capture card?• Do you need an external capture unit?
What software do you need?• If you are encoding via software do you have
the proper encoder?• Will you be generating multiple platforms?
(Real & Windows Media for example)
What do you need to deliver?• What is your desired bit rate?• What is your desired canvas size?• Do you need to deliver multiple bit rates?
When you stream you also archive
• Oddly, most viewers will see the webcast as archived media
• You will need to archive the webcast somewhere• If not on tape or from the distribution point then
you will archive locally
Make sure you have room on your hard drive
3 ¾
These files are not that huge so space should not be that much of a problem unless you are archiving uncompressed media
Suggested minimum Audio bitrates for streaming
FM Radio
Suggested Screen resolutions240x180
For the most part, these sizes are glorified postage stamps
Some Hardware solutions for streaming media
Communitek (www.communitekvideo.com)Digital Rapids (www.digital-rapids.com)Sunnyside Software (www.sunnysidesoft.com)Viewcast (www.viewcast.com)Winnov (www.xstreamengine.com)
Distribution Planning
Audience size will directly impact the amount of distribution you require
Small may only need a single local server, large may require geographically distributed server farms. Discuss your needs with your network administrator
How will you author the web site?
• Will the stream be incorporated into a dynamic site?
• Have you already built and tested the shell?
• Will this be a pop-up player or embedded into a web page.
Authoring considerations:
• How is the website going to be featured on the website?
• Link on the homepage?• Will that link go to an intermediate page or directly
to the stream?• Will a user have to fill out forms or enter
passwords?• Will the media be embedded, use a pop-up
window or a stand-alone application?
Authoring considerations:
• Always put a link to your webcast on your home page. There is no reason someone should have to search for the feed.
• A complex home page combined with a streaming
media event can overload your server and bring the whole thing down. Think about perhaps simplifying your home page on the day of a big event
Emedded or stand-alone• No clear answer.• Some embedded players are seen as a security risk
by the browser or operating system on a user’s computer. While it only requires enabling something as simple as a java script to run, some users may be scared off by the warning.
• On the other hand, a player like Flash is installed on over 98% of the web browsers world-wide.
• Consider offering the option of a link to an embedded player and one to a stand-alone player
Linking to a stand-alone player• You can’t link directly to the streaming media. • Browsers use HTML and streams use RTSP• Browsers have no clue what that data means • You create a metafile that the browser links to• These are small text files that are placed on web
servers• They use special file extensions such as .ram
and .asx that are uniquely associated with media players. Because it is text, the browsers understand it
Windows Media Metafile example• Windows Media uses an XML-based format
(you can recognize it by the angled brackets)• Similar to HTML <asx version=”3.0”>
<entry><ref href=”rtsp://drewke.wmserver.com/streamingclass_live” />
</entry> </asx> • Windows Media uses three different file extensions for streaming
media, all ending in x– .wax for Windows Media Audio– .wvx for Windows Media Video– .avx for generic Windows Media
Real Media Metafile example• Real Media metafiles are plain text and take either .ram
or .rpm file extension– .ram is used when you want the standalone RealPlayer to play the
stream– .rpm is used when you are authoring an embedded player
• A Real metafile would contain:
rtsp://drweke.realserver.com/streamingclass_live.rm
Type this into a text editor, save it with the proper file extension and link to it on your page
QuickTime Metafile example
• A QuickTIme metafile uses the .qtl (QuickTime Link) file extension and is also XML based
<?xml version 1.0”><?quicktime type+”application/x-quicktime-media-link”?><Embed src=”rtsp://drewke.qtserver.com/streamingclass_live.mov” />
An example of embedding a Quicktime player into a web page using ActiveX
• IE uses ActiveX Control to embed functionality into web pages
• ActiveX controls are recognizable by the use of the <object> tag
<object classid=clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B”
codebase=http://wwwapple.com/qtactivex/qtplugin.cabwidth=”240” height=”180”><param name=”src” value=”rtsp://drewke.seanet.com/streamingclass_live.mov”>
</object>
The problem with this solution is it is unique for Iinternet Explorer
You would have to sniff out the user's browser and write the code so it will work across multiple browsers with unique entries for each.