Initiating a Stream
When ready, initiate streaming to the Preset targets you have check-marked in the Streaming Configuration panel, by clicking the STREAM/ENCODE button in the menu bar at the top of the Live Desktop panel.
The button displays elapsed time during streaming/encoding.
Once streaming has started, clicking the presets start or stop that individual preset independently from the others.
Note: You cannot click a Preset streaming on one encoder and expect it to switch to the other encoder. You must stop the first encoder, the select the other encoder.
Capturing a Stream
To archive a live stream file as it is created by an encoder, configure and check a File Capture preset for that encoder.
Production and Capture Considerations
If you’re not intent on live streaming, but wish to capture a live switching session, you would likely record at full resolution using the Record button (rather than Stream). The high quality captured files can then be used later in a DDR, or perhaps be transferred to another computer (even on a different platform) for external processing or editing.
Tip: Use an external hard drive to transfer the files between systems, or transfer them across a local network.
You can always convert these files to a streaming file format if you later decide you’d like to supply them for on demand Internet viewing. This lets you retain best quality right through to final output. When you eventually encode for streaming, you can choose settings that best suit the intended audience and streaming environment. At the very least, if (perhaps to save conversion time) you capture video for web distribution, it’s best to capture it at least at the size that you intend for final output. This helps ensure satisfactory video quality for your viewers. When video is compressed (as it invariably is for web viewing) you can lose important detail.
Other variables to keep in mind when you’re creating video for the web are contrast and motion. During video encoding for web distribution, a fair amount of video information and detail can be lost. For this reason, good lighting of your source video is essential.
Also, web streaming doesn’t handle detail, transitions and motion all that well: So your best shots should be close up, and without a lot of movement. Too, audio from cameras and camcorders is rarely as good as that from external microphones. You should at least use a clip-on lavaliere microphone, if not a directional or shotgun microphone to be sure you record only the audio you really want. Finally, for high quality streaming, consider using a 720p session, even when your cameras may be SD and interlaced (there is no particular benefit to working in SD when your goal is a smaller streaming output.
One of the best approaches when beginning (to stream your productions) is to establish a relationship with a commercial streaming media provider. A good provider can guide you past firewalls, provide public addresses for everyone to view your stream, and provide no end of valuable guidance.
And it may not be as expensive as you think (costs vary based on considerations such as how many viewers you expect, how much web bandwidth you use each month, and so-on). Some services based on an advertising model will even host your stream free.
On Demand or Live Streaming
Not all streaming is live streaming. The difference is similar to watching a television program you previously recorded at a time convenient for you versus watching a live event. On demand streams are stored on a server (often supplied by an external service provider), ready to be transmitted whenever a viewer wishes. Live streams are available at the time they are broadcast, such as during a live concert or event.
On Demand Hosting
The Record module permits you to capture your productions to a local hard drive. The resulting files can be hosted on a network later, so viewers can connect whenever they like. If you have the resources available, you can host the video yourself – but if many people will likely want to view your production, you will likely avail yourself of a service to stream it on your behalf.
Ideally, on demand streaming video begins to play on request after a few moments (letting the stream get a bit ahead of the client playback device is called ‘buffering’, and helps ensure smooth playback). This stands in contrast to other types of online video distribution which requires the viewer to completely download the video file before he can begin play. Given a sufficiently high speed connection between host and viewer, they may well be able to enjoy a seamless viewing experience without stuttering or other issues.
Live streaming is a growing international market, and one you may well wish to serve. This form of streaming is a somewhat more demanding implementation. Rather than record a file and deal with it later, live video is transmitted over the network (effectively in real-time, give or take a little time in the pipe).
Delivering a good quality stream requires that you consider both your network connection capabilities and that of your viewers. As well, to ensure reliable delivery, you will ideally have some idea of the size of your audience. Streaming video is highly compressed to reduce bandwidth demands and make it available to a wider group. The decision as to which encoding format to use for your live stream is up to you or – in some cases – your client.
Here are some things to consider:
Some corporate and institutional network administrators opt to support one or another format exclusively. (Check with your IT department to find out if this affects your decision).
RTMP and RTSP combined have a very wide installed user base, and work well across multiple platforms (PCs, Macs, Linux, etc.).
SRT is an open source protocol that is managed by the SRT Alliance. It can be used to send media over unpredictable networks, like the Internet. More information about SRT can be found at srtalliance.org.
RTSP Stream Decoding
The processing demands from high-quality video applications and devices have increased in the last few years. As video content continues ever-expanding, technology evolves to handle the demand. Vizrt takes advantage of GPU hardware acceleration for all stream decoding.
Unfortunately, some streams are simply incompatible with the GPU decoder. We recommend that the originating stream vendors look to solve the compatibility and take advantage of modern GPU decoding. We also understand that Vizrt users of may not have that option and must wait for vendor development cycles.
As a workaround, if a stream is found to be incompatible, you can append the URL with a command that instructs Viz Vectar Plus to not use hardware acceleration.
(optional components are enclosed in square brackets)
For example, the original URL of:
rtsp:// http://stream_IP_address.com">stream_IP_address.com :554/myStreamserver
would change to: rtsp://stream_IP_address.com:554/myStreamserver?hw_accel=false">rtsp://stream_IP_address.com:554/myStreamserver?hw_accel=false
You’ll often hear the term ‘bitrate’ in connection with streaming. This expression refers to data throughput per second (generally measured in Kilobits per second, or Kbps.) You could think of this as being like water flowing through a hose. You control the ‘faucet’, because you get to choose the streaming Profile setting in the system’s Configuration panels. However, you don’t own the ‘hose’ – or, at least, not the entire hose.
Once the stream leaves your immediate environment, even if you can supply good throughput locally, bandwidth may be constricted elsewhere along the transmission path. The level of Internet traffic can impose limits, but another major factor is the sort of connections your viewing audience may have. Consider an example scenario: Even though you know that most of your audience is going to connect to your program using (relatively slow) wireless devices, you use a very high outgoing bitrate – thinking that this will surely be enough to fill the need. The fact is, though, a high bitrate actually ensures their experience will be poor. The client player tries to play at the specified bitrate, but (in this example) the wireless bottleneck impedes flow. It is as if you connected a fire hose on your end, giving them a suitable high capacity nozzle for their end – but in the last stage of flow, the stream must pass through a small garden hose. Sadly, the stream will be quite insufficient, and output from the ‘nozzle’ (the client player) will falter badly.
Tip: Consider an example scenario.
Even though you know that most of your audience is going to connect to your program using (relatively slow) wireless devices, you use a very high outgoing bitrate – thinking that this will surely be enough to fill the need. However, a high bitrate actually ensures their experience will be poor. The client player tries to play at the specified bitrate, but the wireless bottleneck impedes flow. This is analogous to connecting a fire hose on your end, giving them a suitable high capacity nozzle for their end, yet in the last stage of flow, the stream must pass through a small garden hose. The stream will be insufficient, and output from the ‘nozzle’ (the client player) will falter badly.
For reliable performance, try to ensure the potential upload bandwidth from your system to the net is around twice the bitrate you choose. You can broadcast at a rate closer to your actual ceiling, but reliable performance cherishes headroom.
Also consider the expected download abilities of your viewers. Ideally, a safety margin 1.5 times the stream’s bitrate is desirable. This may mean you need to consider using a lower resolution, or lower framerate for your stream. Doing this when required will generally deliver a smooth result, and is the recommended course.
See Speed Tests in section Diagnostics and Troubleshooting.
Streaming Media Providers
Using a commercial streaming media provider (Content Delivery Network, CDN) bypasses otherwise high-bandwidth requirements for the encoding computer. When you have made arrangements for a streaming media provider to distribute your stream, the encoder only needs enough bandwidth to get a single a/v stream to the provider. All end users connect to the provider to view the stream.
Most streaming providers have access to massive bandwidth (and often, with very little notice, they can scale up your allotment to meet a temporary need.) Since your local bandwidth is really only used for uploading a single stream, you can send a high quality stream, secure in the knowledge that it will not degrade as soon as a second viewer attempts to see it.