Viewers reporting lagging and buffering

[DDT]

Hi all.

My viewers are reporting a bunch of lagging and buffering with my streams that I myself can't seem to see in my settings. Im trying to stream my Switch via an Elgato HD60S+ at 720p60fps. My internet upload speed is ~20 MBPS.

Any suggestions?

 

[FerretBomb]

Use the Quality preset, not Max Quality. Disable both Lookahead and Psychovisual Tuning. All of these use CUDA cores, and can cause encoding overload issues in a system that should not otherwise have them.

You're streaming at 720p60, at 6000kbps. Running a bitrate that high will cause buffering issues for viewers on weaker connections. You can try dropping to 4500kbps which will still have you right around the 0.1bpp quality reducing-rate-of-returns point, or even drop to 3000kbps to provide even more safety margin. Improved accessibility/reliability is king, compared to slight reduction in subtle visual artifacts in the video stream.

Your logfile shows no rendering delay or skipped encoder frames, so the problem most likely is simply on Twitch's end with their replication, transport, and local video delivery servers. Going to a lower bitrate will help mitigate these problems.


I'd also recommend STRONGLY swapping to CQP or CRF quality-target based encoding for your local recording. CBR is the WORST method, but required for streaming due to the infrastructure and video chunking requirements. CQP/CRF will produce a MUCH better video recording, when you don't have to worry about the upload bandwidth bottleneck, since it's just writing to a local hard drive.

 

[DDT]

Use the Quality preset, not Max Quality. Disable both Lookahead and Psychovisual Tuning. All of these use CUDA cores, and can cause encoding overload issues in a system that should not otherwise have them.

You're streaming at 720p60, at 6000kbps. Running a bitrate that high will cause buffering issues for viewers on weaker connections. You can try dropping to 4500kbps which will still have you right around the 0.1bpp quality reducing-rate-of-returns point, or even drop to 3000kbps to provide even more safety margin. Improved accessibility/reliability is king, compared to slight reduction in subtle visual artifacts in the video stream.

Your logfile shows no rendering delay or skipped encoder frames, so the problem most likely is simply on Twitch's end with their replication, transport, and local video delivery servers. Going to a lower bitrate will help mitigate these problems.


I'd also recommend STRONGLY swapping to CQP or CRF quality-target based encoding for your local recording. CBR is the WORST method, but required for streaming due to the infrastructure and video chunking requirements. CQP/CRF will produce a MUCH better video recording, when you don't have to worry about the upload bandwidth bottleneck, since it's just writing to a local hard drive.

Thank you kindly good sir. Your fixes seemed to fix the issues.

Quick question about CQP since recording is pretty new. What is CQ level? Is the default 20 good?

 

[FerretBomb]

Thank you kindly good sir. Your fixes seemed to fix the issues.

Quick question about CQP since recording is pretty new. What is CQ level? Is the default 20 good?

CQ is how far the encoder is allowed to deviate from 'perfect' uncompressed video. The lower the number, the closer to perfect it is.

20 may have very minor visual artifacts, but you have to actively look for them and they will still be subtle. 16 is effectively visually lossless. 12 is only used if you plan to edit and re-encode later, to minimize the re-encode artifacting. Below 12 should not be used without a VERY specific reason... and will be absolutely huge. Even 12 is going to be huge.
Personally I record at 16, but I plan to edit or would probably stick at the default 20.