live stream freezing, timecode out of order error message

Wowza Streaming Engine
1

We are broadcasting a live stream via udp and are experiencing any player we choose seeing the stream freeze every few minutes. The freezing is accompanied by these error messages:

#Fields: x-severity x-category x-event date time c-client-id c-ip c-port cs-bytes sc-bytes x-duration x-sname x-stream-id x-spos sc-stream-bytes cs-stream-bytes x-file-size x-file-length x-ctx x-comment

WARN server comment 2016-04-27 16:11:46 - - - - - 2.0789594461E7 - - - - - - - - SanJosePacketHandler.handlePacket[live/definst/506]: Timecode out of order [video]: 1461773413314:1461773506487

WARN server comment 2016-04-27 16:11:46 - - - - - 2.0789594461E7 - - - - - - - - LiveStreamPacketizerSmoothStreaming.handlePacket[live/definst/506]: Timecode out of order [video]: 14617734133140000:14617735064870000

WARN server comment 2016-04-27 16:11:46 - - - - - 2.0789594461E7 - - - - - - - - CupertinoPacketHandler.handlePacket[live/definst/506]: Timecode out of order [video]: 1461773413314:1461773506487

WARN server comment 2016-04-27 16:11:47 - - - - - 2.0789594931E7 - - - - - - - - LiveStreamPacketizerSmoothStreaming.resetStream[live/definst/506][0:11]: Timecodes jumped back in time.

WARN server comment 2016-04-27 16:11:47 - - - - - 2.0789594931E7 - - - - - - - - SanJosePacketHandler.resetStream[live/definst/506][0:11]: Timecodes jumped back in time.

WARN server comment 2016-04-27 16:11:47 - - - - - 2.0789594931E7 - - - - - - - - CupertinoPacketHandler.resetStream[live/definst/506][0:11]: Timecodes jumped back in time.

WARN server comment 2016-04-27 16:11:47 - - - - - 2.0789595136E7 - - - - - - - - LiveStreamPacketizerPacketHandler.handlePacket[live/definst/506]: Timecode out of order [video]: 1461773413314:1461773506487

WARN server comment 2016-04-27 16:11:47 - - - - - 2.0789595575E7 - - - - - - - - LiveStreamPacketizerPacketHandler.resetStream[live/definst/506][0:11]: Timecodes jumped back in time.

I have tried various changes to wowza settings related to jitter, etc., and have not been able to resolve the problem. Most attempts I have made have resulted in a stream that doesn’t even play at all. We have confirmed that the udp packets we are broadcasting do not have any out of order issues, so we suspect this must be related to dropped packets during the broadcast over the network. Any tips for fixing this, if anyone’s encountered this before?

2

Generally this indicates an encoder issue. It also could be an issue when the computer CPU utilization or GPU utilization is maximized. To debug, see How to debug AAC or MP3 timecode issues with cupertino packetization. Try using Advanced Stream Monitor to monitor the streams and reset them if they become unhealthy. If you see this message immediately after the stream is published before packetization starts, it can be ignored.

Regards,

Salvadore

3

This log message usually appears when there is packet loss for the stream coming from your source encoder. To avoid packet loss for the incoming stream, you will need to make sure that the internet/network connection bandwidth between your encoder and Wowza server is good enough to support that incoming stream. If you are trying to push a stream that has a bitrate value higher that the bandwidth available for your Wowza server, then you might encounter packet loss in your incoming stream, which will get propagated to the playback client as well.

Also, packet loss might happen if you have a congested network, either on the encoder side, or on the Wowza server side.

You can also try to correct any packets which are coming in out of order by adding a sort-buffer on the Wowza side.

How to fix unaligned video and audio with a server-side sort buffer

Any packets received within the buffer duration will then be correctly aligned.

By default the buffer size is 750 ms but this can be increased up to 8000 ms (8 seconds) if required.

Regards,

Salvadore

4

Hi, We have checked extensively and the udp packets being broadcast by the encoder look fine, timestamp wise. The CPU utilization is very low, because we aren’t asking the wowza server to actually do anything stressful. The only thing we can think is that this is due to broadcasting over the network, with packets being dropped or possibly somehow received out of order, but given that that is a universal problem, I don’t understand why wowza wouldn’t be more robust to this sort of thing.