[FFmpeg-devel] [PATCH] Make RTP work with IPv6 enabled

Luca Abeni lucabe72
Tue Oct 16 10:05:18 CEST 2007

Hi Ronald,

On Tue, 2007-10-16 at 00:50 -0400, Ronald S. Bultje wrote:
> ffplay hangs on reading
> the input, vlc works fine though (suggesting that ffserver isn't a problem
> here). This is after the bind/url_split patches have been applied, compiled
> for ipv6, but I've also tried with and without those patches in ipv4-mode,
> and I still see the same problem. ffplay always hangs here on reading udp
> input from rtsp streams. This is on MacOSX 10.4.
Ok, this is a difference in our testing setups (I am on Linux. Tested on
Debian Sarge and Ubuntu <something>). As far as I can see, this is the
only difference, so I guess the problem has to be OS related. Maybe our
UDP code has some problem on MacOSX?

BTW, I think ffserver has never been tested on MacOSX... I do not know
if it has ever worked on such platform.

> If I
> configure rtsp.c (with rtsp_default_protocols) to default to TCP instead of
> UDP, it works. Do I have to do something special to get it to stream over
> udp, or set up ffserver in a different way?
No, I do not think so... I always use an unpatched libavformat (and I
configured vlc to select RTP over UDP as a first option), and it works.
At this point I am just guessing, because I do not know MacOSX... Does
it provide some firewall mechanism which is enabled by default? (I am
asking because I know that windows firewall creates a lot of problems
for UDP streaming...).

If a firewall is not the problem, I suspect you need to get a dump of
the traffic with tcpdump or wireshark, to check if the UDP streams are
actually sent or not. If something like "strace" works on MacOSX, you
can try to strace ffserver, to see what actually happens (in particular,
if the "sendto()" are actually performed, if the destination address is
correct, and if they fail).


More information about the ffmpeg-devel mailing list