COM 597 Streaming Media Lecture 4 July 12, 2007 A little reminder Don't forget your paper due in about 3 weeks 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 dont 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 Capacity Connection TypeBandwidth / Bitrate Dial-up (56K modem)34-37 Kbps Broadband (Cable / DSL) Kbps Frame Relay, Fractional T1128Kbps 1.5 Mbps T11.5 Mbps Ethernet10 Mbps T345 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 Bit rateAudio QualityVideo Quality 32 Kbps (56K modem)FM Radio Quality Very small screen (160x120) Acceptable for talking heads 64 Kbps (ISDN) Very good quality. CD Quality at approximately 96 Kbps, depending on codec used Small screen (196x144, 248x180) Acceptable for talking head content, dreadful for high-motion contnent 256 Kbps (typical low end broadband sustainable speed) Excellent Quarter Screen (320x240) Good quality for talking heads, acceptable quality for most content except very high motion content like sporting events and music videos 700 KbpsExcellent Excellent quality for all content at quarter screen size (320x240); good quality for full screen size (640x480) 1.5 Mbps (Ethernet and High Speed Internet) ExcellentExcellent 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 Lets 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 lets 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? Lets say it is 1 hour 35Mbps x 60 seconds per minute x 60 minutes per hour 35x60x60 = Megabits But wait, we need bytes, not bits / 8 = Megabytes The number is still too unwieldy so divide by 1024 to get Gigabytes / 1024 = 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: oLength of the event oTime of the event oNumber of formats oNumber and size of bit rates oGeographic 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 Bit RateOne Hour FileHours of storage per Gigabyte 37 kbps16 megabytes kbps56 Megabytes kbps132 Megabytes7 700 kbps308 Megabytes3 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 Bit RateMinimum Audio Bit RateQuality Dial-up (34-37 kbps)8 kbpsAM Radio Low Broadband ( kbps)16 kbpsNearly FM Radio Standard Broadband ( kbps)32 kbpsFM Radio Suggested Screen resolutions Bit RateLow Motion ProgrammingHigh Motion Programming Dial-up (34-37 kbps)176x132160x120 Low Broadband ( kbps)240x180192x144 Standard Broadband ( kbps)320x240240x180 For the most part, these sizes are glorified postage stamps 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 Suggested minimum Audio bitrates for streaming Bit RateMinimum Audio Bit RateQuality Dial-up (34-37 kbps)8 kbpsAM Radio Low Broadband ( kbps)16 kbpsNearly FM Radio Standard Broadband ( kbps)32 kbpsFM Radio Suggested Screen resolutions Bit RateLow Motion ProgrammingHigh Motion Programming Dial-up (34-37 kbps)176x132160x120 Low Broadband ( kbps)240x180192x144 Standard Broadband ( kbps)320x240240x180 For the most part, these sizes are glorified postage stamps 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 users 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 cant 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 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 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 tag 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. Multicast v. Unicasting Streaming media may be delivered in three ways Unicast: A server delivers a stream to each individual user. On-demand is always Unicast. Broadcast: A single stream is delivered to many users simultaneously, with each user having his/her own connection to the server Multicast: A single stream is broadcast on a network using a special multicast IP address. When viewers join, their players are instructed to grab packets of the broadcast on the network. Multicast is only used for live and simulated live delivery What is "Simulated Live"? A stream of prerecorded content presented as if it is live. Most webcasts are delivered via unicast delivery. One user --- One stream In a broadcast situation you have a large number of people all watching the same stream. Using traditional Unicast model, each user is sent an individual and unique stream. That puts a big load on the network and the servers. Multicast allows multiple users to tap into one stream. Multicast is more efficient because only one stream is sent out across a multicast-enabled network. Here is how it works To get the media a media player simply tunes into a particular IP address that has the stream. The local router sends each media player a copy of the stream. The nice part is the stream only has to traverse the distance from the router to the server, not around the world or across the country. Here is how it works Multicast routers can send copies of the stream to other multicast routers, which can then multicast the stream on a local network Multicast will only work if both the server and client are multicast enabled. All three of the major platforms support multicasting Multicast pitfalls One of the pitfalls of multicasting on the internet is all the routers on the path must be multicast enabled. That is why you might need to rely on a CDN This is principally because many of the folks controlling different networks dont want stray multicast content on their networks. Both Real and WindowsMedia support protocol rollover, where viewers who cant get the multicast are connected to the stream via unicast. Other Protocols to be aware of Web AcronymNameUse UDPUser Datagram ProtocolSending data in a continuous stream RTPRealtime Transport Protocolwhen streaming media servers build packets of data and send them to the media player, the RTP instructs the server how to reconstruct these packets. This is used specifically with RTSP RTCPReal Time Control ProtocolRTCP packets work with RTP packets to check delivery. It is a way to check service quality MMSMicrosoft Media ServicesA proprietary streaming protocol, just like RTSP. Both Real and MS support MMS. Most Windows Media Metafiles have MMS as the irst three letters of the streaming URL 1-2-3 Smile! SMIL stands for Synchronized Multimedia Integration Language W3C developed it for Multimedia on the Internet (Now SMIL 2.1) It is used for displaying concurrent data interactivity, layout, timing How does SMIL work? An author can specify multiple data types and different regions in the UI Streams can be combined, re-used, and moved around in time and space This gives a developer both freedom and flexibility Lets say you were creating a sports show At the bottom you can stream a text stream of recent scores. It will render as high quality graphics Thumbnails of additional information Logo of your show in the corner Streaming media What is SMIL SMIL is simple XML-based mark-up language SMIL files are simple text looking an awful lot like HTML SMIL can be played back on a variety of players, but are not universal SMIL Coding Concepts When creating SMIL presentations you need to think about your layout in layers Not just for design but also for coding SMIL works not just in X & Y axis, but also on the Z axis (index) This is how you manage layer order SMIL Coding Concepts A SMIL document is similar in structure to an HTML document Like HTML there is a section and a section The section contains layout and metadata information. The section contains the timing information Stream Synchronizing in SMIL Clips can be grouped so that they play back in parallel or in sequence. These groups can be nested (groups within groups) When you use timing attributes you can specify timing relative to the presentation timeline or the clip's internal timeline Where are you likely to see it? SMIL is being implemented on handheld and mobile devices Multimedia Messaging Service (sometimes referred to as Mini-Me SMS) is a video and picture equivalent of SMS also predominantly used in mobile media. More SMIL Info Beginning Chapter in Streaming Media Bible (pp ) RealNetworksWC3Streaming Media World Streaming Bitrate Variations Web AcronymNameUse VBRVariable Bit RateThe encoded rate it is a bit more fluid. Especially with content changes in quality e.g. low-motion talking head v. high motion footage. This is most often used in a non-streaming scenario. CBRConstant Bit RateRate is constant through the file MBRMultiple Bit RateThe player and server shift among two or more constant bit rates, depending on throughput Workshop