[FFmpeg-devel] [PATCH] Make rtpenc.c SSRC randomly set
Wed Jul 9 08:27:13 CEST 2008
On Wed, Jul 09, 2008 at 08:14:09AM +0200, Luca Abeni wrote:
> Hi Stefano,
> Stefano Sabatini wrote:
> > Hi all,
> > RFC 3550 (RTP) states:
> > | SSRC: 32 bits
> > | The SSRC field identifies the synchronization source. 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.
> > Currently rtpenc.c uses always a value of 0.
> Note that random() used to be used here, but has been removed:
> I am not sure what the correct solution would be (and I have to admit that
> I am not a fan of the "random() vs no random()" discussions... I just tend
> to trust other people about this kind of issues), but if someone finds a
> solution on which everyone agree I'll be happy to ack it.
> (In any case, AFAIK this is not causing any real issue... So, even if we
> are not fully compliant with the RFC there are no practical problems.)
the crc of the first frame or extradata or ... will do very well as random
number if one thinks theres any sense in this ...
also reading from /dev/(u)random is an option [it wont work on all OSs but
a failure wont be worse than always using 0]
* random() cannot be called in a lib for various reasons
* av_random(X) is no better than X, i really dislike the kind of
thinking that a bad choice of X would somehow be less bad once its
pulled through a function the author doesnt underdstand.
* X (or av_random(X)) leaks X to the outside, we do not want PIDs or
some pointer values to leak ...
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel