Follow

ON DEMAND OR LIVE STREAMING?

Not all ‘streaming’ is ‘live streaming.’  The difference is similar to i) watching a television program you previously recorded at a time convenient for you, or ii) 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

TriCaster permits you to record live 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

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 realtime, give or take a little ‘time in the pipe’ as it were.) 

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.  Nevertheless, for all cases, TriCaster gives you the tools to do the job.

Naturally, streaming video is highly compressed to reduce bandwidth demands and make it available to a wider group.  TriCaster supports two popular and prolific encoding systems, Microsoft’s Windows Media® and RTMP (Adobe Flash®).

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.).

 

  • Windows Media® is well represented, but perhaps not to the same degree.

Bandwidth Considerations

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 TriCaster’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 the stream at the bitrate you specified, 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.

 

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 – but doing so when required will generally deliver a smooth result, and is the wise course. (Nothing inclines viewers to turn away quicker than a stuttering, start and stop stream. See “Speed Tests” in Section 17.8.1 for some useful resources.)

SECTION 17.6.1 

For more information please download the entire document at new.tk/rt-m

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.