[Ffmpeg-devel] HTTP probing issue... [PATCH]

Ryan Martell rdm4
Wed Feb 21 04:02:06 CET 2007


On Feb 20, 2007, at 7:39 PM, Michael Niedermayer wrote:

> Hi
>
> On Tue, Feb 20, 2007 at 04:32:39PM -0600, Ryan Martell wrote:
>>
>> On Feb 20, 2007, at 3:52 PM, Klaas-Pieter Vlieg wrote:
>>
>>>> From: Ryan Martell [mailto:rdm4 at martellventures.com]
>>>> Sent: 20 February 2007 22:27
>>>>
>>>>> Try this: add a sleep(1); at line 99 in http.c Works for me.
>>>>
>>>> Not sure if I'm following it.  It does the open fine (which
>>>> is where line 99 is in http.c).  My problem is that when it's
>>>> trying to read
>>>> the probe size in libavformat/utils.c, it's not hitting EOF.
>>>> Instead, it's just waiting for more data (after it's read
>>>> everything....)
>>>>
>>> Yes, I had exactly the same problem.
>>> And sorry, the sleep(1) is at line 100, right after http_connect()
>>
>> Hmm...
>>
>> Well, I'll try that too.  But this definitely fixes the problem, and
>> in a good way (I think).
>>
>> Patch will cause http_read to respect the file size if it came down
>> in the header, and only read up to that number of bytes.  If the
>> Content-Length or Content-Range was not set, this does nothing.
>
> rejected, no fix will be accpted until the problem is understood  
> especially
> not one depending on a optional header
>
> i suggest you try a binary search in svn versions to find out when  
> this
> broke, i think someone said it worked in the past, id also take a
> carefull look at os_support.* and related changes

Well, I can try and look for it some more. While trying to figure out  
what had happened I was looking over everything, but nothing jumped  
out at me.  And unfortunately while merging this in I lost my ffmeg  
revision number, so I don' t have a good place to start looking.

os_support doesn't seem to have anything that would address that; I'm  
running on MacOSX, so essentially a *nix build.

Either way, I think the patch is useful.  It allows for returning  
immediately rather than doing any timeout or network calls if it  
knows the length of the file in advance, and it allows for asking for  
the exact length at the end of the file.  If it knows nothing, it  
does nothing, so there shouldn't be any side effects.  And it doesn't  
do anything that's based on weird thread sychronicity issues like  
sleep().

-R




More information about the ffmpeg-devel mailing list