How often does Wowza use RTCP sender report packets to synchronize audio and video RTP source streams? From my observation, only the first RTCP seems to be getting used to sync up the streams. Later reports don’t seem to have any effect.
I am using Wowza Wowza Media Server 2.2.3 build26454. AVSyncMethod is set to senderreport.
Can you also give me some details on how the rtptimecode sync mechanism works? How should the timestamps in the RTP header be encoded for this method to work?
Full problem statement:
I am streaming live content from an RTP source using Wowza. The RTP timestamps in the source audio and video drift at times causing the streams to go out of sync. To overcome this, I have set AVSyncMethod to senderreport in the rtplive app configuration file and I generate periodic RTCP SR packets to synchronize the streams. Wowza seems to be synchronizing the streams at the beginning, but it doesn’t seem to use the RTCP reports that I send later when the RTP timestamps have drifted.
I checked the logs in DEBUG mode and I find that Wowza is printing out the NTP timestamp and RTP timestamp that I send in the RTCP SR correctly.
We only synchronize on the initial SR packet that is received. We do have the ability to continue to sync on later events but this is turned off by default. The only way to turn this on is on a stream by stream basis through Java code. I could make a small change that can make this configurable.
Charlie
Let me send you a patch with the configuration first. The Java code is a bit tricky and I don’t have time to put together an example.
I am not sure why type of description you are looking for. We use the RTCP SR packets to synchronize the streams. We take the NTP value and RTP value in the SR packet to map RTP timecodes from both audio and video back to millisecond wall clock values.
Charlie
Here is the patch:
WowzaMediaServer2.2.3-patch6.zip
To turn on the option to listen to RTCP SR packets after the initial packet add the following property to the RTP/Properties in conf/[application]/Application.xml (be sure to get the correct Properties container - there are several in the Application.xml file):
<Property>
<Name>rtpResyncAudioVideoOnSR</Name>
<Value>true</Value>
<Type>Boolean</Type>
</Property>
The other AVSync values work as follows:
senderreport: Synchronize on RTCP SR sender reports
systemclock: Synchronizes based on the system time the first packet of audio and video hit the server (assume they are hitting simultaneously)
rtptimecode: Assume the RTP timecode values in the RTP packets are synchronized. So based on the sample frequency communicated in the SDP data use simple math to convert to millisecond timecode values:
timecode = ([rtp-timecode] * 1000) / [sample-frequency]
Charlie
Thanks for the kind words. Very happy it is working for you.
Charlie
I’m not sure, but instead of DEBUG logging try adding this Property to the Application.xml /Properties container:
<Property>
<Name>debugRTSPSession</Name>
<Value>true</Value>
<Type>Boolean</Type>
</Property>
Richard
Is there a log message that will fire when the resync occurs? If not, could there be if I enable DEBUG logging?
Thank you for the quick response.
Making it configurable will be very useful. Can you point me to the API call that I should use to set this behaviour?
I have the option of rewriting the RTP timestamps too. How does the rtptimecode synchronization mechanism work?
I was looking for information on the “rtptimecode” configuration value for the AVSyncMethod property. I assume that configuration works without relying on RTCP and expects the RTP timestamps to be encoded in a certain way. Anyway, if you are sending me a patch to solve the problem with RTCP SR, I don’t have to explore that configuration.
Thank you again for the timely responses.
Charlie,
Thank you for the patch and the clarification on the rtptimecode configuration.
I tested the new rtpResyncAudioVideoOnSR configuration and it works as specified. RTP SR packets sent later in the stream are able to synchronize audio and video now.
Your customer support is out of this world.