Previously, we returned any error code except AVERROR_EOF to the
caller - only if AVERROR_EOF or 0 was returned, we proceeded to
the next segment.
With some setups of web servers, using Connection: close in https
and GnuTLS, we don't get a clean error code at the end of segments.
In those cases, just proceed to the next segment.
Tested-by: Antti Seppälä <a.seppala@gmail.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids reading any old data in the AVIOContext buffer after
the seek, and indicates to the mpegts demuxer that we've seeked,
avoiding continuity check errors.
Signed-off-by: Martin Storsjö <martin@martin.st>
Enhance seeking by demuxing until the requested timestamp is
reached within the segment selected by the seek code using the
playlist info.
Some mpegts streams don't have dts set for all packets though,
this seeking method doesn't work well for that case.
Signed-off-by: Martin Storsjö <martin@martin.st>
When this demuxer was created, there didn't seem to be any
consensus of a common short name for this protocol. Now
the consensus seems to be to call it hls.
Signed-off-by: Martin Storsjö <martin@martin.st>
Enhances seeking by demuxing until the requested timestamp is reached within
the segment selected by the seek code using the playlist info.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
According to draft-pantos-http-live-streaming-07, 6.3.4,
the duration of the last media segment in the playlist
should be used as initial minimum reload delay.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids a segfault if the probe function wasn't able to
determine the format.
The bug was found by Panagiotis H.M. Issaris.
Signed-off-by: Martin Storsjö <martin@martin.st>
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 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.
Manual replacements are done in this commit.
In many cases, the id is some constant made up number (e.g. 0 for video
and 1 for audio), which is then not used in the demuxer for anything.
Those ids are removed.
Adding _POSIX_C_SOURCE to CPPFLAGS globally produces all sorts of problems
since it causes certain system functions to be hidden on some (BSD) systems.
The solution is to only add the flag on systems that really require it, i.e.
glibc-based ones.
This change makes BSD systems compile out-of-the-box without the need for
adding specific flags manually. It also allows dropping a number of flags
set manually on a file-per-file basis, but were only present to work around
breakage introduced by the presence of _POSIX_C_SOURCE.
Also add _XOPEN_SOURCE to CPPFLAGS for glibc systems. We use XSI extensions
in several places already, so it is preferable to define it globally instead
of littering source files with individual #defines only needed for glibc.
If there are no variants, the total bitrate of the single
stream isn't known, and exporting variant_bitrate = 0 does
look weird, since there really aren't any variants.
Signed-off-by: Martin Storsjö <martin@martin.st>
This should hopefully fix roundup issue 2586.
This commit only implements it in the demuxer, not in the
protocol handler. If desired, some of the code could be
refactored to be shared by both implementations.
Signed-off-by: Martin Storsjö <martin@martin.st>
Make AVIO_FLAG_ access constants work as flags, and in particular fix
the behavior of functions (such as avio_check()) which expect them to
be flags rather than modes.
This breaks API.
This code could be executed if the demuxer reads more than one
segment before returning from av_open_input_stream.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids issues where EOF at the end of the segment is given
the variant demuxer. Now the demuxers only see one single data
stream (as when using the applehttp protocol handler).
A similar variable for the total stream duration was changed to
int64_t in b79c3df088, due to overflows in some odd
streams.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Michael Niedermayer
Diego Biurrun
Martin Storsjö
Lou Logan
Stefano Sabatini
Mans Rullgard
Panagiotis H.M. Issaris
Alex Converse
Anton Khirnov
Andrey Utkin
Clément Bœsch
Luca Barbato
Stefano Sabatini