Opened 14 years ago

Last modified 10 years ago

#503 new defect

mplayer gets confused when playing avi from web and getting the whole file in response to a "Range" request.

Reported by: mplayer@… Owned by: reimar
Priority: normal Component: demuxer
Version: 1.0pre7 Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:


It I have an .avi file on a (slightly weird, but AFAIU not completely
non-conformant) web server that:

  • Would advertize "Accept-Ranges: bytes" in its HTTP response header.
  • Does not actually support it and would send the whole file in response to a

"Range: ..." HTTP request
then mplayer gets confused when being pointer to that .avi URL.

Namely, it would loop, sending repeated HTTP requests with various "junk" (even
negative at times) "Range: ..." headers.

P.S. Once the server is fixed to send "Accept-Ranges: none", the problem goes away.

P.P.S. The server that send the wrong "Accept-Ranges:" header is gallery2
(, I've filed an RFE to fix it at

Attachments (1)

gallery.log (18.7 KB) - added by mplayer@… 14 years ago.
Output of "mplayer -v -v -v URL.avi"

Download all attachments as: .zip

Change History (5)

Changed 14 years ago by mplayer@…

Output of "mplayer -v -v -v URL.avi"

comment:1 Changed 14 years ago by mplayer@…

comment:2 Changed 14 years ago by reimar

AFAIK this is not fixable, since IIRC when MPlayer sees accept-ranges it tries
to read the index at the end of the file to allow seeking - which obviously
cannot work in such a case (or does the server indicate that it starts sending
data from the beginning? Then a minor improvement might be possible).
You could also try the -noidx switch, maybe it helps.

comment:3 Changed 14 years ago by mplayer@…

(In reply to comment #2)

or does the server indicate that it starts sending data from the beginning?

It definitely does. When it sends the requested partial data,

  • The HTTP status code is 206 (Partial Content) - see

  • The HTTP response header includes the Content-Range field thast specifies

what exactly was returned (according to the specs, this field MUST be present in
any "206" response). This is the header that tells what was actually sent, so it
would be nice if mplayer paid attention to it. See

When the server sends the complete file,

  • The HTTP status code would be the usual 200 (OK) instead of 206
  • There would be no Content-Range header.

comment:4 Changed 10 years ago by compn

  • Owner changed from r_togni@… to reimar
Note: See TracTickets for help on using tickets.