This message was deleted.

You can download the

.ts

files from your bucket and play them with vlc or similar. If the quality is bad there, then it is likely an issue with poor connection from the publisher. If the quality is ok there, then you know the issue is with your HLS server

Thanks DC. I will test and report back

This is one of the issues with HLS. Currently the HLS that Egress generates is for archival, so it's only generated at a single resolution. On slower networks, this means it's not able to perform adaptive bitrate. When the network is slower than the bitrate of the video, you'll see freezes and stalls. We would recommend just using WebRTC for your viewers too. we wrote about this in a recent post

@david Any chance that a knob might surface to tweak the bitrate. We would like to stick with HLS as we are more interested in off loading streaming to a cdn for larger events. It just means we can get away with less server resources for larger events

you can customize all of the encoding settings with the Egress request

Does that mean we could have multiple bitrate streams for HLS or just pick one bitrate for the duration?

you can certainly start multiple Egresses with different bitrates.

Ok at least we have an option. But current concern is just low bandwidth publishers

Rtmp is another option for streaming, if your clients support it

I did a quick test and it seems it's the browser throttling the bandwidth when on 5G (cell). Even when streaming just audio. In the sample app "stats" I can see bandwidth suffering from all green to red. Maybe I can try with a sample native client instead of browser based. Thank you!!

Browser will detect available bandwidth when publishing. It will have no choice but to reduce video quality when congestion is detected. Native SDKs would behave the same way as that core logic is part of libwebrtc. (both browser and our native SDKs both use libwebrtc)