Webcast Distribution
Now that you’ve invested the time and money to produce and encode a high-quality webcast, it’s time to distribute it to the masses. This is where the Internet becomes a new mass medium, one without boundaries or licensing restrictions.
Thankfully, there is an existing web server infrastructure on the Internet, and streaming servers are not that different from web servers. There are a few ways in which they differ, and ways in which server hardware can be optimized for streaming, but basically the concept is the same: streaming servers respond to client requests for files. That’s why it’s important to leverage the experience of your network administrators—they understand how to build solid serving architectures.
This chapter covers the basics of streaming servers, and how you might want to set up your server architecture. In practice, you’ll be working closely with your Network Administrators or working with a content distribution network (CDN) partner. No matter which approach you choose, it is helpful to understand how streaming servers operate. This chapter covers:
• Distribution Basics
• Distribution Techniques
• Server Setup Examples
Distribution Basics
Streaming servers are fairly simple. In a nutshell, they listen for requests from clients, and then fulfill them. The requests may be for an archived file, in which case they look to see if the file exists. In the case of webcasts, they look for a live stream or publishing point of the same name.
The main difference between streaming servers and web servers is that there is a persistent, two-way connection between streaming servers and players. If a viewer wants to pause the stream, the server must stop sending data. If the viewer wants to rewind or fast forward, the server needs to act accordingly. Of course, during a webcast these actions are not available, but nevertheless the functionality must be available.
Streaming servers therefore use different protocols than web servers. Whereas web servers use hypertext transfer protocol (HTTP), streaming servers use the real time streaming protocol (RTSP) or proprietary protocols such as Microsoft Media Services (MMS). These protocols are designed for the unique demands of streaming, which requires a two-way connection, and the ability to tightly control the data stream.
Streaming servers also offer additional functionality, such as the ability to build play lists, and the ability to insert advertising streams or banners. The feature sets vary from platform to platform. This chapter focuses on basic streaming server functionality, which is all you need to get your stream out to a large number of people. If you want to utilize the advanced functionality your server platform offers, you’ll have to refer to your server documentation.
Size Matters
The first thing to consider when setting up your servers is the projected size of your audience. Streaming servers are very efficient and can easily service thousands of concurrent requests. You’re more likely to encounter bandwidth issues than you are server resources issues.
For example, let’s assume we’re expecting an audience of 500 viewers, and we’re serving broadband streams at 300 Kbps. That’s nearly 150 Mbps. If your servers have 100 Mbps network cards in them, as most do, you’d hit your ceiling somewhere in the vicinity of 250-300 users. If you’re using gigabit Ethernet, this would bump up to 2,500-3,000 users. This is because each stream will have some overhead associated with it, and the practical maximum load on a network is 60% to 70% of the theoretical capacity.
If we assume your server has a 100 Mbps network card, it’s easy to see you’re going to need multiple servers for this webcast. If your server has a gigabit Ethernet card, you could service your audience with a single server. Of course, you should always have at least two servers, for redundancy purposes.
ALERT
|
You also have to make sure you have enough bandwidth. Many ISPs clamp down bandwidth on a user-by-user basis. If you’re planning to use a lot more bandwidth than normal, you need to get on the phone and give your network crew plenty of advance notice. |
Running a single streaming media server is well within the reaches of anyone who reads this book. Running a well-balanced, multiple location server array may not be. These days, many streaming media providers choose to use a third party to host their webcasts. Large-scale streaming providers have the infrastructure, the bandwidth, and the experience required for large webcasts.
Even if you’re going to outsource your webcast distribution, it’s important to understand how the process works, so that you understand exactly what third parties are offering. Also, when something goes wrong, you’ll be able to figure out if it was something you did—or if it was your distribution partner.
Equipment
Streaming software can run on virtually any computer, though it’s best to have a server-class machine. Server-class machines are built to withstand years of continuous performance. Streaming servers should also have plenty of RAM, because each stream needs a small amount of dedicated RAM to keep the process open. Start with a Gigabyte of RAM and work your way up from there.
ALERT
|
Streaming servers don’t do much processing, so they don’t need powerful processors. However, a server that is running at 10% CPU load will run much more reliably than a server running at 60% CPU load. There’s really no need to buy a quad-processor box, but a server-class processor is always a good idea. |
Since you’re going to be running a number of streaming servers, you’ll need a way to load balance across the machines. This can be done using hardware or software. If you already have load-balancing hardware for your web servers, this equipment can be used to load balance your streaming servers. You also can load balance via virtual servers such as the Linux Virtual Server, or a simple script.
Platforms
QuickTime, Windows Media, Real, and Flash all have mature server platforms. The platform you choose will depend on a number of issues:
• Audience: If your audience is a known quantity, you may lean towards a particular player, and therefore the corresponding server.
• Server Features: Some server platforms, most notably Windows Media and Real, offer more functionality that is tailored to webcasting.
• Operating System: If your organization has standardized on a particular OS, you may need to choose your server accordingly.
• Stream Quality: While all streaming platforms offer acceptable audio and video quality, the quality of Windows Media and RealMedia currently exceeds that of QuickTime and Flash.
If you’re going for maximum coverage, it’s usually a good idea to offer at least two formats. This may involve running two streaming platforms, but might be worth it if you’re trying to reach every last audience member. This is another reason why using a third party to host your webcast is a good idea.
Author’s Tip 
The Helix server from RealNetworks can serve live Real, QuickTime, and Windows Media streams. The Helix server can not, however, serve Windows Media 9 Series MBR files.
Distribution Techniques
After you decide on the platform (or platforms) you’ll be using, it’s time to think about your server architecture. You’re going to need multiple servers—that much you know. But how will they be deployed? Will they be co-located at a single ISP, or will they be geographically dispersed? How will traffic be distributed across the servers?
The answers to these questions depend largely on the scale of your broadcast, and your budget. Ideally, you want geographically dispersed servers, for two reasons. First, having the servers in different locations on different network segments gives you redundancy if one of the data centers suffers catastrophic failure. Second, your audience may get better stream quality if they’re physically closer to the server.
There is some disagreement as to whether quality improves when the stream has a shorter distance to travel. The problem is not the distance the data has to travel; rather it’s the traffic that the stream may encounter, or a faulty router that may be overloaded or dropping packets. If there’s a traffic problem between you and the streaming server, it doesn’t make a bit of difference where the server is located. However, statistically speaking, having servers in a number of locations certainly reduces the probability of problems.
Regardless of where they’re located, you’re going to need more than one, and therefore the live stream will have to be distributed to all the servers. If you’re running redundant encodes from the site, you may want to send them to two different servers, for even more redundancy. Figure 11-1 illustrates what a redundant server architecture might look like.
Figure 11-1
A highly redundant webcast infrastructure.
In Figure 11-1, two encoders each feed two different intake servers. The intake servers then feed public servers, creating a web of connections that make this setup highly redundant. Depending on which streaming platform you are using, you would either use metafile redundancy, load balancing, or the redundant features built in to the server.
Live Server Redundancy
Webcasts require a redundant server architecture, that much is clear. All the major streaming platforms offer the ability to create redundant architectures, but use different terminology when they describe it.
• Redundancy on the QuickTime platform is described in terms of relays. Any QuickTime server can act as a relay, forwarding a live stream to other servers.
• RealServer redundancy is described using the concept of splitting. Any RealServer can act as a transmitter, sending the stream to other servers configured as receivers.
• The Windows Media system describes live broadcasts in terms of publishing points. A publishing point can have an encoder as its source, or another server.
Redundant server architectures usually consist of a number of origin or ingress servers that receive incoming encoded streams from encoding software. These servers distribute the streams to public servers, which service requests from the audience. The public servers can be coincident with the origin servers, or in completely different locations. The complexity of your architecture is dependent only on your imagination.
Setting up your redundant architecture requires configuration of both the origin servers and the public servers. The origin servers have to be configured to either push streams to public servers, or to allow public servers to pull streams from them. Similarly, public servers have to be configured to allow incoming streams from origin servers, or to request the necessary streams from the origin servers.
Depending on the platform you’re using, you may have to set certain permissions, fill in IP addresses here and there, and specify other necessary parameters. This is easily taken care of via the administration interface provided by your platform, or via a configuration file. Examples of this are given later in this chapter in the “Distribution Examples” section.
After you’ve set up your redundant architecture, you’ll need some form of load balancing to take advantage of it. Load balancing can be done via hardware or software, using varying degrees of intelligence. For example, some load balancing techniques take into account the processor load on each machine when determining which server to send a request to. Others take geography or network paths into account, while some simply use randomization to distribute the load.
Author’s Tip
If you have existing load balancing hardware or software for your web servers, it can probably be used for your streaming servers with a few modifications.
Deployment Considerations
Figure 11-1 illustrates what a redundant webcast server architecture might look like, but says nothing about where the servers are located. The public servers could be located in the same ISP, or geographically dispersed. The physical location of your servers will depend on the audience you’re trying to cater to, and of course budget. Another consideration is the type of broadcast you’re doing: unicast or multicast.
Unicast vs. Multicast — Most webcasts are delivered via unicast delivery (see Figure 11-2), where each audience member is sent a unique copy of the stream. This is particularly inefficient during webcasts, because each audience member must be sent a unique copy of the stream, even though they’re all watching the same programming. A more efficient delivery method known as multicasting can be used to reduce the number of outbound streams.
Figure 12-2
Unicast vs. multicast delivery.
Multicast distribution is similar to traditional broadcasting methods. Using multicast, a single stream is sent across a network. Audience members grab a copy of the data instead of having a unique copy sent to them. This approach can reduce traffic levels drastically.
Although in theory multicasting sounds fantastic, in practice multicasting is not yet feasible on the public Internet. Multicast requires all routers on the network to be multicast-enabled, and for all routers to pass all multicast traffic. The problem is the Internet is a widely-dispersed resource with thousands if not millions of people controlling different network segments, and not everyone wants stray multicast traffic on their networks.
ALERT
|
Given the security conscious times in which we’re living, getting multicasting to work on the public Internet will be a massive undertaking. |
Multicasting should be used in closed environments such as corporate LANs. If you’re doing an internal broadcast, it’s quite simple to do it as a multicast. Not only does it cut down on your LAN traffic, but also since the traffic load is lower, you can afford to encode at a higher bit rate. Internal multicasts should target bit rates in the 700 Kbps-1 Mbps range. This provides enough quality for full screen, full frame rate webcasts.
Hybrid approaches can be used to take advantage of multicasting where it makes sense. For example, Figure 11-1 could include servers that are situated on multicast-enabled networks. Each of those servers would receive a single unicast stream, and then multicast the stream to a local area network.
Live Stream Latency — One drawback to creating redundant server architectures is an increase in stream Latency. Latency is the difference between when an event happens and when the broadcast audience actually sees or hears it. Typical webcasts may have latencies of 15–30 seconds.
The latency occurs for a number of reasons. First, the encoder encodes in near real-time, but not instantaneously, so a small amount is due to the time it takes to encode. The second culprit is the origin server. Servers buffer the incoming streams as a protective measure against network traffic or dropped packets. If you have a highly redundant architecture, with multiple levels of servers, each server will add latency to the stream.
In many cases, latency is not a problem, because the audience is unaware of it. However, in situations where there needs to be audience participation, latency is a big problem. There’s not much you can do about it. If latency is a big issue, then the commercial streaming media platforms are probably not the best answer for you.
Firewalls — Firewalls protect computers from intruders and hackers by monitoring the traffic to and from your servers. Typically firewalls are configured to accept incoming traffic on a limited set of ports, and using a limited set of protocols. Webcast professionals have to worry about a number of different firewalls: the firewalls that may be protecting the distribution servers, the firewalls that the encoders may be behind, and finally the firewalls that the audience members are most likely behind.
If you’re using a firewall to protect your streaming servers, be sure to open up the required input and output ports, and be sure to allow the right kind of traffic. The ports used vary between streaming platforms, but generally include port 554 for RTSP traffic, port 80 for HTTP traffic, and a number of ports for communication between servers, players, and other servers.
If you’re encoding at a remote location and you’re behind a firewall, you’ll most likely have to use the push method of encoding, because firewalls generally don’t allow remote servers to pull data from behind the firewall. There are exceptions, but they generally involve a bit of advanced configuration on the firewall. Usually it’s easier to just use push encoding.
ALERT
|
If your audience is behind a firewall, they will most likely be blocking RTSP traffic, which most firewalls do by default. Streaming servers are aware of this, and do what is known as protocol rollover to mitigate the problem. Using protocol rollover, a streaming server will first attempt to send data via RTSP on port 554, and if it does not receive acknowledgement from the player, then it “rolls over” to RTSP packets sent via TCP/IP on port 80. If this fails, the final option is to send packets via HTTP. |
Webcasting “Canned” Performances
Knowing all you do about the complexity of webcasts, the question has to be asked: “Does it have to be live?” We’re not necessarily talking about the experience the audience has. For example, many “live” events on television are actually produced hours if not weeks in advance, and then simply broadcast “live.” To the audience, the experience is the same.
Streaming media servers enable the exact same functionality. You can produce an entire program, polish and edit it as you like, and then “webcast” it at a predetermined time. As far as the audience is concerned, the event is live, but it reduces the complexity and the risk of a truly live webcast by orders of magnitude:
• You don’t need encoding equipment on site
• You don’t need connectivity on site
• If you mess up, you can do another take, and edit
• If equipment fails, you can fix it, and do another take
Windows Media Services enables simulated broadcasts by using a single file or a play list as a source for a broadcast publishing point instead of an encoded stream. When the publishing point is started, the server automatically begins serving the play list, and the simulated broadcast begins.
The RealServer provides a small software application called the G2SLTA (simulated live transfer agent) that plays back encoded streams and sends them to a server as if it were an incoming live stream. The G2SLTA can be run on the same machine as the server, or on a remote machine. The G2SLTA simulates the broadcast of a single file or a list of files, however, if you’re using a play list, the files must have been encoded using the same settings.
The QuickTime server provides simulated live broadcasts via the Playlist Broadcaster application. The Playlist Broadcaster can simulate broadcasts of single files or play lists. When using play lists, all files must be encoded using the exact same settings.
Author’s Tip
Even if you are shooting an event that cannot be stopped, it is still significantly less complex if you don’t have to worry about encoding and connectivity on site. If your programming doesn’t have to be live, it is well worth Considering.
Server Setup Examples
All streaming servers run based on settings that are read from a configuration file. The Windows Media Services and RealNetworks Helix platforms offer interfaces that enable an administrator to configure the server remotely. This makes server setup easy, and remote troubleshooting and problem solving much simpler.
Most streaming server software is ready to run as soon as it is installed. You must set up an administrative account and accounts for any other people who will be using the server. You also may want to configure the server as part of a redundant architecture, in which case you’ll need to configure whether the server is relaying streams to other servers, or using other servers as a source.
RealNetworks Helix Server
The Helix server provides a simple web-based interface for all administrative tasks (see Figure 11-3). The first thing you’ll want to do is configure all your ports. This interface is available via the Server Setup menu option on the left side. In most cases it’s best to use the default values, because other applications such as encoders and firewalls may assume certain known ports.
There are a number of other general parameters you can set up in the Server Setup section, but most of these can be left with their default settings. Click on the Broadcasting link on the left for webcast setup (see Figure 11-4). The Helix server is capable of webcasting Real, QuickTime, and Windows Media streams, and offers a separate screen of options for each.
Figure 11-3
Configure your ports via the Helix Administrator.
Figure 11-4
The Helix server options for RealProducers.
If you’re webcasting Real streams via a Helix server, there are different settings depending on what version of the encoder you’re running. Legacy encoders require a port number (which defaults to 4040), and default to a mount point of encoder. This means that all your live streams will appear in a directory named encoder. You can change this on this screen if you want. You also can specify an authentication mode on this screen, and create user-names and passwords.
The Helix server also has configuration pages for QuickTime broadcasts and Windows Media broadcasts. On the Windows Media configuration page, you can specify a mount point for Windows Media broadcasts, as well as information about the source encoder (see Figure 11-5). The Helix server only supports pull encoding, and therefore requires the IP address and port from which it should pull the live stream.
Figure 11-5
Enter the Windows Media Encoder information for Windows Media broadcasts.
An interesting feature provided by the Helix server is broadcast redundancy (see Figure 11-6). Broadcast redundancy enables the Helix server to accept more than one source for a live stream. If one stream should fail, the server will automatically switch to another stream as the source. The configuration enables you to configure the behavior of this functionality.
Figure 11-6
Configure the broadcast redundancy.
For server redundancy, you have to set up your servers as transmitters and receivers. These settings are available from the Broadcast Distribution option on the left side (see Figure 11-7). To configure a transmitter, you have to specify at least one receiver to which the server should send streams. You can specify which streams to distribute by specifying a particular mount point. Any streams encoded to that mount point will automatically be distributed to all the receivers. You also must specify the IP address or hostname of the receiving server.
Figure 11-7
Configuring a Helix server as a transmitter.
Be sure to scroll down on this screen, as you have to make a note of what port range and what type of security the transmitter will use. The receiver must be configured to use the exact same port range and security type, or the distribution will fail.
To configure a Helix server as a receiver, click on the Receiver menu option on the left under Broadcast Distribution. The receiver screen is very similar to the transmitter screen (see Figure 11-8). You must specify the transmitters that are allowed to send streams to the server, the port range they’ll be using, and the security type, which may require a username and password.
Figure 11-8
Configuring a Helix server as a receiver.
There are many other configuration options available via the Helix Administrator. There is also a live monitor that enables you to monitor server performance in real time. This can be handy for troubleshooting, and for getting a rough idea of how many people are connected to your webcast.
A full discussion of all the configuration options of the Helix server is beyond the scope of this chapter. For more information, please refer to the documentation that is available from the RealNetworks website:
http://www.realnetworks.com/resources/documentation/index.html
Windows Media Services
Windows Media Services is available as part of the Windows Server software. Before you configure your streaming server, make sure the operating system and the required services are configured appropriately. You can do this by checking the current settings against the default service settings in the Windows Server Help and Support Center.
Setting up a Windows Media server is done via a wizard.
1. From the Manage Your Server window, choose “Add or remove a role” (see Figure 11-9). The Manage Your Server window should already be open, but if not it can be opened via the control panel. If you’re starting with a fresh install of Windows Server, you may be confronted with a Preliminary Steps window; if so make sure you’ve satisfied all the necessary steps before clicking “Next.”
Figure 11-9
To add streaming services, add a “role” to your Windows Server.
2. The server then analyzes what services are already running. If you’re working on a new install, you can either set up a default common set of options, or use the custom configuration method to set up a single service, in this case a streaming server. The safest option is always to set up the minimum amount of services. In this example, we’ll assume we’re only setting up a streaming server. Choose the “Custom configuration” method.
3. Eventually you should see the Server Role window (see Figure 11-10). Highlight the Streaming media server option and click “Next.”
4. This brings up a screen where you confirm your selection. Click “Next.” The Windows Media server then pops up a widow and automatically installs and configures your Windows Media Server. No feedback is required from you.
Figure 11-10
Adding a Streaming server “role” to your Windows Server.
5. When the Windows Media Server has been installed, the pop-up window will display a success message (see Figure 11-11). Click the Finish button. You should now see a Streaming Media Server listed in the Manage This Server window.
Figure 11-11
Congratulations! You’ve installed Windows Media Services.
Now that you have a server installed, you need to configure a publishing point for your webcast.
1. From the Manage This Server window, choose the “Manage this streaming server” link. This opens up the Windows Media Services management window. This is where all the day to day management and administration of your Windows Media services takes place.
This page lists the name of your server, and whether or not it is running (or “started” in Windows Media-speak). You can test your server on this page, monitor the hardware performance, and see who is connected to your server.
2. In this case we’ll create a publishing point by clicking on the “Create a broadcast publishing point” link (see Figure 11-12). This opens up the Add Publishing Point Wizard.
Figure 11-12
Click the green arrow next to “Create a broadcast publishing point” to set up your webcast.
3. The Add Publishing Point Wizard walks you through the simple process of setting up a publishing point. Click “Next” to get through the welcome screen, and then enter a name for your publishing point on the next screen (see Figure 11-13).
Figure 11-13
Enter a name for your publishing point.
4. Next, specify the source for your live stream. You’ll see that the Windows Media Server enables you to use different types of sources, easily enabling rebroad-casts of previously recorded files, or broadcasts of play lists (see Figure 11-14). Choose your source and click “Next.”
Figure 11-14
Choose the source for your webcast.
5. The next screen asks what type of playback scenario you want to create (see Figure 11-15). For webcasts, you want to create a Broadcast Publishing point. Some source options only enable this option; others enable you to create on-demand publishing points. Choose “Broadcast publishing point” and click “Next.”
Figure 11-15
Choose “Broadcast publishing point” for your webcast playback scenario.
6. Next it’s time to choose a delivery option. If you’re webcasting on the public Internet, choose “Unicast.” If you’re webcasting on a multicast-enabled network, you can use multicast to reduce network traffic. You can enable multicast with unicast rollover and cater to both audiences, but this may cause some delay while the Windows Media Player rolls over to unicast. For most applications, Unicast is the easiest approach (see Figure 11-16).
Figure 11-16
Choose your delivery option.
7. The next window is where you specify the address of your encoder. For pull encoding, you must have a hard-coded IP address for the Windows Media Encoder. Your encoder will display the IP address and port number it is expecting connections on. This must match the information you enter here (see Figure 11-17).
Figure 11-17
Enter the IP address of your encoder for pull encoding.
ALERT
|
The IP address displayed in Figure 11-17 is a local network address and will only work if your encoder and server are on an internal LAN. You should use a routable IP address in most cases. |
8. Next the wizard asks if you’d like to enable logging on your publishing point (see Figure 11-18). You should always enable logging so you can keep track of who is watching your webcast, and for how long.
Figure 11-18
Always enable logging for your webcasts.
9. The penultimate screen of the publishing point wizard is a summary, displaying all the settings you just entered (see Figure 11-19). You also have the option on this screen to automatically start the publishing point as soon as the wizard is finished. Provided everything looks right, you can click the next button.
Figure 11-19
Click the “Start publishing point when wizard finishes” to enable your publishing point.
10. The final screen offers you the option of automatically creating a metafile or web page for your webcast. If you choose to have the server create a metafile for you, make sure the URL in the metafile is a fully qualified URL. The wizard defaults to using a local URL, such as:
mms ://Server2003/MyFirstWe beast
This will not be a valid URL for anyone outside of your local server domain. Your URL should use a fully qualified URL or IP address, such as:
mms://server1. mydomain.com/MyFirstWebcast
11. Once you start your publishing point, the server establishes a connection to your source, and your webcast is live. If you need to change anything about your publishing point, or indeed make any changes to your server, you can choose the appropriate selection from the tree of options on the left side. For instance, choose your publishing point from the left hand tree, and then choose the Properties tab (see Figure 11-20). On this page, you can modify all the settings for your publishing point.
Figure 11-20
Modifying your publishing point settings.
12. This is where you set up redundancy. On your origin server, you’d want to make sure that stream splitting was enabled on the Properties page. For your distribution servers, you’d click on the Source tab of your publishing point properties, and click on the Change button, which pops up the Change Content Source window (see Figure 11-21). Type in the URL for the remote broadcast point, and the server will pull live streams from the origin server.
Figure 11-21
Specify a remote publishing point to set up redundant server architectures.
There are a myriad of other configuration options available via the Windows Media Server. There is ample documentation on the Microsoft website, and the server comes with a built-in help system that can help you through most configuration options. For the most part, they’re simple to figure out, using the helpful wizards.
Log Files
Once you’ve successfully completed your webcast, the first question on everybody’s lips will be, “How many people were watching?” If you’re using a third party to handle your distribution, you may have access to real-time statistics that provide you with instant answers. If you’re distributing your own streams, you’ll find your answers in the log files.
Each time a streaming server processes a request from a client, it makes an entrance into a log file. The log file syntax varies from server to server, but at a minimum includes the following information:
• IP address of the client
• Date and time of the request
• The path and filename of the request
• The amount of data that was transferred
Depending on the platform you’re using, you may also have additional information in your log files such as the protocol used, the bit rate of the stream, the player version, and a number of other interesting tidbits. By analyzing this information, you can determine who is watching your webcast, which bit rate they’re watching, and how long they’re watching.
There are a number of programs available to analyze log files. Many web server log file processing programs are adding modules that allow them to process streaming server log files:
• AWStats
• Sawmill
• FunnelWeb
You should use the information you get out of your log files to refine your webcasting efforts. For instance, if your webcasts are 30 minutes long but the average viewer only watches for 10 minutes, then you need to think about your programming. You should be able to find out what player versions people are using to connect to your streams, which may enable you to upgrade the codec you’re using for your webcasts.
You also can get feedback about your distribution architecture from the log files. If many people are connecting from a certain geographic area, it might make sense to locate a server in their area for better performance. You also can look at error logs to see which servers are having the most problems, and why. Log files provide a wealth of information, and should be used to figure out how you can make your webcasts better.
Conclusion
Streaming servers used for webcasts don’t need heavy-duty processing power, but it never hurts to have a server class machine with plenty of RAM. Webcast serving architectures must be redundant. The amount of redundancy will depend on the scale of your webcast. You should always have at least one intake server and two public servers.
All streaming platforms offer good quality and robust performance. Your choice of streaming platform will probably have to do with your audience, your existing server infrastructure, and the feature set of the server.
Given the complexity of a webcast, you should consider whether it is possible to record the event in advance and then webcast it using a simulated webcast at a later time. Although it doesn’t offer the excitement of a truly live event, the audience may not notice the difference, and the reduced number of requirements makes it a worthy alternative.