[FFmpeg-devel] [patch] error codes for http/tcp
Ronald S. Bultje
Fri Jul 27 00:47:57 CEST 2007
thanks for testing again.
On 7/26/07, The Wanderer <inverseparadox at comcast.net> wrote:
> I forget - were you one of the few people with a vaguely legitimate
> reason for not using the correct MIME type for attached patches?
I don't know, something with gmail and firefox or so. Probably not
legitimate, just don't know how to fix it.
> +#ifdef HAVE_GETHOSTBYNAME_R
> > + struct hostent hp_imp;
> > + char buf;
> > + if (gethostbyname_r(name, &hp_imp, buf, sizeof(buf), &hp,
> Looks like you based this off of the old version of the patch.
> Correcting that to "hostname" lets it build.
Oh right, fixed that.
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.
you can use some of the gstreamer samples as http streams, e.g.
> 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
Hm, that's not supposed to happen according to the manpage. Anyway, easily
worked around, patched version should fix this. Just to make sure, can you
confirm that there are no compiler warnings when compiling os_support.c?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7158 bytes
Desc: not available
More information about the ffmpeg-devel