[Ffmpeg-devel] Network patch for MingW users
Michael A. Kohn
mike
Sun Feb 4 14:59:48 CET 2007
>> Index: patched/libavformat/udp.c
>> ===================================================================
>> --- patched/libavformat/udp.c (revision 7813)
>> +++ patched/libavformat/udp.c (working copy)
>> @@ -352,13 +355,32 @@
>> goto fail;
>>
>> /* the bind is needed to give a port to the socket now */
>> - if (bind(udp_fd,(struct sockaddr *)&my_addr, sizeof(my_addr)) < 0)
>> - goto fail;
>> +// if (bind(udp_fd,(struct sockaddr *)&my_addr, sizeof(my_addr)) < 0)
>> +// goto fail;
>> + t=0;
>> + while(1)
>> + {
>> + if (bind(udp_fd,(struct sockaddr *)&my_addr, sizeof(my_addr)) < 0)
>> + {
>> + if (t>100) goto fail;
>> + s->local_port++;
>> + my_addr.sin_port = htons(s->local_port);
>> + }
>> + else
>> + { break; }
>>
>> + t++;
>> + }
>
> What is this good for?
>> len = sizeof(my_addr1);
>> getsockname(udp_fd, (struct sockaddr *)&my_addr1, &len);
>> s->local_port = ntohs(my_addr1.sin_port);
>>
>> +#ifdef __MINGW32__
>> + tmp=65536; /* 64k UDP buffer size. Should this be bigger? */
>> + setsockopt(udp_fd, SOL_SOCKET, SO_RCVBUF, &tmp, sizeof(tmp));
>> +#endif
>
> What is this supposed to do? 64k is the max UDP packet size, and the
> default receive buffer should be at least that big.
Btw, I didn't submit this patch, I submitted earlier patches that
I guess this patch was based on. Anyway...
That while loop around the bind() is a bad fix to the problem that
ffmpeg (at that time, not sure if anyone fixed this yet) always
bound itself to the same 2 ports, no matter if they were in use or
not. So if you started 2 or more instances of ffplay connecting to
an rtsp stream, both instances would want the same ports and one
would fail.
This affected Linux, Windows, and any other OS. I was going to work
on a fix of letting the kernel decide the ports and submit it in a
separate patch (as suggested), but I haven't had time.
As far as the UDP buffer on Windows. The buffer size on Windows
is actually 8k. Take a look:
http://support.microsoft.com/kb/214397
When I ran ffmpeg on Windows without that, I was getting all kinds of
errors. When I bumped it to 64k, it worked great. Sad.
Anyway, I was going to work on some new patches today, but I guess other
people are already working on it. If anyone wants me to work on
it again, toss me an email...
/mike
More information about the ffmpeg-devel
mailing list