Current muxers only use a single bitstream filter, so there is no need to
maintain code which operates on a list of bitstream filters. When multiple
bitstream filters are needed muxers can simply use a list bitstream filter.
If there is a use case in the future when different bitstream filters should be
added at subsequent packets then a new API possibly involving reconfiguring the
list bitstream filter can be added knowing the exact requirements.
Signed-off-by: Marton Balint <cus@passwd.hu>
ff_alloc_extradata() already sets the size of the extradata so doing it
again is unnecessary.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Gyan Doshi <ffmpeg@gyani.pro>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
avformat/movenc still relies on AVCodecContext time_base to mux tmcd
tracks and segment muxer did not copy that field to inner streams
leading to SIGFPE in the child muxer instance.
At present, if the outer stream extradata is empty but first packet
has extradata as a side data element, then only the first segment's
muxer instance may be able to extract this side data and use it.
For all other segments, extradata in packet side data could be missing
and generated segments may be invalid or unplayable in some apps
e.g. for an ADTS AAC stream segmented to MP4, the adtstoasc BSF will
add extradata to the first packet. The MOV muxer for the first segment
will add this to codecpar for the inner stream and write
Decoder Specific Information within the esds box. For other segments,
their esds' will not have this decSpecificInfo and they can't be opened
in Quicktime player or by services like nginx-vod-module.
Not starting a new segment if the elapsed microsecs since the start of the day
equals the the elapsed microsecs since the start of the day at the time of the
last cut seems plain wrong to me, Deti do you remember the original reason
behind this check?
Signed-off-by: Marton Balint <cus@passwd.hu>
This happens because segment_end() returns an error, so seg_write_packet
never proceeds to segment_start(), and seg->avf->pb is never re-set,
so we crash with a null pb when av_write_trailer flushes the packet
queue.
This doesn't seem to be clearly recoverable, so I'm just failing more
gracefully.
Repro:
ffmpeg -i input.ts -f segment -c copy -segment_list /noaxx.m3u8 test-%05d.ts
(assuming you don't have write access to /)
ffmpeg have a generic solution working with all muxer named
output_ts_offset, output_ts_offset will instead of initial_offset
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
because the BSF logic was re-factored into a shareable
function and both av_write_frame and av_interleaved_write_frame use it it
Signed-off-by: LiuQi <liuqi@gosun.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For example you can split a file, keeping a continuous timecode between
each segment:
ffmpeg -i src.mov -timecode 10:00:00:00 -vcodec copy -f segment \
-segment_time 2 -reset_timestamps 1 -increment_tc 1 target_%03d.mov
Signed-off-by: Stefano Sabatini <stefasab@gmail.com>
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 option can force the segmenter to only start a new segment if a packet
reaches the muxer within the specified duration after the segmenting clock
time, which makes it more resilient to backward local time jumps, such as leap
seconds or transition to standard time from daylight savings time.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
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.
