Wowza Community

LiveStream starts 2 minutes. How to speed up?

Our client is looking for RTMP -> HLS cloud service. WowzaCloud fits good, except long “engine” starting time. So it takes 2 minutes to create and start live stream.
Is there way to speed up this process. So a user in our app can click “Start” button and start stream in 5 seconds after click made.

Thanks,
Stan

Hi Stan, wow, 2 minutes is way too long. So when you say “start the live stream” in Wowza Video (Formerly Wowza Cloud), do you mean when you are creating a new stream in the UI, creating a Cloud transcoder and naming the stream etc.?
(if yes, try a different geographic location when selecting “Broadcast” location.

Or do you mean when you actually click on the green button START live stream as in go live? which is what happens when a user clicks play as you had said. That is what I think you mean…

I would check the encoder settings first as far as framerate and GOP. A stream can’t start without a keyframe at the very beginning and will search for it to start the stream.

Also, you may want to Start 2 transcoders in different data centers and use the one that starts first. Not 100%, ideal but greatly improves the odds one transcoder will get hot and fire up more quickly.

Also Wowza Video manager says “Start early if they control content.”

I personally would send a support ticket so we can review the encoder settings and test playback. The wrong encoder settings can really slow things down in the beginning if it’s not optimized.
You can use this as a reference:

https://www.wowza.com/docs/how-to-encode-source-video-for-wowza-video

One last idea is to use the use origin network. They can begin streaming immediately, although latency is increased. It’s effectively a proxy. The customer pushes in RTMP and we start the transcoder for them. We buffer the content coming in until the transcoder is ready and then keep passing it through. So startup is “instant”, but the buffer adds to the latency for the duration of the stream.

Hi Rose,

Thanks for looking. We create live streams via REST API. In GUI that would be create and start live stream together. Yes start is faster for the existent (stopped) live stream.

So our user wants to start broadcasting immediately. And final live latency should be around 10 seconds for HLS output.

I will check “origin network” approach. Another option that came to our mind is to keep pool of “stopped” (created ahead) or even “started” (with no traffic in) live streams where we can take one for immediate broadcasting. The question in that case if that pool of doing nothing empty live streams will be billed.

Stan

Ok let me circle back with the WV manager for an answer on your question.

The answer is yes, you will be billed for started or “hot” transcoder, with or without an actual live stream according to the WV Product Manager.

Are you able to send the stream as WebRTC or no? That way you can start to look at real-time streaming in Wowza Video. Is this possible for your client to stream from a browser or a camera connected to a browser like in OBS?

Does it have to be HLS playback? Are you able to playback as WebRTC for the viewers in a player that supports it like we offer?


Wowza Video Real-Time Streaming at Scale provides half-second latency to all your viewers, no matter where they are. Real-time streaming is perfect for interactive use cases like video chats, auctions, e-sports, fitness, e-commerce, gambling, and more.

If your audience is fewer than 300 viewers or you want to stream in near real-time alongside other delivery protocols, you may choose to use our standard WebRTC solution.

https://www.wowza.com/docs/deliver-real-time-streams-at-scale-with-the-wowza-video-rest-api

Hi Rose,

As the status, we are on hold with our client on this subject. For info, we didn’t find any other provider that does RTMP -> HLS in cloud and with quick start.

I have another question on “Pay As You Go” pricing (https://www.wowza.com/pricing). I remember that 2 years ago there were more detailed breakdown in billing model:

  • viewers were billed based on traffic. Now per hour;
  • there were separate charges for stream ingest and encoding hours depending on stream resolution.

Did the pricing change or there is a hidden page with low level billing model?

Thanks,
Stan