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

Baptiste Coudurier baptiste.coudurier
Tue Feb 27 19:27:01 CET 2007


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.

Patch also fix "still http issue with ffm/ffmpeg/ffserver"

I tested quickly using
ffplay http://samples.mplayerhq.hu/A-codecs/WMA2/theweekend.wmv for http
seeking.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312
-------------- next part --------------
A non-text attachment was scrubbed...
Name: seek.patch
Type: text/x-diff
Size: 814 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070227/f9bf1d64/attachment.patch>



More information about the ffmpeg-devel mailing list