Upgrading from Wowza 3 to 4 - not receiving notification of incoming stream

I am attempting to upgrade from Wowza 3 to 4 with mixed success. We have some custom notification code that is installed in the httplistener that is necessary for our application to function properly - basically one part of our system activates a video source that streams to wowza, and then wowza (and the hooks we have installed there) detect this and notify our video player of the availability of the stream.

Our wowza customaization works with wowza 3, but not with wowza 4. In my testing, wowza is clearly receiving the stream from our video source, and is even making it available for a video player. However the notification hooks are not being called, so the only way I can see the video stream is by looking in our application logs to find our generated token URL and sending that to the video player (VLC in my case).

A little more specifically, in our application instance listener class (implements IApplicationInstanceNotify) we instantiate a media stream action notifier (implements IMediaStreamNotify). The application instance gets created, and thus the media stream action notifier is also created and added to the application instance. However, the media stream notifier’s onMediaStreamCreate method never gets called.

We’re using rtsp if that matters.

If you are re-streaming from RTSP source you can get notification from IMediaStreamActionNotify3.onPublish(), and this is the more typical approach.

Richard

Try putting your Module last in the list of the application’s modules.

Richard

The order that modules appear in the list is important.

Modules have two types of methods. They are Event Listeners and Event Handlers. The Event listeners are defined in the IModuleOn* interfaces and the Event Handlers are defined in ModuleCore.

When an application is loaded, a list of module methods for all modules is complied as part of the startup process and depending on what type of method it is, depends on how it is called.

For Event Listeners, when an event (such as app start or client connect) occurs, the event handler for that event will be called in module order from the first module in the list to the last one. Each module has the chance to modify any value associated with the event but cannot prevent the event from occurring. As each one is called, any values modified by the previous module will be used. Once all of the module methods have been called, the method that called them will continue.

Event listeners generally start with on such as onAppStart or onConnect. The IModuleOn* interfaces are not actually needed and are only provided for reference to ensure you have the method signatures correct.

Generally, where module order is important with Event Listeners is when using security modules that may accept or reject a connection. If you have a module that accepts the connection and one that rejects it, the last one in the list is the one that will take precedence. Both will still be called but the last one will overwrite the value set by the previous one.

Other Event Listeners in Wowza work much the same way. They are generally added with class.add*Listener methods. If you have multiple modules that have the IMediaStreamActionNotify interface then their methods will be called in the order that the listener interfaces are added to the stream.

Event Handlers handle an actual event such as a play or publish event. They can modify the values but can also prevent the event from continuing. Generally, in modules, you will use event handlers that override one of the methods in ModuleCore. The ModuleCore methods are the actual handlers that ultimately handle the event but will only be called if the handler has not been previously overridden or has been called directly.

When Event Handlers are called, only the last module in the list that has the handler will be called. To have the same method called in other modules (including ModuleCore), you must either call it directly or use a special static method called invokePrevious. When invokePrevious is called, the same event handler method will be called in the next module up the list that has the method. If no other custom modules have the method then the ModuleCore method will be called. If you don’t call invokePrevious then the event will stop.

Other event handlers in Wowza are generally added with a class.set type method. When you call this for your own custom handlers then you will replace the default handler with your own so you must either handle all methods or extend the original handler class.

The logging warning you are getting is due to starting a mediaCaster stream but not specifying the mediaCaster type correctly. It is most likely you have started a liverepeater mediaCaster but have the mediaCaster type set to rtp.

Roger.

I’ve tried creating a new class which extends ModuleBase and implements IModuleOnApp, IModuleOnStream, IModuleOnTRPSession, and IMediaStreamActionNotify, and written “handlers” such as onAppStart, onPublish, etc which simply log that they were called. This class is installed as the first in the Application.xml (even before Base ModuleCore). The only handers that are called are the application and application instance ones (the same as what I was seeing with our older code that was originally written against Wowza3). Anything related to stream creation or playback doesn’t seem to fire.

Basically the new module code I just wrote today seems to receive the same handlers as our old code.

Dunno if this matters but we also are getting this log warning: RTPSessionDescriptionDataProviderBasic.getStreamInfo: SDP file missing: /usr/local/WowzaStreamingEngine/content/lv/cameratest (we did not need an SDP file in our Wowza 3 install AFAIK)