[FFmpeg-devel] Correctly fill the SSRC field in RTP packets
Tue Mar 25 16:55:13 CET 2008
Reimar D?ffinger wrote:
> On Tue, Mar 25, 2008 at 03:18:35PM +0100, Luca Abeni wrote:
>> Reimar D?ffinger wrote:
>>>> I think this would require some kind of "global context" (shared
>>>> between all the AVFormatContexts) for the counter, right? Wouldn't
>>>> this break multithreaded applications?
>>> I think it might be better to have a kind of "muxer user data" field in
>>> AVFormatContext and use that to set all this kind of stuff, or at least
>>> something like that...
>> In this way, a user would have to fill the field with a proper value,
>> right? I do not like this idea too much, because I believe a user does
>> not want to cope with the details of SSRC and similar stuff, but the
>> library should select a reasonable value.
> That is assuming the library _can_ select a reasonable value.
Well, almost all the RTP libraries I know can select an SSRC. And most
of the time they select a reasonable one ;-)
I think the point is to select SSRCs so that the probability of duplication
is low. With the current code, such probability is 1...
>> My patch does not ensure uniqueness either, but it ensures that the SSRC
>> is unique inside a session (which is the reasonable thing to guarantee,
>> in my opinion).
> Actually, on 64 bit systems even your patch does not ensure this.
You are right; on 64bit systems there is a (small, I believe) probability
to have duplicate SSRCs in a session.
But in my opinion this probability is small enough to make my patch reasonable
In theory an RTP library should be able to detect SSRC collisions, and to
generate a new SSRC when they happen... But since the RTP muxer is not
receiving RTCP packets, it cannot detect such collisions.
> Note also, that doing this assignment in the rtp muxer will cause quite
> some pain if someone wants to e.g. combine a premuxed rtp stream sent
> directly with one created on-the-fly with the rtpmuxer (assuming this is
> possible, I don't really know that...).
I think the only problem here is to avoid SSRC collisions, as in all the
Anyway, I understand your concerns about the patch, and I'll not commit it.
More information about the ffmpeg-devel