A part of our product has live video chat/conference, which is implemented (due to legacy reasons) on Flash Media Server, and does not currently do any transcoding. We have a requirement to add MBR (or adaptive bitrate) to the live conference. The following image illustrates an approach using FMS in conjunction with Wowza:
The presenter's stream gets routed to Wowza (by FMS) and enters a set of transcoders which are configured to different bit rates. Each transcoder output stream goes to an element (I am not sure what it would correspond to in Wowza terms) which I call the fan-out. The Fan-out element can replicate the incoming stream to multiple RTMP-Endpoints. Finally, each attendee gets its stream from a designated endpoint. The Application (Java) will orchestrate the switching of streams based on the QoS feedback from the attendees.
The act of switching the stream would happen at Wowza - the application would instruct the Fan-out of a specific bitrate to route the media stream to a set of end points. When an attendees bitrate changes and requires a different stream (higher or lower), the application instructs the current Fan-out to cut off its stream (at an I-frame) and the new Fan-out element (with the appropriate bit rate) to add that attendees (RTMP) endpoint in it's set. The idea is that the switching happens without the client knowing it.
Note, that the attendees reverse stream follow a different path and are not shown here. The scenario is interactive in real time, is pretty much a video conference, except that the attendees stream is the most important and must reach all attendees.
Does Wowza give enough flexibility to create such a scenario ? Or is there a better way to do this in Wowza ?
Reviewing your workflow, I believe this would work. I would suggest that you email our Sales Team to help you redefine your workflow as far as your required bit rates, etc., for your player within your chat application. You could also request pricing information at the same time. Send them an email to