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.
The Makito encoder sets stream type 0x11 for AAC.
This patch should be reverted if it breaks decoding valid streams (and
the problem can't be fixed in the probe function).
Fixes trac issue #343.
Carl Eugen Hoyos actually made a patch first, but I missed it because
trac does not send notification emails when an attachment is added.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Also extend the functionality to use the last found program to start the search
after that program.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Unlike other containers RealMedia stores its audio packets in scrambled form,
with interleaver ID preceeding audio codec ID. Currently deinterleaving
decision is tied to the codec while it's possible to have non-default
deinterleaver with audio codec (like Int0 deinterleaver instead of specific
one for Sipro).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
The new function provides a more generic interface than av_fifo_peek()
for peeking at a FIFO buffer data.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
this fixes accuracy with normal ogg files while keeping support for ogg files
starting at times different from 0
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This fixes the situation when there are not enough entries in the index
(e.g. on initial seek there's only one index entry in the index) and index
search returns just the last known entry. That causes seeking function just to
seek there instead of trying harder to get at the requested position.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Currently for multichannel audio position for the last block position is
stored in index (and used for seeking), which is obviously not correct.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>