kukuluLIVE dynamically increases or decreases the number of servers in 30 second increments depending on the load on the distribution network.
In preparation for spikes, individual containment rates are kept at around 50% of the limit,
Basically, viewing will not become "heavy" due to the load on the server side.
If the video stops or buffer waits occur frequently during a specific distribution,
This is most likely caused by the distributor's OBS (encoder) settings.
Especially in an environment where the settings of the computer are set to the limit,
Even if it works fine immediately after setup, problems may occur unexpectedly when you start a heavy game.
If you are a broadcaster, please check the settings below once again and make sure that you are comfortable with the settings.
1: The encoder setting "x264" is very heavy because it is software encoded.
Use hardware encoding whenever possible.
Although it varies depending on the environment, "NVIDIA NVENC H.264 (new)", "H264/AVC Encoder (AMD Advanced Media Framework)", and "QuickSync H.264" are hardware encoding.
Newer OBS allows for lighter weight and higher quality hardware encoding. If you are using an older OBS, we recommend updating to the latest version.
2: Bit rate setting <br>If it is too high, communication stability will be impaired, but if it is too low, the encoding load will increase.
We recommend setting it to around 1500-3500Kbps.
3: Presets (CPU usage presets, target usage, etc.) In an environment where the above encoder setting is "x264", if you set the preset to "slow", it will become extremely heavy.
Please set it to "faster" at most in the relevant environment, and "veryfast" if it is a standard specification.
In a hardware encoding environment, increasing the preset will not reduce stability, but
We recommend settings that are as close to latency and performance as possible.
[Q&A]
Q. I didn't have any problems with other distribution sites, but why does kukuluLIVE require a margin in the settings? A. kukuluLIVE achieves ultra-low latency streaming with a minimum delay of 0.5 seconds, so even the slightest processing delay will cause the buffer to reach zero and playback to be interrupted.
Other distribution sites have an average delay (buffer) of about 10 seconds, and since processing delays can be absorbed during this time, insufficient specifications are less likely to surface.
Q. Will the image quality deteriorate if I use hardware encoding? A. The image quality is lower than with software encoding, but it can be compensated for in most cases by increasing the bit rate by about 20%.
Q. Will using hardware encoding slow down the game? A. Live broadcast encoding does not run the GPU at full power. At most, it is about 10% of the maximum load.
In most environments it is almost negligible.
Q. Is this the same reason why Time Shift may not play properly? A. In most cases, the cause is the same. Timeshift is provided without encoding as standard, but
Only when we detect an inadequacy in the data, we re-encode it and provide it.
For this reason, insufficient specifications may cause a longer time to provide timeshift or lower image quality.
