You will optionally need an RTMP encoder. See the encoders page for a list of encoders that are known to work with ScaleEngine.
You will need a stream source, such as a webcam or capture card. This will be recognized by our built in camera capture system, or your encoder.
Refer to the encoders page for instructions for your specific encoder. If your encoder is not listed, it will probably still work.
Your encoder will need the server URL and stream name, which can be found in the control panel as the "Encoder connection URL" and the name of the stream (we create one but you can name your own) you wish to send to.
Enter this information into your encoder. The name of the fields will vary between encoders, but it is usually some variation of "Server URL" and "Stream Name" or "Stream Key". If there are any username or password fields, leave them blank. Authentication parameters are embedded in the URL.
Some encoders, such as vMix, are fully integrated with us, so all you need to do is login to your ScaleEngine account and the vMix encoder is configured for you.
Once this is set up, you will be able to connect your encoder and begin sending a stream.
You need to encode your stream as h.264 video and either AAC or MP3 audio. AAC is strongly recommended.
Your stream quality is dependant on a number of factors. Your encoder, if it is running on your computer, will use a lot of CPU. You want to be sure you have enough CPU. Tuning your stream to a higher profile or larger frame size will use more CPU, so if you are running out of CPU, reduce your frame size or lower the encoding profile.
You will want to pick the highest profile possible, high, or main, as higher profiles are more efficient. Only use lower profiles if your CPU is unable to keep up, or if you need to support devices that cannot play back main or high profile. If you are stuck supporting one of these devices, our transcoding service can encode a lower bitrate as a different profile, such as baseline for old cellphones.
Bitrate and frame size are the primary things that will affect what the user sees. A higher bitrate will increase the stream quality, but requires that the viewer has sufficient bandwith, and will use more data if they are on a phone. Frame size is often what people will think of as quality, i.e. 1080p (1920 pixels by 1080 pixels). Using a larger frame size will not always give you a better stream! It takes more bandwith to draw more pixels, so if you are sending at a lower bitrate, it will often look better at a lower resolution. Clean 720p upscaled in the player to a 1080p screen will look nicer than blocky, pixelated 1080p.
Another setting that affects the quality is the keyframe rate. The keyframe setting has two influences on what your viewers see. Increasing the frequency reduces the stream startup time for viewers when they begin to watch your stream, because each chunk of video is one keyframe interval, and the viewer has to load an entire chunk before they can play. A one or two second setting will also help to reduce latency, or the inherent delay that happens with live streaming. This is because the chunks being buffered are smaller, and thus add up to less of a delay.
A longer keyframe setting will have the benefit of improving the quality of the stream somewhat, because the encoder can draw more accurate changes in between the keyframes, which consume quite a bit of the available bandwidth, but it will add latency and potentially stream startup delay. If you will also be pushing your stream to social media platforms, they will generally want two second keyframes. We can always transcode your stream to any specific output requirements - for example, a feed that only accepts 800 kb/s, but you want to send 5 Mb/s everywhere else.
A clear network path to your ingest is essential, on a dedicated wired line. You can reasonably expect to be able to send up to half of your available network upload speed. If you have 100 Mb/s upload from your ISP available, you can probably send a 50 Mb/s stream reliably. This will vary considerably. You can use our speed test service in the control panel to verify your connection to us (see Debug URLs). It is important to see what speeds your connection is actually capable of.
We provide you with a couple of different video stream players in our control panel. The best supported streaming protocol is HLS (HTTP Live Streaming), which splits up the stream into "chunks", small files, the duration of which generally match your keyframe interval. So, the player gets a "playlist" describing the where the stream's "chunklists" can be found, and the selected chunklist tells the player which sequential chunks to request so it can start showing the viewer the program.
The playlist file will contain several chunklists, one for each bitrate. Most devices will automatically select a bitrate that will work for the available network it is on. Viewers can optionally select between various bitrates manually.
The clappr project open source player is the one we primarily support. If you have a different licensed player, it will likely work as well, as there are several that are used with our streams in common use.