This reverts commit 9f9ed79d4c.
The hlsopts member was never set anywhere and always NULL, furthermore
the HLS demuxer needs to retrieve the proper options from the underlying
http protocol (cookies, user-agent, etc), so a dummy context won't help.
Instead, use the AVIOContext directly to access the options.
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
This also deprecates our old duplicated callbacks.
* commit '9f61abc8111c7c43f49ca012e957a108b9cc7610':
lavf: allow custom IO for all files
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This can cause problems with urls that have arguments after the filename
This reverts commit b0c57206d5.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Possibly the check as a whole causes more problems than it helps, if so dont
hesitate to remove it
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some (de)muxers open additional files beyond the main IO context.
Currently, they call avio_open() directly, which prevents the caller
from using custom IO for such streams.
This commit adds callbacks to AVFormatContext that default to
avio_open2()/avio_close(), but can be overridden by the caller. All
muxers and demuxers using AVIO are switched to using those callbacks
instead of calling avio_open()/avio_close() directly.
(de)muxers that use the URLProtocol layer directly instead of AVIO
remain unconverted for now. This should be fixed in later commits.
Without EXT-X-MAP support we miss the first bytes of some streams.
These streams worked by luck before byte-ranged segment support was added in
da7759b357
Fixes ticket #4797.
Commit ad701326b4 ("avformat/hls: open playlists immediately when
AVDISCARD_ALL is dropped") inadvertently caused first_packet to never be
cleared, causing select_cur_seq_no() to not use the specific code for
live streams.
In practice this means that when the user selects a different audio
track during live stream (i.e. non-VOD) playback, there may be some
additional delay as the code might select an incorrect segment at first,
and we have to wait for video to catch audio (if too late segment was
selected) or to download more following audio segments (if too early
segment was selected).
Fix that by restoring the zeroing of first_packet.
This will give incorrect results in some cases due to not parsing segments
separately, so it currently requires -strict experimental.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If there is no #EXT-X-BYTERANGE specified, there is no need to seek.
Seeking fails anyway for rtmp, because this protocol does not support
url_seek.
This fixes CNN.m3u from trac ticket 4797 (i.e. Debian bug #798189).
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Broken by commit ba12ba859a. This only
happens with HLS streams which use encryption and require preserving
cookies sent by the server.
Fixes trac issue #4846.
Comment was previously slightly incorrect.
Also, it was placed in the wrong location.
Signed-off-by: Ganesh Ajjanagadde <gajjanagadde@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit '0c73a5a53cc97f4291bbe9e1e68226edf6161744':
hls: Save and forward avio options
Conflicts:
libavformat/hls.c
Merged-by: Michael Niedermayer <michael@niedermayer.cc>
Apparently, some live streams can delete segments too early, maybe
because the client is too far behind. In this case, it's better to skip
the segment, instead of returning EOF. (Yes, the HLS demuxer actually
returns AVERROR_EOF if opening the segment returns a 404 HTTP error.)
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
SAMPLE-AES encryption is not commonly used yet, but without this patch
ffmpeg is thinking that the hls segments are not encrypted which
produces broken files.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Not allocating the pls->ctx will crash in libavformat/hls.c:1410, where
it tries to dereference the field.
Sample: http://ec24.rtp.pt/liverepeater/rtpn.smil/playlist.m3u8
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
