Transcoder kills Loop Until Live and Stream Player ?

[Simon_Haywood1]

Hi!

I’m hoping this is just me! - and that someone can point me to the obvious error that I’ve made.

I’ve been able to set up a WebRTC publish, “backed up” by a Loop-Until-Live of a .mp4, and then consumed with a WebRTC player. However, when I introduce a Transcoder into the mix, it all goes wrong.

It seems that enabling the Transcoder kills the stream for the Loop-Until-Live - it dissapears from the list of available streams. The main stream itself stays in the list of available, streams, but apparently can’t be consumed. Only disabling the transcoder, and restarting the server application (not the host) returns things to normal.

My plan was to use the Transcoder to create separate audio and video streams, that would be consumed separately.

Can these modules co-exist? If so, what obvious thing did I do wrong!?

Thanks!

[Karel_Boek]

Remember that you can’t enable the transcoder on the fly; it requires a restart (“stop-and-start”) of the Application. Stopping the application means that the loop-until-live stream will stop too. But since loop-until-live is controlled on Server level, not on Application level, it means you’ll have to restart the Server process to get your L-U-L stream going again. So you’d enable the Transcoder once, then restart the Wowza Server process, which then will start your L-U-L stream.

If you’ve tried that and it doesn’t work, then there’s maybe something wrong with your transcoder configuration. Another possibility is that you’re using a Developer or Trial License, and you’re running into the license limitations (max. 3 incoming streams; each transcoded stream counts as an incoming stream)

It’s always a good idea to check the logs!

PS: Pardon me for asking; but what’s the advantage of using WebRTC when you’re playing an MP4 in a loop; as opposed to the more scalable, more performant use of HLS or MPEG-DASH?

[Simon_Haywood1]

Hi Karel,

Thanks for your reply. To answer your question first, we are using WebRTC for a real-time application. The looping MP4 is there as a loop-until-live placholder stream, until the incoming WebRTC stream starts.

The problem is much more fundamental that you’ve inferred. Put simply, if I start the Transcoder (and restart the application, as you have noted), the looping MP4 stream does not restart. It is as if the Transcoder and the looping player cannot co-exist.

The only way to recover the situation is to turn off the Transcoder, and then restart the entire server.

[Karel_Boek]

But exactly how do you “start the transcoder”? Because “starting the transcoder” isn’t an action in Wowza. What you do, is publish a stream to an Application that has the transcoder enabled. And again: when you restart the Application, indeed your MP4-loop will stop, because it’s controlled on Server level.

[Simon_Haywood1]

When I say “start the transcoder”, I mean: select the Applications tab in the Streaming Engine web UI, select the application in the side bar menu, then select Transcoder from that side bar, and then click Enable Transcoder in the main body of the UI. Of course, I then need to restart the application. When the application restarts, the stream with the loop is simply not there.

When I say “The MP4 loop stops”, I don’t mean “it stops playing”. I mean that it completely disappears. There is no stream.

[Karel_Boek]

So indeed that is as expected; because - as I wrote - the MP4 loop is controlled at Server level but runs at Application level. So once you stop the Application, that loop stops, but only when you restart the Server, the loop stream is started.

It’s been a while since I configured that module, but I recall there’s an option to control it at Application level instead of Server level. Check the documentation on https://www.wowza.com/docs/how-to-schedule-streaming-with-wowza-streaming-engine-streampublisher

[Simon_Haywood1]

@Karel Boek-Senior Consultant - that turned out to be the key. Restarting the application stops the playback of the stream that’s providing the loop-until-live. To restart that stream, a restart of the server was required. For me, this was unexpected.

If you can put that as an answer, I’ll tick the accept. Thanks!