Using an unsigned variable avoids problems with overflows.
There is further no need for a 64-bit intermediate here.
Signed-off-by: Mans Rullgard <mans@mansr.com>
This simplifies the decoder so it doesn't have to process an in-packet header
or handle arbitrary-sized packets. It also fixes decoding of files with large
headers.
Also reduce verbosity for the unsupported stream message, use
an AVFormatContext for av_log and and print the tag of the
unknown stream.
Improves ticket #672.
AVFMT_NOTIMESTAMPS for crc, as it ignores the timestamps.
AVFMT_VARIABLE_FPS for framecrc, as it prints dts.
Many FATE changes, because avconv is no longer duplicating frames in
those tests.
Also added -vsync 0 for some tests to prevent avconv from dropping
frames until it can be fixed more properly.
AVFMT_NOTIMESTAMPS for md5, as it ignores the timestamps.
AVFMT_VARIABLE_FPS for framemd5, as it prints dts.
-vsync 0 for the vp8 test is needed because with vsync 2 the timestamp
guessing code gets confused by an altref frame that is never displayed
and drops a frame later.
Adding the thread count in frame level multithreading to has_b_frames
as an additional delay causes more problems than it solves.
For example inconsistent behaviour during timestamp calculation in
libavformat.
Thread count and frame level multithreading are both set by the user.
If the additional delay caused by frame level multithreading needs
to be considered in the calling code it has all information to take
it into account.
Should it become necessary to calculate a maximum delay inside
libavcodec it should be exported as its own field and not reusing
an existing field.
Based on a patch by Michael Niedermayer.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>
Some sample IFF ACBM files can be found here:
http://aminet.net/package/dev/basic/ABdemos
Thanks to Peter Ross for his help with this patch.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Note: FCPublish/FCUnpublish are adobe server specific and not described
in the rtmp specification. Some servers might not cope with them at
all.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
The Apple HTTP Live Streaming demuxer's implementation of
seeking searches for the MPEG TS segment which contains the
requested timestamp. In its current implementation it assumes
that the first segment will start from 0.
But, MPEG TS streams do not necessarily start with timestamp
(near) 0, causing seeking to fail for those streams.
This also occurs when using live streaming of HTTP Live Streams.
In this case sliding playlists may be used, which means that in
that case only the last x encoded segments are stored, the earlier
segments get deleted from disk and removed from the playlist.
Because of this, when starting playback of a stream in the middle
of such a broadcast, the initial segment fetched after parsing
the m3u8 playlist will not start from timestamp (near) 0, causing
(the admittedly limited live) seeking to fail.
This patch changes this demuxers seeking implementation to use
the initial DTS as an offset for searching the segments containing
the requested timestamp.
Signed-off-by: Martin Storsjö <martin@martin.st>
The tls protocol handles connections via proxies internally.
With TLS/SSL, the peer verification requires that the client
speaks directly with the server, since the proxy doesn't have
the remote server's private key.
Signed-off-by: Martin Storsjö <martin@martin.st>