These streams are reported as seekable, but all tests show they are not,
and the server merely pretends the streams are seekable. The server
responds with:
content-range: bytes 0-1999999999/2000000000
Range requests seem to be correctly answered, but the actual data
returned at the same offset is different. Assume this is a bug in the
server software. The server identifies itself as:
Server: MediaGateway 3.5.2-001
Add a hack that checks the server name, and disables seeking in this
case.
Test URL: http://8283.live.streamtheworld.com:80/CBC_R1_VCR_H_SC
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The intent of the original check was to increase has_b_frames when
it was incorrectly set to 0. Later codecs allowed larger values
Found-by: divVerent
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
It is my understanding that "Unless otherwise stated, all data in a
QuickTime movie is stored in big-endian byte ordering" [1] in MOV files.
I have a couple of thousand files, which technically are invalid because
their sound sample description element 4CC is 'lpcm' but its version is
0 - and "Version 0 supports only uncompressed audio in raw ('raw ') or
twos-complement ('twos') format" [2]
Because isom.c only contains a mapping for 4CC 'lpcm' to
AV_CODEC_ID_PCM_S16LE, these files have their audio decoded as LE when
it is actually BE.
This commit adds AV_CODEC_ID_PCM_S16BE as the first match for 4CC 'lpcm'.
[1]
https://developer.apple.com/library/mac/documentation/quicktime/QTFF/qtff.pdf
page 21
[2]
https://developer.apple.com/library/mac/documentation/quicktime/QTFF/qtff.pdf
page 178
Reviewed-by: Yusuke Nakamura <muken.the.vfrmaniac@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
This simplifies proper error handling in rtsp.c/rtspdec.c. When
broadcasting over RTSP in TCP mode, the AVIOContext is closed and
recreated for each sent packet, and if the recreation fails, we might
try to close a NULL buffer when freeing things at the end.
Previously, if recreating the buffer in rtspdec.c failed, this would
crash later due to trying to close a NULL buffer.
Signed-off-by: Martin Storsjö <martin@martin.st>
This was added in 9b07a2dc02 as an ABI hack to allow older
code built with lavf 52 to register protocols even if the size
of the URLProtocol struct was increased. Later, registering
protocols from outside of lavf was removed and this workaround
isn't needed any longer since lavf 53.
This removes an unchecked malloc and a memory leak for the cases
when this workaround actually was used - which it hasn't since
lavf 53.
Signed-off-by: Martin Storsjö <martin@martin.st>
Also typedef the private data struct and make its name consistent with
the rest of Libav.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Return value of avpriv_aac_parse_header() is not checked correctly. Fix
it.
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
avconv abuses the API by accessing AVStream.parser (which is private).
Removing AVStream.reference_dts in
2ba68dd044 breaks ABI compatibility for an
old avconv using a newer lavf. Fix this by adding a dummy field until
the next bump.