Results 1 to 4 of 4

Thread: Stream Switching Latency

  1. #1

    Default Stream Switching Latency

    Hi guys.

    I've implemented a stream switching application using this example

    This works well bar one issue. When I swap streams, I end up showing about 1 seconds worth of 'extra' content from the new stream, i.e. content that was being streamed before the switch.

    For example :
    * Two inputs, one a looping mp4, one a camera stream.
    * The (Wowza) application is setup to show the looping video.
    * I wave at the camera then immediately run a command to switch the output stream to the camera.
    * The output stream switches from the looping mp4 to the camera, and shows me waving.

    I had hoped that the swap should swap the stream in realtime, i.e. any content sent prior to the swap would not be shown. However, it would seem Wowza is buffering (or some such) the input stream, leading to the approximate 1s delay.

    To test this, when requesting a switch I introduced a Thread.sleep(1000L) in my code, and this fixes the issue. However, clearly this only works if the delay is consistent across streams and across the hardware hosting Wowza.

    So two questions:

    i) Is the delay consistent?
    ii) If not, is there a way to programmatically measure the delay, so I can introduce a corresponding delay in stream switching?



  2. #2


    In addition to this:

    We're looking to start/stop recording of the video at switch time. At the moment, I've implemented the following :

    // ...
    // Swap stream.;
    // Begin recording.
    ILiveStreamRecordManager liveStreamRecordManager = vHost.getLiveStreamRecordManager();
    IStreamRecorder streamRecorder = liveStreamRecordManager.getRecorder(applicationInstance, eventGuid + "_aac");
    if (streamRecorder == null) {
    	StreamRecorderParameters streamRecorderParameters = new StreamRecorderParameters(applicationInstance);
    	streamRecorderParameters.versioningOption = IStreamRecorderConstants.APPEND_FILE;
    	streamRecorderParameters.startOnKeyFrame = true;
    	liveStreamRecordManager.startRecording(applicationInstance, eventGuid + "_aac", streamRecorderParameters);
    	streamRecorder = liveStreamRecordManager.getRecorder(applicationInstance, eventGuid + "_aac");
    	streamRecorder.createRecorder();	// Required to initialise the recorder.
    It can take a bit of time for the output stream to actually switch after calling -- I had assumed this was because the switch will occur when a keyframe is received on the new stream. If this were the case, the recording should always start on the new stream, since streamRecorderParameters.startOnKeyFrame is set to true.

    However, what actually happens is that the recording contains a bit of the previous stream before switching to the new stream. So my question is, is there a way to guarantee that the recording will start on the new stream, rather than including part of the old stream?



  3. #3


    Hi Henry,

    There are two settings in the Stream API that might be affecting the buffer. Both are related.

    Stream.setStartLiveOnPreviousKeyFrame(true); Default is false. If you are setting this then the stream will look back in the packets to find the previous key frame.

    Stream.setStartLiveOnPreviousBufferTime(long bufferTime); Default 4100. Based on the previous setting, if startLiveOnPreviousKeyFrame is enabled, then the buffer will roll back a maximum of this far.

    If startOnKeyFrame is not set then when the switch to live occurs, the stream will try to locate the latest received key frame to display in the player. It then looks at the latest frame received on the live stream and uses the timecode on this frame to base the rest of the frames on. So it can begin playback, it will then wait until it receives the next key frame so there may be a slight delay where the previous key frame is displayed. Most of the time this will go unnoticed, either if the source stream is new so the last frame is the key frame or the switch occurs very close to the next key frame. If the switch occurs just after a key frame, the delay will be more noticeable.

    If you are manually switching, then you can monitor the incoming packets and perform the switch exactly on the key frame. If using Wowza Streaming Engine, you should be able to use something like the following to monitor the incoming stream.

    import com.wowza.util.FLVUtils;
    import com.wowza.wms.amf.AMFPacket;
    import com.wowza.wms.module.ModuleBase;
    public class MyModule extends ModuleBase
    	class MyLivePacketListener implements IMediaStreamLivePacketNotify
    		public void onLivePacket(IMediaStream stream, AMFPacket packet)
    			if (!doSwitch)
    			if (!stream.getName().equals("myStream_source"))
    			if (!packet.isVideo() && FLVUtils.isVideoKeyFrame(packet))
    				// flush the current packets out into the packet list.  This packet should be the last packet.
    				// Call switch stream method here before returning.
    				// reset the switch flag.
    				doSwitch = false;
    	private volatile boolean doSwitch = false;
    	public void onStreamCreate(IMediaStream stream)
    		stream.addLivePacketListener(new MyLivePacketListener());
    	public void doSwitch()
    		doSwitch = true;
    Note: This listener is called before any sort buffer so if you have a sort buffer enabled on your stream, it will delay the packets.

    Stream recording occurs similar to switching where the recording will start on the latest key frame. You can use the same method to trigger the recording start point.


  4. #4


    Hi Roger.

    Thanks for the detail. I think we'll need to leave Stream.startLiveOnPreviousKeyFrame set to false since we don't want to go 'back in time' any further -- due to the apparent Wowza buffering effect, we're already 'back in time' by some measure when we call switch stream.

    We've approximated a solution by implementing a configurable delay in switching -- when a user clicks switch streams this actually runs after a delay of 750ms. This seems to do the trick, and barring any intervention from those further up the food chain should be good enough :-)

    Thanks again for the assistance on this,



Similar Threads

  1. Dynamic Stream Class Stream Switching Module and Interface Method
    By IPVSINC in forum Wowza Streaming Engine functionality
    Replies: 4
    Last Post: 12-09-2013, 07:46 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts