The initial request contains "Range: 0-", which servers normally
have responded with "HTTP/1.1 206 Partial Content" reply with
a Content-Range header, which was used as indicator for seekability.
Apache, since 2.2.20, responds with "HTTP/1.1 200 OK" for these
requests, which is more friendly to caches and proxies, but the
seekability still is indicated via the Accept-Ranges: bytes header.
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
AVOptions: fix av_set_string3() doxy to match reality.
cmdutils: get rid of dummy contexts for examining AVOptions.
lavf,lavc,sws: add {avcodec,avformat,sws}_get_class() functions.
AVOptions: add AV_OPT_SEARCH_FAKE_OBJ flag for av_opt_find().
cpu detection: avoid a signed overflow
Conflicts:
avconv.c
cmdutils.c
doc/APIchanges
ffmpeg.c
libavcodec/options.c
libavcodec/version.h
libavformat/version.h
libavutil/avutil.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
currently libavformat only allows seeking if a request with "Range:
0-" results in a 206 reply from the HTTP server which includes a
Content-Range header. But according to RFC 2616, the server may also
reply with a normal 200 reply (which is more efficient for a request
for the whole file). In fact Apache HTTPD 2.2.20 has changed the
behaviour in this way and it looks like this change will be kept in
future versions. The fix for libavformat is easy: Also look at the
Accept-Ranges header.
Transforms the loose enumeration of issues that was to far below
in the text into a more verbose paragraph at the top. The new text
also mentions the possibility to propose new types of issues to
track on the development mailing list.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
This change makes the first part of the file easier to read quickly.
It makes it also easier to spot the URLs which might be one of the main
interests of many readers.
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Correct a few grammar and spelling errors. Also improve consistency
by always referring to substatus (not substate).
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
This is the same code as for x86_64.
This is necessary because uname returns PPC64 if the hardware
is 64 bit, however the userland can still be fully 32 bit.
In that case FFmpeg fails to compile because some macros in the
asm code are set up incorrectly.
For details see https://bugs.gentoo.org/show_bug.cgi?id=341235
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Reset it when we actually process an EOI, not when we actually
decide to ignore it for bug-workarounds, and reset it on
SOF to make it more reliable in case of missing EOI.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
* qatar/master:
avconv: fix some bugs introduced in 630902a1e1
libmp3lame: fix typo
AVOptions: drop av_ prefix from static av_get_number().
libx264: use X264_THREADS_AUTO constant instead of 0.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
If st is NULL, it means no 'fmt ' tag is found, but 'data' tag (which
needs a previous 'fmt ' tag to be parsed correctly and st initialized)
check will make sure st is never dereferenced in that case.
These caused scrambled error messages to be printed and
floating point exceptions.
For example when there was no decoder available for a
stream.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
