[FFmpeg-devel] [patch] error codes for http/tcp

[The Wanderer]

Ronald S. Bultje wrote:

> Hi,
> 
> 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?

<snip>

> +#ifdef HAVE_GETHOSTBYNAME_R
> +        struct hostent hp_imp;
> +        char buf[1024];
> +        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 ?? ()
==

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.