As far as I can tell the code should not change behaviour
depending on locale in any of these places.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
As the name indicates we can't just assume what the
"opaque" field contains.
This fixes a crash in third-party applications see e.g.:
http://bugzilla.mplayerhq.hu/show_bug.cgi?id=2126
This fixes also FFmpeg trac #2293, which is a different
third-party application.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Without the information, application may choose audio from one variant
and video from another variant, which leads to fetch two variants from
network. This enables av_find_best_stream() to find matching audio and
video streams, so that only one variant is fetched from network.
Signed-off-by: LYF <yefei.li@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Some HLS servers return 403 when the Range header is present. Disabling http
seekability probing prevents the header from being added.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
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.