[FFmpeg-devel] [PATCH/RFC] sdp/udp: Refactoring of code, don't require a ?multicast option

Martin Storsjö martin
Thu Oct 7 10:01:33 CEST 2010


On Thu, 7 Oct 2010, Luca Abeni wrote:

> On 10/07/2010 09:29 AM, Martin Storsj? wrote:
> > On Thu, 7 Oct 2010, Luca Abeni wrote:
> > 
> > > On 10/05/2010 03:37 PM, Martin Storsj? wrote:
> > > [...]
> > > > And a question more precisely to Luca A: The solution in patch #3 isn't
> > > > all that pretty, but to be able to make it prettier, sdp_get_address and
> > > > resolve_destination would have to be merged. Would you be ok with that?
> > > 
> > > After thinking a little bit about it, my preference would be to
> > > have resolve_destination() returning an is_multicast value, and to do
> > > 	if (!is_multicast) {
> > > 	  ttl = 0;
> > > 	}
> > > after calling it. Then, the change to sdp_get_address() looks ok
> > > (or, you can remove the "else *ttl=5" if you like).
> > 
> > So, like this then? Ok to apply this?
> 
> I suspect resolve_destination() will give a compilation warning if
> CONFIG_NETWORK is not defined... ;-)

Ah, good point.

> Apart from that, I am ok with patch 0003, and I think it can be
> applied as soon as is_multicast_address() is available to sdp.c
> (BTW, I think it should be ff_is_multicast_address()?).

Yes, good point, added the ff prefix. As long as it is static inline, the
symbol name won't be leaked anywhere, but since it may be moved to another 
.c file later, the ff prefix makes sense.

> I suspect patches 0001 and 0002 need approval from other people,
> but I am ok with those patches (modulo the ff_ prefix mentioned
> above).

Patch 0002 was ok'd by Ronald and Luca B on irc yesterday.

Thus, applied all of this.

// Martin



More information about the ffmpeg-devel mailing list