When merging the formats around the automatically inserted
convert filters, the refcount of the format lists can not be 0.
Coverity does not detect it, and suspects a memory leak,
because if refcount is 0 the newly allocated lists are not
stored anywhere. That gives CIDs 1224282, 1224283 and 1224284.
Lists with refcount 0 are used in can_merge_formats(), so the
asserts can not be moved inside the merge functions.
Define positive return values as non errors and leave further meaning undefined
This allows future extensions to use these values
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '77cc958f60f73963be4281d6e82ef81707e40c26':
lavfi: add const to the AVFilter parameter of avfilter_graph_create_filter()
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '7950e519bb094897f957b9a9531cc60ba46cbc91':
Disable deprecation warnings for cases where a replacement is available
Conflicts:
libavcodec/avpacket.c
libavcodec/pthread.c
libavcodec/utils.c
libavdevice/v4l2.c
libavfilter/avfiltergraph.c
libavfilter/buffersrc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This prevents the unneeded insertion of multiple aresample filters in some cases
The format merging is moved to avoid having to call the channel layout
merge twice. The channel layout merge code uses different structures and
is not compatible with the added dry run wrappers.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Prior to this it was possible that format reduction was ended
before it fully propagated leading to failure later in picking
formats.
No testcase with unmodified source exists, the case was reproduced
with less aggressive list merging though.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
query_formats() returning EAGAIN is not considered a progress
in the format negotiation.
If the filter returns EAGAIN but did set some of its formats
lists, it could be considered a partial success and counted
as progress in the negotiation. Not counting it is not a
problem because it currently only happens in the first round,
where there will always be some progress on the other filters.
* commit '48a5adab62bd2a553f5069d41fa632a0701835e5':
lavfi: add avfilter_init_str() to replace avfilter_init_filter().
avfilter_graph_create_filter() opaque is still passed to avfilter_init_filter()
which continues to pass it to init_opaque as its still used in the buffer sinks
the sinks should be changed and the opaque passing removed
Merged-by: Michael Niedermayer <michaelni@gmx.at>
* commit '1565cbc65cbb9f95c11367314a080068895e0cf0':
lavfi: make avfilter_free() remove the filter from its graph.
Conflicts:
libavfilter/avfilter.c
libavfilter/avfiltergraph.c
libavfilter/graphparser.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Since this function adds a standalone filter to a filter graph and we do
not support creating such filters, there is no reason for this function
to exist.
Since we do not support "standalone" filters not attached to an
AVFilterGraph, we should not have a public function to create such
filters. In addition that function is horribly named, the action it does
cannot be possibly described as "opening" a filter.
* qatar/master:
avfiltergraph: check for sws opts being non-NULL before using them.
Conflicts:
libavfilter/avfiltergraph.c
libavfilter/graphparser.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>
