This reduces problems when underlying protocol is not
seekable even if marked as such or if the file has been
cut short.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The code path using for mpegts over rtp doesn't open the demuxer using
mpegts_read_header,
so it never starts listening for PAT/SDT, only uses auto_guess
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This changes so we assume EOF when we can't find the next
streams index entry for non interleaved file.
http://trac.xbmc.org/ticket/5585
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This uses the RIFF header stored size to figure out the expected AVI file size, instead
of the actual file. To work fully it requires handling failed avio_seek() instead
of assuming they always succeed.
Some fate file has been cut off and contains half a frame at the end which previously
was not output during demuxing. This frame is now output to encoder, thus fate
diff update.
It can take a long time before subtitles or data streams show up,
so we shouldn't wait for those before assuming we have all info
for streams.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
If there is only 1 stream in an flv avformat_find_stream_info will continually
read until probesize is reached. This should stop it reading if the metadata
also claims there to be 1 stream.
Fixes MSVR-11-0088.
Credit: Jeong Wook Oh of Microsoft and Microsoft Vulnerability Research (MSVR)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Martin Storsjö <martin@martin.st>
Fixes MSVR-11-0088
Credit: Jeong Wook Oh of Microsoft and Microsoft Vulnerability Research (MSVR)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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>
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.
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.
Joakim Plate
Laurent Aimar
Georgi Chorbadzhiyski
Aviad Rozenhek
Michael Niedermayer
chinshou
Wolfram Gloger
Chiranjeevi Melam
Gavin Kinsey
Yan Jing
Diego Biurrun
Carl Eugen Hoyos
zhentan feng
Asad Mehmood
Kieran Kunhya
Anton Khirnov
Joseph Wecker
Stefan Fritsch
Luca Barbato
Tomas Härdin
Clément Bœsch