[FFmpeg-devel] [patch] error codes for http/tcp
Fri Jul 27 00:20:13 CEST 2007
Ronald S. Bultje wrote:
> On 7/26/07, The Wanderer <inverseparadox at comcast.net> wrote:
>> ffserver.c: In function 'parse_ffconfig':
>> ffserver.c:3836: error: too few arguments to function 'resolve_host'
>> ffserver.c:3854: error: too few arguments to function 'resolve_host'
>> ffserver.c:4295: error: too few arguments to function 'resolve_host'
>> ffserver.c:4306: error: too few arguments to function 'resolve_host'
>> ffserver.c:4346: error: too few arguments to function 'resolve_host'
> ffplay.c/ffmpeg.c don't have references to this function, so it
> should be. Don't know why I don't see this. Anyway, final (hopefully)
> patch attached, thanks for testing!
I forget - were you one of the few people with a vaguely legitimate
reason for not using the correct MIME type for attached patches?
> +#ifdef HAVE_GETHOSTBYNAME_R
> + struct hostent hp_imp;
> + char buf;
> + if (gethostbyname_r(name, &hp_imp, buf, sizeof(buf), &hp, h_errnop))
Looks like you based this off of the old version of the patch.
Correcting that to "hostname" lets it build.
Having built, it appears to work. I'm having trouble finding a
known-good HTTP stream to test with, made harder because my ffplay does
not appear to produce audio at the moment (probably a transitory issue),
but both the system-installed and the patched versions of ffplay produce
a video window with the one stream I've managed to track down so far -
which unfortunately displays only black even when played in MPlayer, so
it's hard to be sure that it's really working correctly.
On the invalid-streams side, it does fail (rather than hanging there, as
with most of the supposedly-genuine streams I've tried) if I pass it
http://192.168.1.3/ (which is my own machine's local address). However,
just to be complete, I decided to try something not even an address,
http://fnord/ - and the installed copy failed cleanly but the patched
copy segfaulted. ffplay_g does not appear to contain line-number
information, but here's a backtrace anyway.
#0 0x080c5d86 in resolve_host (sin_addr=0xb712d36c, hostname=0xb712cee8
"fnord", h_errnop=0xb712d384) at os_support.c:75
#1 0x080c4f87 in tcp_open (h=0x8672ca0, uri=0xb712d8bc
"tcp://fnord:80", flags=2) at tcp.c:58
#2 0x0806f2ca in url_open (puc=0xb712ecc0, filename=0xb712d8bc
"tcp://fnord:80", flags=2) at avio.c:87
#3 0x080c3a2c in http_open_cnx (h=0x86739f0) at http.c:93
#4 0x080c4241 in http_open (h=0x86739f0, uri=0xb71b6740
"http://fnord/", flags=0) at http.c:131
#5 0x0806f2ca in url_open (puc=0xb712edd8, filename=0xb71b6740
"http://fnord/", flags=0) at avio.c:87
#6 0x0806fcb3 in url_fopen (s=0xb712f224, filename=0xb71b6740
"http://fnord/", flags=0) at aviobuf.c:547
#7 0x0806dd91 in av_open_input_file (ic_ptr=0xb712f384,
filename=0xb71b6740 "http://fnord/", fmt=<value optimized out>,
buf_size=0, ap=0xb712f304) at utils.c:435
#8 0x08063322 in decode_thread (arg=0xb7130020) at ffplay.c:1891
#9 0xb7e2a1fb in ?? () from /usr/lib/libSDL-1.2.so.0
#10 0xb7130020 in ?? ()
#11 0x08063260 in ?? () at ffplay.c:1833
#12 0x08674da0 in ?? ()
#13 0xb7e8183c in ?? () from /usr/lib/libSDL-1.2.so.0
#14 0x00000000 in ?? ()
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
More information about the ffmpeg-devel