[FFmpeg-devel] rtpdec.c: AXIS 7401 RTCP RR Keep Alive SSRC
Fri Jul 24 11:21:43 CEST 2009
On Thu, Jul 23, 2009 at 09:20:30PM +0200, Luca Abeni wrote:
> Hi Michael,
> On Thu, 2009-07-23 at 12:33 +0200, Michael Niedermayer wrote:
> > On Wed, Jul 22, 2009 at 01:35:41PM -0700, Edward Patton wrote:
> > > Hi
> > >
> > > I made this change to prevent the AXIS 7401 video server from timing out when sending H264 RTP streamed video. It appears the AXIS ignores the clients SSRC when it is the same as the servers SSRC.
> > Then the server is buggy, the same value is amongth the random ones as well
> > unless the RFC explicitly requires them to be distinct.
> I think the bugs are shared between ffmpeg and AXIS... RFC 3550 says:
> "This identifier SHOULD be chosen randomly, with the intent that no two
> synchronization sources within the same RTP session will have the same
> SSRC identifier. An example algorithm for generating a random
> identifier is presented in Appendix A.6. Although the probability of
> multiple sources choosing the same identifier is low, all RTP
> implementations must be prepared to detect and resolve collisions."
> So, yes, the AXIS server should detect the duplicated SSRC and resolve
> the collision, but libavformat should do the same... Moreover, SSRC
> should be generated "with the intent that no two synchronization sources
> within the same RTP session will have the same SSRC identifier"... We
> are actually doing the exact opposite, by ensuring that the client's
> SSRC is the same as the server one :)
> Maybe we could use "s->ssrc + 1" for the client's SSRC, so that we are
> sure that the collision with the server's SSRC is avoided?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel