Hi,
I have been reliably streaming from IP cameras using the default AVSyncMethod - RTCP senderreport. I recently have come across a set of devices that fail to stream with this setting, but they do stream when I change to systemclock.
What is the impact of using systemclock versus senderreport? For example, does it use more system resources, is it likely that other devices will fail to stream, etc?
Thanks,
Dan
Hi Dan,
When you come across a device that fails with the senderreport method, do you get an error like this:
comment server WARN 200 - Waiting for RTCP packet. See docs for (Application.xml: RTP/AVSyncMethod and RTP/MaxRTCPWaitTime).
This means:
Sender Report (SR) packets, which are sent over the Real-time Control Protocol (RTCP) channel, didn’t arrive within the timeout period specifed by the RTP/MaxRTCPWaitTime property in [install-dir]/conf/[application-name]/Application.xml. SR packets provide timing information between the audio and video in the incoming RTP stream. If the Wowza media server doesn’t detect SR packets for the incoming RTP stream, it writes this message to the log file and tries to use RTP timecode values in the RTP packets to synchronize the audio and video channels.
You can extend the amount of time that the server waits to receive SR packets by changing the RTP/MaxRTCPWaitTime property in [install-dir]/conf/[application-name]/Application.xml or you can change the default method by which the Wowza media server synchronizes the audio and video by changing the RTP/AVSyncMethod property in [install-dir]/conf/[application-name]/Application.xml from the default value (senderreport) to either rtptimecode or systemclock. If set to rtptimecode, the Wowza media server synchronizes the audio and video channels based on RTP timecodes in the RTP packets (as previously mentioned). If set to systemclock, the Wowza media server synchronizes the audio and video channels based on the system time that the first audio and video packets arrive at the media server, assuming that they arrive at the same time.
Please also see this guide for more info and possible alternative solution:
How to dynamically update RTP/AVSyncMethod when re-streaming IP camera streams
I hope this helps answer your question.
Kind regards,
Salvadore
Hi,
Yes, I received the timeout. This particular device didn’t work with senderreport or rtptimecode, the only way I could view the stream is with systemclock.
Is there any system or stream impact to using systemclock? Essentially, what are the potential downsides or gotchas to using systemclock versus the default (senderreport) or the fallback (rtptimecode) since neither of those worked for this particular camera.
Thanks,
Dan
What is the downside to using systemclock? Presumably there is a reason it’s not the default.
There is not usually an advantage of one over the other, except that one will work and the others won’t for a stream.
There should be no difference in resource usage, (unnoticeable if at all)
Regards,
Salvadore