We have a service doing some custom encoding and outputting a h.264/AAC transport stream.
I’m serving this stream up to the Wowza server over UDP.
Once in a while we see some complaints in the log about the timecodes jumping back in time. In searching on this, people often attribute this to a loaded network or system. In this case neither is loaded.
Could this error be caused simply by the UDP packets arriving ‘out of order’, or does this indicate some error in the PT of the encoder?
If the former, can the Wowza server accept the TS over TCP?
Thanks,
Chris
Yes, Wowza can do this over TCP instead of UDP. What version of Wowza are you using? In the most recent version, it is default. Otherwise, you can set this /conf/[app-name]/Application.xml /MediaCaster Property
<Property>
<Name>forceInterleaved</Name>
<Value>true</Value>
<Type>Boolean</Type>
</Property>
Richard
Right, actually forceInterleaved will have no effect in that case. It’s only for rtsp sources that stream over udp by default but can switch to tcp, like some IP cameras.
Take a look at the jitter buffer
https://www.wowza.com/docs/how-to-turn-on-an-rtp-jitter-buffer-and-packet-loss-logging-rtp-and-mpeg-ts
This will at least log useful info about packet loss, and might help resolve some issues.
Richard
Richard,
Thanks for the reply.
I’m running Version 3 of the server (3.0.4 build 1127).
When you say it is the default, do you mean the forceInterleaved field is true? What does the forceInterleaved config option do?
I’m sending the MPEG-TS directly over UDP to the server ok, and I have not set the forceInterleaved in the config.
I also have the server looking for the stream when it starts up. I have modified the StartupStreams.xml and am not sure what I should put for the MediaCasterType. I don’t see a list of available types in the manual, so I have left it as rtp. It does stream ok (except for when the timecode errors occur).
Chris