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

Baptiste Coudurier baptiste.coudurier
Thu Mar 1 17:43:43 CET 2007

Michael Niedermayer wrote:
> Hi
> On Tue, Feb 27, 2007 at 07:27:01PM +0100, Baptiste Coudurier wrote:
>> Hi
>> Ryan Martell wrote:
>>> On Feb 20, 2007, at 9:02 PM, Ryan Martell wrote:
>>>> On Feb 20, 2007, at 7:39 PM, Michael Niedermayer wrote:
>>>>> On Tue, Feb 20, 2007 at 04:32:39PM -0600, Ryan Martell wrote:
>>>>>> 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().
>>> I narrowed the problem down.  If you change HTTP/1.1 back to HTTP/1.0
>>> (as it was before Ronald's patch) it works just fine.  However, this
>>> will make the Range: be in non-compliance, and break the HTTP seeking.
>>> From HTTP/1.1:
>>> Content-Length:
>>>  Applications SHOULD use this field to indicate the transfer-length of
>>> the message-body, unless this is prohibited by the rules in section 4.4.
>>> Any Content-Length greater than or equal to zero is a valid value.
>>> Section 4.4 describes how to determine the length of a message-body if a
>>> Content-Length is not given.
>>> From section 4.4:
>>> For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
>>> containing a message-body MUST include a valid Content-Length header
>>> field unless the server is known to be HTTP/1.1 compliant. If a request
>>> contains a message-body and a Content-Length is not given, the server
>>> SHOULD respond with 400 (bad request) if it cannot determine the length
>>> of the message, or with 411 (length required) if it wishes to insist on
>>> receiving a valid Content-Length.
>>> All HTTP/1.1 applications that receive entities MUST accept the
>>> "chunked" transfer-coding (section 3.6), thus allowing this mechanism to
>>> be used for messages when the message length cannot be determined in
>>> advance.
>>> Messages MUST NOT include both a Content-Length header field and a
>>> non-identity transfer-coding. If the message does include a non-
>>> identity transfer-coding, the Content-Length MUST be ignored.
>>> When a Content-Length is given in a message where a message-body is
>>> allowed, its field value MUST exactly match the number of OCTETs in the
>>> message-body. HTTP/1.1 user agents MUST notify the user when an invalid
>>> length is received and detected.
>>> As my patch stands, it checks if Content-Length has been defined, and if
>>> so, uses it.
>>> So, what do you want me to do?
>> Ok, I dig svn and found out something. See patch attached.
>> Basically http_seek returns -1 (like file_seek), and then url_fseek will
>> return -1 instead of EPIPE, and that will make probing fail:
>> if (url_fseek(pb, 0, SEEK_SET) == (offset_t)AVERROR(EPIPE)) {
>>     url_fclose(pb);
>>     if (url_fopen(pb, filename, URL_RDONLY) < 0) {
>> Should probe check for negative ret, or url_fseek should return EPIPE ?
>> I reestablished EPIPE ret.
> probe of course should check for <0 as it doesnt matter at all why seek
> failed

Ok, done, issue should be fixed.

Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312

More information about the ffmpeg-devel mailing list