This is mostly useful for muxers that wrap other muxers, such as dashenc
and segment. The actual duplicated bitstream filtering is largely harmless,
but delaying the header can cause problems when the muxer intended the header
to be written to a separate file.
This will be used to allow writing file sequences using the tee output onto
multiple places in parallel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This fixes part of Ticket5676
This fixes kodi, mpv, chromium and ffplay build against 3.0 and linked to 3.1
This is a similar ABI fix to 1eb43af1a0
Approved-by: BBB
Approved-by: jamrial
Approved-by: BtbN
Approved-by: nevcairiel
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
* commit 'e1eb0fc960163402bbb4e630185790488f7d28ed':
movenc: Use packets in interleaving queues for the duration at the end of fragments
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
Missing docs found by: nevcairiel
RFC: should we add support so that the C field names always work as av option names/keys ?
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
As long as caller only writes packets using av_interleaved_write_frame
with no manual flushing, this should allow us to always have accurate
durations at the end of fragments, since there should be at least
one queued packet in each stream (except for the stream where the
current packet is being written, but if the muxer itself does the
cutting of fragments, it also has info about the next packet for that
stream).
Signed-off-by: Martin Storsjö <martin@martin.st>
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.
For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.
From Libav commit 05f66706d1.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Until now, the decoding API was restricted to outputting 0 or 1 frames
per input packet. It also enforces a somewhat rigid dataflow in general.
This new API seeks to relax these restrictions by decoupling input and
output. Instead of doing a single call on each decode step, which may
consume the packet and may produce output, the new API requires the user
to send input first, and then ask for output.
For now, there are no codecs supporting this API. The API can work with
codecs using the old API, and most code added here is to make them
interoperate. The reverse is not possible, although for audio it might.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '7fbb3b5b9857276b4cd17b2a530c7e0880d2bc0a':
lavf: use the io_open callbacks for files opened from open_input() as well
Merged-by: Derek Buitenhuis <derek.buitenhuis@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>
Note to maintainers: update tools
Note to maintainers: set a default whitelist for your protocol
If that makes no sense then consider to set "none" and thus require the user to specify a white-list
for sub-protocols to be opened
Note, testing and checking for missing changes is needed
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
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.
This solves the problem discussed in https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
by allowing AVCodec::write_header to be delayed until after packets have been
run through required bitstream filters in order to generate global extradata.
It also provides a mechanism by which a muxer can add a bitstream filter to a
stream automatically, rather than prompting the user to do so.
* commit '21ab6fd01b9107d7171fc1a77c2bfacff845a97a':
lavf: document that passing valid timestamps to muxers is now mandatory
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
All encoders set pts and dts properly now (and have been doing that for
a while), so there is no good reason to do any timestamp guessing in the
muxer.
The newly added AVStreamInternal will be later used for storing all the
private fields currently living in AVStream.
* commit '34ed5c2e4d9b7fe5c9b3aae2da5599fabb95c02e':
avformat: Do not use AVFMT_RAWPICTURE
Removal from ffmpeg.c not merged because some parts of avdevice
still use it
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
Move field to internal part of AVStream and struct to internal.h
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Also fix typo found by Lou Logan:
Sacrifying -> Sacrificing
Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
During remuxing avcodec_copy_context() is discouraged as certain fields
(such as codec_tag) could reflect invalid values between input and
output contextes.
This comment can be traced back to the initial commit from 2001,
and it seemed to be misleading/incorect already back then. (It
was used for normal, non-raw file formats already then.)
Signed-off-by: Martin Storsjö <martin@martin.st>
This is the same logic as is invoked on AVFMT_TS_NEGATIVE,
but which can be enabled manually, or can be enabled
in muxers which only need it in certain conditions.
Also allow using the same mechanism to force streams to start
at 0.
Signed-off-by: Martin Storsjö <martin@martin.st>
This allows restricting demuxers to a list of needed ones for improved security
Note, some demuxers themselfs open other demuxers, these are only restricted if
AVOptions are forwarded to them. Please check that your code does that.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b15b06ebf582ae81e47d236524c9ad6e10c8a0a7':
avformat: use const char* instead of uint8_t* for AVProbeData.mime_type
Conflicts:
libavformat/format.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This makes the field consistent with AVInputFormat.mime_type and the
argument type of av_match_name.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Consider a file created with something like:
cat file1.mp3 file2.mp3 > result.mp3
Then if file2.mp3 has gapless information, result.mp3 would stop playing
something in the middle. This happens because the gapless info directs
the decoder to discard all samples after a certain position. To make
matters worse, the gapless info of file2.mp3 will be used when playing
the file1.mp3 part, because the gapless info is located at the end of
the file.
While handling concatenated gapless files correctly would be insane and
a lot of effort (especially without scanning the whole file on opening),
it's easy to prevent at least early EOF. Playback will happen to work,
even if it's slightly broken.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
The code already had skipping of initial padding, but discarding
trailing frame padding was missing.
This is somewhat questionable, because it will make the decoder discard
any data after the declared file size in the LAME header. But note that
skipping full frames at the end of the stream is required. Encoders
actually create such files.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'b263f8ffe7599d9cd27ec477a12700da8eb2790d':
lavf: add AVFormatContext.max_ts_probe
Conflicts:
doc/APIchanges
libavformat/avformat.h
libavformat/utils.c
libavformat/version.h
lavf-fate/mp3 changes as the estimated input bitrate changes and that is
copied to the output
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'afbd4b7e093adf6d7a830b32759ca3ba8500363d':
lavf: add AVFormatContext/AVStream fields for signaling to the user when events happen.
Conflicts:
libavformat/avformat.h
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The only flags, for now, indicate if metadata was updated and are set after each call to
av_read_frame(). This comes with the caveat that, on stream start, it might not be set properly
as packets might be buffered in AVFormatContext.packet_buffer before being given to the user
in av_read_frame().
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '3a19405d574a467c68b48e4b824c76617fd59de0':
avformat: Use the mime type information in input probe
Conflicts:
libavformat/format.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7215fcf84032118ecd9fb54fb14154d69fea638d':
avformat: Mark AVOutputFormat argument in avformat_query_codec as const
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'ec4f04da1a3462dac429b9d15dee5f027309da15':
avformat: Mark argument in av_{i|o}format_next/ffurl_protocol_next as const
Conflicts:
libavformat/format.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The AVStream.parser field is considered private and its location cannot be
preserved while preserving also ABI compatibility to libav, as libav added fields
before it.
Some tools like ffmpeg.c access this field though
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '194be1f43ea391eb986732707435176e579265aa':
lavf: switch to AVStream.time_base as the hint for the muxer timebase
Conflicts:
doc/APIchanges
libavformat/filmstripenc.c
libavformat/movenc.c
libavformat/mxfenc.c
libavformat/oggenc.c
libavformat/swf.h
libavformat/version.h
tests/ref/lavf/mkv
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Previously, AVStream.codec.time_base was used for that purpose, which
was quite confusing for the callers. This change also opens the path for
removing AVStream.codec.
The change in the lavf-mkv test is due to the native timebase (1/1000)
being used instead of the default one (1/90000), so the packets are now
sent to the crc muxer in the same order in which they are demuxed
(previously some of them got reordered because of inexact timestamp
conversion).
* commit '6d212599aa684f30511fb08ca30fe2378405304e':
avformat: Provide a standard compliance flag
Conflicts:
doc/APIchanges
libavformat/avformat.h
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Currently probesize is cliped at 1mb before being used for format detection.
Alternatively this cliping could be removed but this would then tie various
things like stream analysis to the file detection.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'a312f71090ee620ee252f2034aef6b13e2dafe9c':
lavf: deprecate now unused AVStream.pts
Conflicts:
libavformat/mux.c
libavformat/version.h
mostly not merged as the code is needed for a/vsync drop handling
and what the code does is what is needed, it could maybe be moved
elsewhere or factored somehow but simply removing it would be droping
these features.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Use it instead of checking CODEC_FLAG_BITEXACT in the first stream's
codec context.
Using codec options inside lavf is fragile and can easily break when the
muxing codec context is not the encoding context.
* commit 'a738540366c9b114949b7914c0d08e2c28982cfb':
lavf: properly document the distinction between flags and ctx_flags
Merged-by: Michael Niedermayer <michaelni@gmx.at>
After this commit applications needs to call av_format_inject_global_side_data()
or handle AVStream side data by some other means if they want it not to be lost.
This fixes a API incompatibility with libav.
libav API does not allow the data to be passed through AVPackets
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Provides API to query device capabilities.
Each device must implement callbacks to benefit from this API.
Signed-off-by: Lukasz Marek <lukasz.m.luki@gmail.com>
Use const pointers to AVPacket and AVStream.
Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '25b32586566f285d797737863c97a1c5c9c84e2b':
lavf: add an AVStream field for exporting stream-global side data
Conflicts:
libavformat/utils.c
libavformat/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
For muxing, it accepts
both 0 and AV_NOPTS_VALUE. For demuxing, it will present
AV_NOPTS_VALUE when start_time_realtime is unknown.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '4d7ab5cfebef91820af2933ef2f622ea598e6b53':
doxygen: Add a number of missing function parameter descriptions
Conflicts:
libavformat/avformat.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '394fb56c29eee7f4f8f0334d8b5d30d3c54ac703':
lavf: always unref the packet passed to av_interleaved_write_frame() on error
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '54f7e79d4706a8343dad1d8da51b7d3d3b2cd3b2':
lavf: add some basic documentation of the muxing process
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Currently ff_interleave_packet_per_dts() waits until it gets a frame for
each stream before outputting packets in interleaved order.
Sparse streams (i.e. streams with much fewer packets than the other
streams, like subtitles or audio with DTX) tend to add up latency and in
specific cases end up allocating a large amount of memory.
Emit the top packet from the packet_buffer if it has a time delta
larger than a specified threshold.
Original report of the issue and initial proposed solution by
mus.svz@gmail.com.
Bug-id: 31
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '8b64c2ba0382892cad9e1a5ba601696d4cbb4d04':
lavc: add a dummy field to AVStream to preserve ABI compatibility for avconv
Merged-by: Michael Niedermayer <michaelni@gmx.at>
avconv abuses the API by accessing AVStream.parser (which is private).
Removing AVStream.reference_dts in
2ba68dd044 breaks ABI compatibility for an
old avconv using a newer lavf. Fix this by adding a dummy field until
the next bump.
previously only codec_ids could be forced, which did not allow
forcing a specific implementation like libopenjpeg vs jpeg2000.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '596e5d4783ca951258a7c580951fd161f1785ec1':
lavf: Add a flag to enable/disable per-packet flushing
Conflicts:
libavformat/avformat.h
libavformat/mux.c
libavformat/version.h
This adds a 2nd API to set per packet flushing
If the user application indicates through either a non default then this non default takes
precedence over the other still default value
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This is enabled by default and can be disabled with
"-fflags -flush_packets".
Inspired by a patch from Nicolas George <nicolas.george@normalesup.org>.
Signed-off-by: Martin Storsjö <martin@martin.st>
* qatar/master:
matroskaenc: Allow chapters to be written in trailer
Conflicts:
libavformat/matroskaenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This allows creation of frame accurate chapter marks from sources like
DVD and BD where the precise chapter location is not known until the
chapter mark has been reached during reading.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
* commit '64af59bc4916fac5578b31c89da13c30b591bddf':
avformat: Fix references to removed av_close_input_file in Doxygen
Merged-by: Michael Niedermayer <michaelni@gmx.at>
avconv uses private and internal fields from libavformat, we thus must
match the layout even of the fields marked non public.
Otherwise ffmpegs libavformat could not be used as a dropin replacement
on debian/ubuntu
The current soname of libavformat was not part of any release nor are any
fields marked public moved thus in theory
no installed shared lib ABI breakage should occur. Still the need for this
change is unfortunate and chilling.
If you installed shared libs from a recent development version of libavformat
that is more recent than the last release. You probably want to check or rebuild
applications that linked to it.
minor versions of avformat & avdevice are bumped to allow detecting this
as both use the updated struct
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
There are 4 separate WebVTT text track kinds: subtitles (the default
if not otherwise specified), captions, descriptions, and metadata.
The WebM muxer needs to know which WebVTT text track kind this is, in
order to synthesize the correct track type and codec id.
To allow a demuxer to indicate the text track kind of the input, a new
set of AV_DISPOSITION flag values has been added, corresponding to
each of the non-default text track kind values.
* commit 'c2cb01d418dd18e1cf997c038d37378d773121be':
lavf: introduce AVFMT_TS_NEGATIVE
Conflicts:
libavformat/avformat.h
libavformat/mux.c
tests/ref/lavf/asf
tests/ref/lavf/mkv
tests/ref/lavf/mpg
tests/ref/lavf/ts
tests/ref/seek/lavf-asf
tests/ref/seek/lavf-mkv
tests/ref/seek/lavf-mpg
tests/ref/seek/lavf-ts
This commit does not change the default ts behaviour, such
change will, if its done, be done separately.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Most formats do not support negative timestamps, shift them to avoid
unexpected behaviour and a number of bad crashes.
CC:libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Clément Bœsch