This commit does for AVInputFormat what commit
59c9dc82f4 did for AVOutputFormat:
It adds a new type FFInputFormat, moves all the internals
of AVInputFormat to it and adds a now reduced AVInputFormat
as first member.
This does not affect/improve extensibility of both public
or private fields for demuxers (it is still a mess due to lavd).
This is possible since 50f34172e0
(which removed the last usage of an internal field of AVInputFormat
in fftools).
(Hint: tools/probetest.c accesses the internals of FFInputFormat
as well, but given that it is a testing tool this is not considered
a problem.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Most users of ffio_init_context() simply want to wrap
a buffer into an AVIOContext; they do not provide
function pointers at all.
Therefore this commit adds shortcuts for these two common
operations. This also allows to accept const data when reading
(i.e. the const is now cast away at a central place in
ffio_init_read_context() instead of at several callers).
This also allows to constify the data in ff_text_init_buf().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by allocating AVStream together with the data that is
currently in AVStreamInternal; or rather: Put AVStream at the
beginning of a new structure called FFStream (which encompasses
more than just the internal fields and is a proper context in its own
right, hence the name) and remove AVStreamInternal altogether.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently AVIOContext's private fields are all over AVIOContext.
This commit moves them into a new structure in avio_internal.h instead.
Said structure contains the public AVIOContext as its first element
in order to avoid having to allocate a separate AVIOContextInternal
which is costly for those use cases where one just wants to access
an already existing buffer via the AVIOContext-API.
For these cases ffio_init_context() can't fail and always returned zero,
which was typically not checked. Therefore it has been made to not
return anything.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Fixes two warnings:
libavformat/rtpdec.c:155:20: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
libavformat/rtpdec.c:168:20: warning: return discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
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.
* commit 'b72b212a4c43563f1b9fc3ce9a5ff91f89b857ac':
rdt: Use a separate variable to clarify the different value namespaces
Conflicts:
libavformat/rdt.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The original flags variable contains rtpdec flags, while the
rmflags variable contains RM flag bits which have a completely
different definition.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit '078d43e23a7a3d64aafee8a58b380d3e139b3020':
rtpdec: Free depacketizers if the init function failed
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'bb4a310bb85f43e62240145a656b1e5285b14239':
rtpdec: Don't free the payload context in the .free function
Conflicts:
libavformat/rtpdec_latm.c
libavformat/rtpdec_mpeg4.c
libavformat/rtpdec_mpegts.c
libavformat/rtpdec_xiph.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '78791c086bcaf9eb084c27555b31fea8bbb7624a':
rtpdec: Use .init instead of .alloc to set default values
Conflicts:
libavformat/rdt.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Many of these functions were named foo_free_context, and since
the functions no longer should free the context itself, only
allocated elements within it, the previous naming was slightly
misleading.
Signed-off-by: Martin Storsjö <martin@martin.st>
This is different from how it is handled in codecs/demuxers/muxers
though (where the close function isn't called if the open function
failed), but since the number of depacketizers that have an .init
function is quite limited, this is easy to change.
The main point is that if the init function failed, we shouldn't
try to use that depacketizer at all - this makes sure that the
parse function doesn't need to check for the things that were
initialized in the init function.
Signed-off-by: Martin Storsjö <martin@martin.st>
This makes it more consistent with depacketizers that don't have any
.free function at all, where the payload context is freed by the
surrounding framework. Always free the context in the surrounding
framework, having the individual depacketizers only free any data
they've specifically allocated themselves.
This is similar to how this works for demuxer/muxers/codecs - a
component shouldn't free the priv_data that the framework has
allocated for it.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'feeafb4adabd5c17de1738ed9962e40892b20edb':
lavf: do not export av_register_{rtp,rdt}_dynamic_payload_handlers from shared objects
Merged-by: Michael Niedermayer <michaelni@gmx.at>
When av_reallocp fails, the associated variables that keep track of
the number of elements in the array (and in some cases, the
separate number of allocated elements) need to be reset.
Not all of these might technically be needed, but it's better to
reset them if in doubt, to make sure variables don't end up
conflicting.
Signed-off-by: Martin Storsjö <martin@martin.st>
* commit 'e926b5ceb1962833f0c884a328382bc2eca67aff':
avformat: Drop unnecessary ff_ name prefixes from static functions
Conflicts:
libavformat/audiointerleave.c
libavformat/mux.c
libavformat/mxfenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '90c784cc13f6bf21a8eb69f3b88b50c7a70f6c59':
rtpdec: Pass the sequence number to depacketizers
configure: Make avconv depend on null, anull and resample filters
Conflicts:
configure
Merged-by: Michael Niedermayer <michaelni@gmx.at>
