[FFmpeg-devel] [patch] error codes for http/tcp
Fri Jul 27 13:11:55 CEST 2007
Ronald S. Bultje wrote:
> 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.
With gmail, there may not be a way, aside from complaining to Google.
>> 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),
> you can use some of the gstreamer samples as http streams, e.g.
Not the most ideal of samples, given the "not producing audio" bit, but
that appears to have been more transitory than I thought. It doesn't
exactly play fine, but it does play the first second or so before
falling foul of apparent buffering issues, so whatever problems there
are will not be in the code you've changed.
>> 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
> 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?
Confirmed, both with the previous patch and with your latest one.
As far as I can tell, the latest version of the patch seems OK.
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