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

Luca Abeni lucabe72
Mon Oct 22 09:07:12 CEST 2007

Hi Ronald,

Ronald S. Bultje wrote:
> Hi Luca,
> On 10/18/07, Luca Abeni <lucabe72 at email.it> wrote:
>> I confirm that ffplay from svn can play rtsp:// URLs again (--disable-ipv4
>> is
>> still needed, but that's another patch).
>> I am noticing a regression when receiving MP2 audio, but this is unrelated
>> (I
>> am currently investigating the problem).
> ffserver is fine, I can receive udp and tcp with vlc.
Ok, good to know.

> ffplay only works with tcp. No idea why.
I guess this is a MaxOS related bug, because I do not see it on linux.
I'll redo some tests after lunch, to be 101% sure...

> On udp, everything I try (mpeg1video, mp2, mpeg with both
> encapsulated) hangs in av_read_packet() inside av_try_read_frame() called by
> av_find_stream_info()., both with and without --disable-ipv6.
I guess you applied the patch that originated this thread, right?
Without such patch, ffserver does not work for me, unless I use "--disable-ipv6".

> Data transfer per se shoult not be the problem, clearly, since vlc + ffserver
> works in all cases.
It would be interesting to see a dump of the network packets (with wireshark
or tcpdump), just to be 100% sure about what's going on.

> However, the select() in rtsp.c:udp_read_packet() always returns 0
> (timeout), or hangs if I remove the timeout as a test.  This leads to an
> infinite loop / hang of ffplay.
Assuming that the UDP traffic is correctly arriving, this seems to indicate
a problem with the bind(). But I am just guessing, since I do not know MacOS.

> local_port is set correctly to 5000/5002 in
> udp.c and ffserver writes to it (and again, since vlc succeeds, I assume it
> does so correctly).
Does vlc use the same ports for the RTP streams?

> Not really sure what's wrong at this point... Here's
> another interesting thing: as soon as I add a printf() after the sendto() in
> udp.c:udp_write(), it all works correctly.
This returns to point to a problem in ffserver, or in the RTP muxer, or in the
UDP send code... I am confused :(

If you want to investigate the problem, I suggest to start with a simpler testcase:
just try to stream with ffmpeg, by using
ffmpeg -re -i file.mpg -vcodec copy -an -f rtp rtp:// -vn -acodec copy -f rtp rtp:// -newaudio

ffmpeg will start streaming the audio and video contained in file.mpg, and will
print an SDP that you can use for receiving the streams - just copy it in
"test.sdp", and start "vlc test.sdp".
After that, you can try receiving with ffplay - but you will need the
"is_multicast" (net-3.diff, if I correctly remember the name) patch I posted some
days ago.


More information about the ffmpeg-devel mailing list